Glossary / Monorepos

Monorepos

A monorepo stores multiple applications and packages in one version-controlled repository. It can make coordinated changes, shared tooling, and dependency-aware builds easier, while introducing challenges in boundaries, CI scaling, ownership, dependency isolation, and release management.

Structure and task graph

A monorepo often contains packages or workspaces, each with a manifest and explicit dependency edges. The package graph informs build order, affected-task selection, and versioning. Tooling such as npm/pnpm/Yarn workspaces manages local package links; task runners add caching, affected computation, and parallel execution. A workspace is a package-management concept; “monorepo” is the repository organization and does not require a specific tool.

Shared configuration should be versioned and composable, but over-centralization can make package-specific needs hard to express. Hoisted dependencies can hide undeclared imports. Independent package boundaries should have clear public APIs and avoid deep relative imports across package roots.

Tradeoffs and governance

Monorepos simplify atomic cross-package changes and standardize CI, but increase repository size and can couple release cadence. Ownership rules, CODEOWNERS, package-level changelogs, and selective CI help maintain autonomy. Remote cache trust, secret separation, and untrusted pull request handling matter when CI executes packages from many teams.

Engineering guidance

Adopt a monorepo when coordinated changes or shared infrastructure justify the operational cost. Define package boundaries, enforce declared dependencies, use affected builds based on a correct graph, and maintain a clean full-build path. Monitor CI queue time, cache hit rate, install time, and package coupling.

Interview questions

  1. Monorepo vs monolith? Monorepo is a version-control organization; it can contain many independently deployable services/packages.
  2. Why model package edges? Enables boundaries, build order, impact analysis, and selective CI.
  3. How prevent phantom dependencies? Isolated resolution, lint rules, package managers with strict linking, and explicit manifests.
  4. What is the main CI risk? Incorrect affected/caching logic can skip necessary work or trust unsafe artifacts.
  5. When not use a monorepo? When coordination benefits do not outweigh repo/CI/release governance costs.

References