MAIN ISSUE: MFEs uses latest and not required package versions

[idonava]

After changing the external-package-version-display to use the mui package for the first time in version 2.1.0, the mfe-remote-1-child-1 MFE starts loading the incorrect version of "@mui/material": "5.16.6" instead of the required version "@mui/material": "5.15.2".

• external-package-version-display is the only package/MFE that require "@mui/material" in version "5.16.6".

MFE: mfe-remote-1-child-1
packages:

1. "external-package-version-display": "1.1.0"  (not use "@mui/material" at all) 
   

2. "@mui/material": "5.15.2"
   

MFE: z-mfe-remote-3
packages:

1. "external-package-version-display": "2.1.0" (use "@mui/material": "5.16.6") 
   

2. "@mui/material": "5.16.4"
   

[2heal1]

So your expect is when visit http://localhost:3000/mfe-remote-1/mfe-remote-1-child-1/ , it will load @mui/[email protected]

And when visit http://localhost:3000/z-mfe-remote-3/ , it will load @mui/[email protected]

Am i understand correctly ?

[2heal1]

It seems to run well if it follows my understanding, so I doubt i misunderstood...

[idonava]

I expect mfe-remote-1-child-1 to use exactly the version I asked for, and not a version of external package from another MFE.

MFE	package	required version	actual used version	notes
mfe-remote-1-child-1	@mui/material	5.15.2	5.16.4	version set to 5.15.2, but the MFE took version that is used only in external-package-version-display (5.16.4) from z-mfe-remote-3

In our product, we use a different internal external library, I tried to reproduce the issue with a new library I created - external-package-version-display

The problem with our product:

1. Team X set MFE-X to take a specific version of a library (@mui/material for example) and everything works as it should.
2. Team Y upgrades in MFE-Y external library that is used in @mui/material in a higher version.
3. MFE-X starts to load the mui/material version of MFE-Y's external library - If there are breaking changes or API changes - MFE-X crashes.

I hope it's clear.

[2heal1]

Got it , that's quite clear , I will locate the issue

[2heal1]

But i find the demo's behavior is satisfy your required .

mfe-remote-1-child-1 use @mui/[email protected] and z-mfe-remote-3 use @mui/[email protected]

[2heal1]

I add export const version = 5.15.2 in mfe-remote-1-child/node_modules/@mui/material , and add export const version = 5.16.4 in z-mfe-remote-3/node_modules/@mui/material

mfe-remote-1-child/node_modules/@mui/material/index.js

z-mfe-remote-3/node_modules/@mui/material/index.js

mfe-remote-1-child runtime

z-mfe-remote-3 runtime

then console the version in runtime , and it log as expected

[idonava]

That's a really nice way to check it! I tried it, too, and it seems that the correct versions are coming.
I will try to reproduce the issue in our product and check why some MFEs crash when updating other MFEs . I may not have reproduced it well here.

About the FEDERATION data:

1. Why does the MF object show that mfe-remote-1-child-1 uses 5.16.6 version?
2. Why 5.16.6 version even shared between the MFEs? non of the MFEs request this version, only an external package that is used by another MFE.
   

[2heal1]

hmm that's a problem ,it looks like the data visible has some error, I will check it on Monday.

And you can check whether the real shared has worked as expected.

[idonava]

Hi @2heal1,
I have successfully reproduced the issue. To do this, I created a new external package called external-package-version-display-2. This package exports a string of its version and a component that renders its version.

Additionally, I have created a new version 2.1.4 for the external-package-version-display package. Now, this package uses external-package-version-display-2 and also renders the version of the new package with a yellow background color for easy identification.

I have set the apps/mfe-remote-1/remotes/mfe-remote-1-child-1/package.json file to use the new version of external-package-version-display and the version of external-package-version-display-2 that external-package-version-display uses.

    "external-package-version-display": "2.1.4",
    "external-package-version-display-2": "1.0.1"

And for the apps/z-mfe-remote-3/package.json file, I have set it to:

    "external-package-version-display": "2.1.4",
    "external-package-version-display-2": "1.0.0"

Please note that in this version, external-package-version-display-2 is not the version used by external-package-version-display.

The results are:
mfe-remote-1-child-1 loads the correct versions of external-package-version-display: 2.1.4 & external-package-version-display-2: 1.0.1 BUT external-package-version-display use external-package-version-display-2 version: 1.0.0 and not the required version by the package and the MFE 1.0.1

z-mfe-remote-3 loads the correct versions of external-package-version-display: 2.1.4 & external-package-version-display-2: 1.0.0
in this case I can understand why external-package-version-display-2 uses 1.0.0 (and not 1.0.1), and this is because he's using the external-package-version-display-2 of the MFE.

