TypeScript monorepo strategy: Turborepo vs Nx vs the workspace you already have

Key takeaways

• The "workspace you already have" (pnpm, npm, or yarn) links packages and runs scripts, but its docs describe no content-hash task caching and no task graph. Every CI run is a cold run.
• Turborepo is a task runner plus cache that "uses the package.json scripts you've already written" (Turborepo). Low ceremony, big win on repeated builds. Its core was rewritten in Rust (Vercel, 2024).
• Nx is more than a task runner: computation caching plus nx affected, code generators, and tag-based module-boundary enforcement (Nx). More power, more concepts to learn.
• Popularity isn't fit, but for reference: turbo pulls ~16.3M weekly npm downloads to nx's ~8.9M, while GitHub stars are near-level (~30.6k vs ~29.0k). Read those with caveats, not as a verdict.

TL;DR

Start with the workspace you already have; it links packages and runs scripts fine, it just never caches, so every build and test in CI runs cold. When that cold-run pain is real, Turborepo is the low-commitment fix: it wraps your existing scripts, adds a content-aware cache, and can share that cache remotely. Nx does all of that too, but its real value is the layer above, code generation, a project graph, and enforced module boundaries, which matters when you have many projects and want architecture to be checkable, not just documented. For most small teams the honest path is workspaces, then Turborepo, and Nx only when you're actually feeling the problems Nx solves.

What problem are you actually solving?

You're almost always solving "CI rebuilds everything every time," not "I need a monorepo tool." A monorepo itself is just multiple packages in one repo, and your package manager already handles that. pnpm workspaces need a pnpm-workspace.yaml and use the workspace: protocol to link local packages, so "ui": "workspace:*" resolves to the in-repo package instead of the registry (pnpm); npm and yarn have equivalents (npm). What none of them document is task caching or an intelligent task graph. You can run a script across every package, but each run starts from zero.

TypeScript itself offers one native optimization worth knowing: project references. With composite: true and references, tsc --build acts as a build orchestrator that compiles dependencies in the right order and writes a tsconfig.tsbuildinfo file for incremental rebuilds (TypeScript). That's genuinely useful, but it only speeds up tsc. Your lint, test, and bundle tasks are still cold every run. That gap, caching arbitrary tasks across a package graph, is exactly what Turborepo and Nx exist to fill.

How does Turborepo work, and what is it deliberately not?

Turborepo is a caching task runner that layers onto the scripts you already have. You declare tasks in turbo.json, and Turborepo builds a directed acyclic graph from their relationships. The ^ microsyntax expresses dependencies across packages: "build": { "dependsOn": ["^build"] } means "build this package's dependencies first," while "test": { "dependsOn": ["build"] } (no caret) depends on a task in the same package (Turborepo). That graph is how it parallelizes safely and knows what to cache.

The caching is content-aware. Before running a task, Turborepo builds a hash from the source files, package.json dependencies, environment variables, and build config, then checks the local cache and, if configured, a remote cache; a hit restores the logged output and files instead of rebuilding (Turborepo). Remote cache artifacts are protected with HMAC-SHA256 signatures (Turborepo), and the whole thing runs on a core that Vercel rewrote from Go to Rust (Vercel, 2024).

The important framing is what Turborepo scopes itself to. Its docs describe it as a build system that "uses the package.json scripts you've already written" and is adopted incrementally (Turborepo). It is a task runner and cache. It does not ship code generators or module-boundary enforcement; those are Nx features. That narrowness is a feature for small teams: there's very little new to learn.

How does Nx work, and where is it more than a task runner?

Nx does the same caching job and then adds an architecture layer on top. It analyzes your source into a project graph, derives a task graph for execution order, and caches by a computation hash of each task's declared inputs, checking a local then remote cache and replaying a match including its stdout (Nx). So far, conceptually similar to Turborepo. The differences are what you get beyond that.

Three Nx capabilities have no Turborepo equivalent. First, nx affected uses Git history plus the project graph to run tasks only for the projects a change actually touches (Nx), which is powerful in CI. Second, the @nx/enforce-module-boundaries ESLint rule lets you tag libraries and declare which tags may import which, turning your intended architecture into a lint error when violated (Nx). Third, Nx has generators and a plugin registry for scaffolding, plus Nx Cloud's distributed task execution, where Nx Agents spread tasks across machines using historical run times and the graph (Nx). That's a lot of capability. It's also a lot of concepts, and concepts are a cost.

The honest capability comparison

Feature lists sell tools; capabilities decide fit. Here's what each option actually documents, which is the comparison that matters more than any benchmark.

The pattern is clear. Workspaces plus project references get you a working monorepo with fast tsc. Turborepo adds task caching with almost no new mental model. Nx adds the caching plus an architecture toolkit, at the cost of more to learn. Nobody's wrong here; they're solving different amounts of problem.

Which is more popular, and does it matter?

