Review requested:

• @nodejs/node-api

I am not a fan of this addition, but I am interested to see what the other team members say. Other bindings and engines are just listed on https://github.com/nodejs/abi-stable-node/blob/doc/node-api-engine-bindings.md for reference.

I feel like adding this to our Node-API documentation would possibly give users the impression that we support / back the binding, or favor one binding over the other (as there are multiple Rust bindings).

What if the implementation changes for this napi-rs binding? Even if this scenario is unlikely, we'd need to ensure that now that this documentation stays up-to-date. This adds a dependency for us to maintain / monitor in our documentation.

A quick web search for "node-api rust" would provide people with the required information to find Rust bindings, alleviating us from needing to include it in official Node.js documentation.

I am not a fan of this addition, but I am interested to see what the other team members say. Other bindings and engines are just listed on https://github.com/nodejs/abi-stable-node/blob/doc/node-api-engine-bindings.md for reference.

I feel like adding this to our Node-API documentation would possibly give users the impression that we support / back the binding, or favor one binding over the other (as there are multiple Rust bindings).

What if the implementation changes for this napi-rs binding? Even if this scenario is unlikely, we'd need to ensure that now that this documentation stays up-to-date. This adds a dependency for us to maintain / monitor in our documentation.

A quick web search for "node-api rust" would provide people with the required information to find Rust bindings, alleviating us from needing to include it in official Node.js documentation.

I used napi-rs many times, and it's quite ergonomic for developing Rust for Node.js.

(as there are multiple Rust bindings).

Right now, there are only two binding libraries, I think? napi-rsand neon-rs, or just use webassembly from built-in rust feature. And napi-rs is the best of them, I believe.

What if the implementation changes for this napi-rs binding? Even if this scenario is unlikely, we'd need to ensure that now that this documentation stays up-to-date. This adds a dependency for us to maintain / monitor in our documentation.

It's the same situation for TypeScript support in Node.js, right? It uses swc, which is our downstream.

Anyway, I +1 on this change, but yeah, we might need basic test cases for this?

I would second @KevinEady opinion.
We can probably add a set of links to other language bindings for better visibility, but having a screen sized description per each 3rd party language binding seems to be a bit excessive.

I think the API doc should be impartial on community packages. We should link to https://github.com/nodejs/abi-stable-node/blob/doc/node-api-engine-bindings.md instead.

Fair enough, I'll close this since you've created a PR to link the community package links