TypeScript Monorepo with NPM Workspaces
yieldcode.blog
yieldcode.blog
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.
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
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.
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.