Skip to content

Module Federation shared deep dependency resolved incorrectly #15971

Closed

Description

@tzachbon

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:
console

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:
runtime

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

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

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

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

Activity

  1. itainoam commented on Jun 29, 2022

    @itainoam

    Major issue for me as well.

  2. sokra commented on Jul 1, 2022

    @sokra
    Member

    This configuration:

    shared: {
      uuid: "^8.3.2",
      // or the equivalent:
      uuid: { requiredVersion: "^8.3.2" },
    }

    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).

    shared: ["uuid"],
    // or the equivalent:
    shared: {
      uuid: {},
    }

    Note you can also mix array and object:

    shared: [
      "lib",
      "uuid",
      {
        react: { singleton: true },
        'react-dom': { singleton: true },
      }
    ],

    or use that:

    shared: [
      lib: {},
      uuid: {},
      react: { singleton: true },
      'react-dom': { singleton: true },
    },
  3. nerisa commented on Nov 16, 2022

    @nerisa

    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

  4. vikdet commented on Jun 14, 2024

    @vikdet

    I have the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions