npm / arborist / #187

push

Refactor and explain ERESOLVE conflicts

When a peerDep cannot be resolved, this changes a few things.

First, the Node.explain() method is used to explain what was present
that conflicted, why it's there, what the conflict (or peer conflict)
was that we couldn't install, and why THAT node was trying to be added.
With some prettying up and conversion to human-intelligible language,
this should provide the user with enough information to make an informed
decision about what to do.

Second, we override the peer dep with a "best guess" as to what ought to
go in that location if --force is enabled.  If the target location is
the first place we're trying to place the peerDep (ie, it is the parent
of the node that has the peer dependency), and it has a direct
dependency on the node in question, then we use the parent's dependency
spec instead.

Lastly, if a _set_ of peer dependencies can be moved deeper into the
tree in order to avoid a conflict, we now detect that and do that as
well.

The "fixWithForce" boolean on the explanation object can be used to
suggest that the user MAY retry the command with --force in order to
resolve the situation.  Otherwise, --legacy-peer-deps is the other quick
fix.

With these changes in place, gatsby, reakit, doctokit, and several other
real-world projects that depend on nested conflicting peerDependencies
can be installed, albeit requiring the use of the --force flag.

2211 of 2211 branches covered (100.0%)

Branch coverage included in aggregate %.

3222 of 3222 relevant lines covered (100.0%)

497.22 hits per line