Repository navigation
prebuild-install fails to determine target on Node 23.6.0 #203
Description
On the latest node (23.6.0), prebuild-install fails to install native packages that specify napi versions in the package.json (and maybe other configurations too) - prebuild-install reports a target of undefined. Ex:
$ npm i @mongodb-js/zstd
npm error code 127
npm error path /~/dev/mongoose/node_modules/@mongodb-js/zstd
npm error command failed
npm error command sh -c prebuild-install --runtime napi || npm run clean-install
npm error > @mongodb-js/[email protected] clean-install
npm error > npm run install-zstd && npm run compile
npm error
npm error
npm error > @mongodb-js/[email protected] install-zstd
npm error > bash etc/install-zstd.sh
npm error prebuild-install warn This package does not support N-API version undefined
npm error prebuild-install warn install No prebuilt binaries found (target=undefined runtime=napi arch=arm64 libc= platform=darwin)
npm error bash: etc/install-zstd.sh: No such file or directory
npm error A complete log of this run can be found in: /~/.npm/_logs/2025-01-13T16_59_21_577Z-debug-0.log(note: we realize that this package should be buildable from source, we plan to fix this separately).
Notice that the inferred target is undefined:
target=undefined runtime=napi arch=arm64 libc= platform=darwin)
This behavior is not present on Node versions <23.6.0.
The bug actually lies in napi-build-utils (I filed inspiredware/napi-build-utils#6 too) but that package seems long dead, so I'm filing an issue here as well.
The root cause is that 23.6.0 increased the napi version to 10, which breaks the logic in getBestNapiBuildVersion(), which uses string comparison instead of numeric comparison.
Activity
jschlight commentedon Jan 17, 2025
This issue should now be addressed in inspiredware/napi-build-utils
2.0.0.update Dockerfile to use node 22. Update child dependency prebuild-in…
t3chguy commentedon Feb 28, 2025
It also affects Node 22.14.0 LTS Jod
vweevers commentedon Feb 28, 2025
@t3chguy This has been fixed in 7.1.3. If you can still reproduce it then please open a new issue with details.
t3chguy commentedon Feb 28, 2025
I'm aware, unfortunately https://github.com/atom/node-keytar is archived and won't receive the fix.
Appreciate the fix but this caused major breakage that sows doubt in the ecosystem
element-hq/element-desktop#2161
vweevers commentedon Feb 28, 2025
keytar depends on
"prebuild-install": "^7.0.1"so that range includes the fixed version.t3chguy commentedon Feb 28, 2025
Its package-lock file would like to disagree
https://github.com/atom/node-keytar/blob/master/package-lock.json#L3336-L3338
https://github.com/atom/node-keytar/blob/master/package-lock.json#L2719-L2721
vweevers commentedon Feb 28, 2025
Lock files are not included in npm packages, so they don't apply here. They're only relevant on an application level.
t3chguy commentedon Feb 28, 2025
You're right.
Looks like the issue is down to
prebuildhaving the same bad dependency in v11 which node-keytar depends on. Actually it still depends on the same broken version https://github.com/prebuild/prebuild/blob/master/package.json#L32And I guess the wrong one is being resolved for whatever reason.
vweevers commentedon Feb 28, 2025
A pull request for
prebuildwould be welcome.t3chguy commentedon Feb 28, 2025
Wouldn't help node-keytar unless it was backported 2 major versions of
prebuild:Dvweevers commentedon Feb 28, 2025
Yes, you'd have to fork it. That's just the way it is.
node 23 (need Promise.withResolvers in tests)