You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The remotes look the same. Our problem is as follows: it seems that while React is shared OK (only loaded once per version/shareKey) MUI isn't. Instead, while the host loads its own MUI bundle, the remotes also load bundles of their own containing lots of MUI code. We've got a home-grown analysis tool that measures the impact of module federation code sharing, and here's the output:
This graph shows parsed size of JS bundles loaded by the frontend that contain MUI. The light blue shade is for the bytes loaded by our host, the others colours represent other remotes.
Looking into it using rsdoctor, we see that this bundle is loaded in the remote:
Even though this bundle is already loaded in the host:
To ensure this isn't caused by dependency issues (note how mui-system is not part of the host bundle but it is part of the remote bundle), we have tried to force RSBuild into splitting @mui/material itself out into a separate bundle in the host and the remotes. While that worked fine, and we now had bundles with only MUI and its dependencies in each microfrontend, those bundles were still all loaded by module federation, increasing the total cumulative weight of MUI in our frontend.
Do you have any pointers on what could have caused this, and how to further investigate? The versions of MUI and rsbuild and module federation are the same in remotes and host (we ensure version equality and never specify version ranges on shared libraries).
I tried setting up an example reproduction repo, where everything worked as expected: MUI was bundled separately, and only loaded once. So it must be in the complex interaction of libraries between host and remotes. We suspect it might have something to do with the transitive dependency graph of MUI.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi!
In our MF deployment (shell w/ ~30 remotes) we only share the libraries with the biggest bundle size impact. We use rsbuild for all frontends.
We use Material UI, which we would like to share. Here's our config for our host:
The remotes look the same. Our problem is as follows: it seems that while React is shared OK (only loaded once per version/shareKey) MUI isn't. Instead, while the host loads its own MUI bundle, the remotes also load bundles of their own containing lots of MUI code. We've got a home-grown analysis tool that measures the impact of module federation code sharing, and here's the output:
This graph shows parsed size of JS bundles loaded by the frontend that contain MUI. The light blue shade is for the bytes loaded by our host, the others colours represent other remotes.
Looking into it using rsdoctor, we see that this bundle is loaded in the remote:
Even though this bundle is already loaded in the host:
To ensure this isn't caused by dependency issues (note how mui-system is not part of the host bundle but it is part of the remote bundle), we have tried to force RSBuild into splitting @mui/material itself out into a separate bundle in the host and the remotes. While that worked fine, and we now had bundles with only MUI and its dependencies in each microfrontend, those bundles were still all loaded by module federation, increasing the total cumulative weight of MUI in our frontend.
Do you have any pointers on what could have caused this, and how to further investigate? The versions of MUI and rsbuild and module federation are the same in remotes and host (we ensure version equality and never specify version ranges on shared libraries).
I tried setting up an example reproduction repo, where everything worked as expected: MUI was bundled separately, and only loaded once. So it must be in the complex interaction of libraries between host and remotes. We suspect it might have something to do with the transitive dependency graph of MUI.
Beta Was this translation helpful? Give feedback.
All reactions