Same module imported via import and import -> require points to different code

[oleg-slapdash]

Bug report

What is the current behavior?

When the same library from the same location is imported via commonjs require and es6 import results in two different instances for classes and duplicate code in the bundle.

If the current behavior is a bug, please provide the steps to reproduce.

If an app imports a class directly and then uses a commonjs-based 3rd party library that uses the same library it results having duplicate code in the bundle and instancesof does not work properly. The real issue happens with superstruct package, however, see the demo below with boiled down-version.

Visualization:

["app" - es6 / `import`] -> [library] -> index.es.js -> class CustomError {}
         |
[3rd party module - commonjs / `require`] -> [library] -> index.cjs -> class CustomError {}

Repro: https://github.com/oleg-slapdash/webpack-issue-commonjs-es6-deduplication

git clone https://github.com/oleg-slapdash/webpack-issue-commonjs-es6-deduplication
cd webpack-issue-commonjs-es6-deduplication/
cd app
yarn
yarn webpack
yarn node dist/main.js

Output:
localError.source() ===  index.es.js
thirdPartyError.source() ===  index.cjs
localError instanceof CustomError === true
thirdPartyError instanceof CustomError ===  false

What is the expected behavior?

Webpack should be able to de-duplicate commonjs and es6 imports of the same library. The bundle should contain only one implementation of the library and instances should be able to be checked via instanceof.

Other relevant information:
webpack version: ^5.46.0
Node.js version: v15.1.0
Operating System: Mac OS 10.15.7
Additional tools: N/A

[alexander-akait]

expected, resolution using require and import are different due https://github.com/oleg-slapdash/webpack-issue-commonjs-es6-deduplication/blob/main/library/package.json#L7, Node.js works same

[oleg-slapdash]

@alexander-akait How would you suggest adjusting the code to make it work? The library is a 3rd party module used by thousands and 3rd party module needs to work on nodejs and in the browser.

[alexander-akait]

avoid using instanceof in this case, because library will not work on Node.js too...

[oleg-slapdash]

@alexander-akait Maybe there is away to achieve the same behavior as

"exports": {
    "import": "./index.es.js",
    "require": "./index.cjs"
  },

without code duplication? Or maybe a way to tell webpack to ignore this specific statement?

The real use-case is happening when there is a "shared" package between the client and the server. Because the "shared" package needs to work on node it uses commonjs and because the client needs to support tree shaking it uses es6.

[alexander-akait]

I am afraid no 😞 , my recommendation is migration on ECMA modules for node.js too, it is real different classes, as workaround you can do it myClass.contructor.name === 'Name' to avoid using instanceof

[sokra]

That's why we invented the module condition for the exports field, which is exactly to solve that purpose. Note that node.js doesn't support that, as it's not possible to require ESM.

See more details here: https://webpack.js.org/guides/package-exports

Best follow that pattern: https://webpack.js.org/guides/package-exports/#providing-commonjs-and-esm-version-stateful