Module Federation for Banking Portals

Module Federation's pitch is that independently-built, independently-deployed frontends can share code at runtime without a monorepo forcing every team onto the same release train. That pitch is true, and it's also exactly where the risk lives: "shared at runtime" means the thing that used to be a compile error in a monorepo is now a runtime error in production, discovered by whichever customer happens to navigate into the account-opening micro-frontend first after a shell deploy. This is about the two places that actually breaks, and what closes each one. 

What's actually being shared, and why that's the risk surface 

Module Federation lets a host application (the shell) load remote applications (micro-frontends, owned by other teams) at runtime, and — critically for a framework as stateful as Angular — share singleton dependencies like @angular/core and @angular/common between them, rather than each remote shipping its own copy. Sharing is what makes the architecture viable: without it, every micro-frontend bundles its own Angular runtime, bloating every page load and risking two live instances of a framework that assumes there's only one. 

That sharing is also where version drift becomes a production incident instead of a build warning. A monorepo catches an incompatible dependency bump at compile time, for everyone, before it ships. A federated architecture, by design, lets the payments team ship their remote on Tuesday and the accounts team ship theirs on Thursday, and the first place an incompatibility between them shows up is a customer's browser, not a CI pipeline. 

Dependency version drift: what Webpack Module Federation actually does about it 

Webpack's ModuleFederationPlugin resolves shared singleton versions using SemVer at runtime: if the versions requested by the shell and each remote are compatible, it picks the highest one everyone can use. If they aren't compatible, the default behavior is to still pick a version and hope for the best — which for a stateful singleton like Angular's core, is exactly the scenario that produces a Error: Unsatisfied version exception in production, not a build failure anyone caught beforehand. 

 1 // shell's federation config 
 2 shared: { 
 3   ...shareAll({ 
 4     singleton: true, 
 5     strictVersion: true,       // throw instead of silently picking a version 
 6     requiredVersion: 'auto',   // pull the actual version from this project's package.json 
 7   }), 
 8 }, 

strictVersion: true is the setting worth treating as non-negotiable for a banking portal specifically: it converts a silent, best-effort version resolution into a thrown exception the moment an incompatibility is detected, which is a worse-looking error but a genuinely safer one — a loud failure on load beats a subtly broken shared Angular instance serving real account data. requiredVersion: 'auto' matters for a different reason: hand-typed version strings drift out of sync with package.json the first time someone bumps a dependency and forgets the federation config, which is exactly the kind of gap that turns a routine dependency update into an incompatible-version incident three deploys later. 

The failure that isn't a version mismatch at all 

Dependency versioning is the failure mode most Module Federation guidance covers. It's not the one that actually causes the worst incidents on a multi-team portal. The other one is a runtime contract break: a remote module's exposed component changes its public API — a required input becomes optional, an output event gets renamed, a component that used to render synchronously now returns a promise — and the shell, built and deployed independently, has no compiler in the loop to catch the mismatch. Nothing about Module Federation checks that what a remote exposes today still matches what the shell expects, because they're compiled separately, by separate teams, on separate schedules. 

This is the same category of problem as any other integration boundary between independently-deployed services, and it deserves the same discipline: treat every exposed federated module as a versioned public contract, not an internal implementation detail that happens to be reachable from outside the repo. Concretely, that means: 

Explicit input/output contracts on every exposed component, documented and reviewed with the same rigor as a public API — because that's what it actually is, even though it's TypeScript rather than REST. 

Contract tests run against the real built remote, not a mock, in CI, on both sides of the boundary — the shell's pipeline pulls the actual remote's remoteEntry.js (or Native Federation's manifest) and verifies the exposed modules it depends on still match the expected shape, the same instinct behind contract testing tools like Pact at any other service boundary, applied here to a frontend one. 

A deprecation window for any breaking change to an exposed module — old and new versions exposed side by side for a release or two, exactly the same discipline an API team would apply to a breaking endpoint change, because a federated component has the same blast radius as an API a team doesn't control the deploy schedule of. 

Native Federation: faster, but not yet the same flexibility 

Angular's ecosystem has been moving toward Native Federation — an esbuild-based alternative to Webpack's plugin, and the direction the Angular CLI itself is heading, with real build-time improvements teams report (one enterprise migration cited going from roughly 45 seconds to under 10 for a federated build). 

 1 // federation.config.ts 
 2 export default withNativeFederation({ 
 3   name: 'shell', 
 4   remotes: { accounts: 'http://localhost:4202/' }, 
 5   shared: { 
 6     ...shareAll({ singleton: true, strictVersion: true }), 
 7   }, 
 8 }); 

The syntax is deliberately close to Webpack MF's, which eases migration — but worth knowing before committing a banking portal to it: as of this writing, Native Federation's singleton handling is less flexible than Webpack's. Where Webpack MF can resolve compatible-but-different versions to the highest common one, Native Federation currently expects singleton dependencies to match exactly across the shell and every remote, with community tooling (an in-progress orchestrator project) still catching up to close that gap. For a portal where different teams update dependencies on different schedules, that's a real operational constraint, not a rounding error — worth validating directly against your team's actual dependency-update cadence before migrating, rather than assuming feature parity with Webpack MF. 

The migration doesn't have to be all-or-nothing 

Because Native Federation's manifest format and exposed-module mechanics are close enough to Webpack MF's, teams don't need a single cutover. A shell can stay on Webpack MF while individual remotes migrate to Native Federation independently, module by module, validated against the same contract tests described above before and after the switch — the contract-testing discipline is what actually makes an incremental migration safe, because it's what catches a mismatch introduced by the migration itself, not just by an unrelated dependency bump. 

What actually prevents the drift 

Neither implementation solves version drift or contract breaks by default — both give you the tools and neither enforces using them. The discipline that holds up in practice is boring on purpose: strictVersion: true everywhere so a bad resolution fails loudly instead of silently, requiredVersion: 'auto' so the federation config can't drift from package.json, and contract tests against real built remotes in CI so a breaking change to an exposed module is caught before a shell deploy ships it to a customer, not after. None of that is exotic. It's the same discipline a well-run API team already applies to any boundary they don't fully control — a federated micro-frontend just makes that boundary look, misleadingly, like it's still inside your own build.