Webpack Module Federation

Modern web applications are getting bigger, faster, and more complex.
Teams want to work independently, deploy features separately, and still make everything feel like one app.

That’s exactly where Webpack Module Federation comes in.

Let’s break it down step by step — no heavy jargon, I promise 😊

What Is Module Federation?

Module Federation is a Webpack feature that allows one JavaScript application to use code from another application at runtime.

👉 In simple words:

One app can load and use components, utilities, or modules from another app — without rebuilding the whole project.

Why Was Module Federation Introduced?

Before Module Federation, we had two main problems:

❌ Problem 1: Huge Bundles

• All code was bundled together
• Any small change required rebuilding the entire app

❌ Problem 2: Team Dependency

• Multiple teams working in one repo caused conflicts
• Deployment had to be coordinated

The Solution: Micro Frontends

Micro Frontends mean:

• Break a big frontend into small independent apps
• Each app can be built and deployed separately

But… how do these apps share code?

➡️ That’s where Module Federation shines.

Real-World Analogy

Think of Module Federation like a food court 🍔🍕🍜

• Each stall (app) cooks its own food
• You don’t cook everything in one kitchen
• Customers (users) can order from multiple stalls in one place

Here:

• Food stall = Independent app
• Food = Components / logic
• Food court = Host application

Key Concepts (Very Important)

1️⃣ Host Application

• The main app
• Loads modules from other apps

2️⃣ Remote Application

• The app that exposes components
• Other apps can consume them

3️⃣ Shared Dependencies

• Common libraries like react, react-dom
• Prevents loading the same library multiple times

Basic Example (Simple & Clear)

Scenario

• App1 (Host) wants to use a Button from App2 (Remote)

🔹 App2 (Remote) – Expose a Component

// webpack.config.js (App2)
new ModuleFederationPlugin({
  name: "app2",
  filename: "remoteEntry.js",
  exposes: {
    "./Button": "./src/Button",
  },
});

👉 This means:

• App2 is saying:
  “Hey! I’m sharing my Button component.”

🔹 App1 (Host) – Consume the Remote Component

// webpack.config.js (App1)
new ModuleFederationPlugin({
  name: "app1",
  remotes: {
    app2: "app2@http://localhost:3002/remoteEntry.js",
  },
});

Now in your React code:

const RemoteButton = React.lazy(() => import("app2/Button"));

🎉 Boom! App1 is using App2’s component at runtime.

How Is This Different from NPM Packages?

Why Module Federation Is Powerful

✅ Independent deployments
✅ Faster builds
✅ Better team scalability
✅ True micro frontend architecture
✅ Runtime code sharing

Things to Be Careful About

• Version mismatch of shared libraries
• Network dependency (remote app must be available)
• Slightly complex setup initially

💡 Tip: Always share React as a singleton.

When Should You Use Module Federation?

Use it when:

• Your app is large
• Multiple teams work independently
• You want micro frontends
• You want faster deployments

Avoid it if:

• Small app
• Single developer
• Simple requirements

Final Thoughts

Webpack Module Federation is not magic — it’s a smart way to share code between apps without tight coupling.

Think of it as:

“Importing code from another app… but at runtime.”

Once you understand the concept, it feels natural and extremely powerful 💪