The Ingredients of a Productive Monorepo

Original Article ↗ Hacker News Discussion ↗

Monorepo Advantages (When Done Well)

  • Many commenters report large productivity gains from well-run monorepos: easier refactors, clearer service/ownership graphs, and far better code discovery and reuse.
  • Atomic code changes across services and libraries are a major draw: you can update a library and all its call sites in one change and keep CI green.
  • Shared tooling, consistent layouts, and common dev-environment setup (often with dev servers or Nix-like environments) drastically simplify onboarding and cross-team work.
  • For small-to-mid orgs (<~100 engineers, tens of services), Git usually scales fine and monorepo benefits are seen as “almost all upside.”

Costs, Scale, and Tooling Complexity

  • At “big tech” scale, supporting a single org-wide monorepo often requires custom VCS or heavy tooling teams (Bazel/Buck2, remote execution, virtual filesystems, determinators, etc.).
  • Several note that small teams mistakenly copy Google/Meta patterns (Bazel, k8s, huge infra) and drown in complexity they don’t need.
  • Tooling gaps are real: multi-language, multi-IDE monorepos are hard; language-specific systems (e.g., JS/TS with NX, Rush, npm workspaces) are much easier.

Monorepo vs Polyrepo Tradeoffs

  • Monorepo strengths:
    • Discoverability and single source of truth.
    • Easier “change everything that breaks” migrations and large refactors.
    • One version of internal libraries by default, forcing owners to bear the cost of breaking changes and discouraging long-lived forks.
  • Polyrepo strengths:
    • Clearer boundaries and isolation; teams can version and ship independently.
    • Can avoid central “hero” infrastructure teams and reduce blast radius of shared changes.
  • Several argue polyrepos already spend “millions” on tooling and process, just fragmented and invisible.

Testing, CI, and Determinators

  • Running “all tests for all changes” becomes infeasible quickly; people stress:
    • Need for change-based test selection (determinators) and caching/remote execution.
    • Distinction between fast, local/PR feedback vs slow, exhaustive pre-deploy suites.
  • Some argue multi-hour pre-deploy test suites are acceptable if developers can work on other tasks; others strongly prefer “minutes” to enable fast iteration and advanced rollout techniques.

Versioning and Breaking Changes

  • A central theme: in monorepos you can’t (by default) keep a consumer on an old version; you must:
    • Update all consumers,
    • Provide backwards-compatible APIs and migrate gradually, or
    • Externalize and version the library via an artifact store.
  • This is seen both as a strength (forces real ownership and avoids zombie versions) and as a restriction vs polyrepos’ ability to pin old versions.

Org, Security, and Process Effects

  • Repo structure feeds back into org structure (inverse Conway’s law): monorepos encourage shared infra and central ownership; polyrepos encourage autonomy but also divergence.
  • Permissions typically rely on per-directory ownership (CODEOWNERS/OWNERS) and enforced reviews; monorepo ≠ everyone writes everywhere.
  • Some worry monorepos reduce experimentation and lock runtimes/toolchains; others counter that’s an org/process issue, not inherent to monorepos.