Closed ralphtheninja closed 5 years ago
Note: This hasn't been true from the start though, since n-api in node v8.0.0
has a different api compared to v8.6.0
(e.g. napi_create_error()
).
@gabrielschulhof @mcollina Could you advise us here?
n-api has exited experimental status a little later in the Node 8 LTS cycle. I would build it with the latest version of older LTS line that it is supported. Currently, latest Node 8.
Unfortunately, prebuildify --napi
always targets latest node:
@vweevers Maybe we can patch prebuildify
to do something like:
if (argv.napi && !targets) {
targets = [
abi.supportedTargets.filter(onlyNode).pop(),
abi.supportedTargets.filter(onlyElectron).pop(),
]
if (targets[0].target === '9.0.0') targets[0].target = '9.6.1'
}
Then we should be able to do prebuildify --target whatever --napi
I was thinking that too, but from the current code, it seems @mafintosh has different ideas about what the most suitable node version is?
BTW, should we also define an explicit NAPI_VERSION
? Which:
restricts the N-API surface to just the functionality that was available in the specified (and earlier) versions
I was thinking that too, but from the current code, it seems @mafintosh has different ideas about what the most suitable node version is?
Yes.
BTW, should we also define an explicit
NAPI_VERSION
?
Yeah, we can do this. This should be set to 3 (which is the version used at v8.x LTS)
if (argv.napi && !targets) { targets = [ abi.supportedTargets.filter(onlyNode).pop(), abi.supportedTargets.filter(onlyElectron).pop(), ] if (targets[0].target === '9.0.0') targets[0].target = '9.6.1' }
That doesn't cover electron, unless we call prebuildify twice.
We can do (with the patch)
prebuildify -t 8.14.0 -t electron@3.0.0 --napi
Ah, of course. 👍
There's a TODO
comment in there as well to use --lts
. Maybe we can do something about that?
On second thought, I think I prefer using -t
because then we can do prebuildify -t $(node -v) -t electron@3.0.0
on Travis.
There's a
TODO
comment in there as well to use--lts
. Maybe we can do something about that?
Question is what --lts
means. Oldest LTS, latest LTS, latest LTS that has non-experimental N-API, ..
On second thought, I think I prefer using -t because then we can do prebuildify -t $(node -v) -t electron@3.0.0 on Travis.
Yeah.
Question is what
--lts
means. Oldest LTS, latest LTS, latest LTS that has non-experimental N-API, ..
This is why I changed my mind again :smile:
So, action items:
#define NAPI_VERSION 3
prebuildify
node-gyp-build
to support npm i --build-from-source
https://github.com/Level/leveldown/issues/566prebuildify
x86
from AppVeyor?@vweevers Should we still build on Current
/node
on appveyor/travis?
@vweevers Should we still build on
Current
/node
on appveyor/travis?
No opinion. We will have to update the matrix as node releases come out anyway, because we have to specify the version number on which to prebuild. I'm fine with either current/node
or a hardcoded 11
.
@vweevers Closing this.
From https://nodejs.org/en/docs/guides/abi-stability/
This tells me that if you build on the minimum possible node version (for
leveldown
this meansv8.6.0
) that will cover all future versions. Should we pick this strategy when making prebuilt binaries? At the moment it seems to work well to pick the current node version (v11.4.0
at time of writing) and make it work for earlier versions, but afaikn-api
is not guaranteed to be backwards compatible, right?Input appreciated.
EDIT:
Slightly below above mentioned quote it says:
So it seems we might as well pick the latest version of node.