This repository has been archived by the owner on Jan 20, 2022. It is now read-only.
Do not conflict on meta-peers that will not be replaced #165
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was causing the root metadata (name, version, and the package[''] member) to be missing when we replace the metadata object on the root node during the buildIdealTree step (which we do for 'npm update' with no package name args). Implicitly add the node to the metadata whenever node.meta is set. This required a bit of shuffling around and the removal of some cases where we _were_ explicitly adding the root node, since it is now no longer a thing that can be forgotten. Fix: npm/cli#1997
isaacs
force-pushed
the
isaacs/do-not-collide-on-matching-peer-set-members
branch
from
4da0d9e
to
66f1a7f
Compare
When in a situation where a project has dependencies on several members of a peer set, it was encountering a spurious ERESOLVE error if the entire set was being replaced, but _one_ of the members did not need to be. For example: ``` root -> (a@1, b@1, c@1) a@1 -> PEER(b@1, c@1) a@2 -> PEER(b@2, c@1) b@1 -> PEER(c@1) b@2 -> PEER(c@1) ``` resulting in the tree: ``` root +-- a@1 +-- b@1 +-- c@1 ``` If we try to upgrade both `a` and `b` to version 2, however, we would check the set of peers for each dependency node being replaced, and find that there was a `c` node with a non-peer dependency from the root node, and treat it as a conflict, even though there was no need for `c` to be modified at all! Resolve this by skipping the check when not doing `canPlacePeers` (since it's either already a conflict, or already set to be overridden by the version from the virtualRoot), and ignoring the conflict when a non-overridden node exists in the virtualRoot which meets the non-peer edge keeping the current dependency node in place. In those cases, either we will replace or keep the current node anyway, so there's no need to conflict on it. Fix: npm/cli#2000
isaacs
force-pushed
the
isaacs/do-not-collide-on-matching-peer-set-members
branch
from
66f1a7f
to
9bb36dc
Compare
ruyadorno
approved these changes
Oct 23, 2020
wraithgar
deleted the
isaacs/do-not-collide-on-matching-peer-set-members
branch
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on #163, land that first.
When in a situation where a project has dependencies on several members
of a peer set, it was encountering a spurious ERESOLVE error if the
entire set was being replaced, but one of the members did not need to
be.
For example:
resulting in the tree:
If we try to upgrade both
aandbto version 2, however, we wouldcheck the set of peers for each dependency node being replaced, and find
that there was a
cnode with a non-peer dependency from the root node,and treat it as a conflict, even though there was no need for
cto bemodified at all!
Resolve this by skipping the check when not doing
canPlacePeers(sinceit's either already a conflict, or already set to be overridden by the
version from the virtualRoot), and ignoring the conflict when a
non-overridden node exists in the virtualRoot which meets the non-peer
edge keeping the current dependency node in place. In those cases,
either we will replace or keep the current node anyway, so there's no
need to conflict on it.
Fix: npm/cli#2000