Pandora E-Commerce · Architecture · Webpack-Native

One Bundler. Everything.

① Webpack compiles everything

›

② Output: static files

›

③ Only files deploy

① Build Machine / CI

Developer laptop · CI server · runs before deployment

⚙

📦Webpack 5

One bundler handles everything — Next.js app build, HMR, SSR, and Module Federation in a single process. No second runner needed.

next dev · next build · single process

⏱ HMR ~2–5s · Cold start ~10–30s

// next.config.js — one file, no extras const { ModuleFederationPlugin } = require('webpack').container; const BUILD_ID = process.env.BUILD_ID; // injected in CI module.exports = { webpack(config) { config.plugins.push( new ModuleFederationPlugin({ name: 'home_remote', filename: `remoteEntry.${BUILD_ID}.js`, // → .next/static/chunks/remoteEntry.2292.js shared: { react: { singleton: true } } }) ); return config; } };

✓ One process — output lands in .next/ Versioned filename per deploy → immutable CDN caching safe

⛔ Webpack stays on this machine Never installed on the production server

output

›

② Compiled Output

Static artifacts — the only things that move to production

~2.4 MB

📁.next/static/chunks/

Everything Webpack emits — app chunks, SSR, and MF manifest

              ├📄
              page-xxx.js
              app chunks
            

              ├📄
              react-abc123.js
              shared deps
            

              ├📄
              __federation_expose_PLPPage.js
              MF expose
            

              └📄
              remoteEntry.2292.js
              MF manifest ✓
            

Versioned filename — new BUILD_ID each deploy = new URL = immutable caching safe. No public/ folder needed.

Just compiled

One folder. One process. All CDN benefits.
.next/ handles everything. Webpack stays behind.

Deploy Gate

📁Files

›

✓ Deploys

vs

⚙Tools

📦

✕

✗ Blocked

LIVE

③ Production Server

Cloud · CDN · No bundlers installed

⬡

Node.js Runtime

JavaScript engine on your server

Makes JavaScript run on the server — same language as the browser, but in the cloud. Handles every visitor's HTTP request.

Receives browser HTTP requests

Runs SSR from .next/

Serves remoteEntry.{BUILD_ID}.js from .next/

Does NOT run Webpack

No bundlers installed here

✓

.next/static/chunks/

App chunks · shared deps · remoteEntry.2292.js — all in one folder

Cache-Control: immutable · CDN · Brotli · HTTP/2 ✓

Not installed on server

📦Webpack — build tool only

Pandora E-Commerce · Architecture · Webpack-Native

Pure Webpack vs Turbopack Hybrid — Know the Trade-off

scroll ↓

⚖

Same Runtime Outcome — Different Developer Experience

React is shared correctly in both approaches. The choice is about build speed, setup complexity, and team friction.

📦

Pure Webpack

This approach · one bundler, everything native

HMR speed

2–5s

per change · full rebuild

Cold start

10–30s

initial compilation

Processes

1

single next dev

Config files

1

next.config.js only

HMR latency

~3s

Cold start

~20s

Single process — no coordination between two tools

Native ModuleFederationPlugin — built into Webpack 5

One config file — next.config.js, nothing else

Battle-tested — Webpack MF has years of production use

__webpack_share_scopes__ works natively on both sides

Slow HMR — every change triggers full JS rebuild

Slow cold start — large apps can take 20–30s to boot

No Rust-speed benefits — Turbopack is 10–100× faster

⚡

Turbopack + Webpack

Current POC approach · hybrid, two parallel processes

HMR speed

~50ms

instant · Rust-based

Cold start

~3s

Turbopack fast init

Processes

2

Turbopack + Webpack

Config files

2+

next.config + federation.js

HMR latency

~50ms

Cold start

~3s

Instant HMR — Turbopack recompiles in ~50ms

Fast cold start — ~3s vs 20s with pure Webpack

Next.js default — officially recommended by Vercel

Future-ready — Turbopack adding native MF support

Two parallel processes — coordination required

Two config files — more surface area for bugs

MF workaround — Turbopack has no native MF today

🔗

Runtime behaviour is identical — React is shared correctly in both approaches

Both use Module Federation runtime negotiation. The host registers React via lib:()=>React. The remote's get():i.e(86) fallback is never triggered. 86.js is absent from the Network tab in both setups. The only difference is developer experience — build speed and configuration complexity.

Verified in POC

Pandora E-Commerce · Architecture · Webpack-Native

React Shared Scope — Native Webpack MF

scroll ↓