When a Monorepo Is the Right Answer for Frontend Teams

The monorepo conversation in frontend tends to generate more heat than light. On one side: monorepos are the modern way, every serious engineering organization does it, the tooling is mature. On the other: monorepos are complexity that most teams don't need, they're slow, they require dedicated infrastructure work. Both of these positions are right in different contexts, which makes the generic advice less useful than identifying the specific problems a monorepo solves and deciding whether those are the problems you have.

I've worked in both polyrepo and monorepo setups at teams of different sizes, and the truth is messier than either camp admits. The question worth asking isn't "should we use a monorepo?" It's "what's actually making our current setup painful, and is a monorepo the best fix?"

The problems monorepos genuinely solve

There are a handful of situations where a monorepo addresses real pain at the source rather than adding tooling overhead without corresponding benefit. The first is shared code between multiple applications. If you have a design system, a utilities package, or an API client library that needs to be consumed by two or more frontend applications, managing that code across separate repositories involves a constant overhead of publishing, versioning, and updating package references. In a monorepo, a change to the shared package is immediately reflected in all the apps that consume it, and you can test the change against all of them in a single CI run.

The second is cross-app refactoring. If you ever need to rename an API, change a shared data model, or update a pattern that's used across multiple applications, doing that across separate repos requires coordinating multiple PRs, often with timing dependencies. In a monorepo, it's a single PR that can be reviewed and merged atomically.

Turborepo changed the calculus

For a long time, the main objection to monorepos was legitimate: they were slow. Running a build or a test suite across a large repository, where most of the work was irrelevant to the change you just made, was painful. Tools like Lerna helped but weren't fast enough to eliminate the problem.

Turborepo addresses this with a combination of task pipelines and intelligent caching. It understands the dependency graph between packages in the repo and runs only the tasks that are affected by a given change. With remote caching enabled, tasks that produce the same output as a previous run are skipped entirely — not just on your machine, but across your whole team and CI environment. A build that took eight minutes starts taking forty seconds once the cache is warm.

The workspace structure that scales

The most common monorepo structure for frontend teams separates applications (the deployable products) from packages (the shared libraries). Each package is independently versioned and has its own package.json. Applications import from packages using workspace references, which the package manager resolves locally without going through a registry.

Where it gets complicated

The costs of a monorepo are real, and they compound as the repo grows. CI pipelines require more thought — you need task filtering to avoid rebuilding everything on every commit, and setting that up correctly takes time. Onboarding new engineers is more complex because the repository is larger and the mental model of how packages relate to each other has to be communicated. Git operations — clone, status, grep — are slower in a large repo.

There's also a subtler problem: a monorepo can create a false sense of cohesion. Just because code is in the same repository doesn't mean the team has agreed on architecture, naming conventions, or dependency policies across packages. Governance questions that were deferred because the repo "keeps it all in one place" tend to resurface later at a larger scale. The tooling is not a substitute for the conversations.

Conclusion

A monorepo is the right choice when the pain of managing shared code across multiple repositories becomes a regular cost your team pays. It's the wrong choice when the motivation is following industry trends without a specific problem in mind.

If you're starting fresh and you know you'll have multiple applications sharing non-trivial amounts of code from day one, start with a monorepo — the tooling is good enough that the setup cost is low. If you're considering migrating an existing polyrepo setup, be specific about which problem you're solving. The migration is not free, and the benefits are only guaranteed if the problem you're solving actually exists in your current setup.