@TheLarkInn 👍 for a deprecation message. That way people know to get rid of it. Always go with warnings in deprecations and then drop those in the next major version.

But does 2 count as the next major version? Should it get a deprecation message in webpack 1?

@Kovensky I guess the expectation is that people will try to run webpack 2 with the plugin enabled when they upgrade. So I would push the messages there and then drop in webpack 3.

@bebraw since it outright conflicts with harmony modules, I guess it would be better to turn it into a noop that just prints the deprecation warning (also warning that it does nothing anymore)...

@bebraw since it outright conflicts with harmony modules, I guess it would be better to turn it into a noop that just prints the deprecation warning (also warning that it does nothing anymore)...

I can do that...

As a kind of a replacement of the DedupePlugin, you can now use RootMostResolvePlugin from 'webpack-dependency-suite/plugins/root-most-resolve-plugin'. It's a module.resolve plugin that ensures Webpack uses dependencies from the root-most node_modules as long as they satisfy SemVer version dependency of the requesting module.

See more info.

or just npm dedupe

@sokra npm dedupe won't work with linked modules.

@sokra npm dedupe won't work with linked modules.

we are also in this boat. our app is part of a lerna repo, so npm dedupe doesn't work well there.

After some tests, I'm seeing multiple version of a few modules/files. Like with lodash. In a failry big app with a lot of dependencies, I can see lodash/isFunction.js multiple times for example. One in the root, and a couple of times under some dependencies.

What's the strategy now to dedupe these dependencies? I've tried npm dedupe and it didn't work. I still have all of them in the bundle.

@tleunen use root-most-resolve-plugin.

I don't see any changes with this plugin. I still see multiple lodash/isFunction.js

@tleunen Then it's quite possible that your package's dependencies have version-incompatible ranges with regards to lodash they want to use. I can add an option to root-most-resolve-plugin to skip the SemVer check when matched by some sort of an ignore-list.

But doing that can cause unexpected problems in case package A depends on lodash 2.x and package B on lodash 4.x, the method signatures might be incompatible.

Also, did you add the plugin to the correct place in the config file (to resolve.plugins , not plugins)?

I did.

So looks like it's normal I have the version for react-smooth, because they are using the tilde instead of the caret. But I also have the one for recharts.
So instead of having 3 copies, I should have 2 copies with your plugin, right?

@tleunen yeah, you should have two. So you still have 3? It would be best if I could implement an "error margin" function, so you could say, convert all ~ to ^ to make the matching more loose.