Requires plugins from unrelated version of webpack when two versions are present in a project

[boutell]

This issue was previously reported in #1451 and closed as an upstream issue. However, I reported it as an upstream issue and was told that starting with webpack 5 there's a better way for plugins to access the version of webpack that instantiated them. So please review below, including the response from the webpack developers.

What is the current behavior?

If a project and one of its npm dependencies, let's call it nifty-cms, each depend on two different versions of webpack, i.e. 5 (project level) and 4 (nifty-cms), then npm and yarn will both do the reasonable thing and install webpack twice, with node_modules/nifty-cms/node_nodules containing webpack 4 and node_modules/webpack containing webpack 5. So far so good.

However, if nifty-cms also depends on html-webpack-plugin and the project does not, then html-webpack-plugin will be installed as node_modules/html-webpack-plugin. Again, so far so good. Hoisting is normal.

But here's where we get in trouble: unfortunately, when webpack 4 in nifty-cms loads html-webpack-plugin, html-webpack-plugin then tries to require various files back from webpack itself, for instance:

./index.js:const webpackMajorVersion = Number(require('webpack/package.json').version.split('.')[0]);
./lib/child-compiler.js:const NodeTemplatePlugin = require('webpack/lib/node/NodeTemplatePlugin');

At this point, npm (or yarn) sees that html-webpack-plugin was loaded from node_modules/html-webpack-plugin and loads node_modules/webpack.

But, this is not the version of webpack that instantiated the plugin. So we will get the wrong information about the version of webpack that instantiated us, and potentially incorrect and incompatible plugins as well (see the second require line).

https://github.com/webpack/webpack/issues/12606#issuecomment-774283510

So in a nutshell:

• The compiler object now has a webpack property, containing the webpack exports of the current version running, so plugins no longer need to require webpack or have a webpack dependency.
• webpack 4 doesn't have that, but you can require as a fallback.
• This doesn't give access to all "private modules", however many plugins, including the node plugin you're requiring here, are added to the exported webpack object (per the webpack.js source) so you can access them that way. The version number is also exported.
• Webpack 4 doesn't support this, but you can do fallback requires for that case.

[boutell]

... Except you're doing a new major version that only supports webpack 5, which means this issue should no longer be in play. Never mind. :homer-simpson-shrubbery: