[BUG] unable to resolve dependency tree #2000

edwinm · 2020-10-20T20:55:20Z

Current Behavior:

When I run npm i @typescript-eslint/parser@latest, I get:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! Found: @typescript-eslint/parser@3.10.1
npm ERR! node_modules/@typescript-eslint/parser
npm ERR!   dev @typescript-eslint/parser@"4.5.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! dev @typescript-eslint/parser@"4.5.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /Users/edwinm/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/edwinm/.npm/_logs/2020-10-20T20_34_49_853Z-debug.log

Expected Behavior:

I expect npm to upgrade my package. Npm says "Fix the upstream dependency conflict", but I don't see any.

If npm sees a conflict, it should explain where the conflict is.

Steps To Reproduce:

git clone https://github.com/edwinm/carbonium.git
cd carbonium
npm update
npm i @typescript-eslint/parser@latest

Environment:

MacOS 10.15.7
Node v15.0.0
npm 7.0.2

The text was updated successfully, but these errors were encountered:

isaacs · 2020-10-20T21:37:17Z

Huh, yeah, that isn't a very helpful explanation, is it?

Can you share your package.json file?

isaacs · 2020-10-20T21:37:39Z

Oh, sorry, you posted repro steps, sorry I'd missed that. Taking a look now.

isaacs · 2020-10-20T21:41:06Z

Hmm... this seems to work for me using npm 7.0.2 and 7.0.3 (published today).

Can you share the full debug log at /Users/edwinm/.npm/_logs/2020-10-20T20_34_49_853Z-debug.log and the eresolve report at /Users/edwinm/.npm/eresolve-report.txt? That might shed some light on it.

Also, what git commit are you at in carbonium? Is it possible this has been fixed?

$ git clone https://github.com/edwinm/carbonium.git
Cloning into 'carbonium'...
remote: Enumerating objects: 13037, done.
remote: Counting objects: 100% (13037/13037), done.
remote: Compressing objects: 100% (8729/8729), done.
remote: Total 13037 (delta 3499), reused 12934 (delta 3403), pack-reused 0
Receiving objects: 100% (13037/13037), 23.91 MiB | 15.89 MiB/s, done.
Resolving deltas: 100% (3499/3499), done.

$ cd carbonium
/Users/isaacs/dev/npm/arborist/x/carbonium

$ npm update
npm i @typescript-eslint/parser@latest

added 569 packages, and audited 569 packages in 13s

59 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

$ npm i @typescript-eslint/parser@latest
npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!

> husky@4.3.0 preuninstall /Users/isaacs/dev/npm/arborist/x/carbonium/node_modules/husky
> node husky uninstall

husky > Uninstalling git hooks
husky > Done
npm WARN @typescript-eslint/parser@4.5.0 requires a peer of eslint@^5.0.0 || ^6.0.0 || ^7.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN tsutils@3.17.1 requires a peer of typescript@>=2.8.0 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev || >= 3.5.0-dev || >= 3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || >= 3.7.0-beta but none is installed. You must install peer dependencies yourself.

+ @typescript-eslint/parser@4.5.0
added 12 packages from 19 contributors, removed 546 packages, updated 23 packages and audited 35 packages in 6.273s

7 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

isaacs · 2020-10-20T21:43:53Z

Oh, whoops that last install was in npm v6. trying again, I get this:

$ npm i @typescript-eslint/parser@latest
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! Found: @typescript-eslint/parser@3.10.1
npm ERR! node_modules/@typescript-eslint/parser
npm ERR!   dev @typescript-eslint/parser@"4.5.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! dev @typescript-eslint/parser@"4.5.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /Users/isaacs/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/isaacs/.npm/_logs/2020-10-20T21_42_51_028Z-debug.log

This is weird, it's not a peer conflict, looks like, it's just refusing to clobber an existing dev dep with a new version. That's a bug, yes.

isaacs · 2020-10-20T23:26:43Z

Aha, no, it is a peer conflict, but it's failing to properly report on it, because we ignore other edgesIn when the dep node is a dependency of the root node. https://github.com/npm/arborist/blob/main/lib/node.js#L364-L375

I recall that we added that because it got quite noisy in some cases, but it seems clear to me that was a mistake. When that check is removed, I see a report like this, which is much clearer:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! Found: @typescript-eslint/parser@3.10.1
npm ERR! node_modules/@typescript-eslint/parser
npm ERR!   peer @typescript-eslint/parser@"^3.0.0" from @typescript-eslint/eslint-plugin@3.10.1
npm ERR!   node_modules/@typescript-eslint/eslint-plugin
npm ERR!     dev @typescript-eslint/eslint-plugin@"^3.10.1" from the root project
npm ERR!   dev @typescript-eslint/parser@"4.5.0" from the root project

If you do npm i @typescript-eslint/parser@latest @typescript-eslint/eslint-plugin@latest, updating both dependencies, I would have expected it to work, but in that case, it runs into an issue replacing one while the other is present, even though it's invalid and about to be replaced! My minimized testcase doesn't fail on this, I believe because eslint-plugin comes alphabetically ahead of parser. Building a new simplified test case now.

