Sharing Dependencies in Webpack Module Federation: Singleton or Duplicate

You have three independently deployed apps, and each one bundles its own copy of React. The header component is copied into every repository, so a small fix requires three releases. Webpack 5 Module Federation lets a host application consume exposed modules from remote builds at runtime without bundling them together, but enabling federation is only the first step. The useful takeaway is that your shared dependency policy decides whether you save bytes or create runtime breakage.

How Module Federation shares code at runtime

Module Federation is a webpack 5 feature built around the ModuleFederationPlugin. A remote build exposes modules by name and emits a remote entry file. A host build declares that remote and imports its modules as if they were local. The shared configuration creates a shared scope: packages listed there can be provided once and reused across host and remotes. When a package is marked singleton, webpack keeps only one instance in memory, which matters for frameworks like React where multiple copies can break hooks and context.

Concrete host and remote configuration

Assume webpack 5 and Node.js are installed. Run these commands from each project root with a user account that can read source files and write to the dist directory:

npm run build

Or, if webpack is installed locally:

npx webpack --mode production

Remote build configuration:

// remote/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  name: 'inventory',
  filename: 'remoteEntry.js',
  exposes: {
    './StockTable': './src/StockTable',
  },
  shared: {
    react: { singleton: true, requiredVersion: '^18.2.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
  },
};

Host build configuration:

// host/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  remotes: {
    inventory: 'inventory@https://inventory.example.com/remoteEntry.js',
  },
  shared: {
    react: { singleton: true, requiredVersion: '^18.2.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
  },
};

Expected checks after a production build: the remote build should emit remoteEntry.js, and the host bundle should not contain the exposed StockTable module. A risk to note is that remote modules load over the network, so a failed remote entry request can leave the host unable to render that feature.

Singleton versus duplicated dependencies

Choosing which packages to share is the real engineering decision. Share framework runtimes and design systems as singletons with a strict requiredVersion range so all builds agree on the same major version. Duplicate application-specific libraries unless you genuinely need a single instance; duplication avoids version coupling at the cost of extra bytes. The eager flag can load a small shared module with the host instead of on demand, but it increases the initial host payload.

Limitations and how to verify

Shared singleton versions must be compatible across remotes. Mismatched major versions can cause runtime errors or silent behavior differences. Runtime loading adds network dependency and failure modes that static bundles do not have. Configuration is also version-sensitive; the shared and exposes API can change between webpack releases.

To verify the result, inspect the webpack config for ModuleFederationPlugin and the name, exposes, remotes, and shared sections. Run a production build and confirm each remote emits a remote entry file. Load the host app and open browser developer tools: check the Network tab for the remote entry request, then confirm the shared scope initializes without loading two copies of React.

Closing recommendation

Start with a narrow shared set, pin versions, and expand sharing only when the size and cache benefits outweigh the coupling risk. Treat the federation config as code that needs review during webpack upgrades.