Remote entry and manifest

The remote entry is the file each remote publishes to describe what it exposes and shares; the manifest is the host's list of where each remote entry lives.

These two files are how a host finds and loads remotes at runtime.

The remote entry is generated by the build of each remote. In webpack Module Federation it is a JavaScript file, commonly named remoteEntry.js. In Native Federation it is a JSON file, remoteEntry.json. In both cases it lists the modules the remote exposes and the libraries it shares, with their versions.

The manifest belongs to the host. It maps each remote name to the URL of its remote entry. The host fetches it at startup, so remote URLs are not hard-coded into the host bundle.

Example

{
  "orders": "https://cdn.example.com/orders/remoteEntry.json",
  "invoices": "https://cdn.example.com/invoices/remoteEntry.json"
}

The same host build can run in staging and in production with different manifests. To roll back the orders remote, you point its line to the previous version. The host does not change.

Common misunderstanding

The remote entry is small, and its caching is easy to get wrong. Its file name stays the same between deployments, while the chunks it references have hashed names. If a CDN or a browser caches the remote entry for a long time, users keep loading the old version, or a mix of an old entry and chunks that no longer exist.

Serve the remote entry and the manifest with a short cache lifetime or with revalidation, and cache the hashed chunks for a long time. The manifest is also a control point. Whoever can edit it decides which code runs in production, so protect it like any other deployment credential. See micro-frontends for the wider design.

Related terms

• Host (shell) application
• Remote (micro-frontend remote)
• Native Federation
• Rollback