-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enforce NAPI version in module headers #286
Comments
Looks reasonable. I think we'll need a doc that captures the approach and update the doc on creating a release so that we include the required steps. I also think we should discuss if we start enforcing this before/after we exit experimental. |
@mhdawson I can update the documentation for N-API to describe the approach for module authors, is that sufficient? It would probably make sense to have an answer for this before we exit experimental, but there are more pieces to put into place. I'm not sure how this would fit into the end-to-end pipeline, for instance how do modules surface this value to npm/node-gyp? |
Updating the N-API documentation works for me. |
Based on discussion in the meeting today we'll set the starting version at 2 (the current shipping N-API version) so we don't break any developers. |
I'm still working on this PR, but I took a stab at trying to figure out the version mapping:
* Versions 1 and 2 were really loose (during experimental) so these are approximate. |
I opened the initial PR: nodejs/node#19962 |
PR landed, closing out. |
As discussed today it seems like rather than having developers declare their version specifically it would make sense to enforce it in the header file.
By default only the first version would be exposed and the developer can explicitly opt in using a preprocessor directive:
I've made the required changes in a private branch to start the discussion. If there are no objections I can go ahead and open a PR in the main repo.
The text was updated successfully, but these errors were encountered: