Describe the bug

Hello :)

Module federation tracks shared dependencies with the global object window.__FEDERATION__.__SHARE__. There can be issues with the useIn property, which tracks which application uses which library version.

For what I have seen it happens when:

• shareStrategy: 'version-first'
• The shell and remote use different (but compatible) versions of a shared library (e.g., shell: ^4.16.0, and remote: ^4.17.21)
• The shell uses a lower version than the remote (4.16.0 < 4.17.21)

At runtime:

Both shell and remote actually use 4.17.21, but the useIn array is not correct:

• The shell is not listed in the correct useIn array.

Note: shell and remote are using the same version at runtime 4.17.21

Expected vs actual behavior

Expected: Both shell and shop should appear in the useIn array for the version actually loaded (4.17.21).
Actual: Only shop appears in the useIn array for 4.17.21. shell appears in the useIn array for a version that is not loaded.

When it works

The configuration works when:

• shareStrategy: 'loaded-first'
  or
• or the shell version is higher than the remote version

Reproduction steps

• Clone my repository: git clone git@github.com:romain-trotard/core.git
• Go in the cloned repository: cd core
• Checkout the branch reproduction-useIn: git checkout reproduction-useIn
• Install dependencies: pnpm i
• Build everything: pnpm build
• In 2 different terminal:
  • Go to 3000-home, build and run: cd apps/3000-home && pnpm build && pnpm start
  • Go to 3001-shop, build and run: cd apps/3001-shop && pnpm build && pnpm start
• Go to: http://localhost:3000/shop
• In the devtool log: window.__FEDERATION__.__SHARE__['home_app:1.0.0'].default.lodash
• You can see that the version 4.16.0 is not loaded but shell is in useIn. And in the useIn of 4.17.21 there is only shop.

Tip: You can use the UI buttons to log the lodash version in each app.

Potential fix

I have identified the problematic area and tried a potential fix, but I’m not fully confident in this approach because it introduces complexity by managing three objects:

• shareInfoRes
• registeredShared
• gShared

I believe this alternative could be cleaner by handling just one variable.
After testing several combinations, the fix appears to work.

I’d love to propose a PR, but would appreciate your guidance on the best fix to pursue!

Thanks for the library

Reproduction

https://github.com/romain-trotard/core/tree/reproduction-useIn

Used Package Manager

pnpm

System Info

System:
    OS: macOS 15.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 2.89 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.14.0 - ~/.volta/tools/image/node/22.14.0/bin/node
    Yarn: 1.22.22 - ~/.volta/tools/image/yarn/1.22.22/bin/yarn
    npm: 10.9.2 - ~/.volta/tools/image/node/22.14.0/bin/npm
    pnpm: 10.12.4 - ~/.volta/bin/pnpm
  Browsers:
    Chrome: 137.0.7151.120
    Safari: 18.5

Validations

• Read the docs.
• Read the common issues list.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Module federation issue and not a framework-specific issue.
• The provided reproduction is a minimal reproducible example of the bug.