The caveats are interesting as I don't think I've encountered this issue with Yarn Workspaces.

In my experience yarn workspaces doesn't hoist and flatten node_modules, it tends to hoist the popular version and leaves variances next to that particular workspace e.g. library A and B rely on Typescript 1.0, but library C relies on Typescript 2.0, then Typescript 1.0 will be in root node_modules, while Typescript 2.0 will be in libraryC/node_modules.

It also lets you run `yarn workspaces focus`, so it only installs the node_modules that libraryA needs for example. So the atomic deployments caveat in the article shouldn't be an issue.

I'm surprised NPM workspaces doesn't do this.

Oh the focus is very interesting! I ditched yarn to get back to the official tool, but seems like npm does lag behind yarn and pnpm

I prefer pnpm for monorepos

1st It caches node modules making it faster and space efficient

2nd It creates a root node-modules and then a node-module for each sub package. Which makes it much easier to work with monorepo packages. With a single node-modules you can accidently import packages that your package doesn't declare in package.json

Second this.

pnpm's use of hard links is so perfect for monorepos. As far as your code knows they just have a normal, run of the mill node_modules but without the massive hit on speed and disk space.

I never got the chance to use pnpm. I try to stick to “official” tools. But it sounds interesting, so I’ll check it

I just wish it could move node modules somewhere else. The cache hits the disk so hard my PV falls over.

You don't need to "(...) have to copy the entire node_modules along (...)" when deploying, you can bundle backend code as well.

Theoretically, nothing prevents you from running `npm install` inside the specific package. Do you have any other approach?

You'll loose lockfile pinning/reproducibility if you do that.

Interesting, Would you mind elaborating a bit?

When you think about how to enforce lockfile on monorepo it comes up as one of solutions.

Many people don't realize that you can enforce only single lockfile (ie. at the root of your monorepo, any other lockfiles will be ignored).

One of colleagues proposed and implemented elegant solution based on bundling backend code - that's what ends up in container image when it's built.

It works very well for us.

You end up with minimal, tree shaked code (with mapfile of course <<which can be inlined>>) in your production containers, which resembles go-like single binary builds which are reproducible.