Spokes.wiki Search About
Created
Updated

Module Federation

The mechanism micro-frontends-migration keeps naming and never describes. Paged from its own documentation and repository on 2026-08-22.

module-federation/core, MIT, 2,618★ / 430 forks / 61 open issues, created 2020-10-24, last pushed 2026-08-21, latest release v2.8.2 (2026-08-06). Bundler support: Rspack and Webpack.

What it claims to be

The project's own first sentence is the interesting one for this spoke:

"Module Federation is an architectural pattern for the decentralization of JavaScript applications (similar to microservices on the server-side)."

It states the analogy micro-frontends borrows, in the tool's own words, and states it as the definition rather than as a comparison. The roadmap repeats it — the project intends to become "an architectural method for building large web applications, similar to microservices in the backend," with routing, sandboxing and SSR planned on top.

That is a pattern claim made by a build plugin. Everything else on this page is a bundler feature.

The three roles

The vocabulary is small and the docs define it directly:

  • A producer (remote) is "an application that exposes other modules to be consumed by other JavaScript applications," configured through exposes.
  • A consumer (host) is "an application that consumes modules from other Producers," configured through remotes.
  • A manifest is "a runtime manifest generated by a producer during build. It describes the remote entry, exposed modules, assets, shared dependencies, and type information."

Nothing in the roles is exclusive: an application can be both. The unit of federation is a module, not a page or a route — which is why the same tool serves a genuine micro-frontend split and a plain shared-component library, and why the architectural claim above does not follow from adopting it.

The hard part is shared, and the docs say so

The configuration that decides whether federation works is shared, whose stated purpose is "duplicate dependency loading and singleton restrictions." The negotiation happens at runtime, in a share scope, and the rules are specific:

  • shareKey is the lookup key in the share scope, and "both the producer and the consumer must use the same shareKey" — otherwise the negotiation silently does not happen and each side ships its own copy.
  • singleton: true means the dependency "will only be loaded once, and a higher version will be loaded if the versions are inconsistent." The party holding the lower version gets a warning and the other version.
  • Without singleton, "each side will load its own dependencies" when versions differ.
  • requiredVersion is checked as a floor; on a mismatch the runtime uses "the smallest version available" and warns.
  • import: false means the module is not bundled at all and only the consumer's copy is used.
  • eager loads the shared module immediately, at the price of entry size.

This is the enforcement question the spine keeps asking, answered by a third mechanism. synthesis.md has framed boundary enforcement as deployment (a micro-frontend boundary needs a network call to cross) versus discipline (a feature-first-structure boundary needs code review). Module Federation is neither. The boundary is enforced at runtime, by version negotiation, and the failure mode is not a rejected import or a merge-request comment — it is two copies of React in one page, or a singleton silently upgraded under a team that did not ask for it, discovered in the browser. A boundary whose violations surface as console warnings in production is a fourth category, and the weakest of the three.

micro-frontends-migration has the field report that fits: React Router against Module Federation "needed a manual downgrade." That is exactly this negotiation, resolved by hand.

What 2.0 added

The version in use is not the one shipped inside Webpack 5. Module Federation 2.0 "extends the Webpack 5 core" with dynamic type hinting, the manifest, a federation runtime and a runtime plugin system, which the project says makes it "more suitable for use as a micro-frontend architecture in large-scale Web applications." Plus Chrome DevTools integration.

The direction is legible: the original was a build-time feature that produced a remoteEntry file, and the additions are all about what happens after the build — a manifest describing what a remote actually offers, a runtime that can be extended, and type information crossing the boundary so a consumer can typecheck against a remote it does not compile.

What is not evidenced here

The benefits list — "reduce code duplication," "improve code maintainability," "lower the overall size of your applications," "enhance the performance of your applications" — is the maker's claim about its own product, with no measurement attached. That belongs to the spoke's standing complaint (see synthesis.md → The corpus's own weak spot): the strongest structural claims in this domain are the least measured ones, and this page is graded T1 for the mechanism it documents, not for that list.

Updated 2026-08-25. One version-negotiation incident is now paged: module-federation-singleton-postfix-bug, where a semver prerelease suffix (2.2.2-release.99) stopped a singleton: true from being honoured, each remote loaded its own copy, and the report was closed by an inactivity bot rather than by a decision. It confirms the enforcement finding above with a concrete case and adds a trigger nobody would guess: ordinary release-engineering version strings.

What is still missing is the accounting. No source here measures what federation costs a team over time — bundle bytes lost to duplication, how long a two-instance state ran before anyone noticed, the coupling a shared scope reintroduces, or whether the independence micro-frontends is chosen for survives a singleton: true on the framework.

  • micro-frontends — the architecture; this is one way to implement it, and not the only one.
  • micro-frontends-migration — the practitioner account that names the tool.
  • app-shell — what composes the federated pieces at runtime.
  • ../dev-tooling-wiki — Rspack and Webpack as bundlers are that spoke's; the structural consequences are here.