100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

Monorepo

IntermediateConcept1.4K learners

A monorepo is a source-control strategy in which multiple distinct projects, services, or packages are stored together in a single repository rather than split across many separate repositories.

Definition

A monorepo is a source-control strategy in which multiple distinct projects, services, or packages are stored together in a single repository rather than split across many separate repositories.

Overview

In a polyrepo setup, each service, library, or application lives in its own repository with its own version history and release process. A monorepo takes the opposite approach, housing many related projects — perhaps a frontend app, several backend services, and shared internal libraries — under one repository root, all sharing a single commit history and, typically, a single set of tooling for building, testing, and linting. Large organizations including Google, Meta, and Microsoft run much of their internal codebase this way, and open-source tooling like Nx, Turborepo, and Bazel has made the approach practical for smaller teams too. The main appeal of a monorepo is atomic, cross-project changes: a developer can update a shared library and every project that depends on it in the same pull request, guaranteeing everything stays in sync rather than coordinating version bumps across separate repositories and waiting for each to catch up. It also simplifies code sharing, since internal packages can be imported directly without needing to be published to a package manager registry first, and it gives everyone visibility into the entire codebase rather than siloed access per repository. The trade-off is scale: as a monorepo grows to thousands of projects and millions of files, naive tooling (checking out the whole repo, running every test on every change, standard git operations) can become painfully slow, which is why large-scale monorepos typically require specialized build systems that understand the dependency graph well enough to build and test only what actually changed, along with remote caching to avoid redundant work across the team. It is often mentioned alongside Semantic Versioning in this space.

Key Concepts

  • Stores multiple projects or services in a single shared repository
  • Enables atomic, cross-project commits and pull requests
  • Simplifies internal code sharing without publishing to a package registry
  • Used at scale by organizations like Google, Meta, and Microsoft
  • Requires specialized tooling (Nx, Turborepo, Bazel) to stay performant at scale
  • Provides unified visibility and consistent tooling across all projects
  • Contrasts with a polyrepo approach of one repository per project

Use Cases

Coordinating changes across a frontend app and its backend services in one commit
Sharing internal UI component libraries across multiple products without publishing
Enforcing consistent linting, testing, and CI configuration across all projects
Simplifying dependency upgrades that must be applied across many packages at once
Enabling large engineering organizations to maintain visibility into related codebases
Using incremental build systems to test only what changed in a large codebase

Frequently Asked Questions