CompatRouter has occured error with module federation

[ohpyeong]

Hi, I'm trying to migrate to v6 from v5, but would be maintain some v5 funtionalities. and my project using module federation with carco plugin as host, then I saw your migration guide so I installed react-route-dom-v5-compat and add <CompatRouter> in my code but its not working.
please look around my code and error console below and help

// app.tsx for migrate
<React.Suspense fallback="Loading"> // for module federation
      <BrowserRouter basename={`/`}>
        <CompatRouter> // only this code added according to migration guide
          <LocalizationProvider dateAdapter={DateAdapter}>
            <ErrorBoundary> 
              <Switch>
                <Route
                  exact
                  path={`${process.env.PUBLIC_URL}/login`}
                  component={Login}
                />
              </Switch>
            </ErrorBoundary>
          </LocalizationProvider>
        </CompatRouter>
      </BrowserRouter>
</React.Suspense>

library version below:

// package.json
"react-router-dom": "^5.1.1",
"react-router-dom-v5-compat": "^6.3.0",

module federation config below:

const CracoModuleFederation = require('craco-module-federation');

module.exports = {
  plugins: [
    {
      plugin: CracoModuleFederation,
    },
  ],
  devServer: {
    port: 3000,
  },
};

[tonywang402]

I guess your webpack config cause this issue.
Because accesses the history from v5, sets up a listener, and then renders a "controlled" v6 .
Which needs import something from react-router v6 inside react-router-dom-v5-compat, not react-router v5 in your direct node module

[cjones26]

We were struggling to get the compat package working with MFE, but ended up getting it working by making the following changes to our MFE configuration:

'react-router-dom': {
  singleton: true,
},
'react-router': {
  singleton: true,
},
history: {
  singleton: true,
},
// Without the below changes, MFE would always want to use react-router v6.8.0 by default
'react-router@6.8.0': {
  import: 'react-router',
  shareKey: 'react-router@6.8.0',
  shareScope: 'default',
  singleton: true,
  strictVersion: true,
  version: '6.8.0',
  requiredVersion: '6.8.0',
},
// Same as above, without this in our config, MFE would always want to use history v5.3.0
'history@5.3.0': {
  import: 'history',
  shareKey: 'history@5.3.0',
  shareScope: 'default',
  singleton: true,
  strictVersion: true,
  version: '5.3.0',
  requiredVersion: '5.3.0',
},

After making these changes, everything seemed to be working properly.

[lexa12323]

after this changes errors with history and locations were fixed.
But I have a new one: MFE (this MFE uses react-router as dependency) that consumed react-router: {state: 'CONSUMED', version: '5.2.0'} throw new error:

[alioshr]

@cjones26 Did you finish your react-router migration?

I did not find good examples of the usage of aliases with Shared Api, but it seems that what you did was basically isolate the v6 into a separate alias?

How did you manage to replace the compat package by React router v6 in a non breaking manner? I mean, after getting all routes, router, etc using v6 apis, they are still consuming v5, so you would need to change the shared api deps to share react-router v6.

[cjones26]

We did finish our migration. After all of our APIs were migrated to v6, we search and replaced all import instances from react-router-dom-v5-compat to react-router-dom, then removed the compat package and upgraded everything to the latest versions. Next, we removed the non-essential keys in our MFE configuration and ended up with what we previously had, before starting the migration:

'react-router-dom': {
  singleton: true,
},
'react-router': {
  singleton: true,
},
history: {
  singleton: true,
},
'react-router': {
  singleton: true
},
'history':
  singleton: true,
},

Hopefully that answers your question?

[alioshr]

Thanks for replying back @cjones26 !

I see, but at this point you had to move everything together I guess. We have an orchestrator base MF instance that renders our remotes. I guess that the moment you make these changes on your provider MF instance you needed to do it in sync at the same time with your remotes, am I right and it led to some downtime?

Another question is how did you treat these shared dependencies on the remote apps, did you keep these same shared v6 keys for all the remotes as well?

[cjones26]

No worries! And yeah, it really sucked as we had to basically migrate the entire app over at once, resulting in MRs/PRs with thousands of changes and broke a lot of our tests. We didn't have any downtime, but had the tradeoff of integrating a massive amount of changes at once. Luckily we were able to test in our lower environments before production release, and validate everything was working properly.

Migrating our top level shell/provider MF instance also broke a lot of things in the remotes, which required further changes in order to have nested routes working properly.

As for your last question, yes--all of our remotes, as well as our shell had identical shared deps as listed in my first post above.

We're now looking at migrating to the data router, as the way our routes were designed required us to use a tremendous amount of hacks to get the v6 APIs functioning properly without refactoring the entire routing structure--for instance, we needed to useMatch certain places in conjunction with conditional statements in order to replace v5 nested Route components.

Another thing we discovered with the migration relates to deep link functionality in the app, which basically required us to redirect certain paths to a deep link handler component (think a top level https://website.com/help, which navigates to https://website.com/:userId/:accountId/help), and use a custom useCurrentPath hook (as shown below), then switch on the current path to determine what component to render.

import { matchRoutes, useLocation } from 'react-router-dom';

export const useCurrentPath = (matchPaths: []) => {
  const location = useLocation();
  const agnosticMatchPaths = matchPaths.map((path) => ({ path }));
  const matchedRoutes = matchRoutes(agnosticMatchPaths, location);

  return matchedRoutes ? matchedRoutes[0]?.route.path.replace('/*', '') : null;
}

Overall it was a brutal migration and we're still not really done as we need to basically refactor the entire app to work with the new data router.