Monorepo & Build Systems

A single version-control repository containing multiple related projects or packages; enables code sharing and atomic cross-project changes.

"Moving to a monorepo let us make a breaking change to a shared library and update all five consuming apps in a single pull request with one CI run."

Architecture where each project lives in its own repository; provides maximum isolation but makes cross-project changes and code sharing harder.

"The polyrepo setup meant a shared utility change required five separate PRs, five CI runs, and coordinated releases — the coordination cost eventually drove the monorepo migration."

A directory within a monorepo treated as an individual package; configured in the root package.json workspaces array or pnpm-workspace.yaml.

"Each app and library is a workspace — running npm install at the root hoists shared dependencies and creates symlinks so packages can import each other."

Declaration of dependency order between build tasks: lint must pass before test, test before build. Enables correct parallelisation without race conditions.

"The Turborepo pipeline configuration ensures the shared-ui build task completes before any app that depends on it starts its own build."

Sharing build and test outputs over a network so any developer or CI machine can reuse a result if the inputs have not changed.

"With Nx Cloud remote cache, the second developer to build after a merge gets a 95% cache hit rate — their CI run completes in 45 seconds instead of 8 minutes."

Running tasks only for projects whose source files changed since the base branch: nx affected:test or turbo run test --filter=[HEAD^1].

"On a PR that only changes the auth library, nx affected:test runs tests for auth and the three apps that depend on it — the other 12 apps are skipped."

Directed acyclic graph showing relationships between monorepo packages; used to determine correct build order and the scope of affected projects.

"The dependency graph shows design-tokens has 14 dependents — changing a token triggers rebuilds for all 14 packages in topological order."

Rule preventing circular or disallowed imports between packages; enforced by Nx's enforce-module-boundaries ESLint rule.

"The project boundary rule prevents the shared utility library from importing from any feature library — violations fail CI immediately."

A package within the monorepo that is imported by multiple applications; changes require testing all dependent projects.

"The shared form-validation library is used by four apps — any change to it triggers the affected command to run tests across all four."

Webpack/Vite technique for loading separately deployed and built packages at runtime; the foundation of micro-frontend architectures.

"Module federation lets the checkout team deploy independently — the shell app loads the checkout micro-frontend from its own CDN URL at runtime."

Tool for managing versioning and changelogs in publishable monorepo packages; developers add a changeset file describing the impact, and CI bumps versions and publishes.

"The developer runs changeset add, selects the affected packages and bump type, and writes a description — the release CI uses this to update package.json versions and the changelog."

Monorepo build tool by Nrwl; provides project graph visualisation, task scheduling with remote caching, and plugins for React, Angular, Node.js, and more.

"We use Nx for our React and NestJS monorepo — nx affected:build only rebuilds changed packages, and Nx Cloud caches results across the whole team."

Vercel's monorepo build system focused on task pipelining and remote caching; zero-config for JavaScript and TypeScript projects.

"Turborepo's turbo.json pipeline reduced our CI time from 18 minutes to 4 minutes by running lint, test, and build in parallel with remote cache hits."

Google's open-source, multi-language build system; hermetic builds with fine-grained input/output caching; used in large polyglot monorepos.

"Our platform team uses Bazel for the Go, Python, and TypeScript monorepo — hermetic builds ensure the exact same artefact is produced on every machine."

The build system found a cached output matching the current inputs and skipped re-execution; measured as a percentage (cache hit rate) to evaluate build system effectiveness.

"After enabling remote caching, our cache hit rate reached 88% — engineers no longer rebuild packages that colleagues already built with identical inputs."