Monorepo: Many projects in one repository

In short: Several related programs and libraries live together in a single Git repository instead of many separate ones.

In more detail: In a monorepo, frontend, backend, shared libraries and tools share one repository, but usually have their own folders and packages. Large companies such as Google or Meta work this way, and in the JavaScript world it is common with tools such as pnpm workspaces, Nx or Turborepo. The counterpart is the polyrepo, in which each project has its own repository.

In Depth

Structure

my-company/
  apps/
    web/
    api/
  packages/
    ui/            shared building blocks
    config/
  package.json     workspace configuration

The packages refer to each other through local dependencies, and one command installs everything.

Advantages

• Atomic changes: a change to a library and all its users can be done in one commit and pull request.
• Shared tooling: one lint and test setup, one versioning strategy.
• Easy code sharing without publishing packages.
• Overview: everything in one place, easy to search.

Disadvantages and remedies

The repository becomes large, and naive pipelines rebuild everything on every change. Modern tools build only what is affected (dependency graph) and use a build cache, shared across the team too. Access rights are harder to separate per project; code-owner files (CODEOWNERS) help. Very large repositories need Git features such as sparse checkout.

Deciding

For a small team with related parts a monorepo is often more convenient. If projects are independent, with separate teams and release cycles, a polyrepo can make more sense. A monorepo is not the same as a monolith: services can also be built and delivered separately there.

See also: Git, CI/CD pipeline, SemVer, Modular monolith