Runtime mistakes existing globals for remote containers and can remove them on retry

Open
  • Is something wrong?
#5,222 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@tonoizer is already working on this.

Since Oct 28, 2026.

  • #5223 by @tonoizer — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
20/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
javascript, node.js, typescript, webpack
Domain
backend, devtools

Research direction

Start with the shared runtime's global lookup and cleanup boundary, using the linked reproduction repo's browser and Node cases to understand the collisions. Check the existing tests for preloaded containers, getter exports, and retry cleanup; the issue does not name specific files or tests. Done means foreign globals are preserved, conflicts are rejected before entry execution, and legitimate containers still load. A linked open pull request already covers the shared runtime.

Written by the indexing model from the issue text.

Description

The shared runtime treats an existing global value as an already loaded remote container without checking its interface. With entryGlobalName: 'top' in a browser var remote, loadRemote() returns RUNTIME-002 without fetching the entry. Node's standard loader does the same for process, globalThis, and Buffer, including module entries. Existing falsy/accessor/readonly properties also need careful handling before registration.

Reproduction and raw results: https://github.com/tonoizer/module-federation-global-name-repro

The demo contains a TanStack Start SSR host/remote pair, native and enhanced Rspack compiler fixtures, and a Rsbuild React microfrontend. Safe-name controls load and their counters respond to clicks. Published runtime 2.9.2 reproduces the collision; Rspack 2.2.9's native MF 1.5 and enhanced 2.9.2 reproduce it too. Browser ESM and changing only the host instance name are distinct cases that work in these tests.

Expected behavior: distinguish actual preloaded containers from foreign globals, reject conflicting global registration with an actionable message before loading/executing an entry, preserve foreign properties on cleanup/retry, and keep legitimate getter-export containers working.

There are complementary direct-script protections in the Vite and native Rspack generators: a caller bypassing the Core loader should not assign a container over an existing application/browser global. Those changes belong in their respective repositories and can ship independently. The Core issue concerns the shared runtime lookup and cleanup boundary.

Coordinated PRs:

Core changes apply across consumers of the shared runtime. The Vite and Rspack output guards are separate, independently mergeable protections for direct script registration. They do not depend on one another.

Dominant language
JavaScript
Stars
2.7k
Forks
441
Avg merge
2d 23h
Merged PRs (30d)
18

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from module-federation/core

All issues in module-federation/core

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.