Monorepo
A software development strategy where code for multiple projects is stored in a single repository with shared tooling and unified version history.
Detailed Explanation
A monorepo houses multiple projects (applications, libraries, tools) in one Git repository. Companies like Google, Facebook, and Microsoft use monorepos. Benefits include shared code (libraries used by multiple projects), atomic commits (change code and its dependents together), consistent tooling, and simplified dependency management.
Monorepo tools: Nx (full-featured monorepo toolkit), Turborepo (fast, focused on builds), pnpm workspaces (package management), and Bazel (Google's build system). Monorepos require tooling to handle build performance, dependency graph management, and code ownership.
Why It Matters
Monorepos enable code sharing, atomic changes, and consistent tooling across projects. They are the preferred architecture for many successful companies.
Real-World Example
A company has a web app, mobile app, shared component library, and API in one monorepo. When they update the component library, all projects that depend on it can be tested together in one commit.
When to Use
When you have multiple related projects that share code, when atomic cross-project changes are valuable, or when you want consistent tooling and standards.
Advantages
- Code sharing across projects
- Atomic commits across dependents
- Consistent tooling and standards
- Simplified dependency management
- Easier refactoring across projects
Disadvantages
- Requires specialized tooling (Nx, Turborepo)
- Build performance at scale
- Repository size grows quickly
- Git operations can be slow
- Access control is harder
Related Terms
Frequently Asked Questions
What is the difference between monorepo and monolith?
Monorepo is about code storage (multiple projects in one repo). Monolith is about deployment (all code in one deployable unit). You can have a monorepo with a monolith, or a monorepo with microservices.
Which monorepo tool should I use?
Nx (most features, best DX), Turborepo (fastest builds, simpler), pnpm workspaces (package management only), or Lerna (legacy). Start with Nx for complex projects, Turborepo for simpler ones.
How do I handle build performance in a monorepo?
Use task runners (Nx, Turborepo) that cache builds and only rebuild what changed. Configure affected commands to test only changed projects. Use parallel execution for independent tasks.
Can I migrate from polyrepo to monorepo?
Yes. Use git subtree merge or tools like git-subrepo to combine repositories. Migrate gradually—start with shared libraries, then applications. Expect some disruption during migration.
When should I NOT use a monorepo?
When projects are unrelated, when teams need complete independence, when the repository would be extremely large (>10GB), or when your tooling doesn't support monorepos well.