Monorepo & Build Systems Language

A monorepo is a single version-control repository that contains multiple projects, applications, and shared libraries. Engineers explain it to stakeholders by saying it "enables atomic cross-project changes", "eliminates version-skew between shared packages", and "makes dependency relationships explicit and auditable across the entire codebase".

Build caching stores the outputs of previous task runs and replays them when inputs have not changed, dramatically reducing CI times. Engineers say a cache "hits" or "misses", refer to "remote cache backends" (such as Vercel Remote Cache or Nx Cloud), and describe the process as "restoring artefacts from cache" rather than rebuilding from scratch.

The "affected" command (used in both Nx and Turborepo) analyses the dependency graph to determine which projects are impacted by a given set of changed files. Engineers say "only run tests for affected packages" or "the affected graph shows that a change to the UI kit touches fourteen downstream consumers".

Turborepo is described in terms of "pipelines" defined in turbo.json, "task dependencies" with the dependsOn key, and a focus on pure task orchestration with minimal opinion on project structure. Nx adds "generators", "executors", "project graph visualisation", and an optional "Nx Cloud" distributed task execution layer on top of a similar caching model.

Bazel is a language-agnostic, hermetic build system originally developed at Google, designed for very large codebases with polyglot stacks. Engineers describe "BUILD files", "rules", "sandboxed execution", and "deterministic outputs" as Bazel's distinguishing features, contrasting it with Turborepo's lighter-weight, JS-ecosystem-native approach.

A hermetic build is one that is fully isolated from the host environment: it uses only explicitly declared inputs and produces byte-for-byte reproducible outputs regardless of when or where it runs. Teams use phrases like "hermetic execution environment", "no implicit host dependencies", and "reproducible build artefacts" when justifying a move to Bazel or similar systems.

The debate is framed around trade-offs in "atomic commits across package boundaries", "tooling complexity at scale", "CI pipeline performance", and "team autonomy". Advocates of monorepos highlight "single source of truth" and "simplified refactoring", while polyrepo advocates cite "independent deployment cadences" and "reduced blast radius from breaking changes".

A workspace is a named project or package within the monorepo that has its own package.json (or equivalent) and can be built, tested, and published independently. Package managers such as npm, Yarn, and pnpm support workspaces natively, allowing engineers to "hoist shared dependencies" and "link local packages without publishing to a registry".

Migration planning language includes "incremental adoption", "strangler-fig pattern", "import path aliasing", "codemods to update internal references", and "establishing workspace boundaries for existing packages". Teams also discuss "change management for CI pipelines" and "training developers on the new task graph mental model".

Monorepo architecture decisions involve cross-functional communication with platform teams, DevOps engineers, and engineering managers who use precise tooling vocabulary in RFCs, architecture decision records (ADRs), and pull request discussions. Non-native English speakers who master this vocabulary can contribute more confidently to high-stakes technical decisions at scale.