How to fix it?
Just set z-mfe-remote-3 to use external-package-version-display-2 version 1.0.1.

In our project, we have dozens of MFEs, and both packages are used in our MFEs in different versions.

Is this a module federation bug? We're doing something wrong?

[2heal1]

Let me check this

[2heal1]

This is is module federation bug with shared initializeSharing , I will fix it this week

[idonava]

Let me know if you need any help, I'm available anytime.

[haimrait]

Hey @2heal1 do you have any update regarding this issue

[2heal1]

Yes, i'm fixing it , because it needs to modify both rspack and mf code , so it still needs some time

[2heal1]

I check again . The issue can be fixed by rspack update sub dep shareConfig .

@ahabhgk if users not specify set requiredVersion , the scopeToSharingDataMapping shareConfig's requiredVersion should be ^${pkg.version}

The reproduce repo: https://github.com/2heal1/modernjs-demo/tree/chore/unexpected-required-version

[2heal1]

hi @haimrait @idonava , i locate the issue reason :
Because host set z_mfe_remote_3 and mfe_remote_1 as remotes . So it will register both theirs shared .

And then , since mfe_remote_1 set mfe_remote_1_child_1 as remote , it will register its shared as well .
But according to the registration order , z_mfe_remote_3 register before mfe_remote_1_child_1 .

So mfe_remote_1_child_1 will use z_mfe_remote_3 shard if met re-use conditions . In this case , mfe_remote_1_child_1 will use z_mfe_remote_3's [email protected].

And because you set shared as follows

shared: {
    ...pkg.dependencies,
}

it equals

    "external-package-version-display-2": {
      singleton: false,
      requiredVersion: '1.0.0',
      strictVersion:true
    },
    "external-package-version-display": {
      singleton: false,
      requiredVersion: '2.1.4',
      strictVersion:true
    },

So it will make external-package-version-display load [email protected] .
And the solutions is you can remove requiredVersion , it will auto use ^${pkg.version}

The related change you can view this for details https://github.com/2heal1/base-mf-app/tree/fix/main-issue

And I will release new version next week for above change

[idonava]

@2heal1, that's great! I really appreciate your efforts to help us & make module federation a much better product.
The upcoming changes, will they be released in rspack version >1 or will they also be included in version 0.7.x?

[2heal1]

it needs [email protected] and @module-federation/[email protected]

Above deps have been released now , but since you are using rsbuild , you can wait 2 days for release new version or override the deps

[2heal1]

hey the rsbuild has released version 1.0.1-rc.2 , you can upgrade to validate the issues whether to be fixed .

And this is related demo: https://github.com/2heal1/base-mf-app/tree/fix/main-issue

[idonava]

Thanks @2heal1,
I have run the updated branch (fix/main-issue).

1. mfe-remote-1-child-1
   a. Loading correctly external-package-version-display-2 Version 1.0.1.
   b. Loading correctly external-package-version-display Version 2.1.4 BUT with external-package-version-display-2 Version 1.0.0 and not 1.0.1 as requested in package.json (this is the z-mfe-remote-3 configuration)
   

2. It looks like a version mistake in the __FEDERATION__ object, the mfe-remote-1-child-1 looks correct, but the external-package-version-display version from some reason is 1.0.1 instead of 2.1.4
   

Share Scope Using

I also tried to add a unique shareScope inside mfe-remote-1-child-1:

But the results are:

I think it's because the MFE trying to find the "shortest' way to get the external-package-version-display inside the node_modules folders, and the closet node_modules with external-package-version-display is inside mfe-remote-1 that uses 1.0.1 version.

When I manually copy external-package-version-display version 2.1.4 inside mfe-remote-1-child-1 node_modules, everything is working as expected.

[2heal1]

It's a demand that host can control the deep shared dep's shareConfig, which like conditional override .

It can not support the demand now , but i can support it in the future after discuss with my team.

[2heal1]

But i have a question , does MF 1.0 support it ? I'm really curious about it ...

[idonava]

It probably worked the same on MF 1.0.
At the beginning of our project, we built and deployed all our MFEs together and didn't notice any issues. However, I think things have started to break since we began "versioning" our MFEs and using the runtime plugin.

[2heal1]

I just discuss with my teammate , the override share is a bit complex to maintain , one solution for you is you can use external promise to control the dpes which need strict version https://webpack.js.org/configuration/externals/#externalstypepromise

[2heal1]

you can try the workaround above , i will ask teammate to see if we can support it