Build1 publisher2 min readPublished
Native Federation moves the sharing contract out of the bundler and into the import map
The first part of an eight-part deep dive on Native Federation argues that webpack's container runtime is what ties a federated system to one bundler for life, and that ES modules plus import maps cut that tie.
The Engineer · Build desk
What happened
- The first installment of an eight-part Native Federation deep dive on dev.to sets out why a second implementation of Module Federation's host and remote model was worth building at all.
- It describes webpack Module Federation as wrapping every federated module in a runtime container and negotiation layer, with webpack's own resolution and chunk loading sitting in the load path.
- Native Federation instead publishes a remote's exposed module as a real .js file loaded by dynamic import(), and resolves shared dependencies through the browser's import map.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A team running Module Federation in production now picks between a federation rewrite it can schedule and a bundler migration that later drags the federation layer in with it.
- constraint The bet is only collectable where an adapter exists, and both named adapters target esbuild, so hosts on other build tools either wait or write the adapter themselves.
- capability With resolution living in an import map, a host can change build tools without renegotiating the sharing contract, provided the replacement emits ESM and the same manifest.
- cost The case here is structural and the migration detail sits in a later installment, so anyone acting on it this quarter is estimating the rewrite unaided.
A federated import under webpack is resolved by webpack. Its resolution logic, its chunk loading machinery and its container format sit between the host and the remote, because Module Federation had to retrofit dynamic runtime loading onto a bundler whose value proposition is static dependency analysis at build time [5][6]. The author is not sneering at that. "Webpack Module Federation is, technically, remarkable," the post says, and "Thousands of production systems prove it works." [7][8]
The same call under Native Federation is a dynamic `import()` of a genuine `.js` file [13]. When code asks for `react`, the answer comes from an import map: a JSON structure that tells the browser which URL that bare specifier resolves to [14]. The build tool emits standards-compliant output plus a `remoteEntry.json` manifest saying what is exposed and what is shared, and it stops being responsible for how the browser resolves modules at runtime [15]. No bundler runtime mediates the load [12].
The lock-in argument follows from there. Because the runtime contract is a webpack runtime contract, the host and every remote are implicitly committed to webpack or a webpack-compatible bundler for the life of the federated system [9]. Getting out means carrying Module Federation's runtime into the tool you are migrating to, or re-architecting the federation layer as part of the bundler migration. "Two hard problems, coupled," the post says [11]. The second cost it lists is a parallel module system: Module Federation builds its own resolution and loading logic on top of webpack instead of using ES Modules, which have matured in the browser [10].
Whether that transfers to a given codebase depends on the adapter. Part 1 names two, and both are esbuild: a reference esbuild adapter, and an Angular adapter that hooks directly into Angular's own esbuild-based Application Builder, described as the most mature of the set [16][19]. The article does not name an adapter for Vite or Rspack [21]. Angular teams already on the Application Builder are the population this design is shipped for today.
The post discloses at the top that Claude was used to reformat and structure the content [2]. That is more disclosure than most architecture writeups carry. Core, Adapters, the Orchestrator, version drift and migration go to the seven installments after this one [18][20]. On the v4 rewrite the title advertises, what part 1 delivers is the standards bet and its claimed payoff, which the post puts as "the bundler becomes replaceable" [22][17].
What to watch
- Whether the migration installment documents a measured path off Module Federation for an existing host, rather than a structural argument.
- Whether adapters appear for Vite or Rspack, since both adapters named in part 1 are esbuild-based.
- Whether the Core and Orchestrator installments enumerate what the v4 rewrite actually changed.