Determining why dependencies haven't been deduped

[jamiebuilds]

Do you want to request a feature or report a bug? Feature

What is the current behavior?

Yarn dedupes everything it can by default, but in scenarios where it can't it doesn't share information on why.

What is the expected behavior?

It would be nice if we either had output that explained what is going on with deduping or if there was a command to query for that information.

[sebmck]

We have this, $ yarn why dependency-name-or-path.

[jamiebuilds]

That doesn't have information on the versions required

[wycats]

For what it's worth, I think thinking about it as "deduping" (aka an optimisation rather than something you can rely on) is a pretty confusing mental model.

Sadly, "opportunistic deduping" makes it seem like npm@3 solves a bunch of problems, when in fact it just makes them less common (and makes "works on my machine" bug closures more common and frustrating).

Have we enumerated the scenarios we're targeting with --flat, deduping, and yarn why anywhere? If not, I'll happily take a stab at it (solving this problem is more or less why I got interested in package management in the first place and I'd be happy to write up my thinking on the matter).

[benjamn]

Have we enumerated the scenarios we're targeting with --flat

One of the most compelling reasons for --flat to exist is to prevent multiple installations of react, because it really can't be loaded more than once in the same app (not just a space-saving optimization).

Another common correctness problem that can be solved by --flat is the failure of instanceof when testing an instance of a class defined in another copy of the package. Logically it's the same class, but the constructors are distinct, so you lose. I've had to stop using instanceof in my packages for any objects that might be from an external source, because of this risk.

[benjamn]

What if --flat had the ability to consider different (previous) versions of packages with conflicting dependency constraints, in the hope of finding a set of packages whose constraints agree on a single version of each dependency, without always prompting the user to make a blind choice between conflicting versions?

This line of thinking leads into the territory of constraint solving, and obviously it wouldn't work all the time and yarn would still need to prompt the user to make some decisions.

At the very least, it would be nice if one of the options displayed by the --flat UI was "I don't know" or "I don't care", which would permit multiple installations of the package, a la npm@3.

[benjamn]

If full constraint solving is too different from the spirit of yarn install --flat, then I would propose a separate command, perhaps yarn untangle?