Monorepo vs Polyrepo for Frontend Projects: How Do You Choose?
Compare monorepo and polyrepo for frontend projects — tooling, versioning, and CI tradeoffs — with a clear decision framework.
Expected Interview Answer
A monorepo stores multiple frontend packages (apps, shared UI libraries, config) in one version-controlled repository with a single dependency graph and unified tooling, while a polyrepo splits each package into its own separate repository with its own versioning and release cycle.
In a monorepo, tools like Turborepo, Nx, or pnpm workspaces let you share code across apps instantly through a workspace protocol, run affected-only builds and tests, and enforce consistent linting and TypeScript versions everywhere in a single commit. Cross-cutting refactors — like renaming a shared component prop — land atomically in one pull request instead of being coordinated across several repositories and published package versions. A polyrepo isolates teams and ownership boundaries more cleanly and keeps CI pipelines smaller and faster per repo, but it forces you to publish and bump versions of shared packages, which introduces version drift and "dependency hell" when several apps pin different versions of the same library. The decision usually comes down to organizational scale: monorepos shine when many teams share substantial code and need synchronized releases, while polyrepos fit when teams are fully independent and release on separate cadences.
- Atomic cross-package refactors land in a single commit
- Shared build/lint/TypeScript tooling stays consistent across all apps
- Affected-only build and test graphs speed up CI as the codebase grows
- No published-package version drift between internal dependents
AI Mentor Explanation
A monorepo is like a national cricket academy where every state team trains on the same shared pitch, coaching manual, and equipment store, so a change to the bowling drills reaches every squad the same afternoon. A polyrepo is like each state team running its own separate academy with its own manual, so updating a drill means mailing the new manual to every state and waiting for each to adopt it on its own schedule. The academy model keeps everyone synchronized instantly, but a mistake in the shared manual affects every squad at once. That single-shared-resource versus many-independent-copies tradeoff is exactly the monorepo-versus-polyrepo decision.
Step-by-Step Explanation
Step 1
Assess team and code-sharing scale
Determine how many teams share UI components, config, or utilities across apps.
Step 2
Pick workspace tooling
Choose a monorepo tool (Nx, Turborepo, pnpm workspaces) or set up independent repos with published packages.
Step 3
Define build/test boundaries
Configure affected-only graphs (monorepo) or CI pipelines per repo (polyrepo) to keep feedback loops fast.
Step 4
Establish versioning strategy
Use workspace protocol for instant internal sharing (monorepo) or semantic versioning and changelogs for published packages (polyrepo).
What Interviewer Expects
- Clear articulation of atomic cross-package changes vs published-version drift
- Awareness of tooling: Nx, Turborepo, pnpm/yarn workspaces
- Understanding of CI scaling concerns (affected-only builds) in large monorepos
- Ability to map the choice to team/organizational structure, not just preference
Common Mistakes
- Treating monorepo as purely “one big folder” without workspace tooling or affected-graph CI
- Ignoring that a polyrepo requires real package publishing and versioning discipline
- Assuming monorepos always mean a single deployable — most still ship separate apps
- Not considering repository size/CI cost growth as a monorepo scales
Best Answer (HR Friendly)
“A monorepo keeps all our frontend apps and shared code in one repository so changes update everywhere instantly, while a polyrepo splits them into separate repositories that each version and release independently. I would pick a monorepo when teams share a lot of code and need to stay in sync, and a polyrepo when teams are fully independent and want to release on their own schedule.”
Code Example
// pnpm-workspace.yaml
// packages:
// - 'apps/*'
// - 'packages/*'
// apps/marketing-site/package.json
{
"dependencies": {
"@acme/ui": "workspace:*"
}
}
// A commit to packages/ui/src/Button.tsx is immediately
// consumed by apps/marketing-site with no publish step.
import { Button } from '@acme/ui'
export function CtaSection() {
return <Button variant="primary">Get Started</Button>
}Follow-up Questions
- How do affected-graph builds (Nx/Turborepo) keep monorepo CI fast at scale?
- How would you enforce ownership boundaries inside a large monorepo?
- What does a semantic-release pipeline look like for a polyrepo shared package?
- When would you migrate a polyrepo into a monorepo, and what breaks during that migration?
MCQ Practice
1. What is the main advantage of a monorepo for shared frontend UI code?
Monorepos let internal packages be consumed via workspace links, avoiding publish-and-bump cycles.
2. What is a common risk as a monorepo grows across many teams?
Without tools like Nx or Turborepo computing affected packages, CI reruns everything on every change.
3. What does a polyrepo require that a monorepo typically avoids for shared code?
In a polyrepo, shared code must be published as a versioned package and explicitly upgraded by each consumer.
Flash Cards
Monorepo core benefit? — Atomic cross-package changes with instant internal consumption via workspace links.
Polyrepo core benefit? — Clean team/ownership isolation and independent release cadences.
Common monorepo tools? — Nx, Turborepo, pnpm/yarn/npm workspaces.
Polyrepo shared-code cost? — Version drift from manual publish-and-upgrade cycles across repos.