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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: issue-5850 - Settle override conflicts between edges and propagate changes #7025
base: latest
Are you sure you want to change the base?
fix: issue-5850 - Settle override conflicts between edges and propagate changes #7025
Changes from 31 commits
865070c
cd20196
0cad4e0
6b276f3
fff3072
e97176e
19155ed
dedbccf
4a83786
7ee2f2e
0917421
6d0ad42
67d7d5c
643cbea
c5f6e4a
6c9bbf9
63760d9
6111630
b42d4c8
7d97726
35e5790
35ce2f7
5630954
f859e92
29f0750
17ec457
4cde831
701b125
b119f67
3136b64
80126c7
c4b5338
9db1232
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wraithgar This case means that the same node has two edges with completely different override sets pointing to it, which means that this node can't really decide which one is correct.
Our options are:
Currently I chose (1), but maybe it should at least show some kind of warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A hard-won lesson we learned with peer dependencies is that
1
is not the right choice here. npm 6 can install completely invalid trees, and this was fixed in npm 7.--legacy-peer-deps
can turn the behavior back on, but again it will install trees that have incorrect peer dependencies if there was a conflict. npm should never guess the user's intent.2
is the easiest solution, especially given that3
may eventually fail if we end up with an already duplicated node with conflicting override requirements.So, unless there's a really elegant way to do
3
that does't require an extra mountain of effort,2
is best here. We'll throw with as much context as possible to help the user build a working override set, but we won't build an invalid tree.This also leaves the door open later to implementing
3
, since we can gradually add smaller, specific cases where3
will work, and the fallback to2
will already be in place.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just
throw
anError
object. If we want npm to format the message in a special way based on any other attributes you assign to the object we can do that. A good example of that is here, with the cli's custom error output switch here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @wraithgar, I've encountered a problem with throwing an exception here.
This function is reached both by npm install and npm ls.
If I throw an exception here, npm ls fails without showing the tree, and running npm install again on a badly installed project fails in the initial mapping phase. What do you suggest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AlonNavon
Until clarity on the issue you can always
return false
orreturn false
andlog.silly
it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I checked the behavior of the algorithms here. @jdalton @wraithgar
We shouldn't throw here, we should just log the problem.
The fix to satisfiedBy function in edge.js causes that to return false, and so the edge is marked as invalid.
In the ls case it is marked as erroneous, and in the install case it is detached from this node and connected to a proper node.
So without throwing, we get the correct behavior.