Mention vcpkg port in docs

[Pospelove]

No description provided.

[nodejs-github-bot]

Review requested:

• @nodejs/node-api

[legendecas]

I didn't find these packages on https://vcpkg.io/en/packages.html and I'm not aware of an existing release process that publishes these packages.

@mhdawson please correct me if I'm missing it.

[richardlau]

Looks like these are referencing the ports added by:

• [node-api] Add new port microsoft/vcpkg#26768
• [node-addon-api] Add new port microsoft/vcpkg#28427

[Pospelove]

Looks like these are referencing the ports added by:

Yeah, that's true. I'm not sure what revision of vcpkg does the site use, but those packages are available for users.

Unlike many package managers vcpkg consists of build recipes instead of storing files in the cloud. Those build recipes are being maintained by the community and Microsoft.

The usual workflow is to have vcpkg repo cloned somewhere on your machine. So, once you cloned latest vcpkg or pulled latest changes, you'd be able to run vcpkg install node-api and vcpkg install node-addon-api.

After running those commands you can see a brief explanation on how to use node-api/node-addon-api with your existing CMake project (and some CMake lines to copy-paste).

[mhdawson]

@vmoroz is this something you are aware of?

[vmoroz]

@vmoroz is this something you are aware of?

@mhdawson , I was not aware about the node-api and node-addon-api ports to vcpkg.
vcpkg is a cross-platform packaging system for C++ code that targets improving C++ developer experience.
It is like npm for C++.
There are a number of new package managers came up lately, but vcpkg and Conan are the most popular package managers so far. It is great to see that node-api and node-addon-api support are added to vcpkg!

@Pospelove, I wonder if you could work with the Node-API team to make the vcpkg offering to be more compelling:

• The node-api port seems to be bound to Node.JS version 18.12.1. We position Node-API to be Node.JS-version independent. It has its own versioning schema where we use an integer for a version: 1, 2, 3, etc. The current version is 8. All newer versions are backward compatible with the previous versions. It would be better if the node-api semantic version is based on the Node-API version instead of Node.JS version. Also, it is probably better to source the headers from the node-api-header repo. (Though, these headers seem to be a bit outdated - we need to sync them.)
• What are the intentions regarding updating vcpkg definitions with latest releases of node-addon-api and the node-api?
• It would be nice to understand the end-to-end story for creating npm packages that use CMake. Is it something that can be added to node-addon-examples?

[Pospelove]

@vmoroz Thanks for your interest in this! I'll definitely be glad to finish that work.

It would be nice to understand the end-to-end story for creating npm packages that use CMake. Is it something that can be added to node-addon-examples?

Yeah, I think so. I'll make a PR for that.

What are the intentions regarding updating vcpkg definitions with latest releases of node-addon-api and the node-api?

I've just updated node-addon-api to the newest 6.0 release (see microsoft/vcpkg#29599)
I'll probably pull request "updating" node-api from 18.0.2 to 8 (in order to fix versioning)

[Pospelove]

@vmoroz I have a couple of questions:

1. Why does https://github.com/nodejs/node-api-headers have 0.0.1/0.0.2 tags? How is it related to 1,2,3..8 versions of Node API? I'm asking because I'll need to use a particular commit for vcpkg port update.

2. How do we deal with node.lib? where do I download node.lib for N-API 8 for example?

My first idea would be to just change the version from 18.0.2 to 8 in the node-api port, but keep downloading 18.0.2 dist. Do you think this is a good idea?

[Julusian]

@Pospelove for cmake-js I did some digging and found that it is possible to generate the node.lib file from the data in nodejs/node-api-headers.

https://github.com/cmake-js/cmake-js/blob/master/lib/cMake.js#L293-L315 and https://github.com/cmake-js/cmake-js/blob/master/README.md?plain=1#L124-L127 are the interesting snippets.

It would of course be nice to have these prebuilt and possible to bundle, but this way avoids distributing 'large' files, and could also be used to limit the possible symbols that can be linked

[Pospelove]

@Julusian Thanks! it helps

[mhdawson]

Also, it is probably better to source the headers from the node-api-header repo. (Though, these headers seem to be a bit outdated - we need to sync them.)

@KevinEady is working on automation to do the update so we'll be able to better keep up to date. I think that is about to land so we should be testing it out on an update soon.

[github-actions]

This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open.

[github-actions]

Closing this because it has stalled. Feel free to reopen if this issue/PR is still relevant, or to ping the collaborator who labelled it stalled if you have any questions.