What Is Webpack Module Federation and How Does It Work?
Learn how Webpack Module Federation lets independently deployed bundles share code at runtime, with a working example.
Expected Interview Answer
Module Federation is a Webpack (and now Rspack/Vite-ecosystem) capability that lets separately built and independently deployed JavaScript bundles dynamically load code from each other at runtime, over the network, as if they were part of the same application.
A "host" application declares one or more "remotes" it wants to consume, and each remote exposes specific modules (components, hooks, utilities) via a small manifest file, remoteEntry.js, generated at build time. At runtime, the host fetches that manifest, resolves the requested module, and loads it into the running page — no rebuild or redeploy of the host is required when the remote ships a new version. Shared dependencies like React can be marked as singletons so multiple federated bundles reuse one runtime instance instead of each shipping its own copy, avoiding both bloat and dual-React errors like invalid hook calls. This is the primary technical enabler behind runtime micro-frontend composition: teams deploy their remote independently, and the host picks up the change on the next page load without any coordinated release.
- Independently deployed bundles load each other at runtime with no rebuild of the consumer
- Shared singleton dependencies avoid duplicate framework copies and version conflicts
- Enables incremental adoption — a remote can be added without restructuring the host app
- Decouples release cadence between the host shell and each remote team
AI Mentor Explanation
Module Federation is like a stadium’s broadcast truck plugging into any ground’s shared camera feed on match day without needing to pre-install its own cameras there — it just connects to a published feed address and pulls in exactly the angles it needs. If the ground upgrades a camera overnight, the truck picks up the new feed automatically the next morning with no reconfiguration. Multiple broadcasters can share one feed instead of each rigging duplicate cameras. That runtime-connect-to-a-published-feed model is exactly how Module Federation lets a host app pull in a remote’s code without rebuilding.
Step-by-Step Explanation
Step 1
Remote exposes modules
The remote app configures ModuleFederationPlugin to expose specific components/utilities and builds a remoteEntry.js manifest.
Step 2
Host declares the remote
The host app configures the same plugin with a remotes entry pointing at the remote's published remoteEntry.js URL.
Step 3
Runtime fetch and resolve
When the host code imports from the remote, Webpack fetches the manifest and resolves the specific exposed module over the network.
Step 4
Shared singleton dependencies load once
Marked shared deps like React are deduplicated across host and remotes so only one runtime instance is used.
What Interviewer Expects
- Understanding of host/remote roles and the remoteEntry.js manifest mechanism
- Ability to explain why shared singleton dependencies matter (avoiding duplicate React copies)
- Awareness that this enables independent deployment without rebuilding the host
- Mention of failure modes: version mismatches, dual-React invalid hook call errors
Common Mistakes
- Forgetting to mark framework dependencies as shared singletons, causing duplicate React instances
- Assuming Module Federation requires a full rebuild of the host when a remote changes
- Confusing exposed modules with the entire remote app being loaded
- Not accounting for network failure handling when a remote is unreachable at runtime
Best Answer (HR Friendly)
“Module Federation is a Webpack feature that lets separately built and deployed pieces of an app load each other’s code live, in the browser, without needing a full rebuild. One team can update their part and everyone using it sees the change on their next page load, which is what makes independently deployed micro-frontends practical.”
Code Example
// remote/webpack.config.js
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin')
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'checkout',
filename: 'remoteEntry.js',
exposes: {
'./CheckoutFlow': './src/CheckoutFlow',
},
shared: { react: { singleton: true, requiredVersion: '^18.0.0' } },
}),
],
}Follow-up Questions
- How does Module Federation handle a version mismatch between a shared singleton dependency in host vs remote?
- What happens if a remote is unreachable at runtime, and how would you handle that gracefully?
- How does Module Federation differ from dynamic import() code-splitting within a single app?
- How would you type-check a remote module's exposed API in TypeScript across repository boundaries?
MCQ Practice
1. What file does a Module Federation remote generate for hosts to consume?
remoteEntry.js is the small manifest a host fetches at runtime to resolve exposed modules.
2. Why mark React as a shared singleton in Module Federation config?
Singleton sharing ensures host and remotes reuse one React instance instead of each bundling their own.
3. What is the key runtime behavior that makes Module Federation different from a normal bundle import?
Module Federation loads independently built and deployed code dynamically over the network, not from the host's own build.
Flash Cards
What is remoteEntry.js? — The manifest a Module Federation remote generates for hosts to discover exposed modules.
Why use shared singletons? — To avoid duplicate framework runtime copies and invalid hook call errors.
What does a host do at runtime? — Fetches the remote's manifest and loads the specific requested module over the network.
Main Module Federation benefit? — Independently deployed bundles can be consumed live without rebuilding the host.