Monorepo definition
A monorepo is a single version control repository that holds the code for many projects, such as multiple applications, services and shared libraries, instead of keeping each in its own repository. Companies including Google and Meta use very large monorepos, and tools such as Nx, Turborepo and Bazel make the approach practical for teams of any size.
How does a monorepo work?
A monorepo typically has folders for applications, such as a web app, a mobile app and an API, and folders for shared packages, such as UI components, TypeScript types, API clients and configuration. Workspace features in pnpm, npm or Yarn link internal packages together, so the web and mobile apps import the same shared code directly without publishing it to a registry first.
Worked example: a product team keeps its Next.js website, React Native app, Node.js API and a shared package of data types in one repository. When the API adds a field, a single pull request updates the type, the API and both apps, and CI tests everything that depends on the change together. In separate repositories, the same change would need several coordinated pull requests and version bumps.
Monorepo vs polyrepo
In a polyrepo setup, each service or library has its own repository, pipeline and release cycle. Teams get clear boundaries and independence, but sharing code means publishing packages, and cross-cutting changes require coordination across many repositories. A monorepo makes sharing and large refactors easy and gives one consistent set of tools, at the cost of needing smarter build tooling and clear ownership rules. Neither is universally better; the choice depends on how tightly your projects are connected.
Monorepo tools
The key capability of monorepo tools is understanding the dependency graph: which projects depend on which, so CI can build and test only what a change affects, and cache results so unchanged work is never repeated. Remote caching shares those results across developers and CI.
- Nx: graph-aware task running, caching and code generators for JavaScript and beyond.
- Turborepo: fast task orchestration and remote caching for JavaScript and TypeScript.
- Bazel: Google's open-source build system for very large, multi-language repositories.
- Pants and Buck2: scalable build systems for polyglot codebases.
- Rush and Lerna: tools for managing many JavaScript packages and releases.
- pnpm, npm and Yarn workspaces: the foundation for linking JavaScript packages.
Benefits and challenges
Benefits include atomic changes across projects, easy code sharing, one set of linting, testing and build tools, consistent dependency versions, and visibility into how code is used across the organization. Large refactors become a single reviewed change instead of a multi-week coordination effort.
Challenges include slow CI if every change rebuilds everything, Git performance on very large repositories, access control when not everyone should see all code, and the risk of tightly coupling projects that should stay independent. Ownership files such as CODEOWNERS route reviews, and tools such as Changesets manage versioning for packages released separately.
When to choose a monorepo
A monorepo works well when several applications share code and types, such as a web app, mobile app and backend built by one product team, or when an organization wants consistent tooling and frequent cross-project refactoring. Separate repositories suit independent products, different security boundaries or teams with very different release cycles. Nexzem often sets up TypeScript monorepos with Turborepo or Nx for clients building web and mobile apps together, with affected-only CI so builds stay fast as the codebase grows.