The singleton that stopped being one (module-federation/core #4078)

The first named version-negotiation incident this spoke holds. module-federation describes the shared mechanism from its own documentation and ends by saying nothing here reports what federation costs a team in practice. This is one such report, filed on the project's own tracker.

What happens

A team sharing a library in a monorepo (rslib + rsbuild, pnpm) declares it a singleton with a prerelease version string:

// producer
shared: { 'my-shared-library': { singleton: true, requiredVersion: '2.2.2-release.99' } }
// consumer
shared: { 'my-shared-library': { requiredVersion: '*' } }

The reporter's account: "When a shared library has a version with a postfix, Module Federation does not treat it as a shared singleton. Instead, each remote application loads its own separate instance of the dependency, defeating the purpose of sharing and potentially causing runtime errors (e.g., multiple instances of React, broken context providers)."

And the control that makes it a bug rather than a misconfiguration: "If we remove the postfix and use a standard semantic version (e.g., 2.2.2), the sharing mechanism works perfectly as expected." The consumer had asked for * — every version — and still did not get the shared copy.

Why it belongs here rather than in a bug list

The spoke's finding about this mechanism is that federation enforces its boundary at runtime, by version negotiation, and that a boundary whose violations surface as console warnings in production is the weakest of the enforcement categories it has catalogued. This incident is that claim happening.

Nothing failed. The build succeeded, the consumer's requiredVersion: '*' was satisfied by a copy it loaded itself, and the symptom is two instances of a library in one page — the class of defect that shows up as a broken React context, not as an error naming its cause. A semver prerelease suffix, which is ordinary release-engineering practice, is enough to trigger it.

What happened to the report

Filed 2025-09-18. Two comments. Closed 2025-12-02 as not_planned, carrying a single label: no-issue-activity. So it was closed by inactivity rather than by a decision, and the behaviour is neither fixed nor documented as intended.

That is the part worth keeping. The failure is silent at runtime and the report of it went stale on the tracker — there is no artifact a team evaluating this architecture would encounter before hitting it themselves.

What this is not

One report, not an accounting. It is a single team's reproduction with no measurement attached: no bundle-size figure, no incident duration, nothing about how long the two-instance state ran before anyone noticed. The spoke's edge asked what runtime dependency sharing costs, and one qualitative incident does not answer that. Read it as evidence the cost is real and unmeasured, which is the same shape as the spoke's standing complaint about its whole domain.

Related

module-federation · micro-frontends · micro-frontends-migration · application-architecture