Monorepos

[coryhouse]

Monorepo tools

https://www.robinwieruch.de/javascript-monorepos/

• npmTrends stats on popular options
• My tweet with 10 options
• Lerna
• Nx
• Bolt - Also, see JCreamer's blog post
• Rush
• fynpo
• https://preconstruct.tools/
• Yarn workspace
• pnpm
• Lerna-lite
• File path

Turbo vs nx

Turbo performance tip: an overly-permissive pnpm-workspace.yaml file could make the startup take a while. It does a glob walk of directories, so things like packages/** will recursively search through every directory to try and find a workspace package. When I changed this to the more specific packages/js/* it sped up instantly. (via Turbo vs nx

Via https://github.com/woocommerce/woocommerce/pull/33079#issuecomment-1159192586

Lerna vs Yarn vs Yarn Workspaces

Can create a mono repo with a bunch of projects in a folder and they can all share the same package.json. Downside, you can’t use create-react-app, advantage, you don’t have to maintain separate package.json dependencies for each.

• Assure each project in the monorepo uses the same version of each package

Monorepo notes

Resources
https://monorepo.tools/

Turbo vs NX

Why prefer NX? https://nx.dev/more-concepts/turbo-and-nx (From NX)

Why NX over Turborepo?

1. NX scales farther via remote execution, visualizations, integrated editor tools, lower I/O replays, and visibility enforcements.
2. NX supports integrated model (declare all deps and dev tools at root) - This makes it easy to add new packages. Turbo only supports package model, which means build tools and deps are declared for each package. The package model makes build tools easier to config, but means adding a new package involves a lot of repeated boilerplate for each package. Integrated is more work to get right up front, but scales better. Package-based is an easier starting point and easier to people to understand quickly (since it honors traditional npm-based project conventions), but the copy/paste nature of repeating dev tools for each package doesn’t scale that well.
3. NX analyzes the project graph eagerly. Turbo does so at runtime. So NX scales better.
4. Turbo wipes out everything and replays. NX is smart enough to leave files that need not be rewritten. This is faster, especially on Windows and machines where I/O is slower.
5. Includes metadata that is read by VSCode/Webstorm integrations, GitHub integrations, and 3rd party tools. (Though most people just use the CLI anyway. I don’t need a GUI to find/run scripts.
6. NX can enforce visibility rules to keep packages from “dipping into” each other’s files outside the published API. Can even declare private packages. ESLint can do the same thing.
7. NX provides rich, interactive project graph visualization. Turbo’s is static and not interactive. (Though Turbo’s code-based dependsOn also feels pretty easy to parse for small to medium sized repos).
8. Turbo uses piping, which changes the terminal output. NX supports piping, but also supports other strategies (this way, the output of tools like Cypress is untouched)
9. You can host NX’s cache on-prem.
10. NX supports distributed (cross-machine) task execution that honors order. (Inspired by Bazel) - UPDATE - Turbo recently started supporting this too.
11. NX provides affordances for analyzing cache
12. NX supports transparent remote execution
13. NX plugins support quickly configuring tools like web pack, rollup, TypeScript, etc.
14. NX is pluggable for other languages beyond JS
15. NX has native codegen support (though it’s not hard to gen code using ad-hoc approaches). And using an external, focused code generator makes more sense to me.

Why use Turbo instead of NX? woocommerce/woocommerce#33079 (comment) (From someone that switched to Turbo from NX)

1. NX wants a single version of all deps, or you can’t use plugins. Instead can use https://github.com/JamieMason/syncpack/ if desired to enforce where desired in a Turbo repo.
2. NX mangles arguments. With Turbo, can use plain npm scripts. NX requires you to build a custom executor that wraps the command.
3. Turbo caching is more configurable - You can specify inputs to watch. NX is opinionated on how to do so.<- confirm??
4. Turbo uses the pnpm style filter syntax, so one less thing to learn if using pnpm
5. Small API, that is easy to learn, and incrementally adoptable.