Monorepos can be really powerful, but in choosing one (or frankly polyrepo) you need to admit your application is no longer simple. Now you have dependencies an

Monorepos can be really powerful, but in choosing one (or frankly polyrepo) you need to admit your application is no longer simple. Now you have dependencies and multiple artifacts to deal with. I’ve found yarn berry (the typescript rewrite that is v2 and v3) really great for js centric monorepos. With pnp the node_modules problem goes away. And the plug-in architecture of yarn berry is really powerful. This is important because monorepos always need tooling specific to the problem to work well. Bazel, Buck and Pants are great in the Java/C world - but way to heavy for JS. I’ve shared this plugin before, but in case you missed it - I wrote yarn.build [0] as a lightweight replacement for Bazel et al for yarn. In yarn 3, this installs and vendors it into your repo: yarn plugin import https://yarn.build/latest It’s really powerful when you use many local workspaces (packages), that have dependencies on each other. Provided they’re not circular. Theres a build command that runs in the right topological order calling build in your package.json. And caching the status of builds, so it only rebuilds with changes. After that I added a yarn test command, to do the same thing but run test. This has been really powerful for me. As it’s meant I can treat each workspace as if it was coming from NPM. As such, boundaries are hard, and defined. I often need to ship a nodejs lambda, so I added a bundle command. That works similar to how Bazel does a build. It copies your repo to a temporary directory. Then removes everything you don’t need (local workspaces that aren’t dependencies of the workspace to bundle). And drops an entrypoint.js in the root dir, that reexports your main script (as defined in package.json). Finally it zips it up, ready for lambda or any other nodejs environment. And finally, because yarn.build just calls the build script, it can build anything. So I’ve used I with go quite a bit. You just call go build in the package.json build script (add a test script and test it along with the other workspaces). But some go devs aren’t big fans of a package.json hanging around. So I wrote this other neat (and kinda wild) plug-in [1], that allows package.json to be written as package.yaml (with comments!). Like actual yaml. yarn plugin import https://yarn.build/yaml The yaml plug-in sits in between the file system. It works much better than I expected, though I mostly use it on non-node stuff. As node expects package.json on disk for some stuff. Thankfully the plug-in is opt in per workspace, so it happily falls back to json if that’s there. And only uses yaml if there’s a package.yaml and no package.json. [0] https://yarn.build https://yarn.build [1] https://github.com/ojkelly/yarn.build#plugin-package-yaml https://github.com/ojkelly/yarn.build#plugin-package-yaml