Webpack 5 Module Federation: Runtime Code Sharing for Micro‑Frontends

Why Code Sharing Matters in Modern Frontends

When a single application grows into several teams, bundling everything into one monolith becomes a maintenance nightmare. Module Federation lets each team ship its own Webpack bundle that can be loaded on demand by a host application. The result is smaller initial payloads, independent deployment cycles, and the ability to upgrade parts of the UI without touching the whole codebase.

What Module Federation Actually Does

Module Federation is a Webpack 5 feature that exposes modules from one bundle (the remote) and consumes them from another (the host) via a shared runtime registry. At load time the host asks the remote for a named module; the remote registers that module on the global window object, and the host resolves it through import(). Because the registry lives in the browser, the host can lazily fetch and execute modules from any remote, even if the remote is served from a different domain.

Key Configuration Pieces

• name – unique identifier for a bundle.
• remotes – mapping of remote names to URLs.
• exposes – modules a remote makes available.
• shared – libraries that should be singletons across all bundles.

Concrete Example: A Host & a Remote Exposing a Button

1. Remote Project (Button)

   // webpack.config.js
   const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
   
   module.exports = {
     mode: 'development',
     output: {
       publicPath: 'http://localhost:8081/',
     },
     plugins: [
       new ModuleFederationPlugin({
         name: 'buttonRemote',
         filename: 'remoteEntry.js',
         exposes: {
           './Button': './src/Button.jsx',
         },
         shared: {
           react: { singleton: true, eager: true },
           'react-dom': { singleton: true, eager: true },
         },
       }),
     ],
   };
   

   Run the remote dev server: npm run start:remote (assumes webpack-dev-server listening on localhost:8081).

2. Host Project (App)

   // webpack.config.js
   const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
   
   module.exports = {
     mode: 'development',
     output: {
       publicPath: 'http://localhost:8080/',
     },
     plugins: [
       new ModuleFederationPlugin({
         name: 'hostApp',
         remotes: {
           buttonRemote: 'buttonRemote@http://localhost:8081/remoteEntry.js',
         },
         shared: {
           react: { singleton: true, eager: true },
           'react-dom': { singleton: true, eager: true },
         },
       }),
     ],
   };
   

   In the host’s code, consume the remote module lazily:

   import React, { Suspense } from 'react';
   const RemoteButton = React.lazy(() => import('buttonRemote/Button'));
   
   function App() {
     return (
       <div>
         <h1>Host Application</h1>
         <Suspense fallback="Loading button...">
           <RemoteButton />
         </Suspense>
       </div>
     );
   }
   
   export default App;
   

3. Verification Steps
   • Start both dev servers.
   • Navigate to http://localhost:8080 – the button should appear after a brief load.
   • Open Chrome DevTools Network panel; you should see a request for remoteEntry.js and the Button chunk only when the component mounts.
   • Check the console for any React warnings; only one instance of React should be loaded.

Trade‑Offs and Practical Limitations

• Version Compatibility – If the remote updates a shared library (e.g., React 17 → 18), the host must rebuild to match the version constraints. Mismatched versions can cause rendering glitches or runtime errors.
• Network Latency – The host’s first paint may be delayed by the remote’s fetch. Use CDN caching and prefetch hints to mitigate.
• Debugging Complexity – Errors originate in separate bundles. Ensure source maps are enabled for each remote to trace stack traces back to the original source.
• Deployment Coordination – The host must know the remote’s URL. In production, environment variables or a manifest service can keep these mappings up to date.

Actionable Checklist for Engineers

1. Decide which parts of your app should be isolated as remotes.
2. Add ModuleFederationPlugin to each Webpack config, defining name, exposes, and shared.
3. In the host, declare remotes with the remote’s URL.
4. Consume remote modules with React.lazy or dynamic import() for lazy loading.
5. Configure source maps and CDN caching for production.
6. Set up automated integration tests that spin up both host and remote servers to catch version mismatches early.

With these steps, you can start leveraging Module Federation to build maintainable, independently deployable micro‑frontends while keeping bundle sizes lean and runtime performance high.