Monorepo (Monorepository)

Un Monorepo (Mono-repository) est une stratégie d'organisation de code source consistant à héberger plusieurs projets/applications/libraries dans un unique dépôt Git, par opposition à la stratégie polyrepo (un dépôt par projet). Approche utilisée massivement par Google (Piper, ~2 milliards de lignes de code en un repo), Facebook (Mercurial-based), Microsoft (Windows, Office), Twitter, Uber, Airbnb, Shopify, Stripe.

Avantages : (1) atomic changes cross-projects — un commit unique peut modifier multiple projets dépendants (refactor API + tous les consumers) ; (2) shared tooling et configuration centralisée (linters, formatters, CI configs, dependency versions) ; (3) code sharing facilité (extraire commons en libs internes sans publishing) ; (4) refactoring confiant (find/replace fonctionne globalement, tests cross-projets catch breakage) ; (5) collaboration et discovery (devs voient tout le code, peuvent contribuer cross-team) ; (6) une seule version de chaque dépendance externe (no version skew) ; (7) consistent code style ; (8) simpler dependency management (no internal package versioning hell).

Inconvénients/Challenges : (1) git operations slowdown à scale (clone, status, log sur 100k+ files lent — Google uses VFS for Git, Facebook uses Mercurial extensions, Microsoft GVFS/Scalar) ; (2) CI duration explosion si tout est rebuilt à chaque commit (besoin smart build systems avec change detection) ; (3) access control fine-grained complex (Git natif est all-or-nothing per repo) ; (4) deployment coupling risk (one bad commit can break unrelated services if pipeline mal configuré) ; (5) cognitive overhead (newcomers overwhelmed) ; (6) IDE performance peut souffrir.

Build systems spécialisés pour monorepos : (1) Bazel (Google open source, derivé de Blaze interne) — build incremental, hermetic, multi-language (Java, Go, Python, JS, C++, Rust), parallelization, remote caching, very fast on huge repos ; (2) Buck2 (Meta, successor of Buck, open source 2023) — Rust-based, similar to Bazel ; (3) Pants (Twitter/Foursquare origin) — Python-friendly ; (4) Nx (Nrwl, JS/TS-focused, popular React/Angular/Node monorepos) — change detection, distributed task execution, generators, plugin ecosystem ; (5) Turborepo (Vercel, JS-focused) — incremental builds, remote caching, simpler than Nx ; (6) Lerna (legacy JS, now maintained, used with Nx or alone) ; (7) Rush (Microsoft, JS) — strict package management ; (8) Pulumi/Bit ; (9) PNPM workspaces, Yarn workspaces, npm workspaces (simple JS workspaces).

CI strategies for monorepo : (1) change detection — only build/test projects affected by changed files (Nx affected, Turborepo --filter, Bazel query) ; (2) parallelization extensive ; (3) caching aggressive (remote cache shared between devs and CI) ; (4) sharded test execution ; (5) merge queues (GitHub merge queue, Aviator, Mergify) — prevent ouverture serialize merges avoiding semantic conflicts.

Monorepo vs Polyrepo decision : (1) tight coupling, shared libs, many small services → monorepo (Google, Microsoft style) ; (2) loose coupling, independent teams, polyglot extreme, open source mix → polyrepo (typical at smaller startups, microservices with strong service ownership). Hybride possible : multiple medium-size monorepos par domain.

Tools modernes : Nx + Vercel (JS), Bazel for polyglot, GitHub Actions + Turborepo for JS, Buildkite + Bazel.