Monorepo-Tooling-Entscheidungen mit Claude durchdenken

1. Die eigentliche Grundfrage: Monorepo oder Polyrepo

Bevor überhaupt eine Tooling-Entscheidung ansteht, lohnt sich die vorgelagerte Frage, ob ein Monorepo für die eigene Organisation überhaupt der richtige Schritt ist. Ein Monorepo bündelt mehrere, oft unabhängig deploybare Projekte in einem einzigen Repository und verspricht einheitliches Tooling, geteilten Code und atomare Änderungen über Projektgrenzen hinweg, erkauft sich das aber mit zusätzlicher Build-Komplexität und potenziell längeren CI-Laufzeiten ohne geeignetes Caching.

Claude lässt sich gezielt einsetzen, um diese Grundsatzfrage anhand konkreter, im Prompt mitgegebener Fakten durchzudenken, statt sich auf eine pauschale Trend-Empfehlung zu verlassen. Relevante Eingabegrößen sind die Anzahl der Teams, die Häufigkeit geteilter Code-Änderungen zwischen Projekten, die aktuelle Deployment-Kadenz jedes einzelnen Projekts und die bereits vorhandene CI/CD-Infrastruktur, die eine Migration entweder erleichtert oder erschwert.

2. Ein Prompt für die strukturierte Grundsatzabwägung

Damit die Antwort belastbar wird, sollte der Prompt konkrete Zahlen zum eigenen Setup enthalten, statt nur abstrakt nach Monorepo oder Polyrepo zu fragen. Je mehr reale Kontextdaten mitgegeben werden, desto konkreter und weniger generisch fällt die Abwägung aus.

# Claude Code: strukturierte Monorepo-vs-Polyrepo-Abwägung
claude "Wir haben 4 Teams mit insgesamt 22 Entwicklern, 9 separate
Repositories (3 Frontend-Apps, 4 Services, 2 geteilte Bibliotheken).
Geteilter Code wird aktuell über npm-Pakete in einer privaten Registry
verteilt und etwa zweimal pro Woche manuell aktualisiert. Deployment-
Kadenz variiert stark: Frontend täglich, Services wöchentlich.
Bewerte anhand dieser Zahlen, ob ein Monorepo sinnvoll wäre, und
nenne konkrete Kriterien, die für und gegen den Wechsel sprechen."

3. Nx, Turborepo und Bazel im direkten Vergleich

Fällt die Grundsatzentscheidung für ein Monorepo, unterscheiden sich die verfügbaren Tools deutlich in Reifegrad, Sprachunterstützung und Einstiegshürde. Nx bringt ein umfangreiches Plugin-Ökosystem speziell für JavaScript- und TypeScript-Projekte mit, inklusive Code-Generatoren und eingebauter Abhängigkeitsvisualisierung. Turborepo verfolgt einen bewusst minimalistischeren Ansatz mit Fokus auf schnelles, inkrementelles Caching bei geringerer Konfigurationstiefe. Bazel wiederum ist sprachagnostisch und für sehr große, polyglotte Codebasen konzipiert, verlangt dafür aber eine deutlich steilere Lernkurve.

Claude lässt sich nutzen, um diese drei Optionen entlang konkreter, für das eigene Projekt relevanter Kriterien gegenüberzustellen, etwa vorhandene Sprachvielfalt im Team, Erfahrung mit deklarativen Build-Systemen, und ob eine bestehende CI-Pipeline bereits auf npm-Skripten aufbaut oder von Grund auf neu konzipiert werden kann. Eine allgemeine Bestenliste ohne diesen Kontext liefert selten eine brauchbare Entscheidungsgrundlage.

4. Trade-offs anhand von Teamgröße und Deployment-Kadenz bewerten

Ein kleines Team mit drei bis fünf Entwicklern, die ohnehin an denselben Projekten arbeiten, profitiert oft nur begrenzt von der zusätzlichen Tooling-Komplexität eines vollwertigen Monorepo-Setups, da die Koordinationskosten, die ein Monorepo eigentlich lösen soll, in so einer Größenordnung noch gering sind. Hier kann ein einfacher npm-Workspace ohne zusätzliches Build-Tool bereits ausreichen.

Bei mehreren Teams mit häufig geteiltem Code und unterschiedlicher, aber eng gekoppelter Deployment-Kadenz zeigt sich der Nutzen eines Monorepos dagegen deutlich stärker, insbesondere wenn eine Änderung an einer gemeinsamen Bibliothek regelmäßig mehrere abhängige Projekte gleichzeitig betrifft. Claude kann anhand solcher Abhängigkeitsmuster im Prompt gezielt einschätzen, ob die aktuelle Koordinationslast tatsächlich groß genug ist, um die zusätzliche Tooling-Komplexität zu rechtfertigen.

5. CI-Caching-Strategie als entscheidender Praxisfaktor

Ein häufig unterschätzter Faktor bei der Tool-Wahl ist die Qualität des eingebauten Build-Caches, da ohne effektives Caching ein Monorepo bei wachsender Projektzahl schnell zu spürbar längeren CI-Laufzeiten führt als mehrere kleine, unabhängige Repositories. Nx und Turborepo bieten beide ein Remote-Caching an, das bereits berechnete Build- und Testergebnisse zwischen CI-Läufen und lokalen Entwicklungsmaschinen teilt, sofern sich die relevanten Eingabedateien nicht verändert haben.

