Module Federation: Dynamiske runtime-imports

I en frontendorganisation med flere teams har flere uafhængigt udrullede applikationer ofte brug for at dele UI-komponenter og hjælpefunktioner. Udgivelse til npm kræver en versionsforøgelse, en ny udgivelse og fuld genudrulning af alle applikationer, der bruger pakken — hvilket skaber tæt kobling mellem teams og langsomme iterationscyklusser.

Den traditionelle tilgang (at udgive delt kode som en npm-pakke) betyder, at opdatering af en delt knapkomponent kræver: opdater npm-pakken, udgiv en ny version, opdater alle applikationers package.json, der bruger pakken, genbyg og genudrul alle disse applikationer. Module Federation eliminerer alle disse trin.

Module Federation gør det muligt for én applikation (en "remote") at eksponere JavaScript-moduler, som en anden applikation (en "host") indlæser og kører under kørsel, uden at hosten skal genbygges eller genudrulles. Når brugeren indlæser host-applikationen, henter den dynamisk remote'ets moduler efter behov.

Webpack 5 introducerede Module Federation som en indbygget kernefunktion via ModuleFederationPlugin. Før Webpack 5 krævede lignende mønstre kompleks manuel konfiguration eller tredjeparts-plugins. Plugin'et håndterer automatisk al dynamisk indlæsning og administration af det delte område.

Et remote er en uafhængigt udrullet applikation, der eksponerer et eller flere moduler — React-komponenter, hjælpefunktioner eller komplette funktionssider — som andre applikationer kan bruge. Remotet bygger et remoteEntry.js-manifest, der beskriver, hvad det eksponerer, og hvordan det indlæses.

En host er en applikation, der bruger moduler fra et eller flere remotes. Hosten refererer til remotes via navn og URL i sin Webpack-konfiguration. Når hostens kode importerer et remote-modul, henter og kører Webpacks Module Federation-runtime det dynamisk fra remote'ets URL.

Delte moduler er biblioteker (som React og React DOM), der kun skal indlæses én gang, selv om både hosten og remotet indeholder dem. Ved at markere React som en delt singleton sikrer Module Federation, at der kun kører én React-version — hvilket er afgørende, fordi Reacts hooks ikke fungerer med flere instanser.

Når du bygger et remote, genererer Webpack en fil med navnet remoteEntry.js på den konfigurerede placering. Filen er et letvægtsmanifest og et opstartsscript: den erklærer, hvilke moduler remotet eksponerer, angiver deres chunk-URL'er og initialiserer det delte område. Hosten downloader først denne fil for at finde ud af, hvad remotet tilbyder.

Når hosten støder på en import fra et remote-modul, undersøger den, om remote'ets kode allerede er indlæst. Hvis ikke henter den remoteEntry.js fra remote'ets URL, initialiserer det delte område (og forhandler versioner af delte biblioteker) og downloader og kører derefter den specifikke chunk, der indeholder det ønskede modul.

Et team udruller en ny version af sit remote (med en opdateret Button-komponent) uden at røre host-applikationen. Den næste bruger, der indlæser hosten, får automatisk den nye Button, fordi hosten altid henter fra den aktuelle remoteEntry.js-URL. Ingen genbygning af hosten, ingen genudrulning af hosten og ingen koordinering er nødvendig.

Et ældre microfrontend-mønster bruger iframes til at isolere sektioner, som ejes af forskellige teams. Iframes giver stærk isolation, men gør delt tilstand, URL-routing og styling ekstremt vanskeligt. Module Federation holder alt i den samme JavaScript-kontekst, så delt routing, delt godkendelsestilstand og ensartet styling bliver muligt.

Module Federation løser problemet med uafhængig udrulning af delt frontend-kode ved at muliggøre indlæsning af moduler under kørsel. Remotes eksponerer moduler via remoteEntry.js, og hosts bruger dem dynamisk uden genbygning. Delte singletons (React og React DOM) forhindrer, at biblioteker indlæses flere gange. Denne arkitektur muliggør ægte uafhængig udrulning: Opdater et remote, så ser alle host-applikationer straks ændringen.