Skip to content
This repository has been archived by the owner on Jan 20, 2022. It is now read-only.

[BUG] case where ERESOLVE persists when --force is used #226

Closed
isaacs opened this issue Feb 11, 2021 · 0 comments · Fixed by #228
Closed

[BUG] case where ERESOLVE persists when --force is used #226

isaacs opened this issue Feb 11, 2021 · 0 comments · Fixed by #228
Assignees
Labels
Bug thing that needs fixing

Comments

@isaacs
Copy link
Contributor

isaacs commented Feb 11, 2021

npm/cli#2504

{
  "devDependencies": {
    "react-scripts": "4.0.1",
    "typescript": "^4.1.3"
  }
}
@isaacs isaacs self-assigned this Feb 11, 2021
@isaacs isaacs added Agenda will be discussed at the Open RFC call Bug thing that needs fixing and removed Agenda will be discussed at the Open RFC call labels Feb 11, 2021
isaacs added a commit that referenced this issue Feb 11, 2021
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
isaacs added a commit that referenced this issue Feb 12, 2021
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
isaacs added a commit that referenced this issue Feb 12, 2021
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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug thing that needs fixing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant