Bug: Incorrect Webpack Public Path (__webpack_require__.p) When Navigating Between Script-Loaded MFEs

[shubham-raut-zeuslearning]

With what library do you have an issue?

module-federation

Reproduction of the bug/regression with instructions

When using a script-based Module Federation architecture, navigating between MFEs can cause Webpack's public path (__webpack_require__.p) to point to the wrong MFE. As a result, chunks are loaded from an incorrect base URL, leading to chunk load failures and 404 errors.
When an MFE contains lazy loaded modules the chunk of module is fetch from wrong base path of the MFE whose remoteEntry.js file was loaded last.

• Navigate to MFE-1.
• Load remoteEntry.js for MFE-1.
• __webpack_require__.p is set to MFE-1's base route.
• Navigate to MFE-2.
• Load remoteEntry.js for MFE-2.
• __webpack_require__.p is updated to MFE-2's base route.
• Navigate back to MFE-1.
• Since MFE-1's remoteEntry.js script already exists in the DOM, it is not re-executed.
• MFE-1 attempts to load additional chunks.

MFE-1 attempts to download its chunks using the public path currently stored in __webpack_require__.p, which still points to MFE-2's base route.

Example:

• Expected chunk URL:
  https://host/mfe1/chunk.js

• Actual chunk URL:
  https://host/mfe2/chunk.js

• Since the chunk does not exist under MFE-2's route, the request fails with a 404 or chunk loading error.

Expected behavior

When navigating back to an already loaded MFE, its chunks should be resolved using that MFE's own base route. The public path should be correctly set for the active MFE and should not be affected by previously loaded remotes.

Versions of Native/Module Federation, Angular, Node, Browser, and operating system

Module Federation: 19.0.3
Angular: 21.2.4
Node: 24.15.0
Browser: Chrome/Edge/Firefox
OS: Windows

Other information

One possible approach is to allow remoteEntry.js to be reloaded whenever navigation occurs to an MFE. This can be achieved by:

1. Removing the existing remoteEntry.js script element from the DOM when navigating away from an MFE.
2. Re-adding and reloading the remoteEntry.js script when navigating back to that MFE.

By re-executing remoteEntry.js, the MFE-specific initialization logic runs again, ensuring that __webpack_require__.p and other global variables are updated to the correct base route before any chunks are requested.

This would prevent stale public path values from previously loaded MFEs from affecting chunk resolution for the currently active MFE.

Here one extra LoadRemoteModuleOptions could be passed which states if we want to use cache containerMap[remoteName] or not. And then If we want to reload script we should remove and re-add the script back

Proposed Solution

Introduce an additional option in LoadRemoteModuleOptions to control whether the cached remote container should be reused or reloaded.

For example:

interface LoadRemoteModuleOptions {
  ...
  useCachedContainer?: boolean;
}

Current behavior always reuses the cached container from containerMap[remoteName] and avoids reloading remoteEntry.js.

When useCachedContainer is set to false:

1. Remove the existing container reference from containerMap[remoteName].
2. Remove the corresponding remoteEntry.js script element from the DOM.
3. Re-add the script element and reload remoteEntry.js.
4. Reinitialize the container and store it back in containerMap.

This ensures that the initialization logic within remoteEntry.js is executed again, allowing Webpack to update __webpack_require__.p to the correct base route for the active MFE.

Benefits

• Preserves existing behavior by default.
• Provides an opt-in mechanism for applications affected by stale __webpack_require__.* values.
• Allows MFEs to be fully reinitialized when required.
• Prevents chunk resolution issues caused by navigation between script-loaded MFEs.

I would be willing to submit a PR to fix this issue

• Yes
• No