RFC: report concrete shared providers in federation manifests

[ScriptedAlchemy]

RFC: report concrete shared providers in federation manifests

Problem

A build can provide multiple implementations under the same shared key. Today, its manifest has one summary version and an aggregate asset list. It cannot tell a reader which import and assets belong to each implementation.

For example:

shared: {
  react18: { import: 'react18', shareKey: 'react', version: '18.3.1' },
  react19: { import: 'react19', shareKey: 'react', version: '19.0.0' },
}

Both implementations can be compiled and registered correctly, but a manifest-only tool cannot enumerate both versions or associate each with its files. Recovering that detail currently requires access to bundler-specific module data.

Proposal

Add optional providers records to shared entries in mf-stats.json and mf-manifest.json. A provider is one concrete version/import pair emitted by this build, not another remote or a runtime selection decision.

// Excerpt; existing shared fields remain unchanged.
{
  name: 'react',
  version: '18.3.1',
  providers: [
    {
      version: '18.3.1',
      import: './node_modules/react18/index.js',
      assets: {
        js: { sync: ['react18.js'], async: [] },
        css: { sync: [], async: [] },
      },
    },
    {
      version: '19.0.0',
      import: './node_modules/react19/index.js',
      assets: {
        js: { sync: ['react19.js'], async: [] },
        css: { sync: [], async: [] },
      },
    },
  ],
}

flowchart LR
  A[Compiled shared implementations] --> B[Group by shared key / scope / layer]
  B --> C[Existing shared summary]
  B --> D[Version + resolved import + assets per provider]
  C --> E[Stats and manifest]
  D --> E

Loading

Proposed rules:

• Publish the array only when multiple distinct version/import pairs exist. Coalesce equivalent pairs and sort the output deterministically.
• Keep alternatives within the containing shared identity; never combine different scopes or layers. No new public identity field is required.
• Use build-context-relative resolved imports, preserving resource queries, and the existing JS/CSS asset shape. Shared chunks may appear in more than one provider's assets.
• Preserve existing top-level fields and omit the array for single-provider, consumer-only, or disabled-analysis entries. Readers must accept its absence.

What this enables

Build diagnostics could show which implementations were bundled under a shared key. Artifact-analysis or deployment tools could associate versions with their actual files without loading full bundler stats. These are proposed consumers, not functionality already implemented in the runtime or Lynx adapter.

The implementation PRs add the collection, schema, serialization, and tests needed for that report. They do not change shared registration, version negotiation, singleton selection, or layer behavior.

Tradeoffs and review questions

• Is a portable provider report useful enough to justify collection work and a larger public schema? Which consumer should validate the first use case?
• Should the field live only in build stats, or also in the smaller runtime manifest as proposed?
• Is version plus resolved import sufficient, including resource queries and multiple build configurations?
• Should provider-specific fallback entry/name be a later extension? The original Rspack prototype includes enrichment, but it needs an agreed Webpack/Rspack contract.

An alternative is to keep the current manifest and let specialized tooling inspect compiler data. Before merging, validate cross-bundler output, old-reader compatibility, duplicate handling, disabled analysis, and collection overhead.

Implementation

• Independent core draft: feat(manifest): report concrete shared provider metadata #5083
• Independent Rspack draft: feat(mf): report concrete shared provider metadata web-infra-dev/rspack#15687

Both drafts target main and remain outside the layers stack. Core uses its existing stats collector. Rspack uses its native manifest collector. Neither draft imports the graph or layers refactors. Cross-bundler output, scope/layer grouping, and fallback enrichment still require agreement before adoption.

The complete earlier prototypes remain preserved in core #5078 and Rspack f0a9c614. Provider reporting is not a prerequisite for the separate layers feature.