Module Federation

Module Federation is a bundler feature, introduced in webpack 5, that lets separately built applications load each other's code and share libraries at runtime.

Module Federation first shipped in webpack 5 and is now also available in other bundlers such as Rspack. It lets one build load code from another build at runtime, as if it were a normal lazy-loaded module. The two builds can live in different repositories and be deployed at different times.

Each build declares three things in its configuration:

• exposes: the modules it offers to others.
• remotes: the other builds it wants to consume.
• shared: libraries such as Angular or React that should be loaded once and reused.

Example

A shell application wants to show the orders area owned by another team. This is the configuration of the orders remote:

new ModuleFederationPlugin({
  name: 'orders',
  filename: 'remoteEntry.js',
  exposes: { './routes': './src/app/orders.routes.ts' },
  shared: { '@angular/core': { singleton: true, strictVersion: true } },
});

The shell loads orders/routes when the user navigates to /orders. When the orders team deploys a new version, the shell picks it up on the next page load without a rebuild.

Common misunderstanding

Sharing is negotiated at runtime, so it is easy to assume it always works. If the host and a remote ask for incompatible versions of a singleton library, the result is a runtime error or two copies of the framework on the page. The version policy for shared libraries has to be agreed across teams and checked in CI.

Module Federation solves code loading. It does not solve routing, shared state, consistent styling or team agreements. See micro-frontend platforms for the rest of the picture.

Related terms

• Native Federation
• Host (shell) application
• Remote (micro-frontend remote)
• Remote entry and manifest