-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
[BUG] npm install --force fails for peerOptional conflicts #2504
Comments
Another one:
|
I have the same problem but on BigSur |
this is still a problem on 7.5.3 for me. switching back to v6 |
This is a legit problem with your dependencies. You can't use Nevertheless, it should be ignoring the conflict if I'm using this package.json to reproduce (note the pinned dependency on react-scripts 4.0.1): {
"devDependencies": {
"react-scripts": "4.0.1",
"typescript": "^4.1.3"
}
} |
With a dependency graph like this: ``` root -> (a, b@1) a -> PEEROPTIONAL(b@2) ``` We do not install the peerOptional dependency by default, so even though `b@2` is included in the peerSet of `a`, it is not added to the tree. Then, the `b@1` dependency is added to satisfy root's direct dependency on it, causing the `a -> b@2` edge to become invalid. We then try to resolve the `a -> b@2` edge, and find that we cannot place it anywhere, causing an `ERESOLVE` error. However, because `b@2` is no longer a part of a peerSet sourced on the `root` node, we miss the chance to detect that it should be overridden, resulting in an `ERESOLVE` failure even when `--force` is used. This commit adds the check for `this[_force]` prior to crashing with ERESOLVE, so that cases that avoid our earlier heuristics still accept the invalid resolution when `--force` is in effect. Fix: #226 Fix: npm/cli#2504
With a dependency graph like this: ``` root -> (a, b@1) a -> PEEROPTIONAL(b@2) ``` We do not install the peerOptional dependency by default, so even though `b@2` is included in the peerSet of `a`, it is not added to the tree. Then, the `b@1` dependency is added to satisfy root's direct dependency on it, causing the `a -> b@2` edge to become invalid. We then try to resolve the `a -> b@2` edge, and find that we cannot place it anywhere, causing an `ERESOLVE` error. However, because `b@2` is no longer a part of a peerSet sourced on the `root` node, we miss the chance to detect that it should be overridden, resulting in an `ERESOLVE` failure even when `--force` is used. This commit adds the check for `this[_force]` prior to crashing with ERESOLVE, so that cases that avoid our earlier heuristics still accept the invalid resolution when `--force` is in effect. Fix: #226 Fix: npm/cli#2504
With a dependency graph like this: ``` root -> (a, b@1) a -> PEEROPTIONAL(b@2) ``` We do not install the peerOptional dependency by default, so even though `b@2` is included in the peerSet of `a`, it is not added to the tree. Then, the `b@1` dependency is added to satisfy root's direct dependency on it, causing the `a -> b@2` edge to become invalid. We then try to resolve the `a -> b@2` edge, and find that we cannot place it anywhere, causing an `ERESOLVE` error. However, because `b@2` is no longer a part of a peerSet sourced on the `root` node, we miss the chance to detect that it should be overridden, resulting in an `ERESOLVE` failure even when `--force` is used. This commit adds the check for `this[_force]` prior to crashing with ERESOLVE, so that cases that avoid our earlier heuristics still accept the invalid resolution when `--force` is in effect. Fix: #226 Fix: npm/cli#2504 PR-URL: #228 Credit: @isaacs Close: #228 Reviewed-by: @ruyadorno
Current Behavior:
Run
npm install --force
fails instead of ignoring upstream dependency conflictExpected Behavior:
It should print a warning and continue with the installation.
Steps To Reproduce:
Output:
npm resolution error report
Environment:
The text was updated successfully, but these errors were encountered: