#Manifest and Snapshot

mf-manifest.json is a runtime manifest generated by a producer after build. It describes which modules the producer exposes, where the remote entry is, which assets those modules need, which shared dependencies are available, and where the type files are.

Snapshot is a condensed and pre-resolved result of Manifest information. The runtime can request Manifest and generate Snapshot on demand. If you have a deployment service, it can also generate Snapshot ahead of time and deliver it to the consumer, so the consumer can get the remote entry and preloadable assets directly.

This document only explains the concepts and where they are used. For configuration, see manifest configuration. For complete fields, see mf-manifest.json fields.

#Why Manifest

With only remoteEntry.js, the consumer can load remote modules, but it cannot easily know the assets, types, and shared dependency information behind those remote modules ahead of time.

With mf-manifest.json, the consumer can get more information before loading the remote module:

• Remote entry URL and loading type
• Exposed modules and asset lists
• JavaScript and CSS that can be preloaded
• Shared dependency names, versions, and assets
• Type file URLs

So Manifest is not just another entry URL. It is closer to a runtime instruction file that the producer provides to the consumer.

#Manifest and Stats

After enabling manifest configuration, the build plugin generates both mf-manifest.json and mf-stats.json.

If you only need to consume remote modules, you usually only need mf-manifest.json. If you are building analysis tools, diagnostics, or platform integrations, then inspect mf-stats.json.

#What Snapshot Is

Snapshot can be understood as the module information that the runtime actually consumes.

Manifest is a build artifact from a single producer and is closer to a source manifest. Snapshot reorganizes that information into a structure that is easier for the runtime to consume, such as:

• The final remoteEntry for the producer
• Assets for exposed modules
• Assets that can be preloaded
• Shared dependency information
• Other remote modules that the producer depends on

Without a deployment service, the consumer requests mf-manifest.json first, and the runtime generates Snapshot from it.

Host configures remotes
  -> request mf-manifest.json
  -> parse Manifest
  -> generate Snapshot
  -> load remoteEntry, expose, shared, and preload assets

With a deployment service, the service can consume Manifest ahead of time, generate Snapshot, and deliver it to the consumer.

Producer builds Manifest
  -> deployment service parses Manifest ahead of time
  -> generate Snapshot
  -> Host gets remoteEntry and preload assets directly

This can avoid one extra Manifest request at runtime and move asset resolution to the server side.

#Where We Use It

#Remote Loading

When remotes points to mf-manifest.json, the runtime reads Manifest, generates Snapshot, and then resolves the final remoteEntry URL from Snapshot.

See remotes for configuration.

#Asset Preloading

Manifest contains asset information for exposes and shared dependencies. After Snapshot is generated, the runtime can use that information to preload the JavaScript and CSS required by remote modules.

#Chrome DevTools

Chrome DevTools uses Manifest / Snapshot to understand which federated modules exist on the current page, how modules depend on each other, how shared dependencies are reused, and which remote entry is needed for proxying.

#Local Proxying

When debugging a production page, proxy tools can use Snapshot to identify the target producer and replace it with a locally running Manifest or remote entry.

#Runtime Diagnostics

When remote loading fails, Manifest / Snapshot can help identify where the failure happens:

• Whether the Manifest URL is reachable
• Whether Manifest fields are complete
• Whether the target producer exists in Snapshot
• Whether Snapshot can resolve remoteEntry
• Whether remoteEntry loads successfully
• Whether the expose exists

This helps distinguish Manifest request failures, Snapshot misses, and later remote entry loading failures.

#What You Can Build With It

Manifest / Snapshot is suitable as input for runtime plugins, debugging tools, and deployment platforms.

You can build:

• Preload optimization: get the JS and CSS associated with remote modules earlier and reduce waiting time after user interaction.
• Module graph visualization: show which producers, consumers, and shared dependencies are loaded on the current page.
• Local proxy debugging: replace a producer on a production page with a locally running producer.
• Loading diagnostics: tell whether a failure happens at the Manifest, Snapshot, remoteEntry, or expose stage.
• Shared analysis: check whether shared dependencies are reused, duplicated, or matched against the expected version.

Business code should not modify global Snapshot directly. Prefer consuming this information through Runtime Plugin, DevTools, or a deployment service.

#Impact of disableSnapshot

If optimization.disableSnapshot is enabled, Snapshot and preload-related runtime capabilities are removed to reduce runtime size.

This affects capabilities that depend on Manifest / Snapshot, such as remote type hints, preloading, DevTools visualization, and proxying.

See optimization.disableSnapshot for more details.