napi: stabilization criteria - requirement for alternative VM

[Flarna]

The stabilization criteria for NAPI here says that exit criteria for experimental status requires "Implementation in an alternative VM.".

Which alternative VMs are supported currently? I haven't heard anything from MS chakra since a while.

Is the guilde still up date?

[legendecas]

The motivation is to make sure the API is implementable across VMs, so that we can make sure the API is not specific to V8 and vulnerable to V8 API changes.

I think this criteria is still valid. Maybe we should reword the criteria to be "implementable in another VM", rather than requiring it to be implemented. Good to have opinions from @nodejs/node-api-implementer.

We also have a list of implementation of node-api at https://github.com/nodejs/abi-stable-node/blob/doc/node-api-engine-bindings.md#node-api-bindings-for-other-runtimes.

[bnoordhuis]

Another example of n-api bindings to other engines (jsc, hermes, quickjs): https://blog.nativescript.org/nativescript-8-9-node-api-previews/

[Flarna]

Ah ok. So in short napi is not really a node thing anymore.
So maybe API definition/stabilization should be moved out of node project?

[legendecas]

So in short napi is not really a node thing anymore.

This is not true. The motivation of the criteria is ensuring the ABI stability of node-api, regardless of V8 API changes.

[bnoordhuis]

Read "not just a node thing anymore", which is correct.

[KevinEady]

I am in favor of changing the critieria to "implementable in another VM"

We discussed in the 11 July Node-API meeting, that the term implementable could mean that there has been discussions around the feasibility of implementing the change and/or creating a pull request, whereas implemented means the feature has completely shipped in another engine. We believe this restriction of being "fully shipped" should not block us from taking something out of experimental.