Repository navigation
[BUG] non-previosly seen peer-dependency errors popping up in 8.6.0 #4664
Copy link
Copy link
Closed
Labels
Bugthing that needs fixingthing that needs fixingDocumentationdocumentation related issuedocumentation related issueRelease 8.xwork is associated with a specific npm 8 releasework is associated with a specific npm 8 release
Description
Is there an existing issue for this?
- I have searched the existing issues
This issue exists in the latest npm version
- I am using the latest npm
Current Behavior
After upgrading from 8.5.5 to 8.6.0 I'm starting to get peer dependency issues that are not present when running under 8.5.5.
I don't see anything apparent in https://github.com/npm/cli/blob/latest/CHANGELOG.md#v860-2022-03-31 to account for this change. While it's possible these errors were present before, but hidden; the lack of changelog entry to account for this speaks against that.
$ npm i -g npm@8.5.5
changed 14 packages, and audited 201 packages in 1s
10 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
$ npm i
up to date, audited 1180 packages in 2s
130 packages are looking for funding
run `npm fund` for details
4 vulnerabilities (2 moderate, 2 high)
To address all issues, run:
npm audit fix
Run `npm audit` for details.
$ npm i -g npm@8.6.0
changed 30 packages, and audited 201 packages in 1s
10 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
$ npm i
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: @shiftcoders/dynamo-easy@7.1.0
npm ERR! Found: tslib@2.3.0
npm ERR! node_modules/tslib
npm ERR! tslib@"^2.1.0" from the root project
npm ERR! tslib@"^2.0.0" from @aws-sdk/abort-controller@3.20.0
npm ERR! node_modules/@aws-sdk/abort-controller
npm ERR! @aws-sdk/abort-controller@"3.20.0" from @aws-sdk/node-http-handler@3.21.0
npm ERR! node_modules/@aws-sdk/node-http-handler
npm ERR! @aws-sdk/node-http-handler@"3.21.0" from @aws-sdk/client-sso@3.21.0
npm ERR! node_modules/@aws-sdk/client-sso
npm ERR! @aws-sdk/client-sso@"3.21.0" from @aws-sdk/credential-provider-sso@3.21.0
npm ERR! node_modules/@aws-sdk/credential-provider-sso
npm ERR! 1 more (@aws-sdk/client-sts)
npm ERR! 46 more (@aws-sdk/client-sso, @aws-sdk/client-sts, ...)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer tslib@"^1.10.0" from @shiftcoders/dynamo-easy@7.1.0
npm ERR! node_modules/@shiftcoders/dynamo-easy
npm ERR! dev @shiftcoders/dynamo-easy@"^7.1.0" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: tslib@1.14.1
npm ERR! node_modules/tslib
npm ERR! peer tslib@"^1.10.0" from @shiftcoders/dynamo-easy@7.1.0
npm ERR! node_modules/@shiftcoders/dynamo-easy
npm ERR! dev @shiftcoders/dynamo-easy@"^7.1.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 /home/azatoth/.npm/eresolve-report.txt for a full report.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/azatoth/.npm/_logs/2022-04-01T10_02_06_637Z-debug-0.log
Expected Behavior
I expect 8.6.0 to not error out on these peer-dependency issues.
Steps To Reproduce
No response
Environment
- npm: 8.6.0
- Node.js: v14.19.0
- OS Name: Ubuntu 21.10
- System Model Name:
- npm config:
; "user" config from /home/azatoth/.npmrc
//npm.pkg.github.com/:_authToken = (protected)
//registry.npmjs.org/:_authToken = (protected)
; "project" config from /home/azatoth/Project/(protected)/.npmrc
@(protected):registry = "https://npm.pkg.github.com/"
; node bin location = /home/azatoth/.nvm/versions/node/v14.19.0/bin/node
; cwd = /home/azatoth/Project/(protected)
; HOME = /home/azatoth
; Run `npm config ls -l` to show all defaults.Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Bugthing that needs fixingthing that needs fixingDocumentationdocumentation related issuedocumentation related issueRelease 8.xwork is associated with a specific npm 8 releasework is associated with a specific npm 8 release
Activity
jeroennoten commentedon Apr 1, 2022
Same problem here. No problems on 8.5.5, errors regarding peer dependencies on 8.6.0.
piccit commentedon Apr 1, 2022
I'm seeing this problem too but it's when running
npm ci(after having installed some specific packages using--legacy-peer-deps)aldeed commentedon Apr 1, 2022
To be clear about how big this bug is, everybody with a CI step that does
npm i -g npm && npm i(ornpm ci), that step is now suddenly erring (assuming they have ever previously ignored peer dep errors, which most projects have). The workaround is to pin to npm@8.5.5 but to prevent opening the floodgates of confusion you may want to fix or revert ASAP.johanholmerin commentedon Apr 1, 2022
Git bisect shows it to be caused by bd96ae4. Reproduction at johanholmerin/npm-4664
neogibson commentedon Apr 1, 2022
Yup we are seeing the same error in our CI with 8.6.0, reverting to 8.5.5 works for now though.
docs(ci): add note that configuration must be consistent between inst…
ruyadorno commentedon Apr 1, 2022
hi @johanholmerin thanks so much for taking the time to bisect and sending a reproduction, super handy and we super appreciate it! ❤️
It looks like what most folks here are seeing here is a legitimate
ERESOLVEerror (which began throwing as of v7) that got stored to the lockfile via using eithernpm i --forceornpm i --legacy-peer-depsto generate that file. This should have always been an error and the fix included in v8.6.0 is actually just surfacing these problems in the context ofnpm ci.I apologize for the extra churn this fix seems to be inflicting in some users, we're taking the extra steps of specifically documenting that in the
npm cihelp page, ref: #4666How to fix it:
In your project folder, run:
npm config set legacy-peer-deps=true --location=projectThen
npm cishould be able to install your project again without errors.docs(ci): add note that configuration must be consistent between inst…
wSedlacek commentedon Apr 2, 2022
So just to confirm it is not expected behavior to have installs done with
--forceto continue working on future installs without--force?piccit commentedon Apr 4, 2022
I understand what you're saying here, but why is a
cidoing that validation and not just using what is in the lockfile?jakeonfire commentedon Apr 4, 2022
@ruyadorno running
npm config set legacy-peer-deps=true --location=projectdoes indeed fixnpm installbut does not fixbin/webpack(which results in a stream of errors about not being able to resolve aliased packages likereactandreact-dom). any ideas? we are usingpreactandaliasifyif that is relevant...nlf commentedon Apr 7, 2022
correct.
the root cause of this is that the package tree as described in your
package-lock.jsonis invalid. previously, we did no validation and simply installed what yourpackage-lock.jsontold us to install. doing this, however, was very bad as it produced broken or otherwise incorrect trees (i.e. overrides not being applied, changes from the package.json not being detected, etc).we added a step that validates that your
package-lock.jsonis even correct before we will install it to disk, this helps us detect these problems before they cause problems for our users. we do not plan to restore the behavior of installing whatever was in thepackage-lock.jsonwithout validation, as it causes more harm than good.can you open a new issue for us with reproduction steps? we can take a look and see if this is a problem npm is creating for you there.
4 remaining items
lukekarrys commentedon Apr 13, 2022
@wjaspers that looks very similar to #3666. Does that issue look the same as yours? If not, opening a new issue with reproductions steps would be the best way for us to help.
lukekarrys commentedon Apr 13, 2022
If anyone else is having related issues, please open a new issue so we can triage as I think we've gotten to the bottom of this one.
AndreasA commentedon Apr 13, 2022
@lukekarrys #3666 is an issue since 7.x I think. This is new with
8.6.0as mentioned above, the user was able to install everything fine with 8.5.x but since 8.6.0 this error occurs.not really sure how that could be related to #3666 as that ticket is way older?
I just ran into a similar issue with Shopware 6.4.10.0 and their build-administration script but that might be an issue on their end but it was working with 8.5 as well.
domeq commentedon Apr 15, 2022
@lukekarrys This is a new bug as @AndreasA is saying above and IMHO it's a serious one.
Simplest case to reproduce it:
Start in an empty directory with NPM 8.5.0 installed.
Do
npm i react react-apollo-hooks@0.5.0.react-apollo-hookshas"react": "^16.8.0"in its peer deps so react 16 gets installed even though there's now react 18 available.Now try updating react:
npm i react@17.This prints nice warnings, but the update happens and the version gets bumped in
package.json.Now during build/deploy you obviously run
npm installornpm ci:As mentioned above:
it would make sense to show warnings about peer conflicts in
package.jsonduringnpm installsame way NPM does during package update, but suddenly starting to fail entirenpm installis a very controversial change for a minor release.AndreasA commentedon Apr 15, 2022
There was a similar issue with 8.4.0 as the behavior regarding
npm cichanged. It suddenly failed ifpackage-lock.json and package.json were not perfectly in synch.Which I think is good to do and I actually had expected to be the case for quite some time. Hhowever, as it changed the behavior (potential failings CIs) it should not have happened in a minor version.
Any changes that are potentially breaking which this one is and the one from 8.4.0 should only occur in a major release because then people expect things to potentially break.
Also if I understand it correctly, this issue happens because peer dependencies are not updated, if a dependency is updated?
If so, isn't this also an issue with NPM because it should already fail the update in such a scenario. And maybe add an option to update the dependency and its peer dependencies. Similar to composer with
--update-with-dependenciesand--update-with-all-dependencies. and it fails to update a dependency if the peer dependencies would need to be updated but aren't (either by specifying them or by using the corresponding option)avegancafe commentedon May 24, 2022
Sorry to rehash this issue still, but what's the actual suggested solution for this? Always use
npm install --forceif someone that didn't know the implications of that happened to be upgrading or installing a package and saw that as a suggested recommended solution to their problem in the CLI? @domeq 's example seems pretty common, and doesn't even involve using--forceMoltenCoffee commentedon May 24, 2022
I think most can be resolved using the
overridesoption in your package fileUse newest version of reloaddk/stylelint
Use newest version of reloaddk/stylelint
Use newest version of reloaddk/stylelint
fritzy commentedon Jun 30, 2022
I have created a pinned issue summarizing this discussion as well as #4998.
See the please refer to the pinned issue, #5113