Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monorepos #170

Open
coryhouse opened this issue May 19, 2023 · 0 comments
Open

Monorepos #170

coryhouse opened this issue May 19, 2023 · 0 comments

Comments

@coryhouse
Copy link
Owner

coryhouse commented May 19, 2023

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?

  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.
@coryhouse coryhouse mentioned this issue May 19, 2023
27 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant