Module Federation: Dynamiske importer ved kjøring

I en frontend-organisasjon med flere team trenger flere applikasjoner som distribueres uavhengig, ofte å dele UI-komponenter og hjelpefunksjoner. Publisering til npm krever en versjonsøkning, en ny utgivelse og full utrulling av alle applikasjoner som bruker pakken – noe som skaper tett kobling mellom teamene og langsomme iterasjonssykluser.

Den tradisjonelle tilnærmingen (å publisere delt kode som en npm-pakke) innebærer at en oppdatering av en delt knappkomponent krever følgende: oppdater npm-pakken, publiser en ny versjon, oppdater package.json i alle applikasjoner som bruker pakken, bygg og rull ut alle disse applikasjonene på nytt. Module Federation fjerner alle disse trinnene.

Module Federation gjør det mulig for én applikasjon (en "remote") å eksponere JavaScript-moduler som en annen applikasjon (en "host") laster inn og kjører under kjøring, uten å bygge eller rulle ut hosten på nytt. Når brukeren laster inn host-applikasjonen, henter den dynamisk remote-modulene ved behov.

Webpack 5 introduserte Module Federation som en førsteklasses, innebygd funksjon via ModuleFederationPlugin. Før Webpack 5 krevde tilsvarende mønstre omfattende manuell konfigurasjon eller tredjepartsplugin-moduler. Plugin-modulen håndterer all dynamisk lasting og administrasjon av shared scope automatisk.

En remote er en uavhengig utrullet applikasjon som eksponerer én eller flere moduler – React-komponenter, hjelpefunksjoner eller hele funksjonssider – som andre applikasjoner kan bruke. Remoten bygger et remoteEntry.js-manifest som beskriver hva den eksponerer, og hvordan det lastes inn.

En host er en applikasjon som bruker moduler fra én eller flere remotes. Hosten refererer til remotes med navn og URL i Webpack-konfigurasjonen. Når koden i hosten importerer en remote-modul, henter og kjører Module Federation-kjøremiljøet den dynamisk fra URL-en til remoten.

Delte moduler er biblioteker (som React og React DOM) som bare skal lastes inn én gang, selv om både hosten og remoten inkluderer dem. Ved å merke React som en delt singleton sørger Module Federation for at bare én React-versjon kjører – noe som er avgjørende fordi Reacts hooks slutter å fungere med flere instanser.

Når en remote bygges, genererer Webpack en remoteEntry.js-fil med det konfigurerte filnavnet. Denne filen er et lettvektsmanifest og et bootstrap-skript: den angir hvilke moduler remoten eksponerer, viser URL-ene til chunkene og initialiserer shared scope. Hosten laster ned denne filen først for å finne ut hva remoten tilbyr.

Når hosten møter en import fra en remote-modul, sjekker den om koden til remoten allerede er lastet inn. Hvis ikke henter den remoteEntry.js fra URL-en til remoten, initialiserer shared scope (og forhandler versjoner av delte biblioteker), og laster deretter ned og kjører den spesifikke chunken som inneholder den forespurte modulen.

Et team ruller ut en ny versjon av remoten (med en oppdatert Button-komponent) uten å endre host-applikasjonen. Den neste brukeren som laster inn hosten, får automatisk den nye Button-komponenten fordi hosten alltid henter fra den gjeldende remoteEntry.js-URL-en. Ingen ny bygging eller utrulling av hosten, og ingen koordinering er nødvendig.

Et eldre mikrofrontend-mønster bruker iframes til å isolere seksjoner som eies av ulike team. Iframes gir sterk isolasjon, men gjør delt tilstand, URL-ruting og styling svært vanskelig. Module Federation holder alt i den samme JavaScript-konteksten, slik at delt ruting, delt autentiseringstilstand og konsekvent styling blir mulig.

Module Federation løser problemet med uavhengig utrulling av delt frontend-kode ved å muliggjøre lasting av moduler under kjøring. Remotes eksponerer moduler via remoteEntry.js, og hosts bruker dem dynamisk uten å bygge på nytt. Delte singletoner (React, React DOM) hindrer at biblioteker lastes inn flere ganger. Denne arkitekturen muliggjør ekte uavhengig utrulling: Oppdater en remote, så ser alle host-applikasjonene endringen umiddelbart.