Having another `babel-loader` in the project’s package.json results in silently broken targeting

[platosha]

While trying several different versions of webpack-babel-multi-target-plugin, I have noticed, that some of them result in broken targeting behaviour. Symptoms include:

• the webpack build finishes successfully, no errors or warnings,
• both modern and legacy bundles contain the same code,
• Babel options do not apply, in particular, presetOptions: {debug: true} does not do anything useful.

I had babel-loader dependency in the project’s package.json. When a version mismatch happens, there were two babel-loader installations in the project node_modules/babel-loader and in the plugin node_modules/webpack-babel-multi-target-plugin/node_modules/babel-loader, which seems to be the cause of the issue.

Removing babel-loader from package.json helped. My webpack.config.js was not using babel-loader directly, so removing the dependency didn’t break anything.

Perhaps this is worth documenting somewhere. When someone upgrades a project already using babel-loader to webpack-babel-multi-target-plugin, the old babel-loader dependency could be forgotten in the package.json even though it is not used.

[DanielSchaffer]

Interesting ... I'm curious why this is. There's one place in the plugin code where the babel-loader package is referenced, and that's in targeting.plugin.ts - but that resolves the full path of the plugin, and that is given directly to webpack along with its options, so it's a little odd that the mere presence of another babel-loader package elsewhere in node_modules would mess with that. The debug option being ignored might be a separate issue - see #12.

Anyhow, I'll definitely add a point to the setup instructions about removing babel packages from package.json. Thanks for the report!