isaacs · 2020-10-21T01:42:31Z

Ahahhhh... this doesn't have anything to do with the order of the deps. The (second) issue is that both packages have a peer dependency on estlint, and the root package has an eslint dep as well.

So, first issue, the report isn't helpful. That's addressed by leaving in the other dependencies when a dep node has an edge coming in from the root package. Easy enough.

That would make it clear that you can't simply do npm i @typescript-eslint/parser@latest, because the @typescript-eslint/eslint-plugin package also has to be updated along with it.

Fair enough, so you do npm i @typescript-eslint/parser@latest @typescript-eslint/eslint-plugin@latest to update them both.

Currently that crashes at the phase where it tries to determine of the intended target location has any current dependencies which will collide with one of the peers of the dependency you're trying to add, leading to this loop here.

This finds eslint in the peerSet of the module about to be added, and checks to see if there is an eslint there already. Is that eslint currently valid? Ok, I guess we can't replace it then!

Except... the one we're trying to add also has an eslint of the exact same version.

This fixes the issue:

diff --git a/lib/arborist/build-ideal-tree.js b/lib/arborist/build-ideal-tree.js
index ae9965e..d85d858 100644
--- a/lib/arborist/build-ideal-tree.js
+++ b/lib/arborist/build-ideal-tree.js
@@ -1351,6 +1351,11 @@ This is a one-time fix-up, please be patient...
             // only respect valid edges, however, since we're likely trying
             // to fix the very one that's currently broken!
             if (edge.from === target && edge.valid) {
+              // if we have a replacement in the peerSet that we're trying
+              // to place, and the replacement will be fine, then that's ok.
+              const replacement = dep.parent.children.get(edge.name)
+              if (replacement && replacement.satisfies(edge))
+                continue
               canReplace = false
               break OUTER
             }

Will have a PR up as soon as I have a test for this.

Minimized repro case:

{
  "dependencies": {
    "@isaacs/testing-peer-dep-conflict-chain-a": "1",
    "@isaacs/testing-peer-dep-conflict-chain-single-a": "^1.0.1",
    "@isaacs/testing-peer-dep-conflict-chain-single-b": "^1.0.1"
  }
}

npm install
npm install @isaacs/testing-peer-dep-conflict-chain-single-a@2 @isaacs/testing-peer-dep-conflict-chain-single-b@2

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

- Ensure that root is added when root.meta is set - Include all edges in explain() output when a root edge exists - Do not conflict on meta-peers that will not be replaced - Install peerOptionals if explicitly requested, or dev Fix: #1997 Fix: #2000 Fix: #2005

LilMoke · 2020-10-24T00:31:36Z

I am trying to deploy my app on a Heroku dyno and I am experiencing this same/similiar error. This has just started to happen and the proposed solution I am not sure how to try on a Heroku Dyno, or if it is even a proper fix.

Any help would be appreciated as I need to push out an update to our app and I am not quote sure how to correct this issue.

Salarov · 2020-10-24T14:49:52Z

The same issue installing an angular app in Dotnet project.

npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: vega@0.0.0
npm ERR! Found: zone.js@0.9.1
npm ERR! node_modules/zone.js
npm ERR!   zone.js@"0.9.1" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer zone.js@"~0.10.3" from @angular/core@10.2.0
npm ERR! node_modules/@angular/core
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

LilMoke · 2020-10-24T15:10:08Z

Yes, I do not understand why this is closed when there is no global solution for this. Since you are angular botnet,. it appears to be a real npm issue.

I was hoping someone here would be able to shed some light upon this as it just started happening.

I noticed it when I mistakenly re-deployed my project which has not changed in months. And now this, however, I went to publish the correct app with some changes and it refuses to let me deploy because of this.

Very frustrating since obviously others have the issue. If you find something that you feel may help me also I would love to hear.

Salarov · 2020-10-24T15:14:49Z

Of course, the temporary solution is using prior versions of the node.
I tried 14.13.1 and seems stable.

Here is the link for downloading.

LilMoke · 2020-10-24T15:35:15Z

Wow, yes, I used 14.13.1 and my app deploys fine. No errors! Thank you, you are a life saver I was fooling with this for hours yesterday and today. I tried various versions to no success.

Anyway, I am still puzzled why my default install fails with the default Heroku version of npm. Anyway, I am glad it is resolved for me.

Thanks again!

Salarov · 2020-10-24T17:59:54Z

Wow, yes, I used 14.13.1 and my app deploys fine. No errors! Thank you, you are a life saver I was fooling with this for hours yesterday and today. I tried various versions to no success.

Anyway, I am still puzzled why my default install fails with the default Heroku version of npm. Anyway, I am glad it is resolved for me.

Thanks again!

Happy that helped.

toridoriv · 2020-10-26T18:30:35Z

Of course, the temporary solution is using prior versions of the node.
I tried 14.13.1 and seems stable.

