You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As @bghgary mentioned on the N-API WG meeting on 10/18, there is a use case where developers who are embedding JS engines directly (and not embedding Node) can need a VM-neutral interface to talk to these engines in an ABI-stable manner. Given that N-API already has this, @bghgary suggested factoring out the ES-specific parts of N-API into its own header. Opening this issue to continue that discussion.
I think its a great suggestion. Making it easier for other projects/teams to consume N-API should help overall adoption. In addition it will increase the chances of these projects contributing back enhancements.
As @bghgary mentioned on the N-API WG meeting on 10/18, there is a use case where developers who are embedding JS engines directly (and not embedding Node) can need a VM-neutral interface to talk to these engines in an ABI-stable manner. Given that N-API already has this, @bghgary suggested factoring out the ES-specific parts of N-API into its own header. Opening this issue to continue that discussion.
@bghgary's prototype is here: https://github.com/bghgary/node-addon-api/tree/ES-only
The text was updated successfully, but these errors were encountered: