Issue 1:
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

Issue 2:
This is mostly to open discussion on how to solve a specific problem at this point, I only have a crude idea in my head of how this could be made to work.

I currently have an isomorphic website (www.toons.tv) that's built using React and Webpack on both the server and the client. The current build setup is quite clunky and accounts for a big portion of code in the whole project - the main reason for this is that in order to have an efficient development setup, I of course want to be watching all the assets and rebuild them when changed. However, every time the assets are rebuilt, the JS (both client and server) needs to know the new asset URLs. This means a very complex setup where webpack is only building the JS, and the rest (icon fonts, web fonts, images and other assets) is handled by gulp, and then all these update a build-manifest.json file that is required by the JS, so that the webpack builds are triggered as well.

I'd like to move the asset pipeline completely to webpack instead, but this is problematic because currently you can only have one target (and set of options) per compiler, so the assets would be rebuilt twice and given that some of the assets are not generated deterministically (e.g. the icon fonts), the client could end up with different asset URLs than the server, which could easily lead to resources being loaded twice on the client.

At some point, I would also like to take service workers into use, and the worker would also need the same asset URLs.

One proposal that comes to mind is that you could define per-entry options:

webpack({
entry: {
client: {
entry: "/path/to/client/entry.js",
target: "browser",
},
server: {
entry: "/path/to/server/entry.js",
target: "node",
},
},
});

I do realize that this would probably be a pain to implement, especially if the different entries are supposed to share parts of the pipeline while diverging at some points (e.g. if there's different plugins and/or loaders used by different entries), and also possibly require breaking changes to the plugin API, but I do hope to see this use case solved by webpack at some point.

Cheers! ❤️ ✨