doc: clarity to available addon options

bullet pointed addon optons; wording clarity; fixes typo

PR-URL: https://github.com/nodejs/node/pull/55715
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
This commit is contained in:
Preveen P 2024-11-06 13:25:49 +05:30 committed by GitHub
parent ccac4ee19d
commit 98e5693cd4
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -8,20 +8,25 @@ _Addons_ are dynamically-linked shared objects written in C++. The
[`require()`][require] function can load addons as ordinary Node.js modules.
Addons provide an interface between JavaScript and C/C++ libraries.
There are three options for implementing addons: Node-API, nan, or direct
use of internal V8, libuv, and Node.js libraries. Unless there is a need for
direct access to functionality which is not exposed by Node-API, use Node-API.
There are three options for implementing addons:
* Node-API
* `nan` ([Native Abstractions for Node.js][])
* direct use of internal V8, libuv, and Node.js libraries
Unless there is a need for direct access to functionality which is not\
exposed by Node-API, use Node-API.
Refer to [C/C++ addons with Node-API](n-api.md) for more information on
Node-API.
When not using Node-API, implementing addons is complicated,
involving knowledge of several components and APIs:
When not using Node-API, implementing addons becomes more complex, requiring\
knowledge of multiple components and APIs:
* [V8][]: the C++ library Node.js uses to provide the
JavaScript implementation. V8 provides the mechanisms for creating objects,
calling functions, etc. V8's API is documented mostly in the
JavaScript implementation. It provides the mechanisms for creating objects,
calling functions, etc. The V8's API is documented mostly in the
`v8.h` header file (`deps/v8/include/v8.h` in the Node.js source
tree), which is also available [online][v8-docs].
tree), and is also available [online][v8-docs].
* [libuv][]: The C library that implements the Node.js event loop, its worker
threads and all of the asynchronous behaviors of the platform. It also
@ -35,10 +40,10 @@ involving knowledge of several components and APIs:
offloading work via libuv to non-blocking system operations, worker threads,
or a custom use of libuv threads.
* Internal Node.js libraries. Node.js itself exports C++ APIs that addons can
* Internal Node.js libraries: Node.js itself exports C++ APIs that addons can
use, the most important of which is the `node::ObjectWrap` class.
* Node.js includes other statically linked libraries including OpenSSL. These
* Other statically linked libraries (including OpenSSL): These
other libraries are located in the `deps/` directory in the Node.js source
tree. Only the libuv, OpenSSL, V8, and zlib symbols are purposefully
re-exported by Node.js and may be used to various extents by addons. See
@ -148,8 +153,8 @@ invocation of `NODE_MODULE_INIT()`:
* `Local<Value> module`, and
* `Local<Context> context`
The choice to build a context-aware addon carries with it the responsibility of
carefully managing global static data. Since the addon may be loaded multiple
Building a context-aware addon requires careful management of global static data
to ensure stability and correctness. Since the addon may be loaded multiple
times, potentially even from different threads, any global static data stored
in the addon must be properly protected, and must not contain any persistent
references to JavaScript objects. The reason for this is that JavaScript
@ -255,7 +260,7 @@ such as a main thread and a Worker thread, an add-on needs to either:
* Be declared as context-aware using `NODE_MODULE_INIT()` as described above
In order to support [`Worker`][] threads, addons need to clean up any resources
they may have allocated when such a thread exists. This can be achieved through
they may have allocated when such a thread exits. This can be achieved through
the usage of the `AddEnvironmentCleanupHook()` function:
```cpp
@ -1273,7 +1278,7 @@ class MyObject : public node::ObjectWrap {
#endif
```
The implementation of `myobject.cc` is similar to before:
The implementation of `myobject.cc` remains similar to the previous version:
```cpp
// myobject.cc