I have been digging into an issue with a nan and prebuild based library that was throwing an error only when run in electron 11 serialport/node-serialport#2191

My conclusion is that electron v11.0.0-beta.11...v11.0.0-beta.12 is a breaking abi change and should have changed the abi version number. I haven't raised anything upstream, as I don't see anything they can do other than say to not use that version.

So to make everything happy, prebuild (and others?) need to build for electron 11 against v11.0.0-beta.12 or newer. As they get the version number from this library, it would be nice to fix it here, but I don't know how the data should be modelled, as a single version essentially needs to be ignored.

I don't get the version for electron 4.2.4. It shows 69 for 4.0.4.
How to find ourselves the abi for 4.2.4 or any other electron?

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

I'm pretty sure the wrong ABI was specified for Electron 3, and now that Electron 4 has rolled out, its ABI incorrectly matches Electron 3's, which is causing some issues with prebuilding.

Electron 3.0.0 uses electron/node v9.7.0-33-g538a5023af, which corresponds to Node 9.7.0, which has ABI version 59. But Electron 3 was, I believe erroneously, specified as ABI version 64.

Electron 4.0.0 uses electron/node 4d44266b78256449dd6ae86e419e3ec07257b569, which corresponds to Node 10.11.0, which has ABI version 64.

So now Electron 4.0.0 is correctly specified to have ABI version 64, but 3.0.0 incorrectly shows the same ABI version as 4.0.0, which is screwing up prebuild projects, because it thinks it can reuse Electron 3 binaries for Electron 4 (causing this, and maybe this).

problem

I am using level as my local db server ,when pack my electron app ,I got this error and could not fix it .
I tried using a different version of electron ,but still the same

 make: *** No rule to make target `Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/builder.o', needed by `Release/leveldb.a'.  Stop.
  Error: `make` failed with exit code: 2
  at ChildProcess.onExit (/Users/neptune/github/xxx/app/node_modules/node-gyp/lib/build.js:203:23)
  at ChildProcess.emit (node:events:513:28)
  at ChildProcess._handle.onexit (node:internal/child_process:291:12)

An unhandled rejection has occurred inside Forge:
Error: node-gyp failed to rebuild '/private/var/folders/v6/51277h6j2258m8yvl9rknkhr0000gp/T/electron-packager/darwin-arm64/nnk-24h-live-darwin-arm64-MeCAK9/Electron.app/Contents/Resources/app/node_modules/classic-level'
at ChildProcess.<anonymous> (/Users/neptune/github/xxx/app/node_modules/@electron/rebuild/lib/module-type/node-gyp/node-gyp.js:118:24)
    at ChildProcess.emit (node:events:513:28)
    at ChildProcess._handle.onexit (node:internal/child_process:291:12)

env

node version v18.15.0
electron abi 116
electron version v25.8.1
classic-level 1.3.0

deps

├── @electron-forge/[email protected]
├── @electron-forge/[email protected]
├── @electron-forge/[email protected]
├── @electron-forge/[email protected]
├── @electron-forge/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

https://nodejs.org/en/download/releases/
https://github.com/lgeiger/node-abi/pull/62/files#diff-168726dbe96b3ce427e7fedce31bb0bcR59

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch [email protected] for the project I'm working on.

Semver, the dependent of the node-abi package has CVE-2022-25883 vulnerability. After carefully comparing 7.3.5 and 7.5.3 versions of the semver, concluded on there is no code updates needed but only version of semver need to be updated for node-abi.

NPM Audit: GHSA-c2qf-rxjj-qqgw

Here is the diff that solved my problem:

