I almost picked wrong.<\/p>\n
We were rebuilding our frontend platform at work \u2014 five apps, three shared component libraries, a design token package, and a CLI tool that nobody fully understood anymore. Classic monorepo chaos. I spent about two weeks<\/a> seriously evaluating both Turborepo (2.4) and Nx (21.2) before committing, and I kept flip-flopping right up until the last day. This post is my honest account of that process, including the part where Nx confused me for three<\/a> hours straight before I figured out I was looking at the<\/a> wrong documentation version.<\/p>\n Both tools are genuinely good. That’s the frustrating thing. Choosing between them isn’t about which one is broken \u2014 it’s about which flavor of complexity you’re willing to live with.<\/p>\n Context matters here. I wasn’t doing a toy “hello world” comparison. The repo I was migrating had:<\/p>\n I set up each tool in a branch, ran them both through our actual CI pipeline, and lived with them daily for a week each. I also had a side project \u2014 a smaller, four-package monorepo I maintain alone \u2014 where I could experiment more aggressively without breaking anyone else’s Friday.<\/p>\n Worth mentioning: I was already on pnpm workspaces for both codebases. That affects the setup experience pretty significantly.<\/p>\n The onboarding story for Turborepo is genuinely good. You run The The What genuinely caught me off guard was how opaque the cache miss debugging is. You get Remote caching through Vercel is great if you’re already on Vercel. We’re not. The self-hosted remote cache options have improved \u2014 there are solid open source implementations like If your team is small-to-medium, your stack is mostly Next.js or Vite, and you want to be productive fast, Turborepo will not let you down. The ceiling is real but it’s high enough for most teams.<\/p>\n Nx is a different kind of beast. Calling them comparable tools is like calling a Swiss Army knife and a chef’s knife comparable cutting implements \u2014 they both cut things, but they’re optimized differently.<\/p>\n The thing that immediately differentiates Nx is the project graph and the Turborepo does affected filtering too, via The generator system is either a massive win or annoying overhead depending on your perspective. Running Here’s an example of the Nx project config for one of our packages. Nx uses either More verbose than Turborepo’s The downside is the learning curve is genuinely steep. The docs<\/a> are extensive but I hit multiple moments of “I know what I<\/a> want to do but I can’t find the right term to search for.” I spent three hours once trying to figure out why my<\/a> inferred targets weren’t picking up my Also: Nx Cloud’s pricing has gotten more reasonable in 2025-2026, but it’s still a conversation you’ll have with your finance team. The free tier is generous for smaller teams but you’ll hit limits on larger repos.<\/p>\n Midway through week two \u2014 I was testing Nx at this point \u2014 I tried to benchmark actual build times side by side. Both configured to use<\/a> remote caching, both with warm caches, building the same set of packages. The times were surprisingly close. Within 15% of each other on a cold build, essentially identical on a warm cache hit.<\/p>\n I thought the whole decision would come down to build speed. It did not.<\/p>\n What actually differed was the day-to-day experience of maintaining<\/em> the monorepo over time. Who updates the configs when you add a new package? How painful is it to onboard an engineer who hasn’t touched the build system? What happens when a plugin doesn’t support the new version of a framework you just upgraded to?<\/p>\n Turborepo ages gracefully because there’s genuinely less of it. When something breaks, there are fewer moving parts to inspect. When a new engineer joins and asks “how does CI work?”, I can show them Nx ages powerfully but demands maintenance. The plugin ecosystem means you get a lot for free \u2014 until you’re stuck waiting for an I pushed an Nx plugin upgrade on a Friday afternoon once (yes, I know) and it silently broke the executor for one of our Vite apps. Didn’t catch it until Monday morning. That specific failure wasn’t entirely Nx’s fault \u2014 there was a peer dependency issue I should have caught \u2014 but Turborepo’s thinner abstraction layer means there are fewer of those landmines to step on.<\/p>\n Use Turborepo if your team is under ~15 engineers, you’re building primarily JS\/TS web apps, and you want something you can fully understand and debug yourself. The configuration surface is small enough that you can hold the whole mental model in your head. Remote caching works well with self-hosted options if you’re not on Vercel. You’ll get 80% of the benefit with 20% of the complexity.<\/p>\n Use Nx if you’re running a larger engineering org (20+ engineers), you have polyglot needs (Angular, React, Node, maybe even some Go or Rust tooling through custom executors), or you genuinely need distributed task execution. The For us \u2014 9 engineers, mostly TypeScript, primarily web \u2014 I went with Turborepo 2.4. We got our CI from 18 minutes down to 6 minutes with a warm remote cache, and the config is something every engineer on the team can read and understand without me needing to explain it. That last part turned out to matter more than I expected.<\/p>\nThe Codebase I Actually<\/a> Used for Testing<\/h2>\n
\n
Turborepo: Fast to Start, Occasionally Frustrating to Debug<\/h2>\n
npx create-turbo@latest<\/code> or drop a turbo.json<\/code> into an existing workspace, define your task pipeline, and you’re off. For our<\/a> existing codebase, I had a working incremental build \u2014 with local caching \u2014 inside about two hours. That includes me reading the docs<\/a> carefully, not skimming.<\/p>\nturbo.json<\/code> pipeline definition is expressive but approachable. Here’s roughly what ours looked like after the first pass:<\/p>\n{\n "$schema": "https:\/\/turbo.build\/schema.json",\n "tasks": {\n "build": {\n "dependsOn": ["^build"], \/\/ ^ means "wait for dependencies to build first"\n "outputs": [".next\/**", "dist\/**"]\n },\n "test": {\n "dependsOn": ["^build"],\n "cache": true,\n "inputs": ["src\/**\/*.ts", "src\/**\/*.tsx", "**\/*.test.ts"]\n },\n "type-check": {\n "dependsOn": ["^build"],\n "cache": true\n },\n "lint": {\n "cache": true,\n "inputs": ["src\/**\/*.ts", "**\/.eslintrc*"]\n }\n }\n}\n<\/code><\/pre>\ninputs<\/code> field on test and lint tasks was something I underutilized at first. Once I started being specific about what actually<\/a> affects cache invalidation, our hit rate went from about 60% to around 88% on typical PRs. That’s the kind of tuning that pays off.<\/p>\nMISS<\/code> in the<\/a> output and that’s… kind of it? There’s a --verbosity=2<\/code> flag that helps, and the newer turbo run build --summarize<\/code> output is better than it used to be. But I spent a full afternoon on a Friday trying to figure out why one package kept missing the cache. Turned out I had a .env.local<\/code> file getting picked up as an implicit input. Totally reasonable behavior in retrospect, but the path from “why is this missing” to “oh, it’s that file” was longer than it should have been.<\/p>\nducktape<\/code> and a few others \u2014 but it’s an extra setup step that Nx handles more natively in my experience.<\/p>\nNx: More Power, More Everything (Including More Config)<\/h2>\n
nx affected<\/code> command. When you run nx affected -t test<\/code>, Nx doesn’t just look at which packages have changed \u2014 it understands the actual dependency graph of your workspace and runs tests only for packages that could be affected by your changes. Not just “this package changed” but “this package imports from that package which changed.” On our 9-person team, this cut our average CI test time dramatically on feature branches. We went from running<\/a> ~220 test suites to ~30-60 depending on what changed.<\/p>\n--filter=...[HEAD^1]<\/code> or similar git-based flags, but Nx’s implementation felt more reliable and more deeply integrated into how the tool thinks about your workspace.<\/p>\nnx g @nx\/react:library my-ui-lib<\/code> scaffolds a complete package with correct tsconfig references, barrel exports, jest config, and a README. I thought this would feel patronizing \u2014 I know how to set up a package \u2014 but after the third time I had to bootstrap a shared utility library from scratch, I came around. The consistency is actually<\/a> the point.<\/p>\nproject.json<\/code> or inline targets in package.json<\/code>:<\/p>\n\/\/ packages\/design-tokens\/project.json\n{\n "name": "design-tokens",\n "$schema": "..\/..\/node_modules\/nx\/schemas\/project-schema.json",\n "sourceRoot": "packages\/design-tokens\/src",\n "targets": {\n "build": {\n "executor": "@nx\/js:tsc",\n "outputs": ["{options.outputPath}"],\n "options": {\n "outputPath": "dist\/packages\/design-tokens",\n "main": "packages\/design-tokens\/src\/index.ts",\n "tsConfig": "packages\/design-tokens\/tsconfig.lib.json"\n }\n },\n "test": {\n "executor": "@nx\/jest:jest",\n "outputs": ["{workspaceRoot}\/coverage\/packages\/design-tokens"],\n "options": {\n "jestConfig": "packages\/design-tokens\/jest.config.ts"\n }\n }\n }\n}\n<\/code><\/pre>\nturbo.json<\/code> approach? Yes. But the executor abstraction means Nx can do things Turborepo can’t \u2014 like running builds through Nx Cloud’s distributed task execution, which farms individual tasks out to multiple CI agents. For large repos, this is not a minor feature.<\/p>\nvite.config.ts<\/code> \u2014 the issue was that I’d installed the wrong version of @nx\/vite<\/code> for my Nx core version, and the error message pointed me in a completely wrong direction. I’m not sure if they’ve fixed the version-mismatch error messaging since then, but it bit me hard enough that I remember exactly which week it was.<\/p>\nBuild Speed Wasn’t the Real Decision<\/h2>\n
turbo.json<\/code> and they get it in<\/a> ten minutes.<\/p>\n@nx\/next<\/code> update to support the version of Next.js you just upgraded to, while Turborepo users just… don’t have that problem, because Turborepo doesn’t own your framework integration.<\/p>\nMy Call<\/h2>\n
nx affected<\/code> intelligence pays bigger dividends at scale \u2014 it’s more valuable on a 60-package repo than a 10-package one. Accept the learning curve, invest in it properly, and it pays back.<\/p>\n