Open in StackBlitz

npm i https://pkg.pr.new/@module-federation/vite@861

commit: 503281b

I checked the #792 case as well.

I ran the existing #800 regression test for the react-redux path:

pnpm exec vitest run src/__tests__/index.test.ts -t "excludes shared react from dev optimizeDeps when react-redux is installed"

It passes with this change, so the #792 behavior is preserved.

Tested #861 against the repro — it's necessary but not sufficient

Thanks for the quick PR @dmchoi77. I tested it directly against the minimal repro (https://github.com/abhayzmp/mf-vite-repro) and unfortunately the duplicate-React error still reproduces. I believe the bug has two independent causes and #861 only addresses the first.

How I tested

I applied #861's exact source change to the installed plugin in node_modules:

// src/index.ts (built: lib/index.js)
- const shouldBypassOptimizeDep = isLitShare(key) || key === "react" && hasPackageDependency("react-redux", root);
+ const shouldBypassOptimizeDep = isLitShare(key) || key === "react" && shareItem.shareConfig?.singleton === true;

Important detail: the host and remote resolve to two separate installed copies of the plugin, because they're on different Vite majors:

• host → @module-federation/[email protected] resolved against [email protected]
• remote → @module-federation/[email protected] resolved against [email protected]

I patched both copies (verified the shouldBypassOptimizeDep line in each now uses the singleton gate), then restarted with forced re-optimization:

pnpm dev --force   # vite --force on both apps → "Forced re-optimization of dependencies"

Result

The remote still fails with the same error:

TypeError: Cannot read properties of null (reading 'useSyncExternalStore')
Invalid hook call. ... You might have more than one copy of React in the same app

The stack trace shows react + react-i18next resolving from the remote origin (http://localhost:5001) while react-dom resolves from the host (http://localhost:5173) — i.e. the remote is still ending up with its own React instance even though React is now correctly excluded from its dev pre-bundle.

Why I think there are two causes

Cause 1 — the react-redux gate (what #861 fixes). #800 only excluded React from dev optimizeDeps when react-redux was installed. #861 re-gates that on singleton, which is correct. ✅

Cause 2 — the 1.16.9 share-scope cache-key / singleton-aliasing rewrite (not addressed). After the 1.16.9 cluster, even with React correctly excluded from pre-bundling, the remote's loadShare no longer resolves onto the host's React singleton. The relevant PRs:

• fix: use share scope in loadShare cache key to prevent cross-scope collisions #822 — use share scope in loadShare cache key to prevent cross-scope collisions
• fix: reuse singleton share cache aliases #828 — reuse singleton share cache aliases (its own description: "Fixes remote shared modules with empty config loading local React instead of host singleton… Prevents duplicate React instances and invalid hook calls")
• fix: normalize trailing slash shares #837 — normalize trailing slash shares (react/, react-dom/)
• fix: prefer installed shared version over requiredVersion (#829) #830 — prefer installed shared version over requiredVersion
• fix: select import:false shared providers by strategy #841 / fix: manage default share key compatibility #843 (1.16.10) — select import:false shared providers by strategy / manage default share key compatibility (default:react ⇄ react aliasing)

This matches the bisection: 1.16.6 is the last working version precisely because it predates this rewrite. The dev optimizeDeps exclude (whether automatic or set manually) stopped being sufficient from 1.16.9 onward.

Bisection (no react-redux in the stack)

Suggestion

#861 looks correct and worth merging on its own (the react-redux gate shouldn't have been there). But a complete fix for #858 also needs the share-scope singleton-aliasing path restored so a remote's loadShare resolves onto the host's React singleton in dev — likely a regression introduced by #828 / #837 / #843.

Happy to re-test any follow-up patch against the same repro.

Now that the repo is public and accessible, please feel free to play around, clone and test your changes on it. thanks

I checked this further, and I agree: #861 is necessary but not sufficient, so I’ll keep this PR scoped as “Partially addresses #858”.

I’ve prepared a follow-up patch for the second path you identified. It adds canonical shared cache keys with default-scope compatibility aliases (default:react ⇄ react) and applies the shared cache read/write helpers across loadShare, remoteEntry provider bridging, singleton aliasing, host auto-init preload, and react/compiler-runtime.

I’ll open it as a separate PR instead of expanding #861, so this one can stay focused on the optimizeDeps gating fix. Once it’s up, could you re-test it against the same repro?

Thanks @abhayzmp for your check.