Monorepo

A monorepo is a single repository that holds several projects, such as applications and shared libraries, usually with tooling that understands how they depend on each other.

In a monorepo, the applications and the libraries they share live in one repository with one history. A change that touches a library and its consumers is a single commit and a single pull request. There are no internal package versions to publish and bump, because every project uses the current state of the others.

Tools such as Nx or Turborepo make this workable at scale. They build a graph of the projects, run tasks only for the projects affected by a change, and cache the results.

Example

A company keeps a shell, two remotes and its shared libraries in one repository:

apps/shell
apps/orders
apps/invoices
libs/ui
libs/auth

A developer renames an input of the button in libs/ui. The compiler immediately shows every usage in every application, and the same pull request fixes them. CI builds and tests only the projects that depend on libs/ui.

Common misunderstanding

Monorepo and monolith are often confused. The repository is where code is stored. It says nothing about how the code is deployed. Applications in a monorepo can be built, versioned and deployed independently, and micro-frontends are frequently developed this way.

The opposite assumption is also wrong. Putting code in one repository does not create good boundaries. Without rules, any project can import from any other, and the result is a tangle. Enforce dependency rules with lint, define code owners per folder, and keep the main branch releasable at all times.

Tooling is part of the decision. Without affected-only builds and caching, CI time grows with the size of the repository. See micro-frontends for how a platform can be laid out.

Related terms

• Polyrepo
• Nx
• CI/CD pipeline