Monorepo

Atomické změny. Přejmenujete pole ve sdíleném typu, upravíte všechny obrazovky, které ho používají, a nasadíte společně — a když testy napříč repozitářem neprojdou, změna se nikdy nedostane ven. Se samostatnými repozitáři je stejná úprava týden koordinace a období, kdy produkce běží na nekompatibilní verzi.

Jeden toolchain, jedno CI pro všechno, jedno místo pro konvence. Sdílená UI komponenta, kterou používá e-shop i klientský portál, se opraví jednou a otestuje proti oběma. To je skutečná výhra pro malý tým: méně věcí udržovat v souladu, ne méně složek.

Z monorepa vyroste pravidla, o která nikdo nežádal: který balíček smí importovat který, kdo vlastní sdílenou složku, kdy změna design systému potřebuje schválení, které pipeline běží na jakou změnu. Bez těch pravidel se sdílený balíček stane všech, pak nikoho a repozitář se změní v lepidlo, na kterém visí všechno a které nikdo neudržuje.

Pozornost si žádá i nástrojář. Monorepo s deseti balíčky a naivním buildem kompiluje všechno při každé změně; potřebujete inkrementální build, task runner a vzdálenou cache, aby CI zůstalo pod deseti minutami. Nad zhruba třiceti balíčky a více týmy ty náklady obvykle převáží — samostatné repozitáře s pořádně verzovaným balíčkem se snáz vysvětlují.

Dva projekty, které nesdílí nic než logo, jeden repozitář nepotřebují. Knihovna od dodavatele, jednorázový skript nebo služba s úplně jiným cyklem nasazení jsou jednodušší ve vlastním domově. A projekt jednoho člověka tooling většinou vůbec nepotřebuje — stačí běžná složka se sdíleným balíčkem, který se prostě importuje přes cestu.

Poctivý argument je nudný: monorepo se vyplatí, když aplikace skutečně sdílí kód a vlastní je jeden tým. Když ne, zaplatili jste koordinaci a nedostali ani jednu atomickou změnu.