How to know which of the several ways to make a C/C++ nodeJS addon is used by a particular example or repo?

Question

Apparently a situation has evolved over the years where there are three, four, or five main ways to write a nodeJS addon in C/C++ depending on where you're reading about it.

For those of us just trying to learn and write our first addon in 2021 it can be quite confusing. I might have a couple of tutorials open in my web browser and a couple of code repos downloaded from GitHub to see how certain things are done.

But unless there's a comment at the top that states clearly which of the four ways each tutorial or repo is using, it gets very confusing. And the names each has are not really distinct enough to be much help when you're just starting out.

So what are some things I can look for to know at a glance when I'm looking at code that uses each of these four ways?

I see that there are various main include files that might be at the top of the main C/C++ source file, and that there there are certain macros or function calls with somewhat different names that perform the same actions depending which way the addon uses.

This might be complicated by some of these ways either being wrappers around other ways or sometimes needing to call lower-level functions. I'm not sure.

Answer 1

If you are starting a new native module development (or learning activity) then the best choice could be to use N-API (or its C++ wrapper class node-addon-api). Till the arrival of N-API, none of the native addon abstraction API facility provide ABI stability across node.js major releases. The N-API solved this ABI stability problem and make the native addon built on one node.js version compatible with future node.js version. That means we don't need recompiling the native addon module across all node.js major releases. The N-API is maintained by the Node.js core team itself, that make its future even brighter.

Look like many are going through the same difficulty once I was (while I started learning Node.JS native addon). Then I thought, having a document explaining the native addon evolution a bit may help others while they trying to learn native addons; and created a short documentation and a small set of examples (that I created during may native addon study) and it is available at Node native addon

I also encourage you all to take a look the example repository node.js team has created for us, I may consider this is one of the best node-addon-examples native addon example set.

Answer 2

I'm still working this out as I write it, so there will probably be things I'm getting wrong or overlooking:

1

Short name: (none)
Long name: (none)
Part of Node or external: part
Language: C++
Stable: No
Header files: node.h v8.h uv.h
Doc URL: https://nodejs.org/api/addons.html

2

Short name: NAN
Long name: Native Abstractions for Node
Part of Node or external: external
Language: C++
Stable: no
Header files: nan.h
Macros: NODE_MODULE()
Identifiers: Nan::*
Repo URL: https://github.com/nodejs/nan
Stack Overflow tag: node.js-nan

3

Short name: N-API
Long name: Node-API
Part of Node or external: part
Language: C
Stable: yes
Header files: node_api.h
Macros: NAPI_MODULE() DECLARE_NAPI_METHOD()
Identifiers: napi_*
Doc URL: https://nodejs.org/api/n-api.html
Stack Overflow tag: node.js-napi

4

Short name: node-addon-api
Long name: node-addon-api
Part of Node or external: external
Language: C++
Stable: yes
Header files: napi.h
Macros: NODE_API_MODULE()
Identifiers: Napi::*
Repo URL: https://github.com/nodejs/node-addon-api
Stack Overflow tag: node-addon-api

Other

Short name: node-ffi
Long name: Node.js Foreign Function Interface
Part of Node or external: external
Language: JavaScript
Stable: deprecated
Repo URL: https://github.com/node-ffi/node-ffi
Stack Overflow tag: node-ffi