[BUG] certain combinations of $ref overrides cause "ERR! Unable to resolve reference" from arborist #4395
Comments
|
that's a fun one.. thanks for all the work you put into figuring out the reproduction case, that's super helpful! |
|
closing #4409 as a dupe, but it references a shrinkwrap case specifically. It'll be worth referencing for this bug, and reopening if it turns out to be an independent issue. |
|
Experiencing the same issue, but with a private package source. I have the following overrides: "overrides": {
"luxon": "^1.21.3",
"@vlc/components": "$@vlc/components",
"@vlc/dialog": "$@vlc/dialog",
"@vlc/form": "$@vlc/form",
"@vlc/snackbar": "$@vlc/snackbar",
"@vlc/table": "$@vlc/table",
"formik-material-ui": "$formik-material-ui"
},These work for installing the first package that depends on older versions of all these packages. When installing the next package from the same repository as previous package (which actually only has the previous package as dependency) it errors on the first reference, if that's replaced it errors on the next reference and so on. Changing the references to version numbers works around the problem. I'm actually on npm 8.3.0, but my coworker just upgraded to 8.5.0 yesterday and notified me of the problem. I'm available to perform further diagnosis / share more information. |
|
And also, uninstalling package A and just installing package B (that depends on A only) leads to the same issue. |
The CRA template and smoke test starting failing again since the release of React 18.2.0, because the overrides are for react@^18.1.0 while the main React dependency injected by CRA is now react@^18.2.0.
There is a proper way to avoid this using:
```
"overrides": {
"react": "$react",
"react-dom": "$react-dom"
},
```
However, this is currently not working and results in this error:
```
npm ERR! Unable to resolve reference $react
```
At first I thought this was due to how CRA installs packages, but that doesn't actually seem to be the case; it may be due to npm/cli#4395
For now the only solution seems to be to manually keep it up-to-date, unfortunately (until either `$react` is working or all peer dependency ranges in our tree are good).
The CRA template and smoke test starting failing again since the release of React 18.2.0, because the overrides are for react@^18.1.0 while the main React dependency injected by CRA is now react@^18.2.0.
There is a proper way to avoid this using:
```
"overrides": {
"react": "$react",
"react-dom": "$react-dom"
},
```
However, this is currently not working and results in this error:
```
npm ERR! Unable to resolve reference $react
```
At first I thought this was due to how CRA installs packages, but that doesn't actually seem to be the case; it may be due to npm/cli#4395
For now the only solution seems to be to manually keep it up-to-date, unfortunately (until either `$react` is working or all peer dependency ranges in our tree are good).
… for overrides when we examine override references, if we look at only `this.from.root.package` the root could actually be a virtual one. in order to ensure we resolve references from the real root, we instead need to look at `this.from.sourceReference.root.package` to get the correct value. closes #4395
… for overrides (#5227) when we examine override references, if we look at only `this.from.root.package` the root could actually be a virtual one. in order to ensure we resolve references from the real root, we instead need to look at `this.from.sourceReference.root.package` to get the correct value. closes #4395
|
I am having the same issue with npm version "overrides": {
"webpack": "$webpack"
},which gives me
even though I have webpack in the |
|
same. problem started after deleting |
|
I'm encountering this on version 8.19.2. "Unable to resolve reference $react" despite React being present in my dependencies. |
|
Node v16.18.1, npm v8.19.2.
This is definitely something to do with private packages. Here's my reproduction package.json {
"name": "npm-error-repro",
"engines": {
"node": ">=16.13.0"
},
"scripts": {
"start": "rm -rf package-lock.json node_modules && npm i"
},
"dependencies": {
"@zenbusiness/react-testing": "^2.5.2",
"react": "^18.2.0",
"react-dom": "^18.2.0",
"react-router-dom": "^6.4.3"
},
"overrides": {
"react": "$react",
"react-dom": "$react-dom"
}
}
"dependencies": {
"@testing-library/dom": "^8.17.1",
"@testing-library/jest-dom": "^5.16.4",
"@testing-library/react": "^13.0.1",
"@testing-library/user-event": "^14.4.3",
"jest-extended": "^3.1.0",
"match-media-mock": "^0.1.1",
"waait": "^1.0.5",
"whatwg-fetch": "^3.6.2"
},
"peerDependencies": {
"prop-types": ">=15",
"react": ">=17",
"react-router-dom": ">=6"
},
I'd provide a production repo, but you'd need access to our private github registry to see it. Could somebody at NPM re-open this issue, or do I need to make a new one? |
And work around npm/cli#4395
|
I was having the same basic problem referencing a dependency which points to a local path. As a work around I had to do the following: To be honest, I am not really sure why this set of operations works, but I thought it might shed some light onto the root cause and/or help someone else get around the issue. |
|
EDIT: Last comment (THETCR commented on Jul 9) in related issue #5730 sounds like it could be the actual solution. I have npm 9.8.1 and have and in It worked fine until now, but when I just tried (1st step for migration from CRA to vite) I got this same error for Log file section: |
|
I have the same error: "devDependencies": {
"typescript": "^5.0.2"
},
"overrides": {
"typescript": "^typescript"
}Workaround for me is to use the "GOOD" approach for npm overrides by inlining the version: "devDependencies": {
"typescript": "^5.0.2"
},
"overrides": {
"typescript": "^5.0.2"
} |
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
If a project has a dependency on
"@types/node": "^16.0.0"and attempts to use an overrides entry for"@types/node": "$@types/node"to pin all references of@types/nodeto v16, and then also attempt to create a dependency on either thejestorjest-clipackages, arborist becomes confused and produces the following error message:(see repro steps below for stack trace from debug logs)
I was unable to work out why this specific combination of packages caused problems. Some of the findings from the unsuccessful theories I investigated include:
jest-config(including a minimal synthetic package, see repro steps), but does not repro withjest-configitself@types/nodedependencies (eg,@jest/core)jest-configdependencies with similar names instead of@types/node(eg,@jest/environment)$refExpected Behavior
npm shouldn't error out; it should install the
jestdependency correctly, with transitive dependencies on@types/nodeoverriden to match the directdependencyentry for@types/node.Steps To Reproduce
Relevant snippet of the debug log:
Environment
The text was updated successfully, but these errors were encountered: