npm / arborist / #384 / 1

push

Fix 3 related peerDep ideal tree edge cases

1. we should _never_ place a dep in a target where the target
has a peerDep on that dependency, even if it would be allowed or
conflicts with a higher level.  However, we _should_ continue walking up
the tree in this case, so the solution is to detect this in the walk-up,
and continue to the next spot if there's a peer edge present.

2. It's possible for the virtual root to not contain a peer node, if the
edge is a peerOptional edge.  In that case, we may still need to detect
and add the node, if the current dep version present is outside the
dependency range.  (We do not install peerOptionals by default, but we
DO ensure that they're valid if present, and install when necessary to
avoid loading an invalid version, if possible.)

3. In light of 1 and 2 above, it's important to _always_ attempt to
dedupe peer deps, even if that means downgrading the version in use, or
we find ourselves in many more ERESOLVE cases than we need to be.
Solution here is to effectively always place peerDeps in preferDedupe
mode, regardless of the option that is passed in to Arborist.

2373 of 2373 branches covered (100.0%)

Branch coverage included in aggregate %.

3364 of 3364 relevant lines covered (100.0%)

466.6 hits per line