Claude lässt sich gezielt einsetzen, um eine bestehende CI-Konfiguration daraufhin zu prüfen, welche Schritte tatsächlich von einem solchen Caching profitieren würden und welche aufgrund externer Seiteneffekte, etwa Datenbankmigrationen oder Deployments, grundsätzlich nicht cachefähig sind. Diese Analyse hilft, die Erwartung an den tatsächlich erzielbaren CI-Geschwindigkeitsgewinn realistisch zu kalibrieren, bevor eine Migration überhaupt begonnen wird.

6. Eine Migrationsstrategie von Polyrepo zu Monorepo skizzieren lassen

Eine vollständige Migration in einem einzigen Schritt ist bei mehreren produktiv laufenden Repositories riskant und selten notwendig. Claude lässt sich anweisen, ausgehend von der aktuellen Repository-Landschaft eine schrittweise Migrationsreihenfolge vorzuschlagen, die mit den Projekten beginnt, die den geringsten externen Abhängigkeitsgrad und die geringste Kopplung an separate Deployment-Pipelines aufweisen.

# Claude Code: schrittweise Migrationsreihenfolge vorschlagen lassen
claude "Wir migrieren schrittweise von 9 separaten Repositories zu einem
Nx-Monorepo. Repos: shared-ui-lib, shared-utils, web-app, admin-app,
mobile-app, auth-service, billing-service, notification-service,
search-service. Schlage eine sinnvolle Migrationsreihenfolge vor,
beginnend mit dem geringsten Risiko, und nenne für jeden Schritt
konkrete Stolperfallen (etwa CI-Pfade, Versionierung, Deployment-Trigger)."

7. Häufige Fallstricke bei der Migration, die leicht übersehen werden

Ein wiederkehrendes Problem sind Git-Historie und Blame-Informationen, die bei einer naiven Migration per Copy-Paste verloren gehen. Werkzeuge wie git subtree oder git filter-repo erhalten die Historie beim Zusammenführen mehrerer Repositories, erfordern aber eine sorgfältige, für jedes Quell-Repository einzeln geplante Vorgehensweise, die sich gut vorab mit Claude durchdenken lässt, bevor der eigentliche, nicht ohne Weiteres rückgängig zu machende Merge-Schritt ausgeführt wird.

Ebenso häufig übersehen werden Versionierungsstrategien für geteilte Bibliotheken: Läuft im Polyrepo-Setup jede Bibliothek unter eigener Semver-Versionsnummer, muss im Monorepo entschieden werden, ob weiterhin unabhängig versioniert wird oder ob ein einheitlicher Versionsstand über alle Pakete hinweg eingeführt wird. Beide Ansätze haben etablierte Tooling-Unterstützung in Nx und Turborepo, die Entscheidung sollte aber bewusst und nicht implizit während der Migration getroffen werden.

8. Wann Polyrepo trotz allem die bessere Wahl bleibt

Nicht jede Organisation profitiert von einem Monorepo. Bei Teams, die vollständig unabhängig arbeiten, kaum Code teilen und unterschiedliche, strikt getrennte Deployment-Verantwortlichkeiten und Zugriffsrechte benötigen, etwa aus regulatorischen Gründen oder wegen unterschiedlicher externer Kunden pro Repository, kann ein Polyrepo-Setup weiterhin die klarere und wartungsärmere Wahl sein.

Auch organisatorisch stark getrennte Teams, die bewusst unterschiedliche Technologie-Stacks und Release-Zyklen pflegen wollen, profitieren selten von der erzwungenen Nähe eines gemeinsamen Repositories. Claude kann bei der Abwägung explizit nach solchen organisatorischen Gegenargumenten fragen, statt die Entscheidung ausschließlich aus rein technischer Perspektive zu betrachten, die soziale und organisatorische Realität eines Unternehmens jedoch nicht ersetzen.

9. Checkliste für eine fundierte Tooling-Entscheidung

Vor der endgültigen Entscheidung lohnt sich eine kompakte Checkliste: Wie viele Teams teilen tatsächlich regelmäßig Code miteinander? Wie unterschiedlich ist die Deployment-Kadenz der betroffenen Projekte? Existiert bereits Erfahrung mit deklarativen Build-Systemen im Team? Wie polyglott ist die Sprachlandschaft, und würde ein sprachagnostisches Werkzeug wie Bazel den zusätzlichen Lernaufwand rechtfertigen?

Claude ersetzt nicht die endgültige Entscheidung, liefert aber eine strukturierte, auf die eigenen Zahlen gestützte Abwägung, die deutlich über eine pauschale Trend-Empfehlung aus einem Blogartikel hinausgeht. Wichtig bleibt, die generierten Argumente kritisch mit dem eigenen Team zu diskutieren, bevor eine so grundlegende, später nur mit erheblichem Aufwand rückgängig zu machende Architekturentscheidung tatsächlich umgesetzt wird.

10. Zusammenfassung

11. FAQ: Monorepo-Tooling-Entscheidungen mit Claude: Das Wichtigste auf einen Blick