Monorepo Tools Compared: NX, Turborepo, Bazel, and Rush

The monorepo conversation usually starts when someone on the team says "I'm tired of publishing a new package version just to test a cross-repo change." Then someone suggests a monorepo. Then the team spends two weeks arguing about which tool to use instead of actually moving the code.

This article won't resolve that argument, but it will give you a sharper set of questions to ask before you pick a tool.

What monorepo tools are actually solving

First, a clarification. Turbopack is not a monorepo tool. It's a Rust-based bundler from Vercel meant to replace Webpack inside Next.js. People confuse it with Turborepo constantly. They're different products. Turbopack is a bundler; Turborepo is a task orchestration layer for monorepos. Don't mix them up.

The actual landscape of monorepo tools has two layers. The bottom layer is package management: how packages are linked together, how node_modules is structured, how dependencies are resolved. The top layer is task orchestration: which packages need to rebuild when something changes, how to cache results, how to parallelize work. Most tools live at one layer or span both.

PNPM Workspaces (and Yarn Workspaces)

These are the primitive layer. They don't orchestrate tasks or cache builds. They link packages together inside a single repo and let you run scripts across workspaces. If you have a small codebase, two or three packages, a shared UI library and one app, workspaces alone might be enough. You run pnpm -r build and you're done.

The moment you have a dozen packages and need to figure out which ones actually changed and need rebuilding, workspaces alone become painful. That's where the orchestration tools come in. If you're building multiple frontend apps in a single repo, the microfrontends approach with Single-SPA covers how workspace-based setups interact with frontend architecture boundaries.

Turborepo

Turborepo (from Vercel) is the easiest tool to adopt if you're already in a JavaScript/TypeScript stack. It focuses on one thing: making task execution fast through caching and parallelism. You define your task pipeline in turbo.json, declare which tasks depend on which, and Turborepo does the rest. Run turbo build and it builds only what changed, reads from cache when nothing did, and parallelizes everything it can.

Remote caching is where it shines. Connect to Vercel's remote cache (or self-host with an open-source backend), and a cold CI run becomes a near-instant cache hit. Engineers on different machines can share build artifacts.

What Turborepo does not do: it doesn't generate code, doesn't enforce project structure, doesn't know what frameworks you're using. It's deliberately thin. You wire it up alongside your existing scripts and package manager. That's a strength if you want minimal lock-in. It can be a limitation if you want integrated generators or consistent project scaffolding.

Good fit: frontend-heavy teams already using pnpm or yarn workspaces, Next.js or Vite apps, teams who want fast CI without a big migration cost.

NX

NX (from Nrwl) is the most opinionated tool in this list. It has opinions about folder structure, generator conventions, how projects are named, and how dependencies between them are tracked. That sounds like a lot of overhead. It is, at first. But the payoff is that NX can answer questions your other tools can't: which projects are affected by this PR? Which team owns this library? What does the full dependency graph of this workspace look like?

The nx affected command is powerful once you have more than a few packages. Instead of running tests across every package on every CI run, NX computes which packages were touched by a change (including transitive dependencies) and only runs what matters. At scale, this compresses CI time significantly.

NX also has a plugin ecosystem for React, Angular, Node, Next.js, Remix, and more. These plugins can generate boilerplate, configure testing, set up lint rules, and enforce boundaries between packages via lint rules (e.g., feature packages should not import from other feature packages directly). For a larger organization with multiple teams in one repo, the boundary enforcement alone is worth the setup cost.

The trade-off is the learning curve. NX has its own conventions, its own CLI, and its own concepts (executors, generators, project graph). If your team is small or already has established patterns, it can feel like NX is trying to rewrite your entire setup. It's not wrong, exactly, just opinionated in a direction that doesn't always align with what you already built.

Good fit: medium-to-large JavaScript/TypeScript teams, Angular shops, teams that want generators and enforced architecture boundaries, organizations moving multiple apps into a single repo.

Bazel

