Module federation greatly simplifies the implementation of microfrontends. However, it is — to some extent — linked to webpack. This is not a major issue in the short term, and possibly also in the medium term, because webpack is currently the most popular build tool for web technologies, with over 20 million downloads.

However, we all know that technologies come and go. The Angular team, for example, is currently working on CLI support for the bundler esbuild [1], which looks very promising, particularly in terms of build performance.

This raises the question of how to implement the tried-and-tested mental model of module federation independently of webpack in order to future-proof your own microfrontend architecture. This article provides an answer based on import maps that now work with all major browsers — either natively, as in Chrome or Edge, or by adding a polyfill. The examples shown can be found in [2].

Mental model behind module federation

Before we get into import maps, I would like to talk about the mental model of module federation, which we will try to emulate later with import maps (Fig. 1).

Fig. 1: Overview of module federation

This mental model, among other things, defines host applications that load modules of separately built and separately deployed remote applications. These modules can export any JavaScript construct: Examples include functions, components, and data structures such as Angular modules or routes. The host in the world of microfrontends is a shell, and the remote is the microfrontend itself.

The host loads the provided modules with a dynamic import or — if the remotes are not known in advance — via a low-level API provided by webpack at runtime. The latter is indicated by the auxiliary function loadRemoteModule. This function points to both the name of the published module (exposedModule) and a remote entry (remoteEntry).

The remote entry is a JavaScript file that webpack generates during bundling that contains metadata about the remote. This metadata, among other things, informs the remotes and the host about the dependencies to be shared at runtime. These dependencies must be specified in the configuration under shared.

For example, in Figure 1, it is specified that @angular/core should be shared. This means that even if @angular/core is used in multiple remotes or the host, it is only loaded once.

When sharing dependencies, version conflicts can, of course, occur. Long-time Windows users may recall this issue being referred to as DLL Hell. Fortunately, module federation comes with several strategies for avoiding conflicts (Box: "Module Federation and version conflicts").