Monorepo Workflow - Manage Multiple Projects in One Repository

A monorepo contains multiple projects, packages, or services in a single Git repository. Rather than having separate repos for your frontend, backend, shared libraries, and infrastructure, everything lives together. Companies like Google (with billions of lines of code in one repo), Meta, Microsoft, and Uber use monorepos because they simplify dependency management, enable atomic cross-project changes, and eliminate the overhead of coordinating releases across dozens of repositories.

The monorepo approach is not about dumping everything into one folder. It requires careful tooling, clear ownership boundaries, and intelligent CI/CD that only builds what changed.

Monorepo Structure

Why Monorepo?

Monorepo Tooling

The raw Git experience in a monorepo is poor without dedicated tooling. These tools make monorepos practical:

Turborepo (by Vercel): Task orchestration with remote caching. Runs only affected tasks.

Nx (by Nrwl): Full-featured monorepo toolkit with dependency graph visualization, affected detection, and code generators.

pnpm Workspaces / Yarn Workspaces: Package management with workspace-aware dependency resolution.

CI/CD for Monorepos: Only Build What Changed

The biggest challenge in a monorepo is avoiding the "build everything on every push" problem:

Notice how changes to packages/ui-components trigger the web test (because web depends on it) but not the API test. This dependency awareness is critical for monorepo CI performance.

Code Ownership with CODEOWNERS

Clear ownership prevents the "tragedy of the commons" where shared code has no responsible maintainer:

Branching in a Monorepo

Feature branches in monorepos follow the same patterns as single-project repos, but with scope awareness:

Common Mistakes

Mistake 1: Not investing in tooling. A monorepo without Turborepo/Nx is just a large, slow repository. The tooling makes it practical.

Mistake 2: Running all tests on every change. Without affected-change detection, CI becomes unbearably slow and expensive.

Mistake 3: No clear ownership boundaries. Without CODEOWNERS, shared packages degrade because "everyone's responsibility is no one's responsibility."

Mistake 4: Massive PRs that touch multiple unrelated projects. Just because code lives together does not mean changes should be bundled. Keep PRs focused.

Interview Questions

Q1: What is a monorepo and when should you use one?

A monorepo is a single repository containing multiple projects that may be independently deployable. Use it when projects share significant code, have coupled releases, need atomic cross-project changes, or when you want unified tooling. Not ideal for completely independent services with separate teams and release cycles.

Q2: How do you scale CI/CD for a monorepo?

Use affected-change detection (only build what changed and its dependents), remote caching (Turborepo caches build outputs), parallel execution, and path-based filtering in GitHub Actions. This prevents the O(n) problem of building everything on every push.

Q3: What tools support monorepo workflows?

Turborepo (task orchestration, remote caching), Nx (dependency graph, affected detection, code generators), Lerna (versioning, publishing to npm), and pnpm/Yarn workspaces (package management with workspace linking).

Q4: How do you handle code ownership in a monorepo?

Use CODEOWNERS with path-based ownership, branch protection requiring owner review, clear directory boundaries between teams, and documentation of ownership responsibilities. Each directory should have exactly one owning team.

Q5: What are the drawbacks of monorepos?

Larger clone sizes (mitigate with shallow clones), complex CI setup requiring specialized tooling, potential for tight coupling between projects, access control challenges (everyone can see everything), IDE performance issues with huge codebases, and the learning curve of monorepo-specific tools.