Irgendwann wird ein Angular-Projekt für zwei Teams zu eng: Merge-Konflikte häufen sich, und eines will auf Zoneless umstellen, während das andere andere Prioritäten hat. Der naheliegende Schritt ist ein Monorepo mit mehreren Projekten — Angulars CLI kann das von Haus aus.
Was danach wirklich getrennt ist
Jedes Projekt bekommt eine eigene tsconfig, main.ts und App-Konfiguration.
Der Streit über Grundsatzfragen ist damit entschärft, gebaut wird projektweise,
jedes Artefakt landet in einem eigenen dist-Ordner.
Das fühlt sich nach Unabhängigkeit an. An zwei Stellen ist es keine.
Der Test, der nichts tut
Nimm eine Komponente, die dem Konto-Projekt gehört und auf der Kassenseite des Shop-Projekts erscheint. Ändere sie, baue das Konto-Projekt, liefere aus.
Auf der Kassenseite passiert nichts.
Diese Abhängigkeit wird zur Bauzeit eingelöst: Die fremde Komponente ist ins
andere Projekt hineinkompiliert. Sichtbar wird die Änderung erst, wenn auch das
Shop-Team neu baut. Ein Team hängt damit an der Auslieferung eines anderen — und
getrennte dist-Ordner verdecken das eher, als dass sie es zeigen.
Der zweite Punkt: eine package.json für alle
Alle Projekte teilen sich Paketversionen. Wer aktualisieren will, wartet, bis alle Teams bereit sind — mal ein Vorteil, mal genau die Blockade, die man loswerden wollte.
Das ist kein Grund gegen das Monorepo; für viele Teams ist es die richtige Stufe. Es beantwortet nur nicht die Frage, wer wann ausliefern darf.
Mehr dazu im Seminar
Wie man diese Kopplung sichtbar macht und was Micro-Frontends daran ändern, zeigt das Modul Monorepo & Micro-Frontends. Zum Nachschlagen gibt es dazu das Cheat Sheet mit den Architekturstufen und ihren Auslösern.