the default import cannot be correctly resolve

[h11g]

Describe the bug

Several factors combined together led to this problem.

1. The app uses module federation
2. The app uses a third-party library, thirty-lib, which uses i18next
3. The mf config of the app sets thirty-lib and i18next to the shared scope
4. The third-party library uses a multi-entry packaging method

Details

From the code, it can be seen that i18next in the bundled is a named import, but it is actually a default import, which leads to the inability to find the i18next.on method.

When I try to remove multiple entries or take i18next out of the shared score, this project works fine

Details

export default defineConfig((env) => {
  return {
      ...
      rollupOptions: {
        input: {
          index: './src/react.ts',
          // comment to make project work
          vanilla: './src/vanilla.ts',
        },
        external: ['i18next', 'react-i18next', 'react', 'react-dom'],
      },
    },
   ...
  }
})

or

new ModuleFederationPlugin({
  ...
      shared: {
        ...
        // comment to make project work
        i18next: {
          singleton: true,
          requiredVersion: dep.i18next,
        },
      },
    }),
})

I provided a demo on codesandbox, which makes it easier to debug the project when downloaded locally

Reproduction

https://codesandbox.io/p/devbox/mf-bundle-demo-635f7l

Used Package Manager

pnpm

System Info

System:
    OS: macOS 15.0
    CPU: (8) arm64 Apple M3
    Memory: 79.30 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.14.0 - ~/.nvm/versions/node/v20.14.0/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v20.14.0/bin/yarn
    npm: 10.8.1 - ~/.nvm/versions/node/v20.14.0/bin/npm
    pnpm: 9.11.0 - ~/.nvm/versions/node/v20.14.0/bin/pnpm
    bun: 1.1.12 - ~/.bun/bin/bun
  Browsers:
    Chrome: 129.0.6668.59
    Safari: 18.0

Validations

• Read the docs.
• Read the common issues list.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Module federation issue and not a framework-specific issue.
• The provided reproduction is a minimal reproducible example of the bug.

[loveholly]

Hi @ScriptedAlchemy, any comments here?

[ScriptedAlchemy]

Okay the problem is indeed the default import.
I would sugggest trying this with webpack and see if you get the same issue.
If not, please report it to the rspack repo - looks like a bug.
The bundler should wrap in default import factory handler, i think.

[ScriptedAlchemy]

if i go i18next.default.on, it works in the library

[loveholly]

Thanks for your kindly reply @ScriptedAlchemy. Actually this issue is not only occurred on rspack but also on webpack. The problem is indeed default import. We tested many situation, and finally found that this problem happened when the following three conditions all met:

• A function co-exists with default export and named export, like i18next do:
  • https://github.com/i18next/i18next/blob/f2a6b6c988a325f97766f74a6e9ea39fbc3b0ea8/src/index.js#L3
  • https://github.com/i18next/i18next/blob/f2a6b6c988a325f97766f74a6e9ea39fbc3b0ea8/src/index.js#L8
• Use multiple entry
• Use Module federation

When we use i18next in our codebase under the above conditions:

import i18next from 'i18next'

i18next.init()

Then the bundler will resolve it incorrectly, treating i18next not as a default import. Seems like because init function also is a named export from i18next.

Hope these information can help.

[ScriptedAlchemy]

Most likely this needs to be filed with the webpack core and rspack core projects. Does original federation in webpack also have the issue?

I'll take a look in my source but it seems like a deeper problem to how modules are wrapped. I can make it look for .default but that will have other problem or basically reverse the issue to only default

[h11g]

yeap, original federation in webpack also have the same issue. @ScriptedAlchemy

[ScriptedAlchemy]

I'd open an issue with webpack core. I'd also try it with rspack, which my team has direct control over. If it's a problem in rspack, I can get that patched if a GitHub issue is opened.

As a workaround you can use a runtime plugin on loadShare / the resolver for it and you could automatically return the default export or re merge and modify the exports as you wish.

[jmvtrinidad]

@ScriptedAlchemy The bug is also open on rspack
web-infra-dev/rspack#8043
looks like the team is already on it

[ScriptedAlchemy]

Perfect. Then we will need to wait for it to be fixed on the Rust end so that it aligns correctly with webpack.