Clear and concise description of the problem
I intend to submit a PR for this issue.
React Router 8 changes the package layout in a way that @module-federation/bridge-react cannot support with a peer-range update alone. [email protected] is published, but react-router-dom@latest is still 7.18.0 and there is no react-router-dom@8 package. React Router 8 exposes the DOM APIs from react-router / react-router/dom instead.
Today the bridge still has runtime entry points that require react-router-dom:
@module-federation/bridge-react exports createRemoteAppComponent from src/remote/router-component, whose withRouterData imports react-router-dom.
@module-federation/bridge-react/router imports and re-exports from react-router-dom/.
@module-federation/modern-js-v3/react re-exports @module-federation/bridge-react, so Modern.js v3 consumers inherit the same default import behavior.
@module-federation/bridge-react-webpack-plugin aliases v5/v6 through react-router-dom and v7 through react-router, but it has no explicit v8 alias target.
Because of that, a React Router 8 app that only installs react-router still fails if it imports the default bridge entry or uses the router proxy path. This also means widening react-router peers to include ^8 would advertise a combination that still resolves a removed package.
This is related to #4191, but the problem is slightly different. #4191 covered router optionality and the router-free base path. React Router 8 still needs router-aware bridge support; it just needs to be implemented against the new React Router package layout rather than importing react-router-dom.
Suggested solution
Add first-class React Router 8 support while keeping the existing v5/v6/v7 paths intact:
- Add a
@module-federation/bridge-react/router-v8 entry that uses React Router 8's public package layout (react-router / react-router/dom) instead of react-router-dom.
- Update the bridge default remote component path so a plain
@module-federation/bridge-react import no longer statically imports react-router-dom. Router-specific behavior can remain available through explicit router-aware entries and aliases.
- Update
@module-federation/bridge-react-webpack-plugin router alias detection so React Router 8 resolves to the v8 bridge router entry and still maps the public react-router / react-router/dom requests back to the installed package.
- Widen
react-router peer ranges to include ^8 where bridge support is provided, while keeping react-router-dom capped at ^7 because React Router 8 does not publish that package.
- Add tests proving the default bridge entry can be used without
react-router-dom, the v8 router proxy exports work through react-router, and the webpack alias helper returns the v8 aliases.
- Add changesets for the publishable packages touched by the behavior change.
Alternative
A smaller alternative would be to only widen the peer ranges or route React Router 8 through the existing v7 bridge implementation. That seems risky because the current default bridge entry still imports react-router-dom, and the v7 build currently rewrites to private react-router/dist/... paths during build output. React Router 8 exposes a new public package layout, so a dedicated v8 path is clearer and gives the package manager and bundlers a supported target.
Another alternative is to ask users to import @module-federation/bridge-react/base whenever they do not need router integration. That remains useful, but it does not solve router-aware React Router 8 apps and still leaves the default bridge import path incompatible with an RR8-only install.
Additional context
Current npm metadata checked before filing:
[email protected] has engines.node: >=22.22.0 and peers react >=19.2.7, react-dom >=19.2.7.
[email protected] exports . and ./dom.
react-router-dom@latest is 7.18.0; react-router-dom@8 is not published.
@module-federation/[email protected] peers react-router: ^6 || ^7 and react-router-dom: ^4 || ^5 || ^6 || ^7.
@module-federation/[email protected] peers react-router: ^7 and react-router-dom: ^4 || ^5 || ^6 || ^7.
I searched open issues and PRs for React Router 8 / react-router@8 / react-router-dom@8 before opening this. I found #4191 as the closest prior discussion and no open duplicate for this package-layout compatibility work.
Validations
Clear and concise description of the problem
I intend to submit a PR for this issue.
React Router 8 changes the package layout in a way that
@module-federation/bridge-reactcannot support with a peer-range update alone.[email protected]is published, butreact-router-dom@latestis still7.18.0and there is noreact-router-dom@8package. React Router 8 exposes the DOM APIs fromreact-router/react-router/dominstead.Today the bridge still has runtime entry points that require
react-router-dom:@module-federation/bridge-reactexportscreateRemoteAppComponentfromsrc/remote/router-component, whosewithRouterDataimportsreact-router-dom.@module-federation/bridge-react/routerimports and re-exports fromreact-router-dom/.@module-federation/modern-js-v3/reactre-exports@module-federation/bridge-react, so Modern.js v3 consumers inherit the same default import behavior.@module-federation/bridge-react-webpack-pluginaliases v5/v6 throughreact-router-domand v7 throughreact-router, but it has no explicit v8 alias target.Because of that, a React Router 8 app that only installs
react-routerstill fails if it imports the default bridge entry or uses the router proxy path. This also means wideningreact-routerpeers to include^8would advertise a combination that still resolves a removed package.This is related to #4191, but the problem is slightly different. #4191 covered router optionality and the router-free
basepath. React Router 8 still needs router-aware bridge support; it just needs to be implemented against the new React Router package layout rather than importingreact-router-dom.Suggested solution
Add first-class React Router 8 support while keeping the existing v5/v6/v7 paths intact:
@module-federation/bridge-react/router-v8entry that uses React Router 8's public package layout (react-router/react-router/dom) instead ofreact-router-dom.@module-federation/bridge-reactimport no longer statically importsreact-router-dom. Router-specific behavior can remain available through explicit router-aware entries and aliases.@module-federation/bridge-react-webpack-pluginrouter alias detection so React Router 8 resolves to the v8 bridge router entry and still maps the publicreact-router/react-router/domrequests back to the installed package.react-routerpeer ranges to include^8where bridge support is provided, while keepingreact-router-domcapped at^7because React Router 8 does not publish that package.react-router-dom, the v8 router proxy exports work throughreact-router, and the webpack alias helper returns the v8 aliases.Alternative
A smaller alternative would be to only widen the peer ranges or route React Router 8 through the existing v7 bridge implementation. That seems risky because the current default bridge entry still imports
react-router-dom, and the v7 build currently rewrites to privatereact-router/dist/...paths during build output. React Router 8 exposes a new public package layout, so a dedicated v8 path is clearer and gives the package manager and bundlers a supported target.Another alternative is to ask users to import
@module-federation/bridge-react/basewhenever they do not need router integration. That remains useful, but it does not solve router-aware React Router 8 apps and still leaves the default bridge import path incompatible with an RR8-only install.Additional context
Current npm metadata checked before filing:
[email protected]hasengines.node: >=22.22.0and peersreact >=19.2.7,react-dom >=19.2.7.[email protected]exports.and./dom.react-router-dom@latestis7.18.0;react-router-dom@8is not published.@module-federation/[email protected]peersreact-router: ^6 || ^7andreact-router-dom: ^4 || ^5 || ^6 || ^7.@module-federation/[email protected]peersreact-router: ^7andreact-router-dom: ^4 || ^5 || ^6 || ^7.I searched open issues and PRs for React Router 8 /
react-router@8/react-router-dom@8before opening this. I found #4191 as the closest prior discussion and no open duplicate for this package-layout compatibility work.Validations