Bazel is from Google and is the tool they use to build their actual monorepo. It is hermetic, deterministic, and language-agnostic. You can build Go, Java, Python, C++, TypeScript all in the same Bazel workspace. It will produce the exact same output on every machine, every time, which is a genuinely rare property.

It is also the most complex tool on this list by a wide margin. Bazel has its own build description language (Starlark), its own dependency model, and requires careful configuration of every build rule. The ecosystem has improved, and tools like rules_js and rules_ts have made it usable for frontend projects, but "usable" is doing a lot of work in that sentence. You'll spend real time writing and debugging BUILD files before you get a clean build.

Bazel's caching is exceptional. Remote caching at the action level, not just the task level, means even partial rebuilds are cached with more granularity than Turborepo or NX offer.

Realistically, Bazel makes sense at large organizations with polyglot repos and dedicated infrastructure engineers. If you're a JavaScript shop with 20 engineers and no one has Bazel experience, the cost of adoption will far outweigh the caching benefits you'd get from Turborepo for a fraction of the setup work.

Good fit: large polyglot repos, organizations with dedicated build infrastructure teams, anywhere Google-scale hermeticity and caching granularity matter.

Rush

Rush is from Microsoft and is designed for large JavaScript/TypeScript repositories with strict version consistency requirements. Its model is unusual: it uses shrinkwrap files to lock every dependency precisely, and it manages node_modules in a way that prevents phantom dependency issues (packages accidentally using transitive deps they didn't declare).

Rush cares deeply about the relationship between package versions across your repo. It has a built-in change tracking system where engineers declare what kind of change they're making (patch, minor, major) and Rush generates changelogs and bumps versions accordingly. For a library-heavy monorepo where you publish packages to npm on a regular cadence, Rush's version management is more thoughtful than most alternatives.

The downside: Rush has a steeper setup curve and a smaller community than NX or Turborepo. Finding answers when something breaks takes longer. Its task runner (Rush Stack's heft) is also another layer to learn.

Good fit: organizations managing many published npm packages with strict versioning needs, TypeScript-first large codebases, teams that have wrestled with phantom dependencies.

Lerna

Lerna was the original JavaScript monorepo tool and most people learned the term "monorepo" through it. It solved versioning and publishing before anything else existed. Today it's maintained by the NX team and has been updated to integrate with NX under the hood for task caching.

If you're on a legacy project already using Lerna, upgrading to the newer Lerna with NX integration is straightforward. If you're starting fresh, there's no reason to choose Lerna over NX directly; you're getting a subset of NX's capabilities through a thinner API.

How to choose the right monorepo tool for your team

Most teams overfit on the tool and underfit on the problem. Before you evaluate any of these, answer three questions.

How many packages do you have now, and how many will you have in 18 months? If the answer is "fewer than ten," workspaces plus Turborepo is almost certainly enough.

Do you publish packages to npm, or are these internal packages that never leave the repo? If you publish, Rush or Lerna's versioning support becomes relevant. If everything is internal, task caching matters more than version management.

What's your team's appetite for build tooling complexity? Bazel is exceptional at what it does, but someone has to maintain it. That's a real cost. NX requires buy-in on conventions. Turborepo requires almost nothing but also gives you almost nothing beyond speed. The same trade-off thinking applies to broader architecture decisions, which the five architecture principles article unpacks in detail.

The teams I've seen struggle most are the ones who adopted NX for a five-person project with two apps, spent a month configuring generators they'd never use, then abandoned it for plain PNPM workspaces. Start simpler and add complexity when the pain is real, not when the architecture diagrams look appealing.

If you're unsure, start with PNPM workspaces and Turborepo. You can add NX later without throwing away what you built. Migrating away from Bazel, on the other hand, is its own project.

For deeper dives into software architecture decisions like this one, the Monday BY Gazar newsletter covers system design and tooling choices every week. If you prefer video, the Gazar Breakpoint YouTube channel has walkthroughs of real architectural trade-offs.