Migrating Module Federation from Webpack 5.0.0-beta.16 to Webpack 5.0.0-beta.21

Photo by Kevin Ku from Pexels

I’m sure many of you saw the title and immediately thought, “Yeah, that’s why you don’t use beta”, but let’s face it — if you’ve tooled around with the variety of micro frontend implementations that are out there, you understand the pain points that this speaks to, and why folks are willing to jump on board prematurely. Module Federation is an absolute game changer.

If you’re here, you’ve likely upgraded to Webpack 5.0.0-beta.21 and now things aren’t loading. You’ve likely discovered that documentation is light, although if you haven’t read Zack Jackson’s more recent article regarding some of the changes, I highly recommend checking it out, as he may address some of your troubleshooting woes.

In the meantime, here’s a shortlist of changes to get your application back on track. Some I took from Zack’s article, others I found by poking around in the Webpack repo.

Declaring Remotes

Have you seen this error?

Uncaught ScriptExternalLoadError: Loading script failed.

Hopefully we can address this problem below.

From what I’m gathering between my formerly broken MFE, host, Zack’s article, and the latest Module Federation example, declaring remotes has had a makeover, which likely corresponds with some of the larger changes under the hood.

How remotes used to be declared:

remotes: { 
   app2: “app2”
}

How they’re declared now:

remotes: { 
   app2: "app2@http://localhost:3002/remoteEntry.js"
}

The value must now be a path, prefixed with the app name defined in the MFE’s webpack.config ModuleFederation plugin, and delimited(?) by @ .

This update allows remotes to be consumed without adding a script reference in index.html . However, placing a script reference in the document head avoids a round-trip (as I learned after publishing this article via Sokra).

Exposing Components

Keys must now begin with./ .

Before:

exposes: {
    "Component": "./src/Component"
},

Now:

exposes: {
    "./Component": "./src/Component"
},

Shared Consumption

Uncaught Error: Shared module is not available for eager consumption: 
webpack/sharing/consume/default/<some-package>/<some-package>

Zack describes here how to resolve this issue. Basically, the initial dependencies that your application relies on must be set eager . I went ahead and took advantage of the bundle-loader and bootstrap file strategy since my host dependencies are ever-growing, and writing eager for each was getting tedious.

CB Error after Bootstraping

TypeError: cb is not a function

If you run into this error, you likely have to call your bootstrap function with a callback as an argument.

import bootstrap from './bootstrap'
bootstrap(() => {})

These are the steps I took to migrate to the latest. Thanks to Zack Jackson and Tobias Koppers for all of their hard work.