Pick Your Monorepo Poison: Nx vs Lerna vs Rush vs Bazel vs Turborepo

Lerna: Don't. Just Don't.

Lerna is dead. Maintenance stopped, development's inconsistent, and the community has moved on. I spent 3 hours debugging a Lerna v6 upgrade that broke our publishing pipeline because lerna publish started ignoring our .npmrc file. Found multiple Stack Overflow threads with dozens of other developers having the exact same issue - no fixes, just workarounds.

The original maintainer stepped down and Nx took over stewardship, but it's essentially life support. The GitHub issues pile up faster than fixes. Security vulnerabilities aren't getting patched quickly.

If you're still using Lerna, migrate to Nx or Turborepo now. Don't be the person maintaining legacy tooling in 2025. The security advisories stack up, and dependency updates take months to merge.

Turborepo: Fast Until It Isn't

Turborepo works great for simple use cases. Setup takes 5 minutes, builds are fast, and it stays out of your way. Then you need to do anything beyond basic builds and realize how limited it is.

Real example: tried to add ESLint caching across packages and hit the wall where Turborepo's task graph can't handle conditional dependencies. Ended up with a hacky turbo.json with hardcoded package paths that breaks whenever someone adds a new package type. Their GitHub issues are full of people hitting the same limitation.

The Vercel acquisition accelerated development, but it's still focused on the Next.js ecosystem. If you're not building React apps, you'll fight against its assumptions.

Nx: Will Make You Restructure Everything

Nx is powerful but will consume your life learning it. The migration from v15 to v16 broke our entire CI pipeline because they changed how workspace configurations work. Took our senior engineer 2 weeks to fix all the executor paths. Half the team was blocked waiting for builds to work again.

Once you're past the learning curve, Nx is genuinely impressive. Remote caching through Nx Cloud saved us 30 minutes per CI run. The dependency graph detection is smart enough to catch changes we'd miss manually. The distributed task execution scales builds across multiple machines automatically.

But expect to spend a month just understanding their concepts. The documentation assumes you want to restructure your entire workspace around Nx conventions. Affected commands and project boundaries are powerful but require mental rewiring.

Rush: Enterprise Consultants Love It

Rush is what happens when Microsoft engineers solve problems most teams don't have. The phantom dependency detection found around 80-90 issues in our "clean" codebase that we'd never noticed.

Setup requires understanding their entire ecosystem: Rush, Heft, API Extractor, and Rushstack. Budget for expensive consultants or plan to become a Rush expert yourself. The configuration files alone have 200+ options.

If you're at enterprise scale with compliance requirements, Rush might be worth it. For everyone else, it's overkill that slows down development.

Bazel: Google's Problems, Not Yours

Bazel requires a PhD in build systems. The BUILD files become unmaintainable technical debt that only one person on your team understands. When that person leaves, you're fucked.

I've seen companies invest 6 months getting Bazel working, only to abandon it when they realize the maintenance burden. Unless you're building at Google scale with Google's engineering resources, avoid it.

The remote execution and caching are genuinely impressive, but the complexity isn't worth it for JavaScript projects. Save yourself the headache.

3AM Debugging Stories You Won't Read in the Docs

Nx Migrations Break Things. Always.

The Nx 16 migration changed workspace configurations without warning. Our CI failed with cryptic NX Cannot find configuration for 'build' errors. Spent most of a day digging through their migration scripts to realize they moved executor paths from project.json to nx.json. The error message gave zero indication of what actually broke.

Check the Nx migration guide and breaking changes before upgrading. The Discord community helps, but expect to spend time debugging workspace configuration issues.

Pro tip: Always run migrations on a separate branch first. And budget extra time. They will find ways to break your setup that weren't mentioned in the changelog.

But once you get past the migration hell, Nx Cloud is genuinely impressive. Cut our CI time from 45 minutes to 12 minutes by caching everything remotely. The distributed task execution and remote caching work as advertised. Cache hit rates above 80% are common once you get the configuration right.

Turborepo's Task Graph Lies

Turborepo's dependency detection missed a critical CSS build step that only showed up in production. The turbo.json looked correct:

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    }
  }
}

But it couldn't detect that our component library needed the CSS tokens built first. Had to add hacky beforeAll scripts that shell out to npm run build:tokens before every build. Now the config is unmaintainable and breaks if anyone moves the token files.

The Vercel integration works great if you're all-in on their platform. Otherwise, expect to fight their assumptions.

Rush's Configuration Hell

Rush's rush.json has 200+ configuration options. Our enterprise setup required understanding their entire ecosystem: Rush, Heft, API Extractor, and Rushstack.

The phantom dependency detection is no joke - found around 80-90 issues in our "clean" codebase. Things like importing React without declaring it as a dependency. Rush caught it all, but fixing them took 2 weeks.

Setup time: 1 month for a senior developer. Budget accordingly.

Bazel BUILD Files: Technical Debt Generator

Bazel's BUILD files become unmaintainable quick. Here's what a simple Node.js package looks like:

load("@npm//:defs.bzl", "npm_link_all_packages")
load("@rules_nodejs//nodejs:defs.bzl", "nodejs_binary")

npm_link_all_packages(name = "node_modules")

nodejs_binary(
    name = "server",
    data = [":node_modules"],
    entry_point = "src/index.js",
)

Multiply this by 200 packages and you've got a maintenance nightmare. When the Bazel expert leaves, you're fucked. The learning curve isn't worth it unless you're building at Google scale.

Lerna: Just Say No

I debugged a Lerna publishing issue for 3 hours yesterday. lerna publish was ignoring our .npmrc file after the v6 upgrade. Found multiple Stack Overflow threads with dozens of other developers having the exact same issue.

The maintainers haven't fixed it. Development is inconsistent. Don't use Lerna for new projects in 2025.

The "Will Your Boss Fire You?" Risk Assessment