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
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.
NX scales farther via remote execution, visualizations, integrated editor tools, lower I/O replays, and visibility enforcements.
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.
NX analyzes the project graph eagerly. Turbo does so at runtime. So NX scales better.
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.
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.
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.
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).
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)
You can host NX’s cache on-prem.
NX supports distributed (cross-machine) task execution that honors order. (Inspired by Bazel) - UPDATE - Turbo recently started supporting this too.
NX provides affordances for analyzing cache
NX supports transparent remote execution
NX plugins support quickly configuring tools like web pack, rollup, TypeScript, etc.
NX is pluggable for other languages beyond JS
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.
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.
NX mangles arguments. With Turbo, can use plain npm scripts. NX requires you to build a custom executor that wraps the command.
Turbo caching is more configurable - You can specify inputs to watch. NX is opinionated on how to do so.<- confirm??
Turbo uses the pnpm style filter syntax, so one less thing to learn if using pnpm
Small API, that is easy to learn, and incrementally adoptable.
Monorepo tools
https://www.robinwieruch.de/javascript-monorepos/
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.
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?
Why use Turbo instead of NX? https://github.com/woocommerce/woocommerce/pull/33079#issuecomment-1159192586 (From someone that switched to Turbo from NX)