With version-first share strategy, multiple instances of singleton shared dependencies are fetched and ran in runtime - "Cannot read properties of null (reading 'useEffect')"

[danhorvath]

Describe the bug

Describe the bug

When a host app imports multiple remotes with the exact same version of the shared singleton dependency (in our case react and react-dom) with version-first share strategy, there can occasionally be a runtime error.

After some investigation, we think the issue is that occasionally the singleton dependency gets downloaded for both the host and one of the remotes. When we add logs to the module federation runtime, it appears that first the host's instance of the singleton dependency gets registered in the shareVersionMap, but then it gets overwritten by a remote's instance of it.

In case of runtime error

The console.log below is placed in a function called findVersion in the module-federation runtime. The log also shows the react runtime error that occurs.

The react dependency also gets downloaded twice.

In case of successful startup

The react dependency is only downloaded once (even though the react runtime is fetched twice)

We only experience this issue with the following conditions:

• We use the version-first share strategy
• There are multiple remotes
• At least 1 remote has the exact same version on the shared singleton dependency as the host and that's the highest version of this dependency amongst all the remotes
• The micro-frontends are imported eagerly (with import "..." instead of import())

Reproduction steps:

run pnpm i
run pnpm --filter ./packages/host run dev
run pnpm --filter ./packages/remote run dev
run pnpm --filter ./packages/remote_2 run dev

The reproduction uses the latest versions from @rsbuild/core, @rsbuild/plugin-react and @module-federation/rsbuild-plugin.

This issue is similar to #3170, but that one used loaded-first share strategy.

Reproduction

https://github.com/danhorvath/rsbuild-demo/tree/version-first

Used Package Manager

pnpm

System Info

System:
    OS: macOS 15.1
    CPU: (12) arm64 Apple M3 Pro
    Memory: 1.31 GB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.17.0 - ~/.nvm/versions/node/v20.17.0/bin/node
    npm: 10.8.2 - ~/.nvm/versions/node/v20.17.0/bin/npm
    pnpm: 9.12.3 - ~/.nvm/versions/node/v20.17.0/bin/pnpm
  Browsers:
    Chrome: 130.0.6723.117
    Edge: 130.0.2849.80
    Safari: 18.1

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.

[2heal1]

let me check this

[2heal1]

it will be fixed on this pr

[ScriptedAlchemy]

@danhorvath would you mind sanity checking our release <3 if resolved we can close this

[danhorvath]

It seems the new release fixes the issue in our repro. We couldn't verify it on our project yet, but will close this ticket as soon as we checked it there too.

Thank you for the quick help again.

[danhorvath]

The issue seems to be fixed now also on our platform. Thanks both for the help! 🙏