What Is a Monorepo and When Does It Make Sense
Monorepo vs polyrepo tradeoffs, who uses them, and the tooling landscape
A monorepo is a single Git repository that contains multiple projects — apps, packages, services — that would otherwise live in separate repos. The idea sounds simple. The tradeoffs are subtle and worth understanding before you commit to the structure.
Monorepo vs polyrepo
- Monorepo: one repo, many packages — All your code lives in one place. Shared packages are local dependencies. Changes that span packages are a single commit and a single PR.
- Polyrepo: one repo per project — Each app is independent. Team autonomy is higher. But sharing code means publishing packages, managing versions, and chasing breaking changes across repos.
- The coordination tax — Polyrepos are cheap to start and expensive to coordinate. Monorepos are expensive to set up and cheap to coordinate. The crossover usually happens around 3–5 related projects.
Companies that use monorepos
- Google — Arguably the largest monorepo on earth — billions of lines of code, one repo. They built custom tooling (Bazel) to make it work at scale.
- Meta — One monorepo for most of their products. Invented Mercurial extensions to handle the size.
- Vercel, Stripe, Shopify — Many modern SaaS companies run monorepos for their product families — especially when sharing a design system, auth layer, or API client.
The office building analogy
A polyrepo is like renting separate offices for each team. Everyone decorates their own space, buys their own coffee machine, and makes their own decisions. A monorepo is like a shared open-plan office. Communication is faster, but you need shared norms — or it becomes chaos. The tooling (Turborepo, Nx) is the office manager who enforces those norms.
Tooling overview
- pnpm workspaces — Package manager feature that lets you link local packages together. The foundation most monorepos are built on.
- Turborepo — Build system from Vercel. Adds caching and parallelism on top of pnpm workspaces. The best choice for JS/TS monorepos in 2026.
- Nx — Feature-rich alternative to Turborepo. More configuration, more power. Better for large enterprise teams with mixed tech stacks.
- Yarn/npm workspaces — Similar to pnpm workspaces but pnpm is faster and handles the dependency graph more reliably. Prefer pnpm for new projects.
When to use a monorepo
- You have 2+ projects sharing code — UI component library, shared types, utility functions — any code you copy-paste between repos is a monorepo candidate.
- Your apps deploy together — If a backend change always requires a frontend change, keeping them in separate repos creates friction.
- Your team is small — A 2-person team coordinating across 6 repos spends more time on plumbing than building. A monorepo collapses that overhead.
Try this
Look at your current projects. List any code (types, utilities, UI components, API clients) that exists in more than one repo. If that list has more than 3 items, you are already paying the polyrepo tax. That code belongs in a shared package — which a monorepo makes trivial.