Module Federation: dynamiska importer vid körning

I en frontendorganisation med flera team behöver flera oberoende driftsatta applikationer ofta dela UI-komponenter och verktyg. Publicering till npm kräver en versionshöjning, en ny release och fullständig omdriftsättning av alla applikationer som använder paketet. Det skapar en stark koppling mellan teamen och långsamma utvecklingscykler.

Den traditionella metoden, där delad kod publiceras som ett npm-paket, innebär att en uppdatering av en delad knappkomponent kräver följande: uppdatera npm-paketet, publicera en ny version, uppdatera package.json i alla applikationer som använder paketet, bygga om och driftsätta alla dessa applikationer. Module Federation eliminerar alla dessa steg.

Module Federation låter en applikation, en "remote", exponera JavaScript-moduler som en annan applikation, en "host", laddar och kör vid runtime utan att hosten behöver byggas om eller driftsättas på nytt. När användaren laddar host-applikationen hämtas remotes moduler dynamiskt vid behov.

Webpack 5 introducerade Module Federation som en inbyggd förstaklassfunktion via ModuleFederationPlugin. Före Webpack 5 krävde liknande mönster komplex manuell konfiguration eller plugin-program från tredje part. Plugin-programmet hanterar all dynamisk laddning och hantering av shared scope automatiskt.

En remote är en oberoende driftsatt applikation som exponerar en eller flera moduler – React-komponenter, verktyg eller hela funktionssidor – som andra applikationer kan använda. Remoten bygger ett remoteEntry.js-manifest som beskriver vad den exponerar och hur det ska laddas.

En host är en applikation som använder moduler från en eller flera remotes. Hosten refererar till remotes med namn och URL i sin Webpack-konfiguration. När hostens kod importerar en remote-modul hämtar och kör Webpacks Module Federation-runtime den dynamiskt från remotens URL.

Delade moduler är bibliotek, som React och React DOM, som bara ska laddas en gång även om både hosten och remoten inkluderar dem. Genom att markera React som en delad singleton säkerställer Module Federation att bara en React-version körs – vilket är avgörande eftersom Reacts hooks inte fungerar med flera instanser.

När en remote byggs genererar Webpack en fil med det konfigurerade filnamnet remoteEntry.js. Filen är ett lättviktigt manifest och bootstrap-skript: den deklarerar vilka moduler remoten exponerar, listar deras chunk-URL:er och initierar shared scope. Hosten laddar ner filen först för att upptäcka vad remoten erbjuder.

När hosten stöter på en import från en remote-modul kontrollerar den om remotens kod redan har laddats. Om den inte har det hämtar hosten remoteEntry.js från remotens URL, initierar shared scope genom att förhandla om versioner av delade bibliotek och laddar sedan ner och kör den specifika chunk som innehåller den begärda modulen.

Ett team driftsätter en ny version av sin remote, med en uppdaterad Button-komponent, utan att ändra host-applikationen. Nästa användare som laddar hosten får automatiskt den nya Button-komponenten eftersom hosten alltid hämtar från den aktuella URL:en till remoteEntry.js. Ingen ombyggnad eller omdriftsättning av hosten krävs, och ingen samordning behövs.

Ett äldre mikrofrontendmönster använder iframes för att isolera sektioner som ägs av olika team. Iframes ger stark isolering men gör delat tillstånd, URL-routing och styling extremt svårt. Module Federation behåller allt i samma JavaScript-kontext, vilket möjliggör delad routing, delat autentiseringstillstånd och enhetlig styling.

Module Federation löser problemet med oberoende driftsättning av delad frontendkod genom att möjliggöra laddning av moduler vid runtime. Remotes exponerar moduler via remoteEntry.js och hosts använder dem dynamiskt utan att byggas om. Delade singleton-moduler, som React och React DOM, förhindrar att bibliotek laddas flera gånger. Arkitekturen möjliggör verkligt oberoende driftsättning: uppdatera en remote så ser alla host-applikationer ändringen omedelbart.