Popularity is a weak signal for fit, but people ask, so here's the honest version. On npm, turbo pulled about 16.3 million weekly downloads against nx's roughly 8.9 million in a recent week (npm). But that comparison is unfair to Nx: turbo is essentially one package, whereas Nx's functionality is spread across many separate @nx/* plugin packages, so its true footprint is understated by the single nx number. GitHub stars tell a flatter story: Turborepo sits near 30.6k and Nx near 29.0k, effectively comparable mindshare.

So don't choose on these numbers. They measure distribution and attention, not whether a tool fits your team. A tool with half the downloads can be the right call if it matches how you work. Use popularity only as a tiebreaker for things like community answers and plugin availability, never as the deciding factor.

Which should a small team actually choose?

Match the tool to the pain you actually have, and add capability only when you feel its absence. Here's the progression we recommend for teams under about twenty engineers:

• Stay on plain workspaces (+ TS project references) while your full CI run is still fast enough to tolerate. If a cold build-and-test is a couple of minutes, you don't have a caching problem yet, and adding a tool is premature complexity.
• Add Turborepo when repeated CI runs start hurting and you want that fixed with minimal disruption. Because it wraps your existing package.json scripts and adds little new vocabulary, it's the lowest-risk upgrade, and remote caching lets the whole team and CI share build results.
• Reach for Nx when your problems are architectural, not just speed: many projects, a need to enforce boundaries so the codebase doesn't turn to spaghetti, appetite for code generators to standardize new packages, or CI so large you want distributed execution. Nx pays for its concept overhead once you have those problems, and taxes you if you don't.

The trap at small scale is adopting Nx for its power, then paying its learning and configuration cost while using only the caching, which Turborepo would have given you for far less. Buy the capability when you need it.

How do you migrate without regret?

Move up the ladder one rung at a time, because each step is reversible and the next is only worth it if the previous one stops being enough. Start with workspaces; you likely already have them. If tsc is your bottleneck, add project references first, it's free and native. When cold task runs bite, add Turborepo: it's designed for incremental adoption and sits on top of your scripts, so you can trial it on one pipeline and keep going or back out cheaply.

Only migrate to Nx as a deliberate decision, not a default. It's more opinionated, and while it can be adopted incrementally too, its value shows up when you use the graph, boundaries, and generators, which means committing to its way of structuring a repo. If you're not going to use those, you're carrying weight for nothing. The honest rule: adopt the simplest tool that removes your current pain, and re-evaluate when you feel the next one.

What we got wrong: On a five-person project we reached straight for Nx because it was the "serious" monorepo choice, and spent a sprint learning its project configuration and plugins. We used exactly one feature: task caching. Months later we were still explaining Nx's mental model to every new hire while ignoring 80% of it. On the next project we started with pnpm workspaces and added Turborepo the week CI got slow. It took an afternoon, nobody needed training, and we got the caching that was the only thing we'd actually wanted from Nx. Nx is excellent; we'd just bought a workshop when we needed a wrench.

A quick decision guide

Answer these in order and stop at your first yes.

1. Is your full CI run still fast enough? Stay on workspaces. Add TS project references if tsc specifically is slow.
2. Do you mainly need caching to speed up repeated builds and tests? Add Turborepo. It's the least you can adopt to solve that.
3. Do you need enforced module boundaries, code generators, or distributed CI across many projects? That's Nx's territory; adopt it deliberately and use those features.
4. Are you choosing Nx mostly for caching? Reconsider. Turborepo gives you that with far less to learn.

Frequently asked questions

Is Turborepo or Nx better for a small TypeScript team?

For most small teams, Turborepo, because it solves the common problem (task caching) with almost no new concepts, wrapping the package.json scripts you already have (Turborepo). Nx is better when you need its architecture layer, enforced module boundaries, generators, distributed execution, but those matter more as project count grows. Choose by which problems you actually have.

Do I need Turborepo or Nx at all if I use pnpm workspaces?

Not until repeated builds get slow. pnpm workspaces link packages and run scripts, but document no task caching (pnpm), so every CI run is cold. If that cold run is fast enough, you don't need either tool yet. Add caching when the wait becomes a real cost, not before.

What do TypeScript project references give me?

Native incremental compilation for tsc. With composite: true and references, tsc --build compiles dependencies in order and writes a .tsbuildinfo file so later builds skip unchanged work (TypeScript). It's free and worth setting up, but it only accelerates type-checking and emit, not your lint, test, or bundle tasks.

Does Nx replace my package manager's workspaces?

No; it layers on top. Nx adds a project graph, caching, and tooling above your existing package setup rather than replacing dependency linking. The nx affected command, for instance, combines Git history with that project graph to run tasks only for changed projects (Nx).

Choose the least tool that solves your problem

Monorepo tooling isn't a status symbol; it's a response to a specific pain. The workspace you already have is a real, valid monorepo, it just doesn't cache. Turborepo adds that caching with barely any new surface area, which makes it the right first upgrade for most small teams. Nx is genuinely more capable, and that capability is worth its concept cost exactly when you have the architectural problems it solves, and not a moment sooner. Pick by the pain in front of you, and let the next problem, not the hype, tell you when to move up.

If you're weighing a monorepo migration and want it sized to your team rather than to a conference talk, that's the kind of pragmatic architecture call we help teams make.