Repository navigation
Description
Bug report
What is the current behavior?
When using Module Federation, sharing a dependency and your other dependencies are using it too but in different versions, it won't respect semver matching and use the same version for everything.
For example, even when it is explicitly defined to be shared with ^8.3.2 in the top-level, it matches the 3.4.0 version that another deep dependency consumes.
3.4.0 does not satisfy constraint ^8.3.2
If the current behavior is a bug, please provide the steps to reproduce.
Repo that reproduces the issue - https://github.com/tzachbon/mf-shared-deep-dependency
This example tries to reproduce the problem when sharing a dependency that exists in multiple versions across the node modules but resolves the request incorrectly.
In this example repo, I use uuid package.
└─┬ @startup-code/[email protected] -> ./app1
├─┬ [email protected] -> ./lib
│ └── [email protected]
├── [email protected]
└─┬ [email protected]
└─┬ [email protected]
└── [email protected] deduped
This graph shows that the root uuid is 8.3.2 and the version under lib is 3.4.0.
lib uses the v3 method from uuid.
This method exists only in version 8.3.2.
By default, if we build this project, serve it and click on new uuid, everything crashes as expected:

But when we use Module Federation and share this package from app1 like this:
[
new ModuleFederationPlugin({
name: 'app1',
shared: {
lib: deps['lib'],
uuid: deps['uuid'], // <-- resolve to ^8.3.2
react: { singleton: true, requiredVersion: deps.react },
'react-dom': { singleton: true, requiredVersion: deps['react-dom'] },
},
})
]We can see that the runtime understands the difference between the packages:

But when we click on new uuid which crashed our app, it works (not the desired behavior)...

When we look inside the index file, we can see the moduleToHandlerMapping resolve it incorrectly:

And when we remove the uuid entry from the shared section in ModuleFederationPlugin we can see that the app behaves as expected:

For some reason, even when it is explicitly defined to be shared with ^8.3.2, it matches the 3.4.0 version that lib consumes.
What is the expected behavior?
I would expect that each dependency would get the correct package resolution according to the node resolution algorithm.
In our example -
- top level (App) - 8.3.2
- lib - 3.4.0
Other relevant information:
webpack version: 5.72.1
Node.js version: v16.15.0
NPM version: 8.5.5
Operating System: MacOS Monterey 12.4
Also asked in the Module Federation examples repo -
module-federation/module-federation-examples#2033
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Activity
itainoam commentedon Jun 29, 2022
Major issue for me as well.
sokra commentedon Jul 1, 2022
This configuration:
will force the version to be
^8.3.2.But it's not recommended to do that. You should prefer to let webpack automatically infer the requiredVersion from the nearest package.json (from import location).
Note you can also mix array and object:
or use that:
nerisa commentedon Nov 16, 2022
I have similar issue with my application. However if I follow @sokra 's suggestion to not provide the requiredVersion to the shared libs, I encounter the issue reported here:
#13457
vikdet commentedon Jun 14, 2024
I have the same issue.
feat(sharing): add include/exclude filters to shared modules
feat(sharing): add include/exclude filters to shared modules (#22297)