diff --git a/node_modules/node-abi/package.json b/node_modules/node-abi/package.json
index 1f462bf..1bc9e4e 100644
--- a/node_modules/node-abi/package.json
+++ b/node_modules/node-abi/package.json
@@ -32,7 +32,7 @@
     "tape": "^5.3.1"
   },
   "dependencies": {
-    "semver": "^7.3.5"
+    "semver": "^7.5.3"
   },
   "engines": {
     "node": ">=10"

This issue body was partially generated by patch-package.

And are currently not yet in node-abi

Please support electron 8

An unhandled error occurred inside electron-rebuild
Could not detect abi for version 2.0.0-beta.1 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron

Error: Could not detect abi for version 2.0.0-beta.1 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron
    at Object.getAbi (/project/node_modules/node-abi/index.js:30:9)
    at new Rebuilder (/project/node_modules/electron-rebuild/lib/src/rebuild.js:64:28)
    at rebuildWithOptions (/project/node_modules/electron-rebuild/lib/src/rebuild.js:310:23)
    at Object.doRebuild [as rebuild] (/project/node_modules/electron-rebuild/lib/src/rebuild.js:317:16)
    at Object.<anonymous> (/project/node_modules/electron-rebuild/lib/src/cli.js:114:33)
    at Generator.next (<anonymous>)
    at /project/node_modules/electron-rebuild/lib/src/cli.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (/project/node_modules/electron-rebuild/lib/src/cli.js:4:12)
    at /project/node_modules/electron-rebuild/lib/src/cli.js:69:8
child_process.js:614
    throw err;

What's the way to fix this?

Getting the above error message. Is there a new electron version we need to cater to?

It seems strange that an addon that doesn't use any node headers other than node-api.h (including through napi.h) would have any ABI differences between Node and Electron?

The main thing I guess is that you can't guarantee that it is only using N-API, I myself have written a (test) N-API addon that uses uv.h to get at uv_{get,open}_osfhandle(), but then you can't guarantee it's using N-API at all.

I have just updated my electron version to 6.0.0. While rebuilding SQLite3 with electron-rebuild I am getting the following error.

An unhandled error occurred inside electron-rebuild
Could not detect abi for version 6.0.0 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron

Error: Could not detect abi for version 6.0.0 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron

I am able to rebuild the SQLite package using electron-builder. I am using npx electron-builder install-app-deps.

When upgrading to electron 25.1.1:

Could not detect abi for version 25.1.1 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron

The devDependency semantic-release was updated from 15.13.18 to 15.13.19.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

semantic-release is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

node-abi is incorrectly reporting an ABI version of 84 instead of 88 for Node v15. I assume #95 fixes this as well, but this should further emphasize the need to get that merged.

When using electron: "15.1.1", the process.modules.versions returns abi 98, but node-abi returns 89 for it still, which causes native modules rebuilds to fetch abi 89 builds and breaks those dependencies.

Is this an issue that would be remedied just from a new release?

Support Electron 9

Updating my electron dependency from v4.0.0-beta.11 to v4.0.0 triggered this error:

An unhandled error occurred inside electron-rebuild
Could not detect abi for version 4.0.0 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron

So I guess, the stable release of v4 needs to be added to node-abi.

If you are interested it might be good to move this to the prebuild org so we can all help out more easily :)

Hi 👋 Is there a tldr on the breaking changes between v3 and v2?
We rely on this pretty heavily in prebuild/prebuildify and would like to keep it up to date.

node-abi is a transitive dependency for a library I use. It depends on semver for which a vulnerability was recently fixed, which npm audit reports: GHSA-c2qf-rxjj-qqgw

It seems dependabot already updated the semver dependency in this project to include the fixes. Could you please release a new version with this dependency update? Thanks!

The registry does not show a 115 or 117 but (2) 116s. Is that correct?

Hello. We faced one problem after upgrade ours Electron app from version 11 to 12:

$ electron-rebuild --parallel --force --types prod,dev,optional --module-dir app
× Rebuild Failed

An unhandled error occurred inside electron-rebuild
Could not detect abi for version 12.0.0 and runtime electron. Updating "node-abi" might help solve this issue if it is a new release of electron

Error: Could not detect abi for version 12.0.0 and runtime electron. Updating "node-abi" might help solve this issue if it is a new release of electron
at Object.getAbi (D:\Users\max\Documents\work\post\PartPriem\offline_lk\node_modules\node-abi\index.js:30:9)
at Rebuilder.get ABI [as ABI] (D:\Users\max\Documents\work\post\PartPriem\offline_lk\node_modules\electron-rebuild\lib\src\rebuild.js:111:39)
at ModuleRebuilder.prebuildNativeModuleExists (D:\Users\max\Documents\work\post\PartPriem\offline_lk\node_modules\electron-rebuild\lib\src\module-rebuilder.js:129:146)
at Rebuilder.rebuildModuleAt (D:\Users\max\Documents\work\post\PartPriem\offline_lk\node_modules\electron-rebuild\lib\src\rebuild.js:170:35)
at async Promise.all (index 126)
at async Rebuilder.rebuild (D:\Users\max\Documents\work\post\PartPriem\offline_lk\node_modules\electron-rebuild\lib\src\rebuild.js:148:13)
at async D:\Users\max\Documents\work\post\PartPriem\offline_lk\node_modules\electron-rebuild\lib\src\cli.js:146:9
error Command failed with exit code 4294967295.

