Skip to content

Discussion about the next steps #3

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
NickNaso opened this issue Jul 30, 2021 · 3 comments · Fixed by #4
Closed

Discussion about the next steps #3

NickNaso opened this issue Jul 30, 2021 · 3 comments · Fixed by #4

Comments

@NickNaso
Copy link
Member

In this issue I reported some correlated issues some of them pushed us to work on this repo:

My idea is to continue to work on documentation and then publish on npm.

@mhdawson
Copy link
Member

+1

@Julusian
Copy link

Julusian commented Jun 5, 2022

@NickNaso Thank you for creating this!

I stumbled upon this by accident, while in the middle of overhauling some of the internals of cmake-js. This is a much nicer method than having to download the headers for some arbitrary version of nodejs.

With a bit of work, I even managed to avoid needing to source a copy of node.lib. Using the symbols information it is possible to generate a compatible version without much difficulty.

This removes all the downloads that cmake-js used to perform during a build targetting node-api. It also makes me happier about the safety of using node-api as the non node-api headers are no longer available to be included accidentally.

@NickNaso
Copy link
Member Author

NickNaso commented Jun 6, 2022

Hi @Julusian,
I like to hear your feedback. We created node-api-headers to allow the build of native addon without download all the headers for a specific version of Node.js. This is possible because Node-API is an ABI stable API and it's independent from any Node.js version what matters is the version of Node-API.

Node-API has some experimental API that are not part of any version because they are not considered stable. We removed from the headers the features e / o functions that are under NAPI_EXPERIMENTAL so this means that if a developer set the NAPI_EXPERIMENTAL flag he will obtain a compilation error.

I don't know if this could be a problem, but I want to discuss at the next Node-API meeting https://github.com/nodejs/abi-stable-node#meeting. If you have time and want to join us it will be a pleasure to discuss about this together.

My idea is to use the original Node-API's headers (without removing the experimental feature) and add a new section named EXPERIMENTAL in the symbol.js like reported below:

    EXPERIMENTAL: {
        js_native_api_symbols: [
            // List of symbols in js_native_api.h considered experimental.
        ],
        node_api_symbols: [
          // List of symbols in node_api.h considered experimental.
        ]
    }

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants