You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
...
111 timing command:i Completed in 1071ms
112 verbose stack TypeError: Cannot read properties of null (reading 'package')
112 verbose stack at Link.set root [as root] (/Users/arimus/.nvm/versions/node/v16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/node.js:718:35)
112 verbose stack at Link.replace (/Users/arimus/.nvm/versions/node/v16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/node.js:1155:17)
112 verbose stack at PlaceDep.replaceOldDep (/Users/arimus/.nvm/versions/node/v16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/place-dep.js:426:17)
112 verbose stack at PlaceDep.placeInTree (/Users/arimus/.nvm/versions/node/v16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/place-dep.js:304:12)
112 verbose stack at PlaceDep.place (/Users/arimus/.nvm/versions/node/v16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/place-dep.js:214:10)
112 verbose stack at new PlaceDep (/Users/arimus/.nvm/versions/node/v16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/place-dep.js:71:10)
112 verbose stack at /Users/arimus/.nvm/versions/node/v16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:984:31
112 verbose stack at Array.map (<anonymous>)
112 verbose stack at Arborist.[buildDepStep] (/Users/arimus/.nvm/versions/node/v16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:984:8)
112 verbose stack at async Arborist.buildIdealTree (/Users/arimus/.nvm/versions/node/v16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:216:7)
113 verbose cwd /Users/arimus/workspace/appbuilder-backend
Environment
npm: 8.6.0+
Node.js: v16.13.1
OS Name: OSX
npm config:
; node bin location = /Users/arimus/.nvm/versions/node/v16.13.1/bin/node; cwd = /Users/arimus/workspace/appbuilder-backend; HOME = /Users/arimus; Run `npm config ls -l` to show all defaults.
This is frustrating because I can look at the log and find out the call stack, but it doesn't help me in fixing the problem. I accept that it's my error, but it would save many hours if there were more information about the source of the error.
In my case, I get Cannot read properties of null (reading 'package'). I'm using symbolic links, so there may be an inconsistency, but how can I find it? I can attach the log though I'm wary about posting specific info.
The line
37 verbose shrinkwrap failed to load node_modules/.package-lock.json missing from lockfile: ../mlib/node_modules/ansi-styles
hints at the problem but it works in other contexts
This problem is super frustrating. I'm trying to get the package updated upstream, so that I no longer have a local file dependency, but that is taking a long time as well. Kind of surprised that more folks haven't been having this issue, which would give it more attention.
Worth noting that I've been playing with pnpm recently, which does not have this issue and also has a lot of good features. However, I did find some local relative path dependencies inside my tarball dep. That forced me to adjust to regular npm repo deps and rebuild the tarball, but that was pretty easy. Generally speaking, I'd love to just use npm straight up, but I may bite the bullet and start using pnpm (with shamefully-hoist :P for the time being).
Happy to re-test this when things are fixed though.
@AnatuGreen Can you try to install the dependencies from a terminal that opened with Rosetta (if you're using MacBook with M1 chip)
use node v16.16.0
npm v8
I just encountered this issue with npm 10.1.0. I didn't try downgrading to 9.0.
This is the error
60 verbose stack TypeError: Cannot read properties of null (reading 'package')
In my case, I deleted `node_modules` and then tried what I was previously trying, and it worked.
If this does not resolve it, also deleting the package.lock.json resolves it, it seems also to be related by a package.lock.json that is not matching the current dependency tree in relation with symlinks
Thanks everyone for the reports. This issue has been collecting cases for ~4 years and is really an umbrella for several distinct bugs that all happen to surface the same error (target.package where target is null in Node.set root). Many of the specific scenarios have been fixed in recent npm 11.x releases, including:
I tried to reproduce the originally-reported scenarios on npm 11.12.1 (macOS) and could not trigger the crash with any of:
a project with a ./foo.tgzfile: dep, installed twice (the original repro)
nested file: deps several levels deep
workspaces with cross-workspace deps, with and without install-strategy=linked
npm linked packages in a workspace
For anyone still hitting this on 11.12.1 or newer, could you share a minimal reproduction? Specifically:
The package.json (and package-lock.json if present)
The node_modules/ layout right before the failing install — ls -la node_modules/ and any symlinks (find node_modules -maxdepth 3 -type l)
Full npm install --verbose output (or the _logs/*-debug-0.log)
OS + Node + npm versions
Whether the crash happens from a clean state (no node_modules/, no package-lock.json) or only after some prior install
Without a fresh-state repro, it's almost certainly a stale/inconsistent on-disk state where package-lock.json and node_modules have drifted (the rm -rf node_modules and rm package-lock.json workarounds that work for most people support this). If your case reproduces from a clean state on 11.12.1, that's a new bug worth a separate issue with a runnable repro.
Activity
BobFrankston commentedon Jun 12, 2022
This is frustrating because I can look at the log and find out the call stack, but it doesn't help me in fixing the problem. I accept that it's my error, but it would save many hours if there were more information about the source of the error.
In my case, I get
Cannot read properties of null (reading 'package'). I'm using symbolic links, so there may be an inconsistency, but how can I find it? I can attach the log though I'm wary about posting specific info.The line
hints at the problem but it works in other contexts
silentcloud commentedon Jun 13, 2022
+1
node 16.15.1
npm 8.11.0
lesliesu commentedon Jun 22, 2022
+1
node 16.13.2
npm 8.1.2
AlekhyaYalla commentedon Jul 13, 2022
Any update on this issue? I'm facing this issue
david-987 commentedon Jul 17, 2022
+1
npm cache clear --forcedoesn't work which is my go-to when npm bugs out.npm 8.1.4
node 16.14
Zakyyy commentedon Jul 19, 2022
same
jerinkalexander commentedon Jul 20, 2022
128 verbose node v16.15.1
129 verbose npm v8.14.0
130 error Cannot read properties of null (reading 'children')
131 verbose exit 1
Same here while running npm link.
andrey-helldar commentedon Jul 24, 2022
Node 16.16 and Npm 8.11 and 8.15 too
Show log
arimus commentedon Jul 26, 2022
This problem is super frustrating. I'm trying to get the package updated upstream, so that I no longer have a local file dependency, but that is taking a long time as well. Kind of surprised that more folks haven't been having this issue, which would give it more attention.
Worth noting that I've been playing with pnpm recently, which does not have this issue and also has a lot of good features. However, I did find some local relative path dependencies inside my tarball dep. That forced me to adjust to regular npm repo deps and rebuild the tarball, but that was pretty easy. Generally speaking, I'd love to just use npm straight up, but I may bite the bullet and start using pnpm (with shamefully-hoist :P for the time being).
Happy to re-test this when things are fixed though.
ajibadeabd commentedon Aug 1, 2022
downgrade your node to 16.0, npm to 7+. this workes for me
AnatuGreen commentedon Aug 15, 2022
Mine is this error:
npm ERR! Cannot read properties of null (reading 'children')I have even uninstalled Node and reinstalled it. Same issue
Zakyyy commentedon Aug 15, 2022
@AnatuGreen Can you try to install the dependencies from a terminal that opened with Rosetta (if you're using MacBook with M1 chip)
use node v16.16.0
npm v8
30 remaining items
mwe commentedon Jan 26, 2024
If this does not resolve it, also deleting the package.lock.json resolves it, it seems also to be related by a package.lock.json that is not matching the current dependency tree in relation with symlinks
boshoff commentedon Aug 5, 2024
Node.js: 20.12.1
npm: 10.8.2
OS: macOS 14.6
No luck, much easier to switch to pnpm.
yinsang commentedon Jul 17, 2025
Workspace mode may need to invoke this command.
manzoorwanijk commentedon Mar 28, 2026
Can someone please confirm if it's still an issue after npm v11.12.1?
We recently fixed many such issues in arborist.
bbrodbeck-memtime commentedon May 12, 2026
I have this issue with npm 11.12.1. I cannot update dependencies because of it.
manzoorwanijk commentedon May 12, 2026
Thanks everyone for the reports. This issue has been collecting cases for ~4 years and is really an umbrella for several distinct bugs that all happen to surface the same error (
target.packagewheretargetisnullinNode.set root). Many of the specific scenarios have been fixed in recent npm 11.x releases, including:npm install --workspacecrashes withinstall-strategy=linked#9038, fixed in fix: workspace-filtered install with linked strategy #9041)npm linkedge casesI tried to reproduce the originally-reported scenarios on npm 11.12.1 (macOS) and could not trigger the crash with any of:
./foo.tgzfile:dep, installed twice (the original repro)file:deps several levels deepinstall-strategy=linkednpm linked packages in a workspaceFor anyone still hitting this on 11.12.1 or newer, could you share a minimal reproduction? Specifically:
package.json(andpackage-lock.jsonif present)node_modules/layout right before the failing install —ls -la node_modules/and any symlinks (find node_modules -maxdepth 3 -type l)npm install --verboseoutput (or the_logs/*-debug-0.log)node_modules/, nopackage-lock.json) or only after some prior installWithout a fresh-state repro, it's almost certainly a stale/inconsistent on-disk state where
package-lock.jsonandnode_moduleshave drifted (therm -rf node_modulesandrm package-lock.jsonworkarounds that work for most people support this). If your case reproduces from a clean state on 11.12.1, that's a new bug worth a separate issue with a runnable repro.README: pnpm dlx registration lane (npx crashes in pnpm workspaces — n…
jendrikw commentedon Jul 15, 2026
I have a reproducer for this and/or #5222. This link is valid for one month: https://files.ptb-test.opndsk.de/s/r5xk6kYgYFqKtEM
Simply extract the tgz and run
npm i -D vite@8.1.4 && npm i -D @vitejs/devtools --verbose. This is my output:This is with npm and node installed via apt on a debian testing:
manzoorwanijk commentedon Jul 15, 2026
Did you try with npm v11.18?
Also, can you please create a GitHub repo for the code you want to share? It's hard to trust a compressed file.
fix(arborist): avoid crash when peer back-off detaches a node (npm#9770)
Launch the installed binary instead of npx; release 0.3.8