Monorepo

Was ist ein Monorepo?

Ein Monorepo (Mono-Repository) ist eine Softwareentwicklungsstrategie, bei der der Code mehrerer Projekte in einem einzigen Git-Repository verwaltet wird. Statt für jedes Paket, jeden Service oder jede App ein eigenes Repository zu betreiben, leben alle zusammen -- mit gemeinsamer Versionierung, gemeinsamen Dependencies und gemeinsamen Build-Prozessen.

Der Begriff wird oft mit "Monolith" verwechselt, ist aber grundlegend verschieden. Ein Monorepo enthält typischerweise viele unabhängige Pakete und Anwendungen, die klar voneinander abgegrenzt sind. Google, Meta, Microsoft und Uber betreiben riesige Monorepos mit Millionen von Dateien. Im JavaScript-Ökosystem werden Monorepos durch Tools wie Turborepo, Nx, pnpm Workspaces und Lerna ermöglicht.

Warum ist das wichtig?

In einer Multi-Repo-Welt -- also einem Repository pro Projekt -- entsteht schnell organisatorische Komplexität. Eine Änderung, die drei Pakete betrifft, erfordert drei PRs in drei Repositories, die koordiniert reviewt, gemergt und released werden müssen. Dependency-Updates werden in jedem Repository separat durchgeführt, was zu Versionsdrift führt. Und gemeinsam genutzte Konfigurationen (ESLint, TypeScript, Prettier) müssen synchron gehalten werden -- was in der Praxis selten passiert.

Monorepos eliminieren diese Koordinationskosten. Eine Änderung, die ein Shared Package und zwei konsumierende Apps betrifft, ist ein einziger PR. Die CI/CD-Pipeline testet alle betroffenen Projekte automatisch, und der Review erfasst die gesamte Änderung im Kontext. Dependency-Versionen werden zentral verwaltet, und Konfigurationen werden einmal definiert und von allen Projekten geerbt.

Für TypeScript-Projekte bieten Monorepos einen zusätzlichen Vorteil: Project References ermöglichen es, Typ-Checks über Paketgrenzen hinweg durchzuführen. Wenn ein Shared Package seinen Typen ändert, zeigt der Compiler sofort alle betroffenen Stellen in allen konsumierenden Projekten. In einer Multi-Repo-Welt würde dieser Fehler erst nach dem Publish des Packages und dem Update in den konsumierenden Projekten auffallen -- Tage oder Wochen später.

Die Herausforderung bei Monorepos liegt in der Skalierung der Tooling-Infrastruktur. Build-Zeiten, Test-Zeiten und CI-Kosten steigen mit der Größe des Repositories. Ohne intelligentes Caching und Change Detection werden Builds schnell unpraktisch langsam.

Monorepo in der Praxis

Moderne Monorepo-Toolchains lösen die Skalierungsprobleme durch mehrere Mechanismen:

Workspace-Management: pnpm Workspaces oder Yarn Workspaces verwalten Dependencies über alle Pakete hinweg. Gemeinsame Dependencies werden einmal installiert (Hoisting), paketspezifische Dependencies bleiben isoliert. Ein einziges pnpm install an der Wurzel installiert alles für alle Projekte.

Task-Orchestrierung: Turborepo oder Nx erkennen die Abhängigkeitsgrafik zwischen Paketen und führen Build- und Test-Tasks in der richtigen Reihenfolge aus -- parallelisiert und mit intelligenter Erkennung, welche Pakete von einer Änderung betroffen sind. Wenn nur das UI-Paket geändert wurde, werden nur das UI-Paket und seine Konsumenten neu gebaut.

Remote Caching: Turborepo kann Build-Ergebnisse in einem Remote Cache speichern. Wenn ein Kollege dasselbe Paket mit demselben Input bereits gebaut hat, wird das Ergebnis aus dem Cache geladen statt neu berechnet. Das reduziert CI-Zeiten um 40-70%.

Beispiel: Ein SaaS-Unternehmen organisiert seine Codebasis als Monorepo mit Turborepo:

apps/
  web/          # Next.js Kundenportal
  admin/        # React Admin-Dashboard
  api/          # Node.js API-Server
packages/
  ui/           # Shared Design System
  config/       # Shared ESLint, TypeScript, Prettier
  utils/        # Shared Utilities
  db/           # Datenbankschema und Client

Das Design System im packages/ui-Ordner wird von beiden Frontend-Apps genutzt. Eine neue Button-Variante wird einmal implementiert und ist sofort in beiden Apps verfügbar. TypeScript Project References stellen sicher, dass Typ-Änderungen sofort in allen konsumierenden Projekten geprüft werden. Die CI-Pipeline baut nur die von einer Änderung betroffenen Pakete -- ein PR, der nur das Admin-Dashboard betrifft, triggert keine Builds für die Web-App.

Verwandte Konzepte

• TypeScript -- Typsicherheit über Paketgrenzen hinweg mit Project References
• Design System -- Shared UI-Pakete als Kernvorteil von Monorepos
• CI/CD Pipeline -- Intelligente Pipelines für Monorepo-Builds
• TypeScript-Entwicklung -- Professionelle TypeScript-Monorepo-Setups
• React-Entwicklung -- Komponentenbibliotheken im Monorepo verwalten