Warn about duplicate dependencies

[darrenscerri]

Add duplicate-package-checker-webpack-plugin as proposed here: #1844 .
Display compilation warnings on build.

This feature can be quickly tested by creating an app, installing an old version of fbjs (yarn add fbjs@0.6.0) and importing fbjs from App.js. This will result in having duplicate fbjs packages since React already requires the most recent version of fbjs.

[gaearon]

"duplicate-package-checker" is not a very friendly way to log it. The end user doesn’t know what a "duplicate-package-checker" is. Instead, it should say:

The following packages are duplicated in the bundle:

and also add some instructions on how to avoid it.

[gaearon]

(I understand this may not be possible, but we need to work with its author to ensure it provides a good experience to our users. We also need to make sure we have some sensible instructions to follow to solve the issue.)

[darrenscerri]

Been a while 😄 I've updated the plugin to display a better warning message and beefed up the Readme in the repo with some possible solutions for resolving duplicate package issues (https://github.com/darrenscerri/duplicate-package-checker-webpack-plugin)

As for the warning message, Webpack prepends all warnings with a "Warning in:" which is usually followed by a package name or a path to the file that the warning refers to, so I've settled down on starting the warning with the duplicated package name followed by relevant information.

CRA:

Non-CRA Webpack:

[Timer]

Fancy!

[gaearon]

I think it's not reasonable to warn if the libraries depend on different major versions.
This can't be solved by deduping or any other method safely.

What do you think?

[darrenscerri]

I understand your point, but I think that a different major version of a package is still something that the developer should at least be aware of, due to any of the following:

• Your project is using an outdated package, which may no longer be supported
• Your project is bloated by having 2 packages doing effectively the same thing
• You might run into hard-to-debug issues if your project assumes only a single instance of the package

I agree that solving such issues in this case may not be easy, since it might require the developer to file an issue on the project to update the outdated dependency. Otherwise, the solution may be risky since their may be compatibility issues between the two versions of the package. Having said that, I don't think that giving such a heads-up to the developer is unreasonable.

The only downside I see right now is that using CRA, developers cannot easily exclude packages in order to dismiss the warning for a particular package if they acknowledge and are ok with having multiple versions of that package. The plugin itself supports exclusions, but only through a configuration object passed when instantiating the Webpack plugin.

[gaearon]

How do you feel about adding an option to the plugin to only warn about same majors? I think we could take it in that case. (I agree with you in theory but in practice it will just mean everyone sees something like lodash there and applies incorrect workarounds.)

[gaearon]

Please pin the version.

[darrenscerri]

Yeah I agree, it might potentially lead to impulsive and unsafe workarounds if devs don't really understand the consequences.

[Luchanso]

Can I will review some PR from this repo? It will not confuse?

[gaearon]

I think this is a blocker for the PR: darrenscerri/duplicate-package-checker-webpack-plugin#16

[gaearon]

We should also make sure this doesn't fail the CI when duplicates are found.

[SavePointSam]

Is this still something planned for #3815? Based on the child issue discussion (darrenscerri/duplicate-package-checker-webpack-plugin#16 (comment)), this is no longer being considered. I would request the parent react-script@2.0 issue be updated if this functionality is being dropped.

If this is still desired, what needs to be done to push this forward? I see the fs performance issue is still open and rather stale, like this PR.

Personally, I think this would be a great addition. However, the concerns about actionability and clarity in what is happening will be very difficult to get right. Would it be worthwhile to have subdued output for advanced users that want to know this kind of things with a link to the User Guide that explains everything in greater detail? The biggest combatant to misinformation about solving issues like this, in my opinion, come from having a recommended set of information that is readily presented to the user. No need to search warning messages if there’s is a link right there saying learn more.

Ultimately, I suggest this is not a blocker for 2.0 as I don’t know if anyone clamoring for this functionality, though I totally see the merit behind it. Maybe it’s wortwhile to put in a 2.X?

Thanks! ^_^