Legacy Runtime

The classic @softarc/native-federation-runtime — end-of-life, replaced by the Orchestrator.

@softarc/native-federation-runtime was the original browser-side library: it read remoteEntry.json files, merged them into one ES module import map, injected it into the DOM, and resolved loadRemoteModule() calls against it. One version of each shared dependency, wired up on startup.

Deprecated — end-of-life. This was the default runtime in Native Federation v3. A v4 line was published up to 4.1.2, but the package is now marked deprecated on npm: "This package has reached end-of-life and is no longer maintained. Please switch over to the @softarc/native-federation-orchestrator library."

The Orchestrator is the replacement, and it is where all runtime documentation now lives. It speaks the same remoteEntry.json contract, so migrating a host is mostly a matter of swapping the import and threading the resolved loader through your app — see Migration to v4.

The deep-dive pages for this package — initFederation, loadRemoteModule, the import map and the API reference — live in the v3 docs, where it is the default runtime. They are kept out of the v4 tree because its API is close enough to the Orchestrator's to be mistaken for it.

Why the Orchestrator Replaced It

The classic runtime was deliberately thin. Each of these gaps is a reason it was superseded:

GapHow the Orchestrator handles it
No semver-range resolution. Each shared dependency got one URL per scope; two remotes wanting different rxjs versions simply each kept their own.Compares declared ranges and elects one version per scope — see Version Resolver.
No share scopes. A single implicit scope per remote base URL.Global, named, and strict share scopes.
No persistent caching. Every page load re-fetched every remoteEntry.json.Pluggable storage — sessionStorage / localStorage survive navigation and reloads.
No pluggable storage or logger. Errors went to console.error; state lived on globalThis.__NATIVE_FEDERATION__.Configurable logger and storage handles.
No dynamic init. Remotes had to be known up front, apart from a remoteEntry-based one-off load.initRemoteEntry adds remotes after startup, additively.

Where to Go Instead