Skip to content

[BUG] unable to resolve dependency tree #2000

Closed
Closed
[BUG] unable to resolve dependency tree#2000
Labels
Bugthing that needs fixingRelease 7.xwork is associated with a specific npm 7 release
Milestone
OSS - Sprint 18

Description

@edwinm
edwinm
opened on Oct 20, 2020

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

Activity

  1. edwinm
    added
    Bugthing that needs fixing
    Needs Triageneeds review for next steps
    Release 7.xwork is associated with a specific npm 7 release
    on Oct 20, 2020

  2. isaacs commented on Oct 20, 2020

    @isaacs
    isaacs
    on Oct 20, 2020
    Contributor

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

    Can you share your package.json file?

  3. isaacs commented on Oct 20, 2020

    @isaacs
    isaacs
    on Oct 20, 2020
    Contributor

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

  4. isaacs commented on Oct 20, 2020

    @isaacs
    isaacs
    on Oct 20, 2020
    Contributor

    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

  5. isaacs commented on Oct 20, 2020

    @isaacs
    isaacs
    on Oct 20, 2020
    Contributor

    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.

  6. isaacs commented on Oct 20, 2020

    @isaacs
    isaacs
    on Oct 20, 2020
    Contributor

    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.

  7. isaacs commented on Oct 21, 2020

    @isaacs
    isaacs
    on Oct 21, 2020
    Contributor

    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
  8. darcyclarke
    removed
    Needs Triageneeds review for next steps
    on Oct 21, 2020
  9. darcyclarke
    added this to the OSS - Sprint 18 milestone on Oct 21, 2020
  10. isaacs
    added 3 commits that reference this issue on Oct 21, 2020

    Do not conflict on meta-peers that will not be replaced

    4da0d9e

    Do not conflict on meta-peers that will not be replaced

    66f1a7f

    Do not conflict on meta-peers that will not be replaced

    9bb36dc
  11. ruyadorno
    closed this as completedin 1d6b057on Oct 23, 2020
  12. isaacs
    added a commit that references this issue on Oct 23, 2020

    @npmcli/arborist@1.0.4

    7839655

  13. LilMoke commented on Oct 24, 2020

    @LilMoke
    LilMoke
    on Oct 24, 2020

    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.

  14. Salarov commented on Oct 24, 2020

    @Salarov
    Salarov
    on Oct 24, 2020

    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.

  15. LilMoke commented on Oct 24, 2020

    @LilMoke
    LilMoke
    on Oct 24, 2020

    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.

  16. Salarov commented on Oct 24, 2020

    @Salarov
    Salarov
    on Oct 24, 2020

    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.

  17. LilMoke commented on Oct 24, 2020

    @LilMoke
    LilMoke
    on Oct 24, 2020

    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!

  18. Salarov commented on Oct 24, 2020

    @Salarov
    Salarov
    on Oct 24, 2020

    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.

  19. toridoriv commented on Oct 26, 2020

    @toridoriv
    toridoriv
    on Oct 26, 2020

    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 😅

  20. rumax
    added a commit that references this issue on Oct 26, 2020

    Use fixed node for CI

    2106ee3

  21. rumax commented on Oct 26, 2020

    @rumax
    rumax
    on Oct 26, 2020

    Same issue on Circle CI with

    - image: circleci/node:latest

    Downgrading node to 14 fixes the issue

  22. rumax
    added a commit that references this issue on Oct 26, 2020

    Use fixed node for CI

    dd69bda

  23. strican commented on Oct 26, 2020

    @strican
    strican
    on Oct 26, 2020

    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?

  24. Yodablues commented on Oct 27, 2020

    @Yodablues
    Yodablues
    on Oct 27, 2020

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

  25. isaacs commented on Oct 28, 2020

    @isaacs
    isaacs
    on Oct 28, 2020
    Contributor

    @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

  26. npm
    locked as resolved and limited conversation to collaborators on Oct 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Bugthing that needs fixingRelease 7.xwork is associated with a specific npm 7 release

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions