rfcs VS npm-workspaces-demo

npm workspaces plus Wireit works far better than Lerna, in my experience.

https://github.com/google/wireit

Wireit's ability to specify actual script dependencies, do caching (and on Github actions), and it's long-running service script support make it much more useful and comprehensive than Lerna.

I agree that this should be built into npm. There's an RRFC for it here: https://github.com/npm/rfcs/issues/706

This just got accepted as a proposal in NPM: https://github.com/npm/rfcs/pull/626

npm also plans to support pnpm-style node_modules

(I usually end up removing npm ci from CI/CD since I think it is way too slow and want to cache node_modules from previous builds; I'm waiting for https://github.com/npm/rfcs/issues/415 to land to make this fail-safe npm install --from-lockfile. Yarn does support this already)

I started following this problem from the discussion at npm about making install scripts opt-in. But install scripts are not the only threat, there are more ways for malicious actors:

What I’m proposing is specifically in cases where sub-dependencies may have a known vulnerability but that isn’t in any of the call paths of your direct dependency. It’s an alternative to the “audit assertions”[1] proposal, which I find problematic for reasons I discussed there before I bowed out. My idea is that you can be confident you’re not affected by a vulnerability in a dependency (at any depth), if that vulnerability is no longer in the code in the first place.

It also reduces the surface area to vet in the first place. It’s highly likely many dependencies will be stripped down considerably, if not outright deduplicated or eliminated. The “npm installs thousands of dependencies” thing is a real problem, but it’s also partly because it’s installing stuff you’ll never actually execute in any way.

You can pare down sub-dependencies with confidence, because you already know what code paths are hit by the parent dependency at packaging time. You can’t do that with direct dependencies until you go to package/deploy, because of course you may expand your usage of their APIs during development.

1: https://github.com/npm/rfcs/pull/422

https://github.com/npm/rfcs/issues/509

it more or less just makes it difficult for updates to propogate, which is arguably a good thing.

Even if you run npm install, only npm 7 and up support workspaces. There is no straightforward way to enforce developer npm version although it is not impossible, so you might want to document the version requirement in your root README. A developer without npm 7+ will end up with unresolved modules in their editor.

I made a GitHub repository with this example if you wanna check it in more details. Here’s the link: npm-workspaces-demo.