Runtime
The runtime — @softarc/native-federation-runtime — is the
small browser-side library that reads
remoteEntry.json files, constructs an ES module
import map, injects it into the DOM, and resolves
loadRemoteModule() calls against it. It is the classic
Native Federation runtime: one version of each shared dependency,
wired up on startup, and loaded on demand.
Classic runtime — not the default in v4.
This runtime is the default runtime in Native Federation
v3 and is what
@angular-architects/native-federation re-exports out of
the box. It is the legacy runtime going forward: in
v4 the recommended browser runtime is the new
Orchestrator
(@softarc/native-federation-orchestrator), which adds
semver-range resolution, persistent caching and share scopes on top
of the same remoteEntry.json contract.
The classic runtime is still supported — and still the right choice
when you need raw simplicity, SSR compatibility on the host, or a
drop-in v3 behaviour. If you are starting a new v4 project, prefer
the Orchestrator.
What the Runtime Does
Given a list of remotes (or a manifest URL that resolves to one), the runtime:
-
Loads the host's own
remoteEntry.jsonand registers its shared dependencies at the root of the import map. -
Fetches each remote's
remoteEntry.jsonin parallel and registers:-
the remote's exposed modules as root imports
keyed by
<remoteName>/<exposedKey>; - the remote's shared dependencies under a scope keyed by the remote's base URL.
-
the remote's exposed modules as root imports
keyed by
-
Merges everything into a single import map and injects it as a
<script type="importmap-shim">intodocument.head— so it needs es-module-shims in the page. -
Exposes a
loadRemoteModule()helper that performs a dynamicimport()(throughimportShim) against that import map. -
Optionally opens a Server-Sent Events connection to a remote's
buildNotificationsEndpointto reload the page when the remote rebuilds (dev only).
What the Runtime Does Not Do
The classic runtime is deliberately thin. Things that are not handled here (and are reasons to reach for the Orchestrator in v4):
-
No semver-range resolution. Each shared dependency
gets one URL per scope. If two remotes share different
versions of
rxjsthey simply each keep their own — the runtime does not compare ranges or pick a common version. The first URL registered under a givenpackageName@versionwins for the external lookup (see Externals registry). -
No share scopes. There is a single implicit scope
per remote base URL; there is no
shareScopeconcept. -
No persistent caching. Every page load re-fetches
every
remoteEntry.json. You can append a query string viacacheTagfor cache-busting, but there is nolocalStorage/sessionStoragelayer. -
No pluggable storage or logger. Errors go to
console.error; state lives onglobalThis.__NATIVE_FEDERATION__.
If any of those matter to you, look at the Orchestrator.
Where It Fits
The runtime is the consumer of the artifacts that
Core emits. The contract between
build and runtime is the
remoteEntry.json
file — the runtime does not care which bundler produced it. For how
the runtime relates to the other layers, see the
Architecture Overview.
In this section
-
Getting Started — install the
package, add
es-module-shims, split your bootstrap. -
initFederation— how the host sets federation up: manifest vs. inline map, cache busting, error handling. -
loadRemoteModule— both call signatures, lazy remote registration and fallbacks. -
The Import Map — how imports and
scopes are constructed, how externals are deduplicated,
importmap-shim, and Trusted Types. -
API Reference — the complete public
surface of
@softarc/native-federation-runtime.
If you are an Angular user, you will normally consume the runtime
through @angular-architects/native-federation, which
re-exports initFederation and
loadRemoteModule unchanged. See
Angular Adapter → Runtime
for the Angular-specific bootstrap split.