Workspaces are awesome, but they're inconvenient for deployment.

I presume that the intention of workspaces is that for deployment, you're supposed to push all your packages to an NPM registry, and then yarn install inside a copy of your module outside the workspace will work.

However, there are a bunch of reasons you might not want to push. If it's an open source module, then bumping the version releases the module to the wild. But often you want to test in a production staging environment before releasing the module. If it's a private module then you have to worry about authentication tokens and/or private registries.

The other issue is that there's no yarn.lock for the modules, only a single global yarn.lock.

To elaborate further, take the example from the blog post, jest. And let's assume that jest-diff is an app that can be deployed to a server.

Suppose I download jest-diff via npm pack. I can run yarn install inside of that package, but I'll be installing without the benefit of a yarn.lock, and I need to have access to jest-get-type. Easy enough since it's been published, but publishing has the drawbacks listed above.

What I'd like to be able to do, is in a fresh checkout of jest, cd packages/jest-diff, and then yarn install --vendored. This would then fully populate packages/jest-diff/node_modules. It would copy packages/jest-get-type into packages/jest-diff/node_modules/jest-get-type. It would not create a root node_modules nor a packages/jest-get-type/node_modules, although of course it would create packages/jest-diff/node_modules/jest-get-type/node_modules if it was necessary. It would use the yarn.lock from the repo root for resolutions.

I could then take a tarball of the packages/jest-diff directory and put it on a server to run it there, or run a docker build from the packages/jest-diff directory without having to send my entire workspace as a docker context. I could also check in packages/jest-diff as a deployment branch into git to make sure that subsequent deployments are completely deterministic and don't require a network.