Closed gabrielschulhof closed 1 year ago
@legendecas this is likely a result of the recent addition of NAPI_VERSION 9, possibly we have something missing in our doc of the steps needed for a release.
We may need an additional define MAX_NODE_API_VERSION which we use when reporting what node version is supported.
@mhdawson AFAICT, this only happens when node_version.h
is included after js_native_api.h
, which wouldn't be the case for Node-API add-ons since node_version.h
is not part of Node-API headers.
We may need an additional define MAX_NODE_API_VERSION which we use when reporting what node version is supported.
Are you referring to something like napi_get_version()
?
napi_get_version()?
correct but maybe you already handled that some other way?
@mhdawson AFAICT, this only happens when node_version.h is included after js_native_api.h, which wouldn't be the case for Node-API add-ons since node_version.h is not part of Node-API headers.
So if I understand correctly this is only an issue for our internal testing?
So if I understand correctly this is only an issue for our internal testing?
It would be an issue for embedder's linked node-api addons if node.h
is included after js_native_api.h
.
@legendecas still trying to understrand the scope of the concern.
So maybe a stupid question but what if people simply include node.h before js_native_api.h. Is there no issue or the reverse issue. If it's the latter it seems like we may need to look at what NAPI_VERSION is being used in within core and possibly have a new define which is used in the cases that currently need the value to be set to NAPI_VERSION 9. That's why I mentioned possibly introducing a MAX_NODE_API_VERSION which as you say is likely what should be returned by napi_get_version() even if an addon author has defined NAPI_VERSION as something else.
@mhdawson There would be no warnings if node.h
is included before js_native_api.h
.
Indeed, the NAPI_VERSION
defined in node_version.h
has a different meaning than the one defined in the addons. The one from node_version.h
is identical to napi_get_version()
, indicating the highest Node-API version supported by the Node.js runtime. While the NAPI_VERSION
defined in addons indicates the Node-API version required by the addon and should be lower than or equal to the NAPI_VERSION
of the Node.js runtime.
As node_version.h
is a public header file, renaming the macro NAPI_VERSION
can be breaking. If we introduce a new MAX_NODE_API_VERSION
without renaming the NAPI_VERSION
defined in node_version.h
, I'm afraid the conflict still preserves.
@legendecas
NAPI_VERSION can be breaking
to addons or something else?
If it is something else
and there is a relatively low likelyhood then maybe we can change it and mark SemVer major?
node_version.h
is not part of node-api headers -- so it's not breaking node-api addons. For embedders and C++ addons, marking the change as semver-major makes sense to me.
I don't think non node-api C++ addons should be using NAPI_VERSION ?
yeah, but it's there and can be used. Though I don't think it would be meaningful to be used.
@legendecas thanks for confirming. I think give our discussion the risk of breakage to any addon is quite low, and should not affect Node-api addons where the ABI guarantee exists. Therefore, I think that the way to go is to rename and mark the PR as SemVer major.
It should have no effect on node-api addons, very small chance of affecting any NaN/other addons and being SemVer major should cover any impact on embedders if any.
Reopening to wait for https://github.com/nodejs/node/pull/48501.
Version
main
Platform
all
Subsystem
node-api
What steps will reproduce the bug?
We need to figure out the sequence of include files. We want to avoid such warnings.
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior? Why is that the expected behavior?
No such warnings.
What do you see instead?
This warning.
Additional information
No response