As a monorepo grows to hundreds of contributors and thousands of packages, what specific tooling investments are needed to keep builds, tests, and version control usable -- and what breaks if those investments aren't made?

## Why naive tooling breaks at scale The core mechanical problem a large monorepo creates is that most VCS and build tools were designed with an implicit assumption: repository size and 'amount of work for a given operation' scale together, and that's fine because repositories are small. Once a repository holds thousands of packages and history spans years, that assumption breaks -- a one-line change to a leaf utility should trigger a tiny, fast build/test cycle, but naive tools instead do work proportional to the whole repository, not the change. Naive tools here are: - a build script with no dependency tracking - a CI job that just runs the full test command at the root - a `git clone` that fetches full history Fixing this requires deliberately building or adopting tooling at three layers. ## The first layer: a dependency-aware build system The first and most important layer is a **dependency-aware build system**: - `Bazel` (Google's open-sourced Blaze) - `Buck2` (Meta) - `Pants` - JS-ecosystem tools like `Nx` and `Turborepo` These systems require every package/target to declare its dependencies explicitly, which lets the tool construct a full dependency graph of the repository. When a change comes in, the build system computes the exact transitive set of targets whose inputs changed -- the **'affected target'** set -- and only rebuilds/retests those, skipping everything untouched. Layered on top is **remote/content-addressable caching**: if a target's inputs (source files, dependency versions, compiler flags) hash to something the cache has already built, the result is fetched instead of rebuilt, even across different engineers' machines or CI runs. This is what lets Google claim most builds are cache hits rather than full recompiles despite a codebase with billions of lines. ## The second layer: CI orchestration The second layer is **CI orchestration** built on that same affected-target computation: instead of running the entire test suite on every pull request, CI computes which test targets are reachable from the changed files and runs only those, often sharded across many parallel workers. This keeps PR feedback time roughly proportional to the size of the change, not the size of the repository. ## The third layer: VCS and filesystem scaling The third layer is **VCS/filesystem scaling**, because even with smart builds, a full checkout and full history of a multi-million-file repository is itself too large to be practical on a laptop. Solutions here include: - **sparse or partial checkout** -- only materializing the subdirectories a given team touches - **virtual filesystems** that lazily fetch file contents on first access -- Meta's `EdenFS` and Microsoft's VFS for Git (built specifically so the Windows source tree, hundreds of gigabytes, could live in a single Git-compatible repo) are the best-known examples Google's Piper doesn't use Git at all; it's a custom, centralized, massively sharded backend accessed by most engineers through a copy-on-write client (CitC) rather than a local full clone. ## What the three layers cost The trade-off is real and worth naming honestly: all three layers are expensive to build, adopt, and maintain. Adopting `Bazel` typically means rewriting build configuration for every package in an explicit, hermetic style (no implicit classpath scanning, no ambient environment dependencies), which is a significant one-time migration cost and an ongoing discipline cost -- engineers must correctly declare dependencies or the affected-target computation silently misses things. Remote caching and CI sharding require infrastructure that someone has to run and pay for. This is precisely why smaller organizations often shouldn't reach for a 'Google-style' monorepo setup prematurely: the tooling investment only pays for itself once repository size and contributor count are large enough that naive tooling has actually become the bottleneck. ## The failure mode when the investment is skipped The failure mode when this investment is skipped is very recognizable: - CI queue times creep from minutes to tens of minutes to hours as the repo grows, because every job builds/tests everything regardless of what changed - `git clone` and `git status` become multi-minute operations that new hires dread on day one - engineers start hand-maintaining lists of 'which tests to skip,' which is fragile and drifts out of date - eventually, under enough pain, teams begin either forking pieces out into separate repos (silently reintroducing polyrepo problems) or simply stop running the full test suite locally, pushing more bugs into CI or production The Windows source-depot-to-Git migration and Google's decades of Blaze/Piper investment are the two most cited proof points that this class of tooling is not optional cosmetic polish but the actual precondition for a monorepo working at scale -- without it, 'monorepo' just means 'one big slow repository.'