Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
npx gitnexus crashes during the build:links phase of arborist rebuild, AFTER every package install + postinstall has already returned code: 0. Same node.target is null destructure failure as #8126, at rebuild.js:247 (line shifted vs the 2025 report at :238 but same #addToBuildSet function).
npm warn exec The following package was not found and will be installed: gitnexus@1.6.5
npm error Cannot destructure property 'package' of 'node.target' as it is null.
Verbose stack:
TypeError: Cannot destructure property 'package' of 'node.target' as it is null.
at #addToBuildSet (.../@npmcli/arborist/lib/arborist/rebuild.js:247:22)
at #buildQueues (.../@npmcli/arborist/lib/arborist/rebuild.js:175:40)
at #build (.../@npmcli/arborist/lib/arborist/rebuild.js:145:28)
at Arborist.rebuild (.../@npmcli/arborist/lib/arborist/rebuild.js:73:24)
at async #reifyPackages (.../@npmcli/arborist/lib/arborist/reify.js:322:11)
at async Arborist.reify (.../@npmcli/arborist/lib/arborist/reify.js:128:5)
at async .../libnpmexec/lib/with-lock.js:58:19
All package installs completed successfully before the crash:
info run @ladybugdb/core@0.16.1 install ... { code: 0 }
info run tree-sitter-c@0.21.4 install ... { code: 0 }
info run tree-sitter-cpp@0.23.2 install ... { code: 0 }
info run gitnexus@1.6.5 postinstall ... { code: 0 }
info run protobufjs@7.6.2 postinstall ... { code: 0 }
So the package is fully built on disk; only the bin-symlink step blows up.
Expected Behavior
npx gitnexus should symlink the gitnexus bin and execute it. node.target being null for a workspace/symlink target inside the build queue should be handled (skip / warn / fall through) rather than thrown.
The fix proposed in PR #7065 (null-guard in #addToBuildSet) appears to address exactly this and should be revisited.
Steps To Reproduce
# Any shell, no project state required
cd "$(mktemp -d)"
npx gitnexus --version
Crashes consistently with the error above. Installing the same package globally (npm i -g gitnexus@1.6.5) succeeds — the bug is specific to the npx/reify+rebuild path.
Workarounds
npm i -g gitnexus@1.6.5 (skips the failing rebuild path)
- Install via Homebrew / native package manager
Environment
; node bin location = /Users/alexscott/.hermes/node/bin/node
; node version = v22.22.3
; npm version = v11.16.0
; OS = Darwin 25.5.0 (macOS, Apple Silicon)
Suggested fix
Revisit PR #7065. The #addToBuildSet walk should not assume node.target.package exists — node.target can legitimately be null for some dependency shapes (this issue + #8126 are two independent packages hitting the same edge).
Is there an existing issue for this?
@eslint/cssupgraded out of the trigger structure, not because npm was fixed). PR fix(arborist):node.targetcan benull#7065 (fix(arborist): node.target can be null) was closed without being merged. Bug is still latent and reproducible on the latest npm.This issue exists in the latest npm version
Current Behavior
npx gitnexuscrashes during thebuild:linksphase of arboristrebuild, AFTER every package install + postinstall has already returnedcode: 0. Samenode.target is nulldestructure failure as #8126, atrebuild.js:247(line shifted vs the 2025 report at :238 but same#addToBuildSetfunction).Verbose stack:
All package installs completed successfully before the crash:
So the package is fully built on disk; only the bin-symlink step blows up.
Expected Behavior
npx gitnexusshould symlink thegitnexusbin and execute it.node.targetbeingnullfor a workspace/symlink target inside the build queue should be handled (skip / warn / fall through) rather than thrown.The fix proposed in PR #7065 (null-guard in
#addToBuildSet) appears to address exactly this and should be revisited.Steps To Reproduce
Crashes consistently with the error above. Installing the same package globally (
npm i -g gitnexus@1.6.5) succeeds — the bug is specific to thenpx/reify+rebuildpath.Workarounds
npm i -g gitnexus@1.6.5(skips the failing rebuild path)Environment
Suggested fix
Revisit PR #7065. The
#addToBuildSetwalk should not assumenode.target.packageexists —node.targetcan legitimately benullfor some dependency shapes (this issue + #8126 are two independent packages hitting the same edge).