Open minecrawler opened 2 years ago
Specific steps to reproduce:
git clone git@github.com:oguimbal/pgsql-ast-parser.git
cd pgsql-ast-parser
npm i; npm run build # this makes a dist build with a `package.json` in ./lib
cd ..
mkdir npm-cli-issue-5007-repro
cd npm-cli-issue-5007-repro
npm init -y
npm i -S pg-mem ../pgsql-ast-parser/lib
... then edit package.json
to insert this:
"overrides": {
"pg-mem": {
"pgsql-ast-parser": "$pgsql-ast-parser"
}
}
... then:
npm i
npm i # yes, again
The second (and any subsequent) npm i
execution fails as shown above. Specifically, the unsetFlag
node visitor encounters this node which has target: null
:
ArboristLink {
name: 'pgsql-ast-parser',
packageName: 'lib',
location: 'node_modules/pg-mem/node_modules/pgsql-ast-parser',
path: '/Users/gthb/git/npm-cli-issue-5007-repro/node_modules/pg-mem/node_modules/pgsql-ast-parser',
realpath: '/Users/gthb/git/npm-cli-issue-5007-repro/node_modules/pgsql-ast-parser/lib',
resolved: 'file:../../pgsql-ast-parser/lib',
dev: true,
optional: true,
overrides: Map(2) { 'pgsql-ast-parser' => '$pgsql-ast-parser', 'pg-mem' => '' },
edgesIn: Set(1) { { node_modules/pg-mem prod pgsql-ast-parser@^10.5.2 } },
target: null
}
There seems to be a lot going wrong there :-) ... (not all of it necessarily relevant to this bug, but some of it for sure):
packageName
is 'lib'
, presumably the last path element of the path I specified ... but that lib
folder contains a package.json
with "name": "pgsql-ast-parser"
— should that not be the packageName
value?location
is 'node_modules/pg-mem/node_modules/pgsql-ast-parser'
and that path does exist ... but it's a symlink pointing to ../../pgsql-ast-parser/lib
which resolves to node_modules/pgsql-ast-parser/lib
realpath
is '/Users/gthb/git/npm-cli-issue-5007-repro/node_modules/pgsql-ast-parser/lib'
node_modules/pgsql-ast-parser
is populated out of the lib
folder, it doesn't contain a lib
folder.dev
and optional
are true, but both this project's dependency, and pg-mem
's dependency, on pgsql-ast-parser
, are not dev dependencies and not optional.overrides
contains a second entry 'pg-mem' => ''
... what's that about? (Maybe it does make sense for some internal reason, or maybe it's part of the problem)target
is null
(maybe because of that broken symlink?), while unsetFlag
evidently assumes it can't be nullThe package-lock.json
file contains:
"node_modules/pg-mem/node_modules/pgsql-ast-parser": {
"resolved": "node_modules/pgsql-ast-parser/lib",
"link": true
},
and if I manually change that "resolved"
attribute to replace node_modules/
with ../
:
"node_modules/pg-mem/node_modules/pgsql-ast-parser": {
"resolved": "../pgsql-ast-parser/lib",
"link": true
},
then the next npm i
invocation completes without (reported errors):
changed 1 package, and audited 245 packages in 1s
8 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
... but it changes the package-lock.json
back, undoing my manual change, so if I run npm i
again, it fails like before.
Running into this exact issue as well, trying to install Jest.
42 verbose stack TypeError: Cannot set properties of null (setting 'peer')
42 verbose stack at visit (C:\Users\<user>\AppData\Roaming\nvm\v16.15.1\node_modules\npm\node_modules\@npmcli\arborist\lib\calc-dep-flags.js:104:54)
42 verbose stack at visitNode (C:\Users\<user>\AppData\Roaming\nvm\v16.15.1\node_modules\npm\node_modules\treeverse\lib\depth-descent.js:58:25)
42 verbose stack at next (C:\Users\<user>\AppData\Roaming\nvm\v16.15.1\node_modules\npm\node_modules\treeverse\lib\depth-descent.js:44:19)
42 verbose stack at depth (C:\Users\<user>\AppData\Roaming\nvm\v16.15.1\node_modules\npm\node_modules\treeverse\lib\depth-descent.js:83:10)
42 verbose stack at depth (C:\Users\<user>\AppData\Roaming\nvm\v16.15.1\node_modules\npm\node_modules\treeverse\lib\depth.js:27:12)
42 verbose stack at unsetFlag (C:\Users\<user>\AppData\Roaming\nvm\v16.15.1\node_modules\npm\node_modules\@npmcli\arborist\lib\calc-dep-flags.js:99:5)
42 verbose stack at C:\Users\<user>\AppData\Roaming\nvm\v16.15.1\node_modules\npm\node_modules\@npmcli\arborist\lib\calc-dep-flags.js:65:7
42 verbose stack at Map.forEach (<anonymous>)
42 verbose stack at calcDepFlagsStep (C:\Users\<user>\AppData\Roaming\nvm\v16.15.1\node_modules\npm\node_modules\@npmcli\arborist\lib\calc-dep-flags.js:41:17)
42 verbose stack at visit (C:\Users\<user>\AppData\Roaming\nvm\v16.15.1\node_modules\npm\node_modules\@npmcli\arborist\lib\calc-dep-flags.js:12:20)
Node 16.15.1 (latest LTS at the time of writing) NPM 8.13.2 (latest at the time of writing)
The problem only seems to occur for me in a project with workspaces. Doesn't matter if I execute an install from the main package.json directory, or from any of the individual workspaces. However, MUCH MUCH WORSE is that just executing a straight npm i
also breaks with this issue. So installing packages is not only broken for Jest, but is now completely knackered.
This desperately requires a solution.
In a project without workspaces set up, it works fine for me, but I can't just willy-nilly remove the workspaces feature from our projects for obvious reasons.
Edit: same results with NPM 8.11 and 8.10, so this bug has existed for at least a while. This should give it elevated priority to get it fixed, since downgrading NPM is unrealistic.
For me the node where it breaks:
ArboristLink {
name: 'renewi-campaign',
version: '2.0.0',
location: 'node_modules/renewi-campaign',
path: 'C:\\Projects\\Renewi\\src\\VGW.Web\\Frontend\\node_modules\\renewi-campaign',
realpath: 'c:\\Projects\\Renewi\\src\\VGW.Web\\Frontend\\Campaign',
resolved: 'file:../Campaign',
dev: true,
optional: true,
isWorkspace: true,
edgesIn: Set(1) {
{ "" workspace renewi-campaign@file:C:\Projects\Renewi\src\VGW.Web\Frontend\Campaign }
},
target: null
}
path
and realpath
both exist.dev
and optional
to be true. This is a workspace, not a depedency.target
is null.I tried to monkey-patch the offending package by inserting various defenses to get node.target
to be not null, but it always results in other errors indicating to missing or incorrect values within the target
object (I have no way of knowing what it expects of course).
Here's a workaround so that at least we can get back to work. In the arborist
package, I've made these changes in the calc-dep-flags.js
file:
@@ -30,7 +30,7 @@ const calcDepFlagsStep = (node) => {
resetParents(node, 'optional')
// for links, map their hierarchy appropriately
- if (node.isLink) {
+ if (node.isLink && node.target) {
node.target.dev = node.dev
node.target.optional = node.optional
node.target.devOptional = node.devOptional
@@ -100,11 +100,11 @@ const unsetFlag = (node, flag) => {
tree: node,
visit: node => {
node.extraneous = node[flag] = false
- if (node.isLink) {
+ if (node.isLink && node.target) {
node.target.extraneous = node.target[flag] = false
}
},
- getChildren: node => [...node.target.edgesOut.values()]
+ getChildren: node => [...(node.target?.edgesOut.values() ?? [])]
.filter(edge => edge.to && edge.to[flag] &&
(flag !== 'peer' && edge.type === 'peer' || edge.type === 'prod'))
.map(edge => edge.to),
This makes installs go without errors, but of course I don't know if this is the right way to go. The root cause is the fact that target
is null, or the fact that target is assumed (blindly, might I add) to be an object.
running into this again and it's a big problem.
What is the status of implementing a fix?
This bug is even still in triage, so no fix in sight :(
I've been running into this now too.
We also have workspaces (single package-lock.json
). This seems to work in linux (WSL more specifically) but not on windows.
I've tested on versions 8.15.0 and 8.11.0, both are broken.
I reinstalled node and still had the same issue. Only once I deleted C:\Users\<user>\AppData\Local\npm-cache
was I able to install my packages.
I'm not saying this is the right thing to do, or that anyone should do it. I'm not entirely sure what the side effects might be.
Still the same. A new version has been released since I posted my diff with a fix, and it appears it hasn't been included. The bug still exists.
Let me reiterate how severe this is: we cannot install, update, or uninstall anything. We cannot even do an audit fix
which is super important to be able to do!!
This DESPERATELY needs a proper fix.
Who can we tag to escalate this issue to critical/blocking priority?
It seems that a lot of bugs remain in triage for a very long time (up to 10 months as far as I saw) while other issues are removed from triage within hours. Even when we are not in triage anymore I don't think that would guarantee a fast resolution. Especially since there are only a few people affected while millions don't have the bug.
So, I am not sure what the best way is with such a long bug tracker....
My solution is to change my workflow so I don't have to use NPM (or other package managers) anymore for the case in which I triggered the bug. It's even better / faster without NPM, so I'm not sad to have dropped it. It's not something everyone can do, though.
I'd rather not go with a workaround. Besides, the number of people complaining is far smaller than the number of people affected. And if everyone would go with a workaround, NPM would not have any incentive to fix the bug. This would lead to hackery "solutions", like we've already seen way too many of in other fields of tech.
The bug is provable, demonstrable, repeatable, persistent, and totally cripples NPM. It could potentially affect millions of people, because there seem to be several kinds of setups that may be a cause for this bug. I honestly don't see why this isn't enough to get someone to fix it properly, and release it within a week or so. There's no shame in having to perform a hotfix release, but there is definitely a lot more shame in letting crippling bugs linger.
Ran in to this on NPM 8.13.2 after manually editing the package.json
to change a remote dependency to use a local version instead (I changed "dep": "1.2.3"
to "dep": "file:..."
) as well as manually bumping a few other package versions, then running npm i
. Removing the 3 dependencies that I made local from my package.json
manually, then installing them using npm i
fixed the issue.
Here's the error log I got:
2022-07-29T14_26_46_259Z-debug-0.log
Seems like the problem is actually in the package-lock.json file - when I revert my changes in package-lock after the first install of the new package, it installs again. I didn't have to remove node_modules.
Seems like the problem is actually in the package-lock.json file - when I revert my changes in package-lock after the first install of the new package, it installs again. I didn't have to remove node_modules.
That's great, but when never having manually edited the package-lock, it should not cause any runtime errors like this. There for I would consider a manual edit of the package-lock to be a workaround, not a solution.
Seems like the problem is actually in the package-lock.json file - when I revert my changes in package-lock after the first install of the new package, it installs again. I didn't have to remove node_modules.
That's great, but when never having manually edited the package-lock, it should not cause any runtime errors like this. There for I would consider a manual edit of the package-lock to be a workaround, not a solution.
Yup I agree with you 100% - just wanted to provide more details in case anyone knew how to fix it
NPM devs - just ran into this again with the latest npm (8.19.2) that comes with Node.js 16.18.0.
Can we please get an explanation of why this isn't bloody fixed yet? This issue BREAKS NPM ENTIRELY in these scenarios, how does that not give this issue highest possible priority?!
Sorry about the tone of voice, but I'm sure you can understand why I'm getting a little bit cross on the appalling amount of progress being made.
Oy! Any and all NPM devs!
Why do you keep releasing new versions of NPM without fixing this issues that COMPLETELY BREAKS NPM.
It's been way too long since this issue got reported, and it hasn't recieved the priority it deserves. Can you tell I'm getting a bit cross? Of course I am. I feel like this issue is getting ignored on purpose.
This issue COMPLETELY AND UTTERLY BREAKS ALL NPM COMMANDS for certain codebases. How does this not get the utmost highest possible priority? Sorry guys/gals, but I would be deeply ashamed for a bug like this, and would probably drop everything and fix this before anything else gets done. I feel this is completely reasonable. Especially after FIVE BLOODY MONTHS of having this BLOCKING issue open without resolution.
But instead, the opposite happens. Explain yourselves please.
While all-caps shouting and “explain yourselves” is a little over the top 😊, the total silence here is discouraging.
I mean literally it is now discouraging me from putting in work to make a useful bug report for the new npm bug I've found, because here I extracted minimal steps to reproduce and summarized the specific things that are going wrong, and ... no response. For half a year. That puts quite the damper on people's drive to help out the project.
I think it's completely justified at this point. This is ridiculous.
first off, i'd like to thank the folks who exercised restraint when expressing their frustration here. i know it's difficult, but your efforts to help us understand this bug as well as the proposed fix above are extremely appreciated.
secondly, i would like to kindly remind folks that we are a very small team responsible for a large number of packages in a rapidly evolving code base. we do our best to triage issues as they come in, but due to the amount of issues we have as well developing new features and processes we often fall behind. while that unfortunately means that some issues do not receive the priority we would like, it does not mean that we are ignoring the issues or the people reporting them.
i'm working on related parts of arborist this week and plan to take a deeper look at this. bear with us a bit longer and we'll get this fixed.
@gthb your reproduction isn't working for me in npm@9, i actually get an unrelated error having to do with resolving the override in your example. i've fixed the unrelated error here and after that i'm still unable to make your reproduction work.
does anyone else have a step-by-step reproduction they can share? i'm not convinced the pull request linked above fixes this issue
@gthb your reproduction isn't working for me in npm@9
I took a look and yep, it reproduces with those instructions up to and including v8.15.1 but not in v8.16.0 onwards. I git-bisected my way to https://github.com/npm/cli/commit/050284d2abb6aa91a0f9ffad5b0c4f074e5dbf6d which is the commit that causes this to no longer reproduce (EDIT: with my particular repro instructions). Before that commit, npm i
changes the package-lock.json
this way:
--- package-lock-noproblem.json 2022-12-13 22:10:53
+++ package-lock.json 2022-12-13 22:36:34
@@ -1859,6 +1859,10 @@
}
}
},
+ "node_modules/pg-mem/node_modules/pgsql-ast-parser": {
+ "resolved": "node_modules/pgsql-ast-parser/lib",
+ "link": true
+ },
"node_modules/pg-pool": {
"version": "3.5.2",
"resolved": "https://registry.npmjs.org/pg-pool/-/pg-pool-3.5.2.tgz",
@@ -1904,6 +1908,7 @@
"resolved": "../pgsql-ast-parser/lib",
"link": true
},
+ "node_modules/pgsql-ast-parser/lib": {},
"node_modules/picomatch": {
"version": "2.3.1",
"resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz",
@@ -3957,6 +3962,11 @@
"moment": "^2.27.0",
"object-hash": "^2.0.3",
"pgsql-ast-parser": "file:../pgsql-ast-parser/lib"
+ },
+ "dependencies": {
+ "pgsql-ast-parser": {
+ "version": "file:node_modules/pgsql-ast-parser/lib"
+ }
}
},
"pg-pool": {
after which the next npm i
will fail as described in the repro instructions.
But it's important to note that once package-lock.json
is poisoned in this way, the problem will persist, i.e. newer versions of npm will not fix it. They just won't introduce it in a package-lock.json
that doesn't already have the problem. So if I nuke my package-lock.json
(or copy the OK version back over it like I did in my bisecting expedition here), then the problem is gone (at least as manifested in my repro case). But versions v8.15.1 and earlier will reintroduce it.
So, others who are still experiencing this in npm versions v8.16.0 and newer (e.g. @thany), do you get it also with a package-lock.json
generated from scratch? Or only with one that already has the problem?
Hi @gthb,
Unfortunately I do still have the problem running npm 9.2.0. I recently had to wipe my package-lock (which already had this problem for a long time) and so I got to test out your theory. I deleted my package-lock files (these were at several places in the monorepo - I deleted all of them through a recursive search). I also removed any node_modules folders. Then I went back to the top of the mono repo and ran a fresh install. Then, I ran an install just in the workspace of one package, and was presented with our old familiar error:
npm ERR! Cannot set properties of null (setting 'dev')
I have a totally brand new package-lock that's a whole major version upgraded, so the package-lock very much changed in a significant way, however, I'm still getting the same error.
Let me know if there's any info I can provide to help with diagnosing the issue.
Yeah, to be clear, the particular way to reproduce this that I wrote up above appears to have gone away in v8.16.0. For sure there may be other ways to reproduce it, as the error being reported is quite a low-level internal one. I bet it would be useful to our npm friends (I'm just some passer-by like you) if you could extract a minimal way to reproduce it, from your case, like I did from mine.
Ah I see understood. OK I should have some time to put that together next week. Thanks for clarifying.
This and similar Cannot set property '{something}' of null
issues when using workspaces may be fixed by a PR I've just opened: https://github.com/npm/cli/pull/6193
The PR was to fix another specific issue I was having, but the underlying bug it fixes may prevent the package being resolved as null
in other places.
@ixalon
Looks like this fix made it into 9.6.0 which I have installed. Still getting the Cannot set properties of null (setting 'peer')
error.
Based on the error message, node.target on line 104 of calc-dep-flags.js is null. https://github.com/npm/cli/blob/latest/workspaces/arborist/lib/calc-dep-flags.js#L104
Just for kicks, I kept adding sanity checks until the thing eventually installed.
calc-dep-flags.js line 15
getChildren: (node, tree) => {
if (!tree?.edgesOut) return []; // ADDED
return [...tree.edgesOut.values()].map(edge => edge.to);
}
calc-dep-flags.js line 21
const calcDepFlagsStep = (node) => {
if (!node.target) return; // ADDED
node.js line 1105
matches (node) {
if (!node) return false; // ADDED
diff.js line 74
getChildren: node => {
node = node.target
if (!node) return []; // ADDED
At what cost? Who knows. Everything seems to work ok.
Hopefully this gives you an idea of how this error is propagating through the code.
Just ran into this again today, so am very interested in better diagnostics so I can figure out what is happening.
I'm running npm 9.5.0 in both windows and WSL (Linux) and npm install Express @types/express fails in Windows with the peer message but works in WSL.
@Giwayume - what OS were you using?
Windows 10 64 bit, running commands in CMD.
try the same command in wsl in the same directory
I can't do that, I use virtual box and wsl causes irreversable damage to virtualbox if it's enabled once.
@ixalon This is still not resolved, unfortunately. Looks like your fix was published in npm@9.6.0
. I'm currently running npm@9.6.1
and still experiencing this issue. It does appear to be related to workspaces, however.
Looks like there was a nefarious node_modules
that was nested inside a sub-package. Removing that still errors out, but at least now I get Cannot read properties of null (reading 'edgesOut')
.
Still seeing this error for 9.6.3
a workaround for now to get things moving in our project is to use pnpm publish
instead. But would be nice to use npm
directly.
the same issue npm v9.6.4 node v18.15.0 monorepo
The npm command is run from the command line of Windows v10 x64:
npm install npm ERR! Cannot set properties of null (setting 'peer')
what helps: not convenient but removing all node_modules folders from monorepo and npm install
I made an attempt to trace down the source of the problem, but not knowing much about the structure of the code, there is only so much I can do in a finite time. Somewhere the value of node.target (in link.js?) is being set to null or not being set. It's the latter that is the most difficult to isolate.
I usually find a workaround, but what I really need is to find out where node.target is not getting set yet is still being used.
I just posted this on a Microsoft discussion. It may give a clue to what may be going on though probably not in itself. Even then it indicates another nasty problem that has no easy solutions.
...
I just figured out a nasty problem with WSL, but I don't have an answer.
Windows and Linux have fundamentally different take on symbolic links.
Windows has both junctions and symlinks (SYMLINKD). If I create a symbolic link in Linux, it is turned into a relative SYMLINKD. This is OK as long as I'm in the same directory but if I'm in node and install a link to another module, the SYMLINKD fails because it is in the wrong context!
npm creates JUNCTIONS (absolute pointers) when run in Windows, but because it uses links in Linux, they become SYMLINKD in Windows and fail when evaluated in the wrong context with very nonobvious error messages.
So I tried to be smart and create an absolute /mnt... link in Linux and it created a JUNCTION in Windows to "...." which obviously didn't work.
JUNCTIONS have their own problems (I need to write about the wormhole bug I ran into due to them) but at least I can create tools if I move directories). But the SYMLINKD problem is harder to work around because I sometimes need to use WSL NPM when npm fails in Windows (which may be due to the problem I'm working around).
This a textbook case of an impedance mismatch that is hard to work around without modifying the semantics of the file systems. And, even then, who knows what implicit dependencies are strewn around.
To be clear this is absolutely not a Windows or WSL specific issue and has nothing to do with symlinks or npm link.
This error occurs in all environments including plain Linux and without any symlinks involved. It's to do with npm getting confused whilst loading the package tree - especially in a monorepo (workspaces), but it can also happen without workspaces.
You're probably right. But it is an issue that is difficult to solve so I may report it on its own
pnpm
8.10.0 now uses @npmcli/arborist
so this bug also affects pnpm users. In Vite, our publishing step is failing due to this error . It fails locally running npm pack
or pnpm pack
in packages/vite
. Within that directory, I can also reproduce by simply running this:
import Arborist from '@npmcli/arborist'
const a = new Arborist()
await a.loadActual()
I don't understand what the right fix is, but I'm able to workaround the issue by wrapping this part with a if (root !== this) {}
: https://github.com/npm/cli/blob/11e3c415260a93c2fe0fc012ecd572f304de30c7/workspaces/arborist/lib/node.js#L581-L585
Because it seems that when this part below kicks in, it does not re-set the _target
anymore:
Vue is facing this issue, too. But I'm not sure if it's our fault or npm's. Because the direct cause is a circular dependency:
https://github.com/vuejs/core/blob/9ca468c68bb1b84ce3ab5b4bedcabad3c2a7b618/packages/server-renderer/package.json#L34-L36
https://github.com/vuejs/core/blob/9ca468c68bb1b84ce3ab5b4bedcabad3c2a7b618/packages/vue/package.json#L98-L104
@vue/server-renderer
depends on vue
as a peer dependency, while vue
depends on @vue/server-renderer
as a direct dependency. After removing this circular dependency, the error's gone.
I am experiencing this issue with npm pack
and on an npm install
when i have a package lock and a node_modules folder.
The package json contains file dependencies { dependencies : { "mymodule": "file:.." }}
resulting in junction folders.
I have debugged the aborist code and the node that it visiting and throwing on is access to an arborist Link class. When the link class is constructed, the target property is set. Somewhere in the code the Link.target
is set to null, i am not able to find where that happens and why.
Deleting the node_modules resolves the problem, running an npm install a second time causes the error again
I see this issue in the project with links to two sibling modules one which has dependency on anyther
be-eslint-config
-> be-eslint-plugin
-> be-configs
mkdir diia
cd diia
# be-configs
git clone https://github.com/diia-open-source/be-configs
pushd be-configs
npm i
npm run build
npm test
npm link
popd
# be-eslint-plugin
git clone https://github.com/diia-open-source/be-eslint-plugin
pushd be-eslint-plugin
npm link @diia-inhouse/configs
npm i
npm run build
npm test
npm link
popd
# be-eslint-config
git clone https://github.com/diia-open-source/be-eslint-config
pushd be-eslint-config
npm link @diia-inhouse/configs @diia-inhouse/eslint-plugin
# Here you will run into https://github.com/npm/cli/issues/5007
npm i
ArboristLink which trigger this issue is following
ArboristLink {
name: '@diia-inhouse/configs',
version: '1.27.1',
location: '../be-eslint-plugin/node_modules/@diia-inhouse/configs',
path: 'D:\\d\\kant\\GitHub\\diia\\be-eslint-plugin\\node_modules\\@diia-inhouse\\configs',
realpath: 'D:\\d\\kant\\GitHub\\diia\\be-configs',
resolved: 'file:../../../be-configs',
dev: true,
optional: true,
peer: true,
edgesIn: Set(1) { { ../be-eslint-plugin dev @diia-inhouse/configs@^1.26.3 } },
target: null
}
node inspect
and setBreakpoint('build-ideal-tree.js', 204)
which is await this.#fixDepFlags()
exec('console.log(this.idealTree.edgesOut.get("@diia-inhouse/configs"))')
exec('console.log(this.idealTree.edgesOut.get("@diia-inhouse/eslint-plugin"))')
Results in
ArboristEdge {
name: '@diia-inhouse/configs',
spec: '1.26.3',
type: 'dev',
from: '',
to: 'node_modules/@diia-inhouse/configs',
error: 'INVALID'
}
ArboristEdge {
name: '@diia-inhouse/eslint-plugin',
spec: '1.6.0',
type: 'prod',
from: '',
to: 'node_modules/@diia-inhouse/eslint-plugin'
}
at the same time
exec('console.log(this.idealTree.children.get("@diia-inhouse/eslint-plugin").target.edgesOut.get("@diia-inhouse/configs"))')
results in
ArboristEdge {
name: '@diia-inhouse/configs',
spec: '^1.26.3',
type: 'dev',
from: '../be-eslint-plugin',
to: '../be-eslint-plugin/node_modules/@diia-inhouse/configs'
}
but
exec('console.log(this.idealTree.children.get("@diia-inhouse/configs"))')
results in
ArboristLink {
name: '@diia-inhouse/configs',
version: '1.27.1',
location: 'node_modules/@diia-inhouse/configs',
path: 'D:\\d\\kant\\GitHub\\diia\\be-eslint-config\\node_modules\\@diia-inhouse\\configs',
realpath: 'D:\\d\\kant\\GitHub\\diia\\be-configs',
resolved: 'file:../../../be-configs',
dev: true,
edgesIn: Set(1) { { "" dev @diia-inhouse/configs@1.26.3 INVALID } },
target: ArboristNode {
name: 'be-configs',
packageName: '@diia-inhouse/configs',
version: '1.27.1',
location: '../be-configs',
path: 'D:\\d\\kant\\GitHub\\diia\\be-configs',
dev: true,
edgesOut: Map(33) {
,,,,
}
....
}
Notice the difference in versions.
Thanks very much for the additional details. It's worth noting that when I use WSL to run the identical command in Linux it works. The caveat is that Linux creates symlinks which do not work when dynamically importing to another app, so I have to work around it by converting the symlinks to junctions.
I don't think it's solely an npm issue, but I've discovered a workaround for my workspace/monorepo setup.
We were declaring workspaces layout like this:
// root package.json
"workspaces": [
"./apps/**",
],
this **
glob pattern matches all subfolders of everything under apps/
. This includes possible nested node_modules/, which is our case.
a single *
solved the issue
// root package.json
"workspaces": [
"./apps/*",
],
If your use case truly requires matching all subfolders (e.g. apps/some-subfolder/my-nested-app
), then you'll likely need additional glob pattern entries to selectively include or exclude them as needed
It definitely isn't limited to workspaces with wildcards, though; we are seeing this in a monorepo where all the child projects are listed explicitly with no globs of any kind, neither **
nor *
.
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
I can only hit this particular error in a certain directory with a certain package, but I can reproduce it over several npm versions and it's 100% of the time.
There are more examples available in #3711 (the author refuses to reopen the bug even though it is not fixed and people are hitting it!).
After having a working npm for years and not changing the config, I just ran into it on npm v8.1.4. Upgraded to v8.5.4 and the problem did not go away. Here's the log with the latest version (8.12.1):
I redacted the user and package name as they are company internals. I use a company artifactory with npm registry. However, this has worked for me before and is working for thousands of our developers as we speak, so I think it's a local problem with my npm.
Expected Behavior
npm i <package>
installs the package successfullySteps To Reproduce
Environment
; "user" config from C:\Users\.npmrc
registry = ""
strict-ssl = false
; node bin location = C:\Program Files\nodejs\node.exe ; node version = v17.2.0 ; npm local prefix = C:\Users\\tmp
; npm version = 8.12.1
; cwd = C:\Users\\tmp
; HOME = C:\Users\
; Run
npm config ls -l
to show all defaults