Craignewkirk · June 29, 2018 16:39 · Jun 2, 2018 · Jun 2, 2018 · Jun 2, 2018 · Jun 2, 2018
diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -2,7 +2,7 @@
 ### For Web Client /Front End Projects
 ##### (That Probably Use HTML, CSS, and JS)
 
-I made a list of 20 things I might want out of a monorepo tool to use as a basis for comparing some of the options including [Lerna](https://lernajs.io/), [Northbrook](https://github.com/northbrookjs/northbrook), and [Rush](https://aka.ms/rush).
+I made a list of 20 things I might want out of a monorepo tool for a Design System to use as a basis for comparing some of the options including [Lerna](https://lernajs.io/), [Northbrook](https://github.com/northbrookjs/northbrook), and [Rush](https://aka.ms/rush).
 
 :warning: Northbrook's author says the [project is pretty dead and now uses Lerna](https://twitter.com/TylorS167/status/880763832695746560).
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -1,5 +1,6 @@
 # Mono Repository Tool Comparison
-### For Web Front End Projects
+### For Web Client /Front End Projects
+##### (That Probably Use HTML, CSS, and JS)
 
 I made a list of 20 things I might want out of a monorepo tool to use as a basis for comparing some of the options including [Lerna](https://lernajs.io/), [Northbrook](https://github.com/northbrookjs/northbrook), and [Rush](https://aka.ms/rush).
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -47,8 +47,9 @@ Research was done using the documentation, googling for articles, checking out i
 - ✅ Distribute one, some, or all modules
   > Has both fixed and independent options.
   > With e.g. `lerna publish` will distribute any with changes
-  > With e.g. `lerna publish --force-publish=moduleOne,moduleTwo`
+  > Kinda can with e.g. `lerna publish --force-publish=moduleOne,moduleTwo`
   > Beware issues with `--scope` and `--ignore`! See [#1055](https://github.com/lerna/lerna/issues/1055) and [#1384](https://github.com/lerna/lerna/issues/1384).
+  > Isn't actually effective, the way I mean it.
 
 - ✅ Distribute arbitrary bundles
   > With e.g. `lerna publish --force-publish=bundleOne`

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -30,7 +30,7 @@ I made a list of 20 things I might want out of a monorepo tool to use as a basis
 
 ## Tools
 
-Research was done using the documentation, googling for articles, checking out issues, and a little poking around on basic demo repos. I haven't used any of these tools extensively yet, so if you see anything I have wrong, please let me know. Tools included are Lerna, Northbrook, and Rush.
+Research was done using the documentation, googling for articles, checking out issues, and a little poking around on basic demo repos. I haven't used any of these tools extensively yet or done more than glance at their source code, so if you see anything I have wrong, please let me know. Tools included are Lerna, Northbrook, and Rush.
 
 ### Lerna
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -313,4 +313,4 @@ At first, I thought I'd end up favoring Rush because of how well their doc expla
 
 Finally, here's a presentation I gave on how I'm using Lerna monorepos for Design Systems.
 
-[![]()](https://docs.google.com/presentation/d/e/2PACX-1vSjH9LUuKJ0ebRdEQhKESDMyYjJEBD1ROcncRGYjMQWQvUiwzG_yzdYaeG6AbxgvhRYXBgMibCmgncS/pub)
+[![design-systems-and-monorepos](https://user-images.githubusercontent.com/1043291/40451148-7a3c78dc-5e92-11e8-8334-9247313408b0.png)](https://docs.google.com/presentation/d/e/2PACX-1vSjH9LUuKJ0ebRdEQhKESDMyYjJEBD1ROcncRGYjMQWQvUiwzG_yzdYaeG6AbxgvhRYXBgMibCmgncS/pub)
diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -310,3 +310,7 @@ At first, I thought I'd end up favoring Rush because of how well their doc expla
 - https://github.com/boennemann/alle
 - https://gist.github.com/nolanlawson/457cdb309c9ec5b39f0d420266a9faa4
 - https://github.com/boltpkg/bolt
+
+Finally, here's a presentation I gave on how I'm using Lerna monorepos for Design Systems.
+
+[![]()](https://docs.google.com/presentation/d/e/2PACX-1vSjH9LUuKJ0ebRdEQhKESDMyYjJEBD1ROcncRGYjMQWQvUiwzG_yzdYaeG6AbxgvhRYXBgMibCmgncS/pub)
diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -302,10 +302,11 @@ At first, I thought I'd end up favoring Rush because of how well their doc expla
 
 ## Related
 
-https://www.npmjs.com/package/zelda
-https://github.com/whoeverest/wsrun
-https://github.com/JamieMason/syncpack
-https://github.com/guigrpa/oao
-https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/
-https://github.com/boennemann/alle
-https://gist.github.com/nolanlawson/457cdb309c9ec5b39f0d420266a9faa4
+- https://www.npmjs.com/package/zelda
+- https://github.com/whoeverest/wsrun
+- https://github.com/JamieMason/syncpack
+- https://github.com/guigrpa/oao
+- https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/
+- https://github.com/boennemann/alle
+- https://gist.github.com/nolanlawson/457cdb309c9ec5b39f0d420266a9faa4
+- https://github.com/boltpkg/bolt
diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -299,3 +299,13 @@ Northbrook's design is really appealing to me personally, but as it is mostly an
 **Score**: 11/20
 
 At first, I thought I'd end up favoring Rush because of how well their doc explained the underlying functionality of `rush install`. But I couldn't find some relevant and clearly necessary-to-me docs about how `rush change` works; on the test repo I always got output that `No change file is needed.` Combined with a lack of findable posts from developers that becomes a bigger issue. Side-by-side with Lerna its appeal is mainly its use of safer linking and some of the more enterprise features.
+
+## Related
+
+https://www.npmjs.com/package/zelda
+https://github.com/whoeverest/wsrun
+https://github.com/JamieMason/syncpack
+https://github.com/guigrpa/oao
+https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/
+https://github.com/boennemann/alle
+https://gist.github.com/nolanlawson/457cdb309c9ec5b39f0d420266a9faa4
diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -1,5 +1,5 @@
 # Mono Repository Tool Comparison
-## For Web Front End Projects
+### For Web Front End Projects
 
 I made a list of 20 things I might want out of a monorepo tool to use as a basis for comparing some of the options including [Lerna](https://lernajs.io/), [Northbrook](https://github.com/northbrookjs/northbrook), and [Rush](https://aka.ms/rush).
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -1,4 +1,5 @@
 # Mono Repository Tool Comparison
+## For Web Front End Projects
 
 I made a list of 20 things I might want out of a monorepo tool to use as a basis for comparing some of the options including [Lerna](https://lernajs.io/), [Northbrook](https://github.com/northbrookjs/northbrook), and [Rush](https://aka.ms/rush).
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -57,12 +57,12 @@ Research was done using the documentation, googling for articles, checking out i
   > With e.g. `lerna exec --scope moduleOne,moduleTwo -- {{whatever}}` anything
 
 - ✅ "Share" dependencies across modules safely
-  > Almost with `lerna bootstrap --hoist`, except see https://github.com/lerna/lerna/issues/867.
+  > Almost with `lerna bootstrap --hoist`, except see [#867](https://github.com/lerna/lerna/issues/867).
   > Now can be assisted by Yarn Workspaces for improved sharing that is as safe as Yarn can make it.
 
 - 🔲 "Pin" common dependencies across modules
   > Can be used with NPM shrinkwrap, NPM lockfiles, or Yarn lockfiles.
-  > But see https://github.com/lerna/lerna/issues/377
+  > But see issue [#377](https://github.com/lerna/lerna/issues/377)
 
 - ✅ "Link" module-to-module dependencies safely
   > With e.g. `lerna bootstrap`

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -47,7 +47,7 @@ Research was done using the documentation, googling for articles, checking out i
   > Has both fixed and independent options.
   > With e.g. `lerna publish` will distribute any with changes
   > With e.g. `lerna publish --force-publish=moduleOne,moduleTwo`
-  > Has some issues with `--scope` and `--ignore` https://github.com/lerna/lerna/issues/1055 https://github.com/lerna/lerna/issues/1384
+  > Beware issues with `--scope` and `--ignore`! See [#1055](https://github.com/lerna/lerna/issues/1055) and [#1384](https://github.com/lerna/lerna/issues/1384).
 
 - ✅ Distribute arbitrary bundles
   > With e.g. `lerna publish --force-publish=bundleOne`

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -47,6 +47,7 @@ Research was done using the documentation, googling for articles, checking out i
   > Has both fixed and independent options.
   > With e.g. `lerna publish` will distribute any with changes
   > With e.g. `lerna publish --force-publish=moduleOne,moduleTwo`
+  > Has some issues with `--scope` and `--ignore` https://github.com/lerna/lerna/issues/1055 https://github.com/lerna/lerna/issues/1384
 
 - ✅ Distribute arbitrary bundles
   > With e.g. `lerna publish --force-publish=bundleOne`

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -111,7 +111,7 @@ Research was done using the documentation, googling for articles, checking out i
 
 #### Lerna Score
 
-**Score**: 17/20
+**Score**: 18/20
 
 Perhaps unsurprisingly, Lerna did the best at meeting the qualifications, although Northbrook has appealing simplicity and flexibility and Rush's relatively safer strategy for sharing NPM dependencies and ability to deterministically install and to pin dependencies stood out. Lerna used with Yarn and [Yarn Workspaces](https://yarnpkg.com/lang/en/docs/workspaces/) seems equal to Rush in these respects.
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -55,9 +55,9 @@ Research was done using the documentation, googling for articles, checking out i
   > With e.g. `lerna run {{whatever}}` NPM scripts run conditionally
   > With e.g. `lerna exec --scope moduleOne,moduleTwo -- {{whatever}}` anything
 
-- 🔲 "Share" dependencies across modules safely
+- ✅ "Share" dependencies across modules safely
   > Almost with `lerna bootstrap --hoist`, except see https://github.com/lerna/lerna/issues/867.
-  > Can be assisted by Yarn workspaces for improved sharing!
+  > Now can be assisted by Yarn Workspaces for improved sharing that is as safe as Yarn can make it.
 
 - 🔲 "Pin" common dependencies across modules
   > Can be used with NPM shrinkwrap, NPM lockfiles, or Yarn lockfiles.
@@ -113,7 +113,7 @@ Research was done using the documentation, googling for articles, checking out i
 
 **Score**: 17/20
 
-Perhaps unsurprisingly, Lerna did the best at meeting the qualifications, although Northbrook has appealing simplicity and flexibility and Rush's relatively safer strategy for sharing dependencies and ability to deterministically install and to pin dependencies stood out.
+Perhaps unsurprisingly, Lerna did the best at meeting the qualifications, although Northbrook has appealing simplicity and flexibility and Rush's relatively safer strategy for sharing NPM dependencies and ability to deterministically install and to pin dependencies stood out. Lerna used with Yarn and [Yarn Workspaces](https://yarnpkg.com/lang/en/docs/workspaces/) seems equal to Rush in these respects.
 
 ### Northbrook
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -56,10 +56,11 @@ Research was done using the documentation, googling for articles, checking out i
   > With e.g. `lerna exec --scope moduleOne,moduleTwo -- {{whatever}}` anything
 
 - 🔲 "Share" dependencies across modules safely
-  > Almost with `lerna bootstrap --hoist`, except see https://github.com/lerna/lerna/issues/867
+  > Almost with `lerna bootstrap --hoist`, except see https://github.com/lerna/lerna/issues/867.
+  > Can be assisted by Yarn workspaces for improved sharing!
 
 - 🔲 "Pin" common dependencies across modules
-  > Maybe able to use normal NPM install with shrinkwrap/package-lock or Yarn?
+  > Can be used with NPM shrinkwrap, NPM lockfiles, or Yarn lockfiles.
   > But see https://github.com/lerna/lerna/issues/377
 
 - ✅ "Link" module-to-module dependencies safely

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -209,7 +209,7 @@ Northbrook's design is really appealing to me personally, but as it is mostly an
 #### Rush Qualifications
 
 - 🔲 Supports both NPM and Yarn
-  > NPM only for now
+  > NPM only for now, though it's worth noting that Rush claims to be able to deterministically install NPM dependencies, which is one of Yarn's major benefits.
 
 - ✅ Build one, some, or all modules
   > User defines NPM `test` script, Rush assumes it builds and tests.

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -202,6 +202,8 @@ Perhaps unsurprisingly, Lerna did the best at meeting the qualifications, althou
 
 Northbrook's design is really appealing to me personally, but as it is mostly an orchestrator of plugins and I'd rather use Semantic Release and Commitizen directly for functionality like `nb release` and `nb commit` the appeal over Gulp is mostly in `nb exec` and `nb link`. Its relatively lower profile in the community in comparison to Lerna is also, unfortunately, persuasive. 
 
+:warning: Northbrook's author says the [project is pretty dead and now uses Lerna](https://twitter.com/TylorS167/status/880763832695746560).
+
 ### Rush
 
 #### Rush Qualifications

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -35,68 +35,68 @@ Research was done using the documentation, googling for articles, checking out i
 
 #### Lerna Qualifications
 
-- [x] Supports both NPM and Yarn
+- ✅ Supports both NPM and Yarn
 
-- [x] Build one, some, or all modules
+- ✅ Build one, some, or all modules
   > With e.g. `lerna run build` or `lerna exec --scope moduleOne -- gulp build`
 
-- [x] Test one, some, or all modules
+- ✅ Test one, some, or all modules
   > With e.g. `lerna run test` or `lerna exec --scope moduleOne -- gulp test`
 
-- [x] Distribute one, some, or all modules
+- ✅ Distribute one, some, or all modules
   > Has both fixed and independent options.
   > With e.g. `lerna publish` will distribute any with changes
   > With e.g. `lerna publish --force-publish=moduleOne,moduleTwo`
 
-- [x] Distribute arbitrary bundles
+- ✅ Distribute arbitrary bundles
   > With e.g. `lerna publish --force-publish=bundleOne`
 
-- [x] Run arbitrary commands and tasks for one, some, or all modules
+- ✅ Run arbitrary commands and tasks for one, some, or all modules
   > With e.g. `lerna run {{whatever}}` NPM scripts run conditionally
   > With e.g. `lerna exec --scope moduleOne,moduleTwo -- {{whatever}}` anything
 
-- [ ] "Share" dependencies across modules safely
+- 🔲 "Share" dependencies across modules safely
   > Almost with `lerna bootstrap --hoist`, except see https://github.com/lerna/lerna/issues/867
 
-- [ ] "Pin" common dependencies across modules
+- 🔲 "Pin" common dependencies across modules
   > Maybe able to use normal NPM install with shrinkwrap/package-lock or Yarn?
   > But see https://github.com/lerna/lerna/issues/377
 
-- [x] "Link" module-to-module dependencies safely
+- ✅ "Link" module-to-module dependencies safely
   > With e.g. `lerna bootstrap`
 
-- [x] Install unique dependencies for individual modules
+- ✅ Install unique dependencies for individual modules
   > With e.g. `lerna bootstrap`
 
-- [x] Distribute to a pre-release channel
+- ✅ Distribute to a pre-release channel
   > With e.g. `lerna publish --canary`
 
-- [x] Parallelization of tasks
+- ✅ Parallelization of tasks
   > Has relevant options including `--stream`, `--parallel`, and `--concurrency`
 
-- [x] Support changelog generation
+- ✅ Support changelog generation
   > With e.g. `lerna publish --conventional-commits` or `lerna run` or `lerna exec`
 
-- [x] Support documentation generation
+- ✅ Support documentation generation
   > With e.g. `lerna run docs` or `lerna exec -- gulp docs`
 
-- [x] Support UI style guide generation
+- ✅ Support UI style guide generation
   > With e.g. `lerna run styleguide` or `lerna exec -- gulp styleguide`
 
-- [x] Ability to use Semantic Release in distribution
+- ✅ Ability to use Semantic Release in distribution
   > https://github.com/atlassian/lerna-semantic-release
 
-- [x] Ability to use Commitizen in development
+- ✅ Ability to use Commitizen in development
   > https://github.com/atlassian/lerna-semantic-release
 
-- [ ] Ability to use Greenkeeper for dependencies
+- 🔲 Ability to use Greenkeeper for dependencies
   > Only for top level `package.json`, not individual modules.
   > But note this may more appropriately be a feature for Greenkeeper to support.
 
-- [x] Sufficiently documented
+- ✅ Sufficiently documented
   > Good documentation for getting started and a little beyond, not _great_ yet
 
-- [x] Community Activity
+- ✅ Community Activity
   > Some community posts, active on GitHub
 
 #### Lerna Notes
@@ -120,71 +120,71 @@ Perhaps unsurprisingly, Lerna did the best at meeting the qualifications, althou
 
 #### Northbrook Qualifications
 
-- [x] Supports both NPM and Yarn
+- ✅ Supports both NPM and Yarn
 
-- [x] Build one, some, or all modules
+- ✅ Build one, some, or all modules
   > With e.g. `nb --only moduleOne,moduleTwo exec -- npm run build`
 
-- [x] Test one, some, or all modules
+- ✅ Test one, some, or all modules
   > With e.g. `nb --only moduleOne,moduleTwo exec -- npm run test`
 
-- [x] Distribute one, some, or all modules
+- ✅ Distribute one, some, or all modules
   > Seems to have both fixed and independent options.
   > With e.g. `--comver` is default, independent presumably via `--semver`
   > With e.g. `nb release --only moduleOne,moduleTwo` also supports detecting changes.
 
-- [x] Distribute arbitrary bundles
+- ✅ Distribute arbitrary bundles
   > With e.g. `nb release --only=bundleOne`
 
-- [x] Run arbitrary commands and tasks for one, some, or all modules
+- ✅ Run arbitrary commands and tasks for one, some, or all modules
   > With e.g. `nb --only moduleOne,moduleTwo exec -- {{whatever}}`
 
-- [ ] "Share" dependencies across modules safely
+- 🔲 "Share" dependencies across modules safely
   > Supported with package.json in root and plugin system.
   > Result should be similar to Lerna, however.
 
-- [x] "Pin" common dependencies across modules
+- ✅ "Pin" common dependencies across modules
   > Can use normal NPM install with shrinkwrap/package-lock or Yarn.
 
-- [x] "Link" module-to-module dependencies safely
+- ✅ "Link" module-to-module dependencies safely
   > With e.g. `nb link`
 
-- [x] Install unique dependencies for individual modules
+- ✅ Install unique dependencies for individual modules
   > With e.g. `nb exec -- npm install`
 
-- [ ] Distribute to a pre-release channel
+- 🔲 Distribute to a pre-release channel
   > Possibly as arbitrary command, otherwise appears unsupported.
 
-- [ ] Parallelization of tasks
+- 🔲 Parallelization of tasks
   > Not mentioned anywhere, so appears unsupported. 
 
-- [x] Support changelog generation
+- ✅ Support changelog generation
   > Users can generate from `nb commit` format, write custom plugins, etc.
 
-- [x] Support documentation generation
+- ✅ Support documentation generation
   > With e.g. `nb exec -- npm run docs` or write a plugin.
 
-- [x] Support UI style guide generation
+- ✅ Support UI style guide generation
   > With e.g. `nb exec -- npm run styleguide` or write a plugin.
 
-- [x] Ability to use Semantic Release in distribution
+- ✅ Ability to use Semantic Release in distribution
   > Doesn't appear to be any existing integration, could write a plugin.
   > Unclear if you could replace `nb release`.
 
-- [x] Ability to use Commitizen in development
+- ✅ Ability to use Commitizen in development
   > Doesn't appear to be any existing integration, could write a plugin (or just use alongside?).
   > Unclear if you could replace `nb commit`.
   > Unclear how a non-conventional commit format would impact `nb release`.
   > But it passes because it does support plugins and by-module tasks, meaning tooling around the related areas will be easier.
 
-- [ ] Ability to use Greenkeeper for dependencies
+- 🔲 Ability to use Greenkeeper for dependencies
   > Only for top level `package.json`, not individual modules.
   > But note this may more appropriately be a feature for Greenkeeper to support.
 
-- [ ] Sufficiently documented
+- 🔲 Sufficiently documented
   > Enough documentation for basics, but not quite good yet.
 
-- [ ] Community Activity
+- 🔲 Community Activity
   > No community posts found, some activity on GitHub.
 
 #### Northbrook Notes
@@ -206,78 +206,78 @@ Northbrook's design is really appealing to me personally, but as it is mostly an
 
 #### Rush Qualifications
 
-- [ ] Supports both NPM and Yarn
+- 🔲 Supports both NPM and Yarn
   > NPM only for now
 
-- [x] Build one, some, or all modules
+- ✅ Build one, some, or all modules
   > User defines NPM `test` script, Rush assumes it builds and tests.
   > With e.g. `rush rebuild --to moduleOne --to moduleTwo`
 
-- [x] Test one, some, or all modules
+- ✅ Test one, some, or all modules
   > User defines NPM `test` script, Rush assumes it builds and tests.
   > With e.g. `rush rebuild --to moduleOne --to moduleTwo`
 
-- [x] Distribute one, some, or all modules
+- ✅ Distribute one, some, or all modules
   > Change detection based with `rush change` and `rush publish`.
   > Unclear if able to force changes.
   > Maybe always using `rush publish --include-all` could simulate fixed versioning?
 
-- [x] Distribute arbitrary bundles
+- ✅ Distribute arbitrary bundles
   > Probably, with a `bundleOne` module and above.
 
-- [ ] Run arbitrary commands and tasks for one, some, or all modules
+- 🔲 Run arbitrary commands and tasks for one, some, or all modules
   > Can still set up tooling and run commands normally, but doesn't assist with by-module tasks.
 
-- [x] "Share" dependencies across modules safely
+- ✅ "Share" dependencies across modules safely
   > Supported with implicit pinning during `rush install`.
   > Unclear if or how a root `package.json` is handled.
 
-- [x] "Pin" common dependencies across modules
+- ✅ "Pin" common dependencies across modules
   > With `rush generate` it makes installs deterministic.
   > Also has a manual pinning option.
 
-- [x] "Link" module-to-module dependencies safely
+- ✅ "Link" module-to-module dependencies safely
   > With e.g. `rush link`
 
-- [x] Install unique dependencies for individual modules
+- ✅ Install unique dependencies for individual modules
   > Happens during `rush install`.
 
-- [x] Distribute to a pre-release channel
+- ✅ Distribute to a pre-release channel
   > At minimum, can make pre-release versions with `--prerelease-name` flag.
 
-- [x] Parallelization of tasks
+- ✅ Parallelization of tasks
   > Supported and has `--parallelism` flag.
   > Also does subset builds, provides incremental through optional Gulp integration.
 
-- [x] Support changelog generation
+- ✅ Support changelog generation
   > It appears so, how is unclear; seems to have to do with `rush change`.
   > Then `rush publish` will automatically generate one according to docs.
 
-- [ ] Support documentation generation
+- 🔲 Support documentation generation
   > It appears it might have an "AEDoc" (API Extractor) integration.
   > But would have to set up custom in project root, and Rush doesn't assist with by-module tasks.
 
-- [ ] Support UI style guide generation
+- 🔲 Support UI style guide generation
   > Would have to set up custom in project root, and Rush doesn't assist with by-module tasks.
 
-- [ ] Ability to use Semantic Release in distribution
+- 🔲 Ability to use Semantic Release in distribution
   > Would have to set up custom in project root, and Rush doesn't assist with by-module tasks.
   > Also unclear if you could replace `rush publish`.
 
-- [ ] Ability to use Commitizen in development
+- 🔲 Ability to use Commitizen in development
   > Doesn't appear to be any existing integration, could just use alongside?
   > Not marking because it's unclear if it's possible to integrate with `rush publish` changelog, which would add complication since Rush doesn't assist with by-module tasks.
 
-- [ ] Ability to use Greenkeeper for dependencies
+- 🔲 Ability to use Greenkeeper for dependencies
   > Not checked because it's unclear if or how a root `package.json` is handled.
   > As with the others, can't use for individual modules.
   > But note this aspect may more appropriately be a feature for Greenkeeper to support.
 
-- [ ] Sufficiently documented
+- 🔲 Sufficiently documented
   > Okay documentation, have to fill in with CLI `-h`.
   > Missing some critical parts about `rush change`, etc.
 
-- [ ] Community Activity
+- 🔲 Community Activity
   > No community posts found, some activity on GitHub
 
 #### Rush Notes

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -206,7 +206,7 @@ Northbrook's design is really appealing to me personally, but as it is mostly an
 
 #### Rush Qualifications
 
-- [x] Supports both NPM and Yarn
+- [ ] Supports both NPM and Yarn
   > NPM only for now
 
 - [x] Build one, some, or all modules

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -206,7 +206,7 @@ Northbrook's design is really appealing to me personally, but as it is mostly an
 
 #### Rush Qualifications
 
-- [ ] Supports both NPM and Yarn
+- [x] Supports both NPM and Yarn
   > NPM only for now
 
 - [x] Build one, some, or all modules

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -116,6 +116,8 @@ Perhaps unsurprisingly, Lerna did the best at meeting the qualifications, althou
 
 ### Northbrook
 
+:warning: Northbrook's author says the [project is pretty dead and now uses Lerna](https://twitter.com/TylorS167/status/880763832695746560).
+
 #### Northbrook Qualifications
 
 - [x] Supports both NPM and Yarn

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -2,7 +2,7 @@
 
 I made a list of 20 things I might want out of a monorepo tool to use as a basis for comparing some of the options including [Lerna](https://lernajs.io/), [Northbrook](https://github.com/northbrookjs/northbrook), and [Rush](https://aka.ms/rush).
 
-:warning:
+:warning: Northbrook's author says the [project is pretty dead and now uses Lerna](https://twitter.com/TylorS167/status/880763832695746560).
 
 ## Qualifications Wanted
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -1,6 +1,8 @@
 # Mono Repository Tool Comparison
 
-I made a list of 20 things I might want out of a monorepo tool to use as a basis for comparing some of the options including Lerna, Northbrook, and Rush.
+I made a list of 20 things I might want out of a monorepo tool to use as a basis for comparing some of the options including [Lerna](https://lernajs.io/), [Northbrook](https://github.com/northbrookjs/northbrook), and [Rush](https://aka.ms/rush).
+
+:warning:
 
 ## Qualifications Wanted
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -135,10 +135,9 @@ Perhaps unsurprisingly, Lerna did the best at meeting the qualifications, althou
 - [x] Run arbitrary commands and tasks for one, some, or all modules
   > With e.g. `nb --only moduleOne,moduleTwo exec -- {{whatever}}`
 
-- [x] "Share" dependencies across modules safely
-  > Supported with `package.json` in root and plugin system.
-  > But note it doesn't seem to automatically detect shared dependencies.
-  > Would probably want to make a shortcut for initial install.
+- [ ] "Share" dependencies across modules safely
+  > Supported with package.json in root and plugin system.
+  > Result should be similar to Lerna, however.
 
 - [x] "Pin" common dependencies across modules
   > Can use normal NPM install with shrinkwrap/package-lock or Yarn.
@@ -195,7 +194,7 @@ Perhaps unsurprisingly, Lerna did the best at meeting the qualifications, althou
 
 #### Northbrook Score
 
-**Score**: 15/20
+**Score**: 14/20
 
 Northbrook's design is really appealing to me personally, but as it is mostly an orchestrator of plugins and I'd rather use Semantic Release and Commitizen directly for functionality like `nb release` and `nb commit` the appeal over Gulp is mostly in `nb exec` and `nb link`. Its relatively lower profile in the community in comparison to Lerna is also, unfortunately, persuasive. 
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -20,7 +20,7 @@ I made a list of 20 things I might want out of a monorepo tool to use as a basis
 - **Support documentation generation**: See if there's any specific features, otherwise overlaps with arbitrary commands.
 - **Support UI style guide generation**: See if there's any specific features, otherwise overlaps with arbitrary commands.
 - **Ability to use Semantic Release in distribution**: The tool's release feature may fill need, but options are good.
-- **Ability to use Commitizen in development**: The tool's release feature may fill need, but options are good.
+- **Ability to use Commitizen in development**: The tool may have a feature that fills a similar need, but options are good.
 - **Ability to use Greenkeeper for dependencies**: Support for multiple `package.json` may be more a feature for Greenkeeper, but want to make a note.
 - **Sufficiently documented**: Is there enough to get started and to go deeper as use evolves?
 - **Community Activity**: Are other developers posting about it? What's the GitHub activity like?

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -266,9 +266,9 @@ Northbrook's design is really appealing to me personally, but as it is mostly an
   > Not marking because it's unclear if it's possible to integrate with `rush publish` changelog, which would add complication since Rush doesn't assist with by-module tasks.
 
 - [ ] Ability to use Greenkeeper for dependencies
-  > Not for individual modules.
-  > Unclear if or how a root `package.json` is handled.
-  > But note this may more appropriately be a feature for Greenkeeper to support.
+  > Not checked because it's unclear if or how a root `package.json` is handled.
+  > As with the others, can't use for individual modules.
+  > But note this aspect may more appropriately be a feature for Greenkeeper to support.
 
 - [ ] Sufficiently documented
   > Okay documentation, have to fill in with CLI `-h`.
@@ -290,4 +290,4 @@ Northbrook's design is really appealing to me personally, but as it is mostly an
 
 **Score**: 11/20
 
-At first, I thought I'd end up favoring Rush because of how well their doc explained the underlying functionality of `rush install`. But I couldn't find some relevant and clearly necessary-to-me docs about how `rush change` works; on the test repo I always got output that `No change file is needed.` Combined with a lack of findable posts from developers and that becomes even more of an issue. Side-by-side with Lerna its appeal is mainly its use of safer linking and some of the more enterprise features.
+At first, I thought I'd end up favoring Rush because of how well their doc explained the underlying functionality of `rush install`. But I couldn't find some relevant and clearly necessary-to-me docs about how `rush change` works; on the test repo I always got output that `No change file is needed.` Combined with a lack of findable posts from developers that becomes a bigger issue. Side-by-side with Lerna its appeal is mainly its use of safer linking and some of the more enterprise features.
diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -206,7 +206,7 @@ Northbrook's design is really appealing to me personally, but as it is mostly an
 - [ ] Supports both NPM and Yarn
   > NPM only for now
 
-- [ ] Build one, some, or all modules
+- [x] Build one, some, or all modules
   > User defines NPM `test` script, Rush assumes it builds and tests.
   > With e.g. `rush rebuild --to moduleOne --to moduleTwo`
 

diff --git a/monorepo-tool-comparison.md b/monorepo-tool-comparison.md
@@ -206,7 +206,7 @@ Northbrook's design is really appealing to me personally, but as it is mostly an
 - [ ] Supports both NPM and Yarn
   > NPM only for now
 
-- [x] Build one, some, or all modules
+- [ ] Build one, some, or all modules
   > User defines NPM `test` script, Rush assumes it builds and tests.
   > With e.g. `rush rebuild --to moduleOne --to moduleTwo`