Is the `binary.napi_versions` property being used correctly?

[shirakaba]

Referring to these lines here:

node-api-example-lib/package.json

Lines 26 to 30 in 3cdfba5

	"binary": {
	"napi_versions": [
	3
	]
	},

The binary field is documented on this third-party site. It sounds like it should be used together with the following cmake code:

add_compile_definitions(NAPI_VERSION=${napi_build_version})

However, it appears we're hard-coding that:

node-api-example-lib/CMakeLists.txt

Line 4 in 3cdfba5

add_compile_definitions(-DNAPI_VERSION=4)

We should either omit it from the package.json altogether or feed it into CMakeLists as a variable.

My worry about it being in the package.json is that library authors might not understand what it's for and delete it by accident. Though if the CMakeLists.txt would take it as an optional variable and simply fall back to a given value if it's omitted, then we'd get the best of both worlds.

[kraenhansen]

The main reason this is hardcoded is because that's what cmake-js does in their template: https://github.com/cmake-js/cmake-js?tab=readme-ov-file#general

I agree it would be good to drive it from somewhere if it's already there and the behaviour of cmake-js, but currently cmake-rn doesn't read that "binary" object from.

[shirakaba]

Okay, it looks like the redundancy does have a purpose. If you omit binary.napi_versions from package.json, cmake-rn compiles just fine, but cmake-js can't find napi.h.

New question: the value in package.json refers to version 3, while the value in the CMakeLists.txt refes to version 4. Should we align them both on the same version, and if so, which one?