© SkillUp/Shutterstock.com
Lösungsansätze mit Module Federation

Versionskonflikte in Microfrontends


Benötigen mehrere Microfrontends dieselben Abhängigkeiten in unterschiedlichen Versionen, liegt ein Konflikt vor. Zum Auflösen dieser Konflikte bietet Module Federation einige Strategien an.

Die Idee hinter Microfrontends ist ja eigentlich sehr nett: Unterschiedliche Teams schreiben kleine, wenig komplexe Frontends, die gemeinsam zur Laufzeit eine umfangreiche Lösung ergeben. Wie in den letzten Ausgaben gezeigt, vereinfacht das mit webpack 5 veröffentlichte Module Federation dieses Vorgehen ungemein: Es unterstützt beim dynamischen Laden von Microfrontends und erlaubt sogar das Teilen von Abhängigkeiten. Somit müssen Pakete, die in mehreren Microfrontends zum Einsatz kommen, nur ein einziges Mal geladen werden.

Genau das kann jedoch auch zum Fallstrick werden: Was, wenn einzelne Microfrontends dieselben Bibliotheken in verschiedenen Versionen verwenden? Glücklicherweise bietet Module Federation für solche Fälle einige sehr schlaue Strategien. Diese möchte ich hier anhand von einem Beispiel beschrieben. Den Quellcode findet man unter [1].

Beispiel

Um die einzelnen Strategien zum Auflösen von Versionskonflikten zu demonstrieren, kommt hier ein einfaches Beispiel zum Einsatz. Es handelt sich um eine Microfrontend-Shell, die ein Microfrontend mittels Module Federation lädt (Abb. 1).

steyer_versionskonflikte_1.tif_fmt1.jpgAbb. 1: Beispiel zur Veranschaulichung von Konfliktlösungsstrategien

Sowohl die Shell als auch das Microfrontend nutzen das für dieses Beispiel bereitgestellte npm-Paket useless-lib [2]. Diese Bibliothek liegt in verschiedenen Major-, Minor- und Patch-Versionen vor und bietet eine Konstante mit der geladenen Versionsnummer. Die einzelnen Anwendungen teilen diese Bibliothek mittels Module Federation und geben die verwendete Version aus. In Abbildung 1 ist die Welt noch in Ordnung – hier nutzen sowohl die Shell als auch das Microfrontend die Version 1.0.0 der useless-lib. Module Federation lädt die Bibliothek somit nur einmal und die beiden Anwendungen erhalten Zugriff darauf.

Semantic Versioning als Standard

Lassen Sie uns nun unser Beispiel ein wenig variieren, sodass sich ein Versionskonflikt ergibt. Dazu tragen wir die folgenden Versionen in den package.json-Dateien der beiden Anwendungen ein:

Shell: "useless-lib": "^1.1.0" Micro Frontend: "useless-lib": "^1.0.0"

Hier liegen also mit 1.1 und 1.0 zwei unterschiedliche Minor-Versionen vor. Allerdings gibt das Präfix „^“ an, dass sich die jeweiligen Anwendungen auch mit höheren Minor-Versionen zufriedengeben. Halten sich alle an die Regeln von Semantic Versioning, sollte das auch bedenkenlos möglich sein, zumal höhere Minor-Versionen per Definition abwärtskompatibel sind.

Diese Versionen sind nun mit npm install oder Yarn zu installieren. Starten wir danach unsere Shell, sehen wir, dass Module Federation sowohl für die Shell als auch für das Microfrontend die Version 1.1 nutzt (Abb. 2).

steyer_versionskonflikte_2.tif_fmt1.jpgAbb. 2: Sowohl Shell als auch Microfrontend nutzen Version 1.1

Das veranschaulicht auch schon das Standardverhalten beim Auftreten von Versionskonflikten: Module Federation ermittelt die höchste kompatible Version und teilt sie. Hierzu berücksichtigt es die Einträge in der package.json samt ihrer Präfixe wie „^“.

Es ist übrigens unerheblich, ob die Shell oder ein Microfrontend die höchste kompatible Version liefert. Module Federation wertet beim Programmstart die Metadaten der einzelnen Anwendungen aus und ermittelt basierend darauf die zu nutzende Version. Das bedeutet aber auch, dass Module Federation alle zu teilenden Bibliotheken in eigene Bundles stecken muss, damit auch andere Anwendungen sie laden können (Abb. 3).

steyer_versionskonflikte_3.tif_fmt1.jpgAbb. 3: Geteilte Bibliotheken landen in separaten Bundles

Geteilte Bundles und Tree-Shaking

Geteilte Bundles sind leider nicht tree-shakable, zumal webpack ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang