Problém polyrepo
Polyrepo přístup — jeden repozitář na balíček, aplikaci nebo službu — funguje, dokud nepřestane. Aktualizujete sdílenou utilitu a potřebujete ji publikovat, pak aktualizovat verzi v 5 konzumujících repozitářích, pak otevřít 5 PR, pak čekat na 5 CI pipeline. Změna, která by měla trvat 10 minut, trvá celý den. Monorepa to řeší tím, že všechno dají do jednoho repozitáře: sdílené knihovny, frontendové aplikace, backendové služby a konfigurace — vše verzované společně.
Turborepo vs. Nx
Turborepo a Nx jsou dva vedoucí nástroje pro TypeScript monorepa. Oba poskytují orchestraci tasků (spuštění buildů přes všechny balíčky v pořadí závislostí), cachování (přeskočení práce, která se nezměnila) a detekci ovlivněných balíčků (testování jen balíčků ovlivněných vašimi změnami). Turborepo je jednodušší — je to build systém, který dělá jednu věc dobře. Nx je víc opinionated — zahrnuje generátory kódu, grafy závislostí a ekosystém pluginů. Pro většinu týmů pod 50 vývojářů vyhrává jednoduchost Turborepo.
Jasné hranice balíčků
Klíčem ke zdravému monorepu jsou jasné hranice balíčků. Každý balíček by měl mít jednu zodpovědnost, dobře definované veřejné API (exportované přes index.ts) a vlastní tsconfig.json. Použijte TypeScript project references pro rychlé inkrementální buildy. Vynucujte pravidla závislostí — balíček UI komponent by neměl importovat z databázového balíčku. Nástroje jako Nx module boundary rules nebo vlastní ESLint pravidla to udělají vymahatelným, ne jen aspiračním.
Superschopnost sdílené konfigurace
Sdílená konfigurace je podceňovaná superschopnost. Jeden ESLint config, jeden Prettier config, jedna tsconfig base, jeden Tailwind preset — sdílené přes všechny balíčky. Když aktualizujete lintovací pravidlo, aplikuje se všude okamžitě. Když onboardujete nového vývojáře, naučí se jednu sadu konvencí. Ve steezr každý klientský projekt začíná jako Turborepo monorepo se sdílenými configy, UI balíčkem a aplikačně specifickými balíčky. Počáteční investice se vrátí během prvního měsíce.
