Monorepo en multirepo: definities zonder verkeerde koppelingen
| Criterium | Monorepo | Multirepo |
|---|---|---|
| Cross-project wijzigingen | Eén commit of PR kan meerdere projecten omvatten | Meestal meerdere repositories, versies en PR's |
| Dependencies | Eenvoudiger centralisatie en gedeelde regels | Meer versieonafhankelijkheid |
| CI | Vereist graph-aware selectie, cache en schaal | Kleinere natuurlijke scope per pipeline |
| Toegang | Path ownership via regels en reviews | Natuurlijke isolatie op repositoryniveau |
| Tooling | Meer gedeelde standaarden | Meer vrijheid per project |
| Releases | Kunnen onafhankelijk zijn maar vragen orchestratie | Natuurlijk gescheiden pipelines |
Een monorepo is één repository met meerdere logisch gescheiden projecten, zoals applicaties, services, libraries of tools. Multirepo, ook polyrepo genoemd, houdt deze onderdelen in aparte repositories. Repositorygrenzen zijn grenzen van broncodebeheer, niet automatisch deploymentgrenzen. [1][13][15]
Een monorepo kan dus veel onafhankelijk gedeployde services bevatten, terwijl een multirepo-opzet modules van één groot systeem kan bevatten. Repositorystrategie gelijkstellen aan monolith versus microservices leidt tot verkeerde architectuurbeslissingen.
Wat Google Research laat zien: beide modellen hebben echte voordelen
Google Research onderzocht engineers met ervaring in beide modellen en vond zichtbaarheid van de volledige codebase als belangrijk monorepo-voordeel. Dat helpt bij het vinden van herbruikbare API's, voorbeelden en het bijwerken van afhankelijke code tijdens migraties. Ook centrale dependency management werd gewaardeerd. [1]
Hetzelfde onderzoek noemt multirepo-voordelen: meer vrijheid in toolchains, sterkere toegangsgrenzen en meer stabiliteit tussen projecten. Ook de kwaliteit van tooling rond het repositorymodel blijkt een belangrijke factor. [1]
Cross-project wijzigingen: het duidelijkste praktische monorepo-voordeel
Als één interfacewijziging backend, frontend, libraries en tests tegelijk raakt, kan een monorepo de hele migratie in één commit of pull request opnemen. Google noemt het bijwerken van afhankelijke code tijdens API-migraties als belangrijk voordeel van een gedeeld repository. [1][2]
In multirepo wordt dezelfde verandering vaak een reeks stappen: producer wijzigen, versie publiceren, consumers bijwerken en meerdere pull requests coördineren. Automatisering helpt, maar repositorygrenzen blijven integratieprocesgrenzen.
Dependencies en versies: centralisatie tegenover onafhankelijkheid
Monorepos maken het eenvoudiger om gedeelde dependencyversies gelijk te houden en lokale packages direct te refereren. Yarn Workspaces koppelt packages binnen één project, terwijl Constraints regels voor versies of `package.json` over de hele workspace kan afdwingen. [13][14]
Multirepo geeft elk project meer vrijheid over versies en upgradeplanning, maar gedeelde libraries kunnen uiteenlopen. Dit model werkt goed wanneer contracten stabiel zijn en artifacts via gecontroleerde registries worden gepubliceerd.
CI in een monorepo: alles opnieuw bouwen bij elke commit is het verkeerde model
Een groot monorepo hoort niet na elke wijziging alle tests en builds te draaien. Nx `affected` gebruikt Git-geschiedenis en de projectgraph om de kleinste getroffen projectset te bepalen en niet-gerelateerd werk over te slaan. [4]
Remote caching deelt al berekende resultaten tussen developer machines en CI, terwijl distributed execution resterende taken over meerdere machines verdeelt. Bazel pakt hetzelfde probleem aan met remote execution en caching voor build- en testacties. [5][7][8]
Multirepo-CI: kleinere scope betekent niet nul coördinatie
In multirepo ziet één pipeline van nature minder code, waardoor build en tests eenvoudiger tot één project te beperken zijn. Dat is een echt voordeel bij los gekoppelde services met duidelijk eigenaarschap.
De coördinatiekosten verschijnen bij afhankelijkheden tussen repositories. Een wijziging in een gedeelde library of contract kan publicatie, meerdere repo-updates, versiecompatibiliteit en integratietests vereisen. Google noemt stabiliteit als multirepo-voordeel en zichtbaarheid en migraties als monorepo-sterktes. [1]
Architectuurgrenzen: een monorepo zonder regels wordt snel problematisch
Een gedeeld repository mag niet betekenen dat elk project vrij naar elk ander project importeert. Nx kan modulegrenzen declaratief afdwingen via projecttags en dependency constraints en zo ongewenste imports en ongeplande koppeling blokkeren. [6]
In multirepo bestaan sommige grenzen fysiek doordat code in aparte repositories staat. Dat vervangt architectuur niet: sterke koppeling kan nog steeds ontstaan via API's, databases, queues of gedeelde libraries.
Toegang en beveiliging: multirepo heeft vaak het eenvoudigste model
GitHub kent rollen en permissies toe op repositoryniveau. Aparte repositories passen daarom natuurlijk wanneer teams of contractors verschillende codebases mogen zien. Rollen lopen van Read tot Admin. [11]
In een monorepo kunnen CODEOWNERS en rulesets reviews voor specifieke paden en teams afdwingen, maar dit zijn ownership- en goedkeuringsmechanismen. Als harde scheiding van codezichtbaarheid nodig is, sluiten aparte private repositories meestal directer aan op het toegangsmodel. [10][12]
Releases en deployment: één repository betekent niet één release
Yarn beschrijft workspaces als meerdere packages binnen één project en noemt expliciet dat ze onafhankelijk gedeployed kunnen worden. Gradle multi-project builds splitsen een systeem eveneens in logische subprojecten met eigen dependencies en taken. [13][15]
Een monorepo kan dus aparte pipelines en versies hebben voor applicaties, services en libraries. Multirepo biedt deze onafhankelijkheid natuurlijker, maar heeft meer automatisering nodig wanneer meerdere releases als één productwijziging moeten worden gecoördineerd.
Repositorygrootte en Git: zeer grote monorepos vragen bewuste tooling
Google beschreef een intern monorepo met miljarden regels code, maar benadrukte ook de speciaal gebouwde infrastructuur. Dat voorbeeld bewijst dat monorepos ver kunnen schalen, niet dat die schaal gratis of geschikt voor elk bedrijf is. [2]
Modern Git biedt `sparse-checkout` om de working tree tot een geselecteerde subset van tracked files te beperken. Het helpt bij grote repositories, al markeert de Git-documentatie dit gedrag nog steeds als experimenteel en wijzigbaar. [9]
Tooling in 2026 verlaagt de kosten van beide aanpakken
In JavaScript bestaan native workspaces plus volwassen projectgraphs, caching en affected-only CI. In het JVM-ecosysteem ondersteunt Gradle multi-project builds, terwijl composite builds onafhankelijke builds kunnen combineren en samen ontwikkelen zonder eerst artifacts te publiceren. [13][15][16]
Dit is ook belangrijk voor multirepo: aparte repositories hoeven geen volledig losgekoppelde lokale workflow te betekenen. Composite builds laten zien hoe onafhankelijke buildgrenzen behouden kunnen blijven terwijl projecten samen worden getest. [16]
AI coding agents voegen in 2026 een nieuw criterium toe
Nx-documentatie uit 2026 stelt dat coding agents profiteren van volledige monorepo-context, een bevraagbare projectgraph, snelle affected-only verificatie en afgedwongen grenzen. Omdat Nx een leverancier van monorepo-tooling is, moet dit als productperspectief worden gezien en niet als onafhankelijk bewijs. [3]
In de praktijk kan gedeelde context een agent helpen om een contract en consumers in één taak te wijzigen. Multirepo kan daarentegen de hoeveelheid code en permissies binnen één agentsessie beperken. Het is een extra criterium, geen doorslaggevend argument op zichzelf.
Wanneer monorepo kiezen
Monorepo is vooral aantrekkelijk wanneer applicaties en libraries vaak samen veranderen, veel teams componenten delen en atomic refactors en een zichtbare dependency graph nodig zijn. Google Research ondersteunt deze voordelen via zichtbaarheid, API-discovery, gebruiksvoorbeelden, migraties en centrale dependencies. [1]
Voorwaarde is investeren in modulegrenzen, selectieve CI, caching, code ownership en automatisering. Zonder die controles verplaatst groei de complexiteit alleen naar één enorme pipeline. [4][5][6]
- Veel wijzigingen over frontend, backend en libraries heen.
- Veel gedeelde code en gemeenschappelijke engineeringstandaarden.
- Behoefte aan atomic refactors.
- Eén of compatibele toolchain.
- Bereidheid om te investeren in graph, cache en selectieve CI.
- Geen harde eis om het grootste deel van de code voor andere interne teams te verbergen.
Wanneer multirepo kiezen
Multirepo is sterk wanneer domeinen duidelijke grenzen hebben, teams onafhankelijke toolchains, levenscycli en permissies nodig hebben en cross-project wijzigingen relatief zeldzaam zijn. Google noemt toolflexibiliteit, toegangscontrole en stabiliteit als betekenisvolle voordelen. [1]
Een ander duidelijk signaal is code met beperkte zichtbaarheid, aparte compliance-eisen of afzonderlijke contractor-groepen. GitHubs repositoryrollen ondersteunen deze scheiding direct. [11]
- Sterke teamautonomie en aparte levenscycli.
- Verschillende talen, toolchains en buildprocessen.
- Strikte toegangs- of compliance-eisen.
- Weinig wijzigingen over veel projecten heen.
- Stabiele contracten en volwassen versiemanagement.
- Onafhankelijke pipelines zijn belangrijker dan één platformbrede dependency graph.
Hybride model en praktische keuze in 2026
| Situatie | Standaardrichting | Waarom |
|---|---|---|
| Veel wijzigingen over meerdere apps en libraries | Monorepo | Atomic refactors en gedeelde dependency graph |
| Teams mogen niet alle code zien | Multirepo | Repositorypermissies vereenvoudigen isolatie |
| Teams hebben verschillende toolchains en lifecycles | Multirepo | Minder centrale standaardisatie |
| Sterk gedeeld platform en libraries | Monorepo | Betere zichtbaarheid en centrale dependencies |
| Veel kleine services | Hangt ervan af | Frequentie van gedeelde wijzigingen telt meer dan aantal services |
| Gemengde domein-, toegangs- en technologie-eisen | Hybride | Domeinmonorepos plus geselecteerde aparte repositories |
De keuze hoeft niet binair te zijn. Een organisatie kan domeinmonorepos gebruiken voor sterk samenhangende producten, aparte repositories voor securitygevoelige of klantspecifieke componenten en gedeelde packages via registries. Gradle composite builds laten zelfs zien hoe onafhankelijke builds samen ontwikkeld kunnen worden. [16]
Meet vóór een migratie de frequentie van cross-project wijzigingen, gedeelde dependencies, CI-duur, het aantal repositories dat een typische feature raakt, toegangsvereisten en releasecoördinatiekosten. Die gegevens zouden de repositorytopologie moeten bepalen.
