Material-ui/lab and material-ui/pickers overriding styles when being imported from remote federated modules

[jmelendez-cbs]

We are using webpack 5 and a design system that hosts federated modules from material ui. As of now we have the following setup for the ModuleFederationPlugin.

    new ModuleFederationPlugin({
      name: 'rosters-web-app',
      // TODO: Make optional depending if the DS is running locally
      remotes: {
        'dataeng-ds': federationUrl
      },
      shared: {
        ...pkgJson.dependencies,
        "@material-ui/core": {
          singleton: true,
        },
        react: { 
          singleton: true, 
          requiredVersion: pkgJson.dependencies.react 
        },
        "react-dom": { 
          singleton: true, 
          requiredVersion: pkgJson.dependencies["react-dom"] 
        }
      },
    })

This is how a page on the app displays:

However, when we use a component from material-ui/lab or material-ui/pickers it seems the styles get messed up.

Notice the buttons are now unstyled/overwritten

Does anyone have an idea on why this is happening?

Note: I have also tried adding

      "@material-ui/lab": {
          singleton: true,
        },

to the shared list and it still does not work.

[JohnDaly]

It could be because you're not specifying a version requirement for the @material-ui/core dependency, and you're getting a different copy which introduces the styling discrepancies.

When Webpack tries to determine which copy of that library to use, it will find the highest version available (unless told otherwise). If @material-ui/lab or @material-ui/pickers have the @material-ui/core package listed as a peerDependency, then you could be getting a version of the library that causes the problem you're seeing.

[yescine]

@jmelendez-cbs I am having the same issue, even when I specify the shared dependencies with their version!

[yescine]

@jmelendez-cbs I am having the same issue, even when I specify the shared dependencies with their version!

As mentioned in #548 sharing "@material-ui/" as singleton solve the issue, but how could we know which library has to be singleton !?

[jmelendez-cbs]

It could be because you're not specifying a version requirement for the @material-ui/core dependency, and you're getting a different copy which introduces the styling discrepancies.

When Webpack tries to determine which copy of that library to use, it will find the highest version available (unless told otherwise). If @material-ui/lab or @material-ui/pickers have the @material-ui/core package listed as a peerDependency, then you could be getting a version of the library that causes the problem you're seeing.

I went through and made sure the peerDependencies were shared that material/lab required but still no luck.

[jmelendez-cbs]

@jmelendez-cbs I am having the same issue, even when I specify the shared dependencies with their version!

As mentioned in #548 sharing "@material-ui/" as singleton solve the issue, but how could we know which library has to be singleton !?

Yeah, from what I understand, the libraries that use a context should be shared as singletons. I think the issue here could be the way that material-ui imports and exports some components for the lab. In particular the Button component. I traced my issue back to the Button.

An extra styled sheet for ButtonBase was being added to the of my index.html doc which was over-writing the styles.

I have not solved this issue yet.

[yescine]

@jmelendez-cbs have same issue with Floating Action Button from Mui-v4.10.0 that use the same ButtonBase component, more deep dive on how Module Federation deal with large Css Framework like Mui is needed !( it's beyond my scope :( )

[ScriptedAlchemy]

How to know if a lib needs to be a singleton. Mainly you have to see what happens. In general anything that uses react context needs to be a singleton. Things like redux

[slavab89]

As more and more libraries rely on react context, it will cause the list of singletons to be quite long. Is there some kind of plan to deal with it more elegantly?

[ScriptedAlchemy]

Not the concern of Webpack. We compile code that's it.

Ways to work around the problem tho, ship library as remote themselves. So it's centrally owned.

I could write a plugin that finds any use of react context in its parser and set those as singleton. However that's beyond the scope of my time and capacity. But it's possible to traverse the module graph automatically

[slavab89]

Although this has been marked as closed, i would like to continue and try to understand the issue.
Is this material-ui specific thing?? We don't notice this with other libraries that we're using.

The effects of this issue are understood. It seems to download and load the same component twice (For example, Button or Typography) and if this happens at various times of the page, it will cause the component to create styles once more and add them to .
The big question is why it does that.

To my understanding, the solution of using material-ui/core/ (With a Trailing Slash) will make everything under this as a shared component individually, which in turn creates a whole bunch of files (As they are all shared individually).
Although this should not make an issue since the browser can cache them, and initially if it uses http2 it will download a bunch of them together, it still creates a bunch more files.
BUT, this does solve the issue since webpack notices the file paths are exactly the same..?

Can it be that, due to different tree-share combinations of those components, it bundles Button in different files between the remotes and therefore forces the loading of that component once more?

[ScriptedAlchemy]

Although this has been marked as closed, i would like to continue and try to understand the issue.

Is this material-ui specific thing?? We don't notice this with other libraries that we're using.

The effects of this issue are understood. It seems to download and load the same component twice (For example, Button or Typography) and if this happens at various times of the page, it will cause the component to create styles once more and add them to .

The big question is why it does that.

To my understanding, the solution of using material-ui/core/ (With a Trailing Slash) will make everything under this as a shared component individually, which in turn creates a whole bunch of files (As they are all shared individually).

Although this should not make an issue since the browser can cache them, and initially if it uses http2 it will download a bunch of them together, it still creates a bunch more files.

BUT, this does solve the issue since webpack notices the file paths are exactly the same..?

Can it be that, due to different tree-share combinations of those components, it bundles Button in different files between the remotes and therefore forces the loading of that component once more?

Happy to continue this. From a comprehensive standpoint.

Here's how I understand the issue. That package is like a highly interconnected monorepo of other packages. So /lab and /core most likely import something like /context-bus or /themes as well.

And it's those that need to be singletons - it's not a normal package where everything is just in one package. You're installing many material sub dependencies when using one of the higher level ones.

So the problem ends up as, there's still something both those packages rely on, another node module from materials repository organization.

While you're federating the high level, one, there are likely internals that also need to be shared, but are not necessarily immediately obvious because they're mostly used internally. By higher level packages you import from. Hence why my usual suggestion is if you don't know what all is actually shared. Or used. Sharing "@mui/" is going to share any requires that starts with mui, regardless of where or how deep the import is.

Then you could console log webpack share scopes. And see all the packages actually being used by the apps - manually add them one by one till you find which one actually needs to be shared as a singleton. But doing the trailing slash is a great way to flush out all the things actually imported. And can choose.

Like sentry, similar deal. I can "@sentry/" and see that share scope contains /hub /tracing /browser /client /core.

This is a similar issue some big npm packages have. So In a really tough case I can just use the trailing slash and that'll probably work but can make builds a little larger. So using it just to flush out what are all the actual dependencies that are used and console log, then process of elimination

I know it's not great, and I will try to implement a "hinting" capability into Medusa so it can show you this stuff in like a GUI app. So I know it's not super straightforward to just find something - but you can get the info. I'm hoping to improve the tools to help give you insights about it

[ScriptedAlchemy]

const federationConfig = {
  name: "stores_mfe",
  remotes: {
    coco: 'coco'
  },
  shared: {
    "@mui/": {}
  }
};

// in app code
console.log(__webpack_share_scopes__.default)