6 Months with Turborepo: Expectations vs Reality

Why we went monorepo

We had 5 packages. Two frontends, one backend, two shared libraries. Managing them in separate repos meant that every time we updated a shared library, we had to publish to npm, bump the version in the other projects, test everything... This cycle took 45 minutes each time.

Going monorepo was supposed to eliminate that pain. It was half right and half wrong.

Why Turborepo

We evaluated Nx too. Honestly, Nx has more features. But the setup was complex. Two out of three team members had zero monorepo experience, and we wanted a low learning curve. Turborepo just needs one turbo.json for basic configuration.

(Also, I won't lie -- being in the Vercel ecosystem was part of the decision.)

Build caching is genuinely fast

I'll give it that. After setting up remote caching, our average CI build time dropped from 8 minutes 42 seconds to 2 minutes 15 seconds. Unchanged packages just get pulled from cache, so there's no need to rebuild everything.

Locally, if you run turbo run build back to back, the second run finishes almost instantly. That experience was great, and I was happy early on.

But problems started showing up

Around month three, inter-package dependencies started getting tangled. Shared library A references shared library B, the frontend imports both A and B but with different versions, that kind of thing. TypeScript path configs differed across packages, so IDE autocompletion broke.

These aren't Turborepo problems -- they're monorepo problems. But expecting Turborepo to magically solve them was the real mistake.

How the team reacted

"Why does my project break when someone touches a different package?" I heard this question every week for 4 months. Even after explaining that this is literally the point of a monorepo, people weren't really convinced.

PRs started mixing changes across multiple packages, which made code review more complex. "This part isn't even my responsibility?" became a frequent comment. Setting up CODEOWNERS helped a bit, but it wasn't perfect.

(I realized too late that a monorepo isn't a technical tool -- it's a change in how you collaborate.)

Builds got faster, but other things got slower

git clone got slower. The repo ballooned to 1.2GB. Shallow clone in CI fixes it, but the initial local clone takes 3 minutes 47 seconds.

ESLint got slower too. Running a full lint takes over 2 minutes. Turborepo's filtering handles this, but typing --filter every time is annoying.

Honest assessment at 6 months

Build caching and parallel task execution are genuinely good. Instant reflection of shared code changes is nice too. But if your team is small and you don't have many packages, plain multi-repo might just be easier.

With our team size (3 people) and 5 packages, we probably didn't need a monorepo. We're using it since it's already set up, but I'm not sure I'd default to monorepo on the next project.