Module Federation: Dynamic Runtime Imports

In a multi-team frontend organization, multiple independently deployed applications often need to share UI components and utilities. Publishing to npm requires a version bump, new release, and full redeploy of every consuming application — creating a tight coupling between teams and slow iteration cycles.

The traditional approach (publish shared code as an npm package) means that updating a shared button component requires: update the npm package, publish a new version, update every consuming app's package.json, rebuild and redeploy every consuming app. Module Federation eliminates all of these steps.

Module Federation allows one application (a "remote") to expose JavaScript modules that another application (a "host") loads and executes at runtime, without rebuilding or redeploying the host. When the user loads the host app, it dynamically fetches the remote's modules on demand.

Webpack 5 introduced Module Federation as a first-class built-in feature via the ModuleFederationPlugin. Before Webpack 5, similar patterns required complex manual configuration or third-party plugins. The plugin handles all the dynamic loading and shared scope management automatically.

A remote is an independently deployed application that exposes one or more modules — React components, utilities, or entire feature pages — for other applications to consume. The remote builds a remoteEntry.js manifest that describes what it exposes and how to load it.

A host is an application that consumes modules from one or more remotes. The host references remotes by name and URL in its Webpack configuration. When the host's code imports a remote module, Webpack's Module Federation runtime fetches and executes it dynamically from the remote's URL.

Shared modules are libraries (like React and React DOM) that should only load once, even if both the host and remote include them. By marking React as a shared singleton, Module Federation ensures only one version of React runs — critical because React's hooks break with multiple instances.

When you build a remote, Webpack generates a remoteEntry.js file at the configured filename. This file is a lightweight manifest and bootstrap script: it declares what modules the remote exposes, lists their chunk URLs, and initializes the shared scope. The host downloads this file first to discover what the remote offers.

When the host encounters an import from a remote module, it checks if the remote's code is already loaded. If not, it fetches remoteEntry.js from the remote's URL, initializes the shared scope (negotiating shared library versions), then downloads and executes the specific chunk containing the requested module.

A team deploys a new version of their remote (updated Button component) without touching the host application. The next user who loads the host gets the new Button automatically because the host always fetches from the current remoteEntry.js URL. No host rebuild, no host redeploy, no coordination needed.

An older micro-frontend pattern uses iframes to isolate team-owned sections. Iframes provide strong isolation but make shared state, URL routing, and styling extremely difficult. Module Federation keeps everything in the same JavaScript context, enabling shared routing, shared auth state, and consistent styling.

What is the role of remoteEntry.js in Module Federation?

Module Federation solves the independent deployment problem for shared frontend code by enabling runtime module loading. Remotes expose modules via remoteEntry.js; hosts consume them dynamically without rebuilding. Shared singletons (React, React DOM) prevent duplicate library loading. This architecture enables true independent deployment: update a remote and all host applications see the change immediately.