Here is the link for downloading.

Thank you so much! You saved my life 😅

- Fixes npm/cli#2000

rumax · 2020-10-26T18:36:58Z

Same issue on Circle CI with

- image: circleci/node:latest

Downgrading node to 14 fixes the issue

- Fixes npm/cli#2000

strican · 2020-10-26T21:24:41Z

FYI, this seems to be an issue I'm getting on the out-of-the-box Typescript create-react-app. @isaacs, that may be worth adding to a test pass somewhere, it seems like a pretty major project that you'd want to verify before release.

Repro steps:

npx create-react-app myapp --template typescript
cd myapp
rm -rf node_modules
npm install

@isaacs It seems like the issue is fixed via npm/arborist@1d6b057. Is there a way to track when that gets released in an npm release?

Yodablues · 2020-10-27T18:42:49Z

Also having this issue after upgrading to Node 15.0.1 and npm 7.0.5.

isaacs · 2020-10-28T00:34:54Z

@strican It's in @npmcli/arborist 1.0.4, which is included in npm 7.0.4 https://github.com/npm/cli/releases.

This issue has gotten quite a few "me too" comments that are in fact different examples, with different versions of npm in some cases. Please post new issues for problems that occur with different packages, or using different versions of npm. The original post here has been root-caused, addressed, and verified fixed.

If you are in fact having the same problem, then the solution is to update to the latest release of npm, where this issue is fixed. If you are having a different issue with the same error code, with different packages, using the latest version of npm, then please post a new issue. We cannot get to the bottom of your problem any other way.

Thus, I am lovingly and compassionately locking this issue, to force y'all to actually get help from us <3

edwinm added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Oct 20, 2020

darcyclarke removed the Needs Triage needs review for next steps label Oct 21, 2020

darcyclarke added this to the OSS - Sprint 18 milestone Oct 21, 2020

isaacs mentioned this issue Oct 21, 2020

Do not conflict on meta-peers that will not be replaced npm/arborist#165

Closed

ruyadorno closed this as completed in npm/arborist@1d6b057 Oct 23, 2020

mtrezza mentioned this issue Oct 23, 2020

Dependency error 4.0.3... parse-community/parse-server#6967

Closed

4 tasks

TJKoury mentioned this issue Oct 23, 2020

switch to using terser plugin instead of uglify CesiumGS/cesium#9214

Closed

rumax added a commit to rumax/react-native-PDFView that referenced this issue Oct 26, 2020

Use fixed node for CI

2106ee3

- Fixes npm/cli#2000

rumax added a commit to rumax/react-native-PDFView that referenced this issue Oct 26, 2020

Use fixed node for CI

dd69bda

- Fixes npm/cli#2000

harshbafna mentioned this issue Oct 27, 2020

Regression suite fails to install newman with latest nodejs pytorch/serve#755

Closed

npm locked as resolved and limited conversation to collaborators Oct 28, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] unable to resolve dependency tree #2000

[BUG] unable to resolve dependency tree #2000

edwinm commented Oct 20, 2020

isaacs commented Oct 20, 2020

isaacs commented Oct 20, 2020

isaacs commented Oct 20, 2020

isaacs commented Oct 20, 2020

isaacs commented Oct 20, 2020

isaacs commented Oct 21, 2020

LilMoke commented Oct 24, 2020

Salarov commented Oct 24, 2020 •

edited by isaacs

Loading

LilMoke commented Oct 24, 2020 •

edited

Loading

Salarov commented Oct 24, 2020 •

edited

Loading

LilMoke commented Oct 24, 2020

Salarov commented Oct 24, 2020

toridoriv commented Oct 26, 2020

rumax commented Oct 26, 2020

strican commented Oct 26, 2020

Yodablues commented Oct 27, 2020

isaacs commented Oct 28, 2020

[BUG] unable to resolve dependency tree #2000

[BUG] unable to resolve dependency tree #2000

Comments

edwinm commented Oct 20, 2020

Current Behavior:

Expected Behavior:

Steps To Reproduce:

Environment:

isaacs commented Oct 20, 2020

isaacs commented Oct 20, 2020

isaacs commented Oct 20, 2020

isaacs commented Oct 20, 2020

isaacs commented Oct 20, 2020

isaacs commented Oct 21, 2020

LilMoke commented Oct 24, 2020

Salarov commented Oct 24, 2020 • edited by isaacs Loading

LilMoke commented Oct 24, 2020 • edited Loading

Salarov commented Oct 24, 2020 • edited Loading

LilMoke commented Oct 24, 2020

Salarov commented Oct 24, 2020

toridoriv commented Oct 26, 2020

rumax commented Oct 26, 2020

strican commented Oct 26, 2020

Yodablues commented Oct 27, 2020

isaacs commented Oct 28, 2020

Salarov commented Oct 24, 2020 •

edited by isaacs

Loading

LilMoke commented Oct 24, 2020 •

edited

Loading

Salarov commented Oct 24, 2020 •

edited

Loading