This error can be fixed when manually change abi_registry.json and replace target from "12.0.0-nightly.20201013" to "12.0.0"

We use Node-abi version 2.19.3. Upgrading to versions 2.20.0 and 2.21.0 has no effect

Could not detect abi for version 18.0.3 and runtime electron. Updating "node-abi" might help solve this issue if it is a new release of electron

After ensuring the new CI pipeline is up and running, let's switch the "master" branch over to "main". 🙂

Why node v8.0.0 in deprecatedTargets?

https://electronjs.org/blog/electron-3-0

Error: Could not detect abi for version 4.1.0 and runtime electron. Updating "node-abi" might help solve this issue if it is a new release of electron

package.json {
...
"node-abi": "^2.7.1",
...
}

Hey. Trying to install the brave browser using npm and get the following warnings. Just want to rubber duck why I get it (it's not crucial for installing)

  SOLINK_MODULE(target) Release/obj.target/sha3.node
  COPY Release/sha3.node
make: Leaving directory '/home/lms/src/browser-laptop/node_modules/sha3/build'

> [email protected] install /home/lms/src/browser-laptop/node_modules/bufferutil
> prebuild-install || node-gyp rebuild

/home/lms/src/browser-laptop/node_modules/node-abi/index.js:44
  throw new Error('Could not detect abi for version ' + target + ' and runtime ' + runtime + '.  Updating "node-abi" might help solve this issue if it is a new release of ' + runtime)
  ^

Error: Could not detect abi for version 3.0.1 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron

The dependency tree looks like:

lms@x240 ~/src/browser-laptop (master)
$ npm ls node-abi
[email protected] /home/lms/src/browser-laptop
└─┬ [email protected]
  └─┬ [email protected]
    └─┬ [email protected]
      └─┬ [email protected]
        └── [email protected] 

It seems that node-abi does not support correctly the latest electron version, named 11.

Here is, for example, the full error brought up by "electron-rebuild" :

An unhandled error occurred inside electron-rebuild
Could not detect abi for version 11.0.0 and runtime electron. Updating "node-abi" might help solve this issue if it is a new release of electron

After updating an electron app to electron version 16.0.0, when running electron-forge start I get this error:

PS C:\Users\alexa\awel-personal> yarn dev
✔ Checking your system
✔ Locating Application
✖ Preparing native dependencies: 0 / 1

An unhandled error has occurred inside Forge:
Could not detect abi for version 16.0.0 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron
Error: Could not detect abi for version 16.0.0 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron
    at Object.getAbi (C:\Users\alexa\awel-personal\node_modules\node-abi\index.js:36:9)
    at Rebuilder.get ABI [as ABI] (C:\Users\alexa\awel-personal\node_modules\electron-rebuild\src\rebuild.ts:127:33)
    at ModuleRebuilder.get metaData [as metaData] (C:\Users\alexa\awel-personal\node_modules\electron-rebuild\src\module-rebuilder.ts:34:54)
    at ModuleRebuilder.alreadyBuiltByRebuild (C:\Users\alexa\awel-personal\node_modules\electron-rebuild\src\module-rebuilder.ts:40:28)
    at Rebuilder.rebuildModuleAt (C:\Users\alexa\awel-personal\node_modules\electron-rebuild\src\rebuild.ts:264:24)
    at Rebuilder.rebuild (C:\Users\alexa\awel-personal\node_modules\electron-rebuild\src\rebuild.ts:200:9)
    at C:\Users\alexa\awel-personal\node_modules\@electron-forge\core\src\util\rebuild.ts:32:5

In Node.js 17.0.0 an header is missing and this cause the following error during the compilation of a C++ addon.

In file included from ../node_modules/nan/nan.h:58:
In file included from /var/folders/b1/nkhppp291574ww7ftwplz6t80000gn/T/prebuild/node/17.0.0/include/node/node.h:63:
In file included from /var/folders/b1/nkhppp291574ww7ftwplz6t80000gn/T/prebuild/node/17.0.0/include/node/v8.h:25:
In file included from /var/folders/b1/nkhppp291574ww7ftwplz6t80000gn/T/prebuild/node/17.0.0/include/node/v8-array-buffer.h:13:
In file included from /var/folders/b1/nkhppp291574ww7ftwplz6t80000gn/T/prebuild/node/17.0.0/include/node/v8-object.h:10:
/var/folders/b1/nkhppp291574ww7ftwplz6t80000gn/T/prebuild/node/17.0.0/include/node/v8-persistent-handle.h:10:10: fatal error: 'v8-weak-callback-info.h' file not found
#include "v8-weak-callback-info.h"  // NOLINT(build/include_directory)

This was a known problem and was solved in version 17.0.1; so, in order to solve this compilation error, this row should be changed to: "target": "17.0.1".

In fact, forcing prebuild to use source of Node.js 17.0.1, the compilation succeeds:

$ npx prebuild -r node -t 17.0.1 --force --strip --tag-prefix ""
prebuild info begin Prebuild version 11.0.0
prebuild info build Preparing to prebuild @matteodisabatino/[email protected] for node 17.0.1 on darwin-x64 using node-gyp
prebuild info find Python using Python version 3.10.0 found at "/usr/local/opt/[email protected]/bin/python3.10"
prebuild http GET https://nodejs.org/dist/v17.0.1/node-v17.0.1-headers.tar.gz
prebuild http 200 https://nodejs.org/dist/v17.0.1/node-v17.0.1-headers.tar.gz
prebuild http GET https://nodejs.org/dist/v17.0.1/SHASUMS256.txt
prebuild http 200 https://nodejs.org/dist/v17.0.1/SHASUMS256.txt
(node:9457) [DEP0150] DeprecationWarning: Setting process.config is deprecated. In the future the property will be read-only.
(Use `node --trace-deprecation ...` to show where the warning was created)
prebuild info spawn /usr/local/opt/[email protected]/bin/python3.10
prebuild info spawn args [
prebuild info spawn args   '/Users/matteodisabatino/Work/repos/gc_info/node_modules/node-gyp/gyp/gyp_main.py',
prebuild info spawn args   'binding.gyp',
prebuild info spawn args   '-Dmodule_name=gc_info',
prebuild info spawn args   '-f',
prebuild info spawn args   'make',
prebuild info spawn args   '-I',
prebuild info spawn args   '/Users/matteodisabatino/Work/repos/gc_info/build/config.gypi',
prebuild info spawn args   '-I',
prebuild info spawn args   '/Users/matteodisabatino/Work/repos/gc_info/node_modules/node-gyp/addon.gypi',
prebuild info spawn args   '-I',
prebuild info spawn args   '/var/folders/b1/nkhppp291574ww7ftwplz6t80000gn/T/prebuild/node/17.0.1/include/node/common.gypi',
prebuild info spawn args   '-Dlibrary=shared_library',
prebuild info spawn args   '-Dvisibility=default',
prebuild info spawn args   '-Dnode_root_dir=/var/folders/b1/nkhppp291574ww7ftwplz6t80000gn/T/prebuild/node/17.0.1',
prebuild info spawn args   '-Dnode_gyp_dir=/Users/matteodisabatino/Work/repos/gc_info/node_modules/node-gyp',
prebuild info spawn args   '-Dnode_lib_file=/var/folders/b1/nkhppp291574ww7ftwplz6t80000gn/T/prebuild/node/17.0.1/<(target_arch)/node.lib',
prebuild info spawn args   '-Dmodule_root_dir=/Users/matteodisabatino/Work/repos/gc_info',
prebuild info spawn args   '-Dnode_engine=v8',
prebuild info spawn args   '--depth=.',
prebuild info spawn args   '--no-parallel',
prebuild info spawn args   '--generator-output',
prebuild info spawn args   'build',
prebuild info spawn args   '-Goutput_dir=.'
prebuild info spawn args ]
prebuild info spawn make
prebuild info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
  CXX(target) Release/obj.target/gc_info/src/gc_info.o
  CXX(target) Release/obj.target/gc_info/src/event.o
  CXX(target) Release/obj.target/gc_info/src/heap_stats.o
  CXX(target) Release/obj.target/gc_info/src/gc_stats.o
  SOLINK_MODULE(target) Release/gc_info.node
prebuild info build Stripping debug information from build/Release/gc_info.node
prebuild info build Packing build/Release/gc_info.node into prebuilds/@matteodisabatino/gc_info-v1.1.0-node-v102-darwin-x64.tar.gz
prebuild info build Prebuild written to prebuilds/@matteodisabatino/gc_info-v1.1.0-node-v102-darwin-x64.tar.gz

If you want I can provide a pull request.

Please support it, electron-forge will fail at start script.

https://github.com/electron/electron/releases/v1.6.0 (abi is 53)

When new version of Electron is created it takes a lot of time before it's supported by node-abi. In current situation there is no support for Electron 10 so it's not possible to rebuild native modules for application which uses Electron 10 as module electron-rebuild uses node-abi to get information about abi version for the given version of Electron. Would it be possible to add support for new version of Electron as soon as it is created (as nightly version)? I could create pull requests with required changes when new version of Electron is created in the future.

Version 5.5.0 of semver was just published.

This version is covered by your current version range and after updating it in your project the build failed.

semver is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

The main search loop here assumes that allTargets is in order:
https://github.com/lgeiger/node-abi/blob/9c5acd11ae297c4eabb29c531334dec4b09ebdf3/index.js#L22-L27

By construction (deprecatedTargets first, ..., futureTargets last, and each of those lists written in increasing order) this should be true. However, the test suite does not check this, and it's easy for bugs to creep in. For example,

var supportedTargets = [
  // ...
  {runtime: 'electron', target: '5.0.0', abi: '70', lts: false}
]

var futureTargets = [
  {runtime: 'electron', target: '5.0.0-beta.0', abi: '68', lts: false}
]

then attempting to run getAbi('5.0.0', 'electron') throws:

Error: Could not detect abi for version 5.0.0 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron
    at Object.getAbi (/path/node-abi/index.js:41:9)

This is because semver.lte('5.0.0-beta.0','5.0.0') === true but 5.0.0 came before 5.0.0-beta.0 in the list being searched.

See #62 (comment)

As of 2.19.0 node-abi has been reporting v14.0.0's version as 81, when it is 83.

Probably related to #90

Please support it, tks

All versions (and what version of Node.js they use) are available here, it is always up-to-date. You should attempt a network request first to this url before falling back to hard-coded versions:

• https://nwjs.io/versions.json

would be cool is allTargets had an .lts === true flag if a release is currently lts

The first beta release of the 2.x series was just released, but it seems node-abi does not support it yet. For example, I encounter Could not detect abi for version 2.0.0-beta.1 and runtime electron. when building my app.

It looks like 2.0.0-beta.1 uses Chrome 61.0.3163.10, so do we just need to add an entry saying '61' to support this or is there more to it than that?

Latest released version (v2.19.3) incorrectly returns ABI 85 for Electron 12.0.0-beta.1 which leads to issues when using prebuild (prebuild/prebuild#273).

run thie under node v16.6.1 windows 10
console.info(14.1.1 ${nodeAbi.getAbi('14.1.1', 'electron')})

I get
14.1.1 89

The last commit of adding node 19 failed on CircleCI: https://app.circleci.com/pipelines/github/electron/node-abi/95/workflows/880d98b6-f4c3-485d-8803-caf402f90262/jobs/283

Why LTS field for target 4.x has condition new Date() < new Date(2017, 4, 1)? (same for 6.x)
what lts field means? lts at the moment? why this field not always true?

Hey folks! Sorry, but it looks like the auto-publish for this module is no longer working due to travis-ci.org being deprecated. I think someone with admin privileges needs to migrate the jobs over to travis-ci.com or another CI alternative in order for the jobs to continue.

Are there plans to continue to support the existing CI jobs, or should others work around this in the short-term? Thanks!