Repository navigation
Bring N-API out of experimental #501
Description
The criteria for bringing N-API out of experimental were discussed in the VM Summit last July and captured here: nodejs/abi-stable-node#284.
The items where:
- Multiple implementations of n-api on at least 2 VMs
- Was already in place as N-API is implemented on V8 and Chakra core
- Define N-API / async_hooks dependency
- This was completed last August in src,async_hooks,n-api: refactor async callback handling node#14697
- At least two modules used in real world use cases on at least one VM
- There are now 3 modules being used in production using N-API (see #293 for more details):
- bcrypt-n-api - in Lexgenda Search engine
- node-zopfli in Microsoft Edge Developer Portal
- iotivity-node@1.3.1-0 in CANPIE
- There is additional real world usage through:
- There are 21017 downloads so far of node-addon-api, the C++ wrapper for use as an
alternative to NAN.
- There are now 3 modules being used in production using N-API (see #293 for more details):
- At least two modules that are NPM installable with pre-builds and all unit tests passing
-
We have worked through the process of how N-API will integrate with node-pre-gyp and
have a pull request here to integrate the required changed #345 -
We did not have to make any changes to the APIs to support working with node-pre-gyp and
don't believe any future changes will be required either. As such the N-API team does not believe
waiting until the PR lands is necessary to move N-API out of experimental.
-
We have not had to make any breaking changes to the APIs since the last ones which were originally planned for Node 8.6.x back in September 2017.
Along the way we have had comments from a number of modules owners that they will be more interested in moving to N-API once it comes out of experimental.
At this point in time, the N-API team believes it has met the substance of the criteria originally set out and the recommendation of the N-API team is to move it out of experimental as we believe that we will not get a material amount of additional validation while it remains in experimental. This is because modules owners are reluctant to invest while it is in that state.
Activity
cjihrig commentedon Mar 5, 2018
+1. Thanks for all of the hard work on N-API.
jasnell commentedon Mar 5, 2018
+1
ofrobots commentedon Mar 5, 2018
I support this.
mcollina commentedon Mar 5, 2018
+1
rvagg commentedon Mar 6, 2018
+1
fhinkel commentedon Mar 6, 2018
+1
fhinkel commentedon Mar 6, 2018
If there's no objections, moving N-API out of experimental doesn't need a TSC vote, right?
Trott commentedon Mar 6, 2018
@fhinkel Looking at our documented process in GOVERNANCE.md, we can skip a vote if we:
I think this should be removed from the meeting agenda, although by our rules, only @mhdawson can do that because they put it on the agenda in the first place. Michael or someone else can mention it during announcements if they want to raise awareness at the meeting.
But it sure looks like this is going to sit here for 72 hours (because I think the clock starts when @nodejs/tsc is @-mentioned), and then be affirmed without a vote.
fhinkel commentedon Mar 6, 2018
@Trott thanks for explaining. Definitely didn't want to rush it, just making sure we don't skip a vote if needed.
Trott commentedon Mar 6, 2018
71 hours and 35 minutes to go! 😄
mhdawson commentedon Mar 6, 2018
I'm happy to remove from the agenda. I just wanted to make sure we had some visibility/comments and I think that is occurring.
mcollina commentedon Mar 8, 2018
As part of this process we should make sure that the real-world usage is captured in citgm. It's important we verify that we are not regressing things.
@mhdawson can you add a couple of those modules?
14 remaining items
n-api: take n-api out of experimental
n-api: take n-api out of experimental
n-api: take n-api out of experimental
n-api: take n-api out of experimental
n-api: take n-api out of experimental