OSSForks/node
1
0
Fork 0
mirror of https://github.com/zebrajr/node.git synced 2026-01-15 12:15:26 +00:00
Code Issues Actions 7 Packages Projects Releases Wiki Activity

doc: rename N-API to Node-API

Browse Source 
Refs: https://github.com/nodejs/abi-stable-node/issues/420
PR-URL: https://github.com/nodejs/node/pull/37259
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
This commit is contained in:
Gabriel Schulhof
2021-02-06 19:40:36 -08:00
parent 72f9c53c0f
commit 2084f31e27
6 changed files with 178 additions and 177 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
doc/api/addons.md
View File

@@ -7,12 +7,13 @@ _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: N-API, nan, or direct
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 N-API, use N-API.
Refer to [C/C++ addons with N-API](n-api.md) for more information on N-API.
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 N-API, implementing addons is complicated,
When not using Node-API, implementing addons is complicated,
involving knowledge of several components and APIs:
* V8: the C++ library Node.js uses to provide the
@@ -245,7 +246,7 @@ changes:
In order to be loaded from multiple Node.js environments,
such as a main thread and a Worker thread, an add-on needs to either:
* Be an N-API addon, or
* Be an Node-API addon, or
* 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
@@ -437,11 +438,11 @@ addon developers are recommended to use to keep compatibility between past and
future releases of V8 and Node.js. See the `nan` [examples][] for an
illustration of how it can be used.
## N-API
## Node-API
> Stability: 2 - Stable
N-API is an API for building native addons. It is independent from
Node-API is an API for building native addons. It is independent from
the underlying JavaScript runtime (e.g. V8) and is maintained as part of
Node.js itself. This API will be Application Binary Interface (ABI) stable
across versions of Node.js. It is intended to insulate addons from
@@ -451,17 +452,17 @@ recompilation. Addons are built/packaged with the same approach/tools
outlined in this document (node-gyp, etc.). The only difference is the
set of APIs that are used by the native code. Instead of using the V8
or [Native Abstractions for Node.js][] APIs, the functions available
in the N-API are used.
in the Node-API are used.
Creating and maintaining an addon that benefits from the ABI stability
provided by N-API carries with it certain
provided by Node-API carries with it certain
[implementation considerations](n-api.md#n_api_implications_of_abi_stability).
To use N-API in the above "Hello world" example, replace the content of
To use Node-API in the above "Hello world" example, replace the content of
`hello.cc` with the following. All other instructions remain the same.
```cpp
// hello.cc using N-API
// hello.cc using Node-API
#include <node_api.h>
namespace demo {
@@ -493,7 +494,7 @@ NAPI_MODULE(NODE_GYP_MODULE_NAME, init)
```
The functions available and how to use them are documented in
[C/C++ addons with N-API](n-api.md).
[C/C++ addons with Node-API](n-api.md).
## Addon examples

4
doc/api/errors.md
View File

@@ -1823,7 +1823,7 @@ would be possible by calling a callback more than once.
<a id="ERR_NAPI_CONS_FUNCTION"></a>
### `ERR_NAPI_CONS_FUNCTION`
While using `N-API`, a constructor passed was not a function.
While using `Node-API`, a constructor passed was not a function.
<a id="ERR_NAPI_INVALID_DATAVIEW_ARGS"></a>
### `ERR_NAPI_INVALID_DATAVIEW_ARGS`
@@ -2559,7 +2559,7 @@ added: v9.0.0
removed: v10.0.0
-->
Used by the `N-API` when `Constructor.prototype` is not an object.
Used by the `Node-API` when `Constructor.prototype` is not an object.
<a id="ERR_NO_LONGER_SUPPORTED"></a>
### `ERR_NO_LONGER_SUPPORTED`

2
doc/api/index.md
View File

@@ -14,7 +14,7 @@
* [Async hooks](async_hooks.md)
* [Buffer](buffer.md)
* [C++ addons](addons.md)
* [C/C++ addons with N-API](n-api.md)
* [C/C++ addons with Node-API](n-api.md)
* [C++ embedder API](embedding.md)
* [Child processes](child_process.md)
* [Cluster](cluster.md)

298
doc/api/n-api.md
View File

@@ -1,30 +1,29 @@
# N-API
# Node-API
<!--introduced_in=v8.0.0-->
<!-- type=misc -->
> Stability: 2 - Stable
N-API (pronounced N as in the letter, followed by API)
is an API for building native Addons. It is independent from
the underlying JavaScript runtime (for example, V8) and is maintained as part of
Node.js itself. This API will be Application Binary Interface (ABI) stable
across versions of Node.js. It is intended to insulate Addons from
changes in the underlying JavaScript engine and allow modules
Node-API (formerly N-API) is an API for building native Addons. It is
independent from the underlying JavaScript runtime (for example, V8) and is
maintained as part of Node.js itself. This API will be Application Binary
Interface (ABI) stable across versions of Node.js. It is intended to insulate
addons from changes in the underlying JavaScript engine and allow modules
compiled for one major version to run on later major versions of Node.js without
recompilation. The [ABI Stability][] guide provides a more in-depth explanation.
Addons are built/packaged with the same approach/tools outlined in the section
titled [C++ Addons][]. The only difference is the set of APIs that are used by
the native code. Instead of using the V8 or [Native Abstractions for Node.js][]
APIs, the functions available in the N-API are used.
APIs, the functions available in Node-API are used.
APIs exposed by N-API are generally used to create and manipulate
APIs exposed by Node-API are generally used to create and manipulate
JavaScript values. Concepts and operations generally map to ideas specified
in the ECMA-262 Language Specification. The APIs have the following
properties:
* All N-API calls return a status code of type `napi_status`. This
* All Node-API calls return a status code of type `napi_status`. This
status indicates whether the API call succeeded or failed.
* The API's return value is passed via an out parameter.
* All JavaScript values are abstracted behind an opaque type named
@@ -33,14 +32,14 @@ properties:
using `napi_get_last_error_info`. More information can be found in the error
handling section [Error handling][].
The N-API is a C API that ensures ABI stability across Node.js versions
Node-API-API is a C API that ensures ABI stability across Node.js versions
and different compiler levels. A C++ API can be easier to use.
To support using C++, the project maintains a
C++ wrapper module called [`node-addon-api`][].
This wrapper provides an inlineable C++ API. Binaries built
with `node-addon-api` will depend on the symbols for the N-API C-based
with `node-addon-api` will depend on the symbols for the Node-API C-based
functions exported by Node.js. `node-addon-api` is a more
efficient way to write code that calls N-API. Take, for example, the
efficient way to write code that calls Node-API. Take, for example, the
following `node-addon-api` code. The first section shows the
`node-addon-api` code and the second section shows what actually gets
used in the addon.
@@ -78,13 +77,13 @@ it still gets the benefits of the ABI stability provided by the C API.
When using `node-addon-api` instead of the C APIs, start with the API [docs][]
for `node-addon-api`.
The [N-API Resource](https://nodejs.github.io/node-addon-examples/) offers an
excellent orientation and tips for developers just getting started with N-API
and `node-addon-api`.
The [Node-API Resource](https://nodejs.github.io/node-addon-examples/) offers
an excellent orientation and tips for developers just getting started with
Node-API and `node-addon-api`.
## Implications of ABI stability
Although N-API provides an ABI stability guarantee, other parts of Node.js do
Although Node-API provides an ABI stability guarantee, other parts of Node.js do
not, and any external libraries used from the addon may not. In particular,
none of the following APIs provide an ABI stability guarantee across major
versions:
@@ -111,19 +110,19 @@ versions:
```
Thus, for an addon to remain ABI-compatible across Node.js major versions, it
must use N-API exclusively by restricting itself to using
must use Node-API exclusively by restricting itself to using
```c
#include <node_api.h>
```
and by checking, for all external libraries that it uses, that the external
library makes ABI stability guarantees similar to N-API.
library makes ABI stability guarantees similar to Node-API.
## Building
Unlike modules written in JavaScript, developing and deploying Node.js
native addons using N-API requires an additional set of tools. Besides the
native addons using Node-API requires an additional set of tools. Besides the
basic tools required to develop for Node.js, the native addon developer
requires a toolchain that can compile C and C++ code into a binary. In
addition, depending upon how the native addon is deployed, the *user* of
@@ -207,15 +206,15 @@ available to the module user when the native module is installed.
## Usage
In order to use the N-API functions, include the file [`node_api.h`][] which is
located in the src directory in the node development tree:
In order to use the Node-API functions, include the file [`node_api.h`][] which
is located in the src directory in the node development tree:
```c
#include <node_api.h>
```
This will opt into the default `NAPI_VERSION` for the given release of Node.js.
In order to ensure compatibility with specific versions of N-API, the version
In order to ensure compatibility with specific versions of Node-API, the version
can be specified explicitly when including the header:
```c
@@ -223,10 +222,10 @@ can be specified explicitly when including the header:
#include <node_api.h>
```
This restricts the N-API surface to just the functionality that was available in
the specified (and earlier) versions.
This restricts the Node-API surface to just the functionality that was available
in the specified (and earlier) versions.
Some of the N-API surface is experimental and requires explicit opt-in:
Some of the Node-API surface is experimental and requires explicit opt-in:
```c
#define NAPI_EXPERIMENTAL
@@ -236,9 +235,9 @@ Some of the N-API surface is experimental and requires explicit opt-in:
In this case the entire API surface, including any experimental APIs, will be
available to the module code.
## N-API version matrix
## Node-API version matrix
N-API versions are additive and versioned independently from Node.js.
Node-API versions are additive and versioned independently from Node.js.
Version 4 is an extension to version 3 in that it has all of the APIs
from version 3 with some additions. This means that it is not necessary
to recompile for new versions of Node.js which are
@@ -325,37 +324,38 @@ listed as supporting a later version.
</tr>
</table>
\* N-API was experimental.
\* Node-API was experimental.
\*\* Node.js 8.0.0 included N-API as experimental. It was released as N-API
version 1 but continued to evolve until Node.js 8.6.0. The API is different in
versions prior to Node.js 8.6.0. We recommend N-API version 3 or later.
\*\* Node.js 8.0.0 included Node-API as experimental. It was released as
Node-API version 1 but continued to evolve until Node.js 8.6.0. The API is
different in versions prior to Node.js 8.6.0. We recommend Node-API version 3 or
later.
Each API documented for N-API will have a header named `added in:`, and APIs
which are stable will have the additional header `N-API version:`.
Each API documented for Node-API will have a header named `added in:`, and APIs
which are stable will have the additional header `Node-API version:`.
APIs are directly usable when using a Node.js version which supports
the N-API version shown in `N-API version:` or higher.
the Node-API version shown in `Node-API version:` or higher.
When using a Node.js version that does not support the
`N-API version:` listed or if there is no `N-API version:` listed,
`Node-API version:` listed or if there is no `Node-API version:` listed,
then the API will only be available if
`#define NAPI_EXPERIMENTAL` precedes the inclusion of `node_api.h`
or `js_native_api.h`. If an API appears not to be available on
a version of Node.js which is later than the one shown in `added in:` then
this is most likely the reason for the apparent absence.
The N-APIs associated strictly with accessing ECMAScript features from native
The Node-APIs associated strictly with accessing ECMAScript features from native
code can be found separately in `js_native_api.h` and `js_native_api_types.h`.
The APIs defined in these headers are included in `node_api.h` and
`node_api_types.h`. The headers are structured in this way in order to allow
implementations of N-API outside of Node.js. For those implementations the
implementations of Node-API outside of Node.js. For those implementations the
Node.js specific APIs may not be applicable.
The Node.js-specific parts of an addon can be separated from the code that
exposes the actual functionality to the JavaScript environment so that the
latter may be used with multiple implementations of N-API. In the example below,
`addon.c` and `addon.h` refer only to `js_native_api.h`. This ensures that
`addon.c` can be reused to compile against either the Node.js implementation of
N-API or any implementation of N-API outside of Node.js.
latter may be used with multiple implementations of Node-API. In the example
below, `addon.c` and `addon.h` refer only to `js_native_api.h`. This ensures
that `addon.c` can be reused to compile against either the Node.js
implementation of Node-API or any implementation of Node-API outside of Node.js.
`addon_node.c` is a separate file that contains the Node.js specific entry point
to the addon and which instantiates the addon by calling into `addon.c` when the
@@ -456,8 +456,8 @@ Native addons may need to allocate global state which they use during
their entire life cycle such that the state must be unique to each instance of
the addon.
To this end, N-API provides a way to allocate data such that its life cycle is
tied to the life cycle of the Agent.
To this end, Node-API provides a way to allocate data such that its life cycle
is tied to the life cycle of the Agent.
### napi_set_instance_data
<!-- YAML
@@ -474,7 +474,7 @@ napi_status napi_set_instance_data(napi_env env,
void* finalize_hint);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] data`: The data item to make available to bindings of this instance.
* `[in] finalize_cb`: The function to call when the environment is being torn
down. The function receives `data` so that it might free it.
@@ -503,7 +503,7 @@ napi_status napi_get_instance_data(napi_env env,
void** data);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[out] data`: The data item that was previously associated with the currently
running Agent by a call to `napi_set_instance_data()`.
@@ -513,18 +513,18 @@ This API retrieves data that was previously associated with the currently
running Agent via `napi_set_instance_data()`. If no data is set, the call will
succeed and `data` will be set to `NULL`.
## Basic N-API data types
## Basic Node-API data types
N-API exposes the following fundamental datatypes as abstractions that are
Node-API exposes the following fundamental datatypes as abstractions that are
consumed by the various APIs. These APIs should be treated as opaque,
introspectable only with other N-API calls.
introspectable only with other Node-API calls.
### napi_status
<!-- YAML
added: v8.0.0
napiVersion: 1
-->
Integral status code indicating the success or failure of a N-API call.
Integral status code indicating the success or failure of a Node-API call.
Currently, the following status codes are supported.
```c
@@ -578,18 +578,18 @@ typedef struct {
not implemented for any VM.
* `engine_error_code`: VM-specific error code. This is currently
not implemented for any VM.
* `error_code`: The N-API status code that originated with the last error.
* `error_code`: The Node-API status code that originated with the last error.
See the [Error handling][] section for additional information.
### napi_env
`napi_env` is used to represent a context that the underlying N-API
`napi_env` is used to represent a context that the underlying Node-API
implementation can use to persist VM-specific state. This structure is passed
to native functions when they're invoked, and it must be passed back when
making N-API calls. Specifically, the same `napi_env` that was passed in when
making Node-API calls. Specifically, the same `napi_env` that was passed in when
the initial native function was called must be passed to any subsequent
nested N-API calls. Caching the `napi_env` for the purpose of general reuse,
nested Node-API calls. Caching the `napi_env` for the purpose of general reuse,
and passing the `napi_env` between instances of the same addon running on
different [`Worker`][] threads is not allowed. The `napi_env` becomes invalid
when an instance of a native addon is unloaded. Notification of this event is
@@ -645,14 +645,14 @@ typedef enum {
} napi_threadsafe_function_call_mode;
```
### N-API memory management types
### Node-API memory management types
#### napi_handle_scope
This is an abstraction used to control and modify the lifetime of objects
created within a particular scope. In general, N-API values are created within
the context of a handle scope. When a native method is called from
created within a particular scope. In general, Node-API values are created
within the context of a handle scope. When a native method is called from
JavaScript, a default handle scope will exist. If the user does not explicitly
create a new handle scope, N-API values will be created in the default handle
create a new handle scope, Node-API values will be created in the default handle
scope. For any invocations of code outside the execution of a native method
(for instance, during a libuv callback invocation), the module is required to
create a scope before invoking any functions that can result in the creation
@@ -718,7 +718,7 @@ An opaque value returned by [`napi_add_async_cleanup_hook`][]. It must be passed
to [`napi_remove_async_cleanup_hook`][] when the chain of asynchronous cleanup
events completes.
### N-API callback types
### Node-API callback types
#### napi_callback_info
<!-- YAML
@@ -735,7 +735,7 @@ added: v8.0.0
napiVersion: 1
-->
Function pointer type for user-provided native functions which are to be
exposed to JavaScript via N-API. Callback functions should satisfy the
exposed to JavaScript via Node-API. Callback functions should satisfy the
following signature:
```c
@@ -778,8 +778,8 @@ operations. Callback functions must satisfy the following signature:
typedef void (*napi_async_execute_callback)(napi_env env, void* data);
```
Implementations of this function must avoid making N-API calls that execute
JavaScript or interact with JavaScript objects. N-API calls should be in the
Implementations of this function must avoid making Node-API calls that execute
JavaScript or interact with JavaScript objects. Node-API calls should be in the
`napi_async_complete_callback` instead. Do not use the `napi_env` parameter as
it will likely result in execution of JavaScript.
@@ -816,7 +816,7 @@ The data arriving from the secondary thread via the queue is given in the `data`
parameter and the JavaScript function to call is given in the `js_callback`
parameter.
N-API sets up the environment prior to calling this callback, so it is
Node-API sets up the environment prior to calling this callback, so it is
sufficient to call the JavaScript function via `napi_call_function` rather than
via `napi_make_callback`.
@@ -838,7 +838,7 @@ typedef void (*napi_threadsafe_function_call_js)(napi_env env,
* `[in] context`: The optional data with which the thread-safe function was
created.
* `[in] data`: Data created by the secondary thread. It is the responsibility of
the callback to convert this native data to JavaScript values (with N-API
the callback to convert this native data to JavaScript values (with Node-API
functions) that can be passed as parameters when `js_callback` is invoked.
This pointer is managed entirely by the threads and this callback. Thus this
callback should free the data.
@@ -874,12 +874,12 @@ end of which `handle` must be passed in a call to
## Error handling
N-API uses both return values and JavaScript exceptions for error handling.
Node-API uses both return values and JavaScript exceptions for error handling.
The following sections explain the approach for each case.
### Return values
All of the N-API functions share the same error handling pattern. The
All of the Node-API functions share the same error handling pattern. The
return type of all API functions is `napi_status`.
The return value will be `napi_ok` if the request was successful and
@@ -922,10 +922,10 @@ typedef struct napi_extended_error_info {
* `error_message`: Textual representation of the error that occurred.
* `engine_reserved`: Opaque handle reserved for engine use only.
* `engine_error_code`: VM specific error code.
* `error_code`: n-api status code for the last error.
* `error_code`: Node-API status code for the last error.
[`napi_get_last_error_info`][] returns the information for the last
N-API call that was made.
Node-API call that was made.
Do not rely on the content or format of any of the extended information as it
is not subject to SemVer and may change at any time. It is intended only for
@@ -953,7 +953,7 @@ This API retrieves a `napi_extended_error_info` structure with information
about the last error that occurred.
The content of the `napi_extended_error_info` returned is only valid up until
an n-api function is called on the same `env`.
a Node-API function is called on the same `env`.
Do not rely on the content or format of any of the extended information as it
is not subject to SemVer and may change at any time. It is intended only for
@@ -963,7 +963,7 @@ This API can be called even if there is a pending JavaScript exception.
### Exceptions
Any N-API function call may result in a pending JavaScript exception. This is
Any Node-API function call may result in a pending JavaScript exception. This is
the case for any of the API functions, even those that may not cause the
execution of JavaScript.
@@ -974,10 +974,10 @@ exception is pending and no additional action is required. If the
instead of simply returning immediately, [`napi_is_exception_pending`][]
must be called in order to determine if an exception is pending or not.
In many cases when an N-API function is called and an exception is
In many cases when a Node-API function is called and an exception is
already pending, the function will return immediately with a
`napi_status` of `napi_pending_exception`. However, this is not the case
for all functions. N-API allows a subset of the functions to be
for all functions. Node-API allows a subset of the functions to be
called to allow for some minimal cleanup before returning to JavaScript.
In that case, `napi_status` will reflect the status for the function. It
will not reflect previous pending exceptions. To avoid confusion, check
@@ -988,7 +988,7 @@ When an exception is pending one of two approaches can be employed.
The first approach is to do any appropriate cleanup and then return so that
execution will return to JavaScript. As part of the transition back to
JavaScript, the exception will be thrown at the point in the JavaScript
code where the native method was invoked. The behavior of most N-API calls
code where the native method was invoked. The behavior of most Node-API calls
is unspecified while an exception is pending, and many will simply return
`napi_pending_exception`, so do as little as possible and then return to
JavaScript where the exception can be handled.
@@ -1021,7 +1021,7 @@ generated internally. The goal is for applications to use these
error codes for all error checking. The associated error messages
will remain, but will only be meant to be used for logging and
display with the expectation that the message can change without
SemVer applying. In order to support this model with N-API, both
SemVer applying. In order to support this model with Node-API, both
in internal functionality and for module specific functionality
(as its good practice), the `throw_` and `create_` functions
take an optional code parameter which is the string for the code
@@ -1293,7 +1293,7 @@ This API can be called even if there is a pending JavaScript exception.
## Object lifetime management
As N-API calls are made, handles to objects in the heap for the underlying
As Node-API calls are made, handles to objects in the heap for the underlying
VM may be returned as `napi_values`. These handles must hold the
objects 'live' until they are no longer required by the native code,
otherwise the objects could be collected before the native code was
@@ -1307,7 +1307,7 @@ held live for the lifespan of the native method call.
In many cases, however, it is necessary that the handles remain valid for
either a shorter or longer lifespan than that of the native method.
The sections which follow describe the N-API functions that can be used
The sections which follow describe the Node-API functions that can be used
to change the handle lifespan from the default.
### Making handle lifespan shorter than that of the native method
@@ -1331,13 +1331,13 @@ substantial resources. In addition, even though the native code could only
use the most recent handle, all of the associated objects would also be
kept alive since they all share the same scope.
To handle this case, N-API provides the ability to establish a new 'scope' to
To handle this case, Node-API provides the ability to establish a new 'scope' to
which newly created handles will be associated. Once those handles
are no longer required, the scope can be 'closed' and any handles associated
with the scope are invalidated. The methods available to open/close scopes are
[`napi_open_handle_scope`][] and [`napi_close_handle_scope`][].
N-API only supports a single nested hierarchy of scopes. There is only one
Node-API only supports a single nested hierarchy of scopes. There is only one
active scope at any time, and all new handles will be associated with that
scope while it is active. Scopes must be closed in the reverse order from
which they are opened. In addition, all scopes created within a native method
@@ -1368,8 +1368,8 @@ for (int i = 0; i < 1000000; i++) {
```
When nesting scopes, there are cases where a handle from an
inner scope needs to live beyond the lifespan of that scope. N-API supports an
'escapable scope' in order to support this case. An escapable scope
inner scope needs to live beyond the lifespan of that scope. Node-API supports
an 'escapable scope' in order to support this case. An escapable scope
allows one handle to be 'promoted' so that it 'escapes' the
current scope and the lifespan of the handle changes from the current
scope to that of the outer scope.
@@ -1502,7 +1502,7 @@ described in the earlier section. The lifespan of a normal handle is
managed by scopes and all scopes must be closed before the end of a native
method.
N-API provides methods to create persistent references to an object.
Node-API provides methods to create persistent references to an object.
Each persistent reference has an associated count with a value of 0
or higher. The count determines if the reference will keep
the corresponding object live. References with a count of 0 do not
@@ -1646,7 +1646,7 @@ While a Node.js process typically releases all its resources when exiting,
embedders of Node.js, or future Worker support, may require addons to register
clean-up hooks that will be run once the current Node.js instance exits.
N-API provides functions for registering and un-registering such callbacks.
Node-API provides functions for registering and un-registering such callbacks.
When those callbacks are run, all resources that are being held by the addon
should be freed up.
@@ -1770,7 +1770,7 @@ This must be called on any `napi_async_cleanup_hook_handle` value obtained
from [`napi_add_async_cleanup_hook`][].
## Module registration
N-API modules are registered in a manner similar to other modules
Node-API modules are registered in a manner similar to other modules
except that instead of using the `NODE_MODULE` macro the following
is used:
@@ -1778,7 +1778,7 @@ is used:
NAPI_MODULE(NODE_GYP_MODULE_NAME, Init)
```
The next difference is the signature for the `Init` method. For a N-API
The next difference is the signature for the `Init` method. For a Node-API
module it is as follows:
```c
@@ -1788,8 +1788,8 @@ napi_value Init(napi_env env, napi_value exports);
The return value from `Init` is treated as the `exports` object for the module.
The `Init` method is passed an empty object via the `exports` parameter as a
convenience. If `Init` returns `NULL`, the parameter passed as `exports` is
exported by the module. N-API modules cannot modify the `module` object but can
specify anything as the `exports` property of the module.
exported by the module. Node-API modules cannot modify the `module` object but
can specify anything as the `exports` property of the module.
To add the method `hello` as a function so that it can be called as a method
provided by the addon:
@@ -1871,7 +1871,7 @@ NAPI_MODULE_INIT() {
}
```
All N-API addons are context-aware, meaning they may be loaded multiple
All Node-API addons are context-aware, meaning they may be loaded multiple
times. There are a few design considerations when declaring such a module.
The documentation on [context-aware addons][] provides more details.
@@ -1885,19 +1885,19 @@ For more details on building addon modules in general, refer to the existing
API.
## Working with JavaScript values
N-API exposes a set of APIs to create all types of JavaScript values.
Node-API exposes a set of APIs to create all types of JavaScript values.
Some of these types are documented under [Section 6][]
of the [ECMAScript Language Specification][].
Fundamentally, these APIs are used to do one of the following:
1. Create a new JavaScript object
2. Convert from a primitive C type to an N-API value
3. Convert from N-API value to a primitive C type
2. Convert from a primitive C type to a Node-API value
3. Convert from Node-API value to a primitive C type
4. Get global instances including `undefined` and `null`
N-API values are represented by the type `napi_value`.
Any N-API call that requires a JavaScript value takes in a `napi_value`.
Node-API values are represented by the type `napi_value`.
Any Node-API call that requires a JavaScript value takes in a `napi_value`.
In some cases, the API does check the type of the `napi_value` up-front.
However, for better performance, it's better for the caller to make sure that
the `napi_value` in question is of the JavaScript type expected by the API.
@@ -2028,12 +2028,12 @@ napiVersion: 1
napi_status napi_create_array(napi_env env, napi_value* result)
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[out] result`: A `napi_value` representing a JavaScript `Array`.
Returns `napi_ok` if the API succeeded.
This API returns an N-API value corresponding to a JavaScript `Array` type.
This API returns a Node-API value corresponding to a JavaScript `Array` type.
JavaScript arrays are described in
[Section 22.1][] of the ECMAScript Language Specification.
@@ -2055,7 +2055,7 @@ napi_status napi_create_array_with_length(napi_env env,
Returns `napi_ok` if the API succeeded.
This API returns an N-API value corresponding to a JavaScript `Array` type.
This API returns a Node-API value corresponding to a JavaScript `Array` type.
The `Array`'s length property is set to the passed-in length parameter.
However, the underlying buffer is not guaranteed to be pre-allocated by the VM
when the array is created. That behavior is left to the underlying VM
@@ -2086,7 +2086,7 @@ napi_status napi_create_arraybuffer(napi_env env,
Returns `napi_ok` if the API succeeded.
This API returns an N-API value corresponding to a JavaScript `ArrayBuffer`.
This API returns a Node-API value corresponding to a JavaScript `ArrayBuffer`.
`ArrayBuffer`s are used to represent fixed-length binary data buffers. They are
normally used as a backing-buffer for `TypedArray` objects.
The `ArrayBuffer` allocated will have an underlying byte buffer whose size is
@@ -2245,7 +2245,7 @@ napi_create_external_arraybuffer(napi_env env,
Returns `napi_ok` if the API succeeded.
This API returns an N-API value corresponding to a JavaScript `ArrayBuffer`.
This API returns a Node-API value corresponding to a JavaScript `ArrayBuffer`.
The underlying byte buffer of the `ArrayBuffer` is externally allocated and
managed. The caller must ensure that the byte buffer remains valid until the
finalize callback is called.
@@ -2418,7 +2418,7 @@ raised.
JavaScript `DataView` objects are described in
[Section 24.3][] of the ECMAScript Language Specification.
### Functions to convert from C types to N-API
### Functions to convert from C types to Node-API
#### napi_create_int32
<!-- YAML
added: v8.4.0
@@ -2660,7 +2660,7 @@ The native string is copied.
The JavaScript `String` type is described in
[Section 6.1.4][] of the ECMAScript Language Specification.
### Functions to convert from N-API to C types
### Functions to convert from Node-API to C types
#### napi_get_array_length
<!-- YAML
added: v8.0.0
@@ -3252,7 +3252,7 @@ This API returns the Undefined object.
## Working with JavaScript values and abstract operations
N-API exposes a set of APIs to perform some abstract operations on JavaScript
Node-API exposes a set of APIs to perform some abstract operations on JavaScript
values. Some of these operations are documented under [Section 7][]
of the [ECMAScript Language Specification][].
@@ -3616,21 +3616,21 @@ Specification.
## Working with JavaScript properties
N-API exposes a set of APIs to get and set properties on JavaScript
Node-API exposes a set of APIs to get and set properties on JavaScript
objects. Some of these types are documented under [Section 7][] of the
[ECMAScript Language Specification][].
Properties in JavaScript are represented as a tuple of a key and a value.
Fundamentally, all property keys in N-API can be represented in one of the
Fundamentally, all property keys in Node-API can be represented in one of the
following forms:
* Named: a simple UTF8-encoded string
* Integer-Indexed: an index value represented by `uint32_t`
* JavaScript value: these are represented in N-API by `napi_value`. This can
* JavaScript value: these are represented in Node-API by `napi_value`. This can
be a `napi_value` representing a `String`, `Number`, or `Symbol`.
N-API values are represented by the type `napi_value`.
Any N-API call that requires a JavaScript value takes in a `napi_value`.
Node-API values are represented by the type `napi_value`.
Any Node-API call that requires a JavaScript value takes in a `napi_value`.
However, it's the caller's responsibility to make sure that the
`napi_value` in question is of the JavaScript type expected by the API.
@@ -3645,7 +3645,7 @@ const obj = {};
obj.myProp = 123;
```
The equivalent can be done using N-API values with the following snippet:
The equivalent can be done using Node-API values with the following snippet:
```c
napi_status status = napi_generic_failure;
@@ -3672,7 +3672,7 @@ const arr = [];
arr[123] = 'hello';
```
The equivalent can be done using N-API values with the following snippet:
The equivalent can be done using Node-API values with the following snippet:
```c
napi_status status = napi_generic_failure;
@@ -3699,7 +3699,7 @@ const arr = [];
const value = arr[123];
```
The following is the approximate equivalent of the N-API counterpart:
The following is the approximate equivalent of the Node-API counterpart:
```c
napi_status status = napi_generic_failure;
@@ -3725,7 +3725,7 @@ Object.defineProperties(obj, {
});
```
The following is the approximate equivalent of the N-API counterpart:
The following is the approximate equivalent of the Node-API counterpart:
```c
napi_status status = napi_status_generic_failure;
@@ -3835,12 +3835,12 @@ typedef struct {
If this is passed in, set `value` and `method` to `NULL` (since these members
won't be used). The given function is called implicitly by the runtime when
the property is accessed from JavaScript code (or if a get on the property is
performed using a N-API call). [`napi_callback`][] provides more details.
performed using a Node-API call). [`napi_callback`][] provides more details.
* `setter`: A function to call when a set access of the property is performed.
If this is passed in, set `value` and `method` to `NULL` (since these members
won't be used). The given function is called implicitly by the runtime when
the property is set from JavaScript code (or if a set on the property is
performed using a N-API call). [`napi_callback`][] provides more details.
performed using a Node-API call). [`napi_callback`][] provides more details.
* `method`: Set this to make the property descriptor object's `value`
property to be a JavaScript function represented by `method`. If this is
passed in, set `value`, `getter` and `setter` to `NULL` (since these members
@@ -3863,7 +3863,7 @@ napi_status napi_get_property_names(napi_env env,
napi_value* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object from which to retrieve the properties.
* `[out] result`: A `napi_value` representing an array of JavaScript values
that represent the property names of the object. The API can be used to
@@ -3894,7 +3894,7 @@ napi_get_all_property_names(napi_env env,
napi_value* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object from which to retrieve the properties.
* `[in] key_mode`: Whether to retrieve prototype properties as well.
* `[in] key_filter`: Which properties to retrieve
@@ -3922,7 +3922,7 @@ napi_status napi_set_property(napi_env env,
napi_value value);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object on which to set the property.
* `[in] key`: The name of the property to set.
* `[in] value`: The property value.
@@ -3944,7 +3944,7 @@ napi_status napi_get_property(napi_env env,
napi_value* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object from which to retrieve the property.
* `[in] key`: The name of the property to retrieve.
* `[out] result`: The value of the property.
@@ -3966,7 +3966,7 @@ napi_status napi_has_property(napi_env env,
bool* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object to query.
* `[in] key`: The name of the property whose existence to check.
* `[out] result`: Whether the property exists on the object or not.
@@ -3988,7 +3988,7 @@ napi_status napi_delete_property(napi_env env,
bool* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object to query.
* `[in] key`: The name of the property to delete.
* `[out] result`: Whether the property deletion succeeded or not. `result` can
@@ -4011,7 +4011,7 @@ napi_status napi_has_own_property(napi_env env,
bool* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object to query.
* `[in] key`: The name of the own property whose existence to check.
* `[out] result`: Whether the own property exists on the object or not.
@@ -4019,7 +4019,7 @@ napi_status napi_has_own_property(napi_env env,
Returns `napi_ok` if the API succeeded.
This API checks if the `Object` passed in has the named own property. `key` must
be a string or a `Symbol`, or an error will be thrown. N-API will not perform
be a string or a `Symbol`, or an error will be thrown. Node-API will not perform
any conversion between data types.
#### napi_set_named_property
@@ -4035,7 +4035,7 @@ napi_status napi_set_named_property(napi_env env,
napi_value value);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object on which to set the property.
* `[in] utf8Name`: The name of the property to set.
* `[in] value`: The property value.
@@ -4058,7 +4058,7 @@ napi_status napi_get_named_property(napi_env env,
napi_value* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object from which to retrieve the property.
* `[in] utf8Name`: The name of the property to get.
* `[out] result`: The value of the property.
@@ -4081,7 +4081,7 @@ napi_status napi_has_named_property(napi_env env,
bool* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object to query.
* `[in] utf8Name`: The name of the property whose existence to check.
* `[out] result`: Whether the property exists on the object or not.
@@ -4104,7 +4104,7 @@ napi_status napi_set_element(napi_env env,
napi_value value);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object from which to set the properties.
* `[in] index`: The index of the property to set.
* `[in] value`: The property value.
@@ -4126,7 +4126,7 @@ napi_status napi_get_element(napi_env env,
napi_value* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object from which to retrieve the property.
* `[in] index`: The index of the property to get.
* `[out] result`: The value of the property.
@@ -4148,7 +4148,7 @@ napi_status napi_has_element(napi_env env,
bool* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object to query.
* `[in] index`: The index of the property whose existence to check.
* `[out] result`: Whether the property exists on the object or not.
@@ -4171,7 +4171,7 @@ napi_status napi_delete_element(napi_env env,
bool* result);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object to query.
* `[in] index`: The index of the property to delete.
* `[out] result`: Whether the element deletion succeeded or not. `result` can
@@ -4194,7 +4194,7 @@ napi_status napi_define_properties(napi_env env,
const napi_property_descriptor* properties);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object from which to retrieve the properties.
* `[in] property_count`: The number of elements in the `properties` array.
* `[in] properties`: The array of property descriptors.
@@ -4222,7 +4222,7 @@ napi_status napi_object_freeze(napi_env env,
napi_value object);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object to freeze.
Returns `napi_ok` if the API succeeded.
@@ -4249,7 +4249,7 @@ napi_status napi_object_seal(napi_env env,
napi_value object);
```
* `[in] env`: The environment that the N-API call is invoked under.
* `[in] env`: The environment that the Node-API call is invoked under.
* `[in] object`: The object to seal.
Returns `napi_ok` if the API succeeded.
@@ -4261,8 +4261,8 @@ of the ECMA-262 specification.
## Working with JavaScript functions
N-API provides a set of APIs that allow JavaScript code to
call back into native code. N-API APIs that support calling back
Node-API provides a set of APIs that allow JavaScript code to
call back into native code. Node-APIs that support calling back
into native code take in a callback functions represented by
the `napi_callback` type. When the JavaScript VM calls back to
native code, the `napi_callback` function provided is invoked. The APIs
@@ -4273,7 +4273,7 @@ following:
* Get the arguments passed into the callback.
* Return a `napi_value` back from the callback.
Additionally, N-API provides a set of functions which allow calling
Additionally, Node-API provides a set of functions which allow calling
JavaScript functions from native code. One can either call a function
like a regular JavaScript function call, or as a constructor
function.
@@ -4522,7 +4522,7 @@ const arg = 'hello';
const value = new MyObject(arg);
```
The following can be approximated in N-API using the following snippet:
The following can be approximated in Node-API using the following snippet:
```c
// Get the constructor function MyObject
@@ -4548,7 +4548,7 @@ Returns `napi_ok` if the API succeeded.
## Object wrap
N-API offers a way to "wrap" C++ classes and instances so that the class
Node-API offers a way to "wrap" C++ classes and instances so that the class
constructor and methods can be called from JavaScript.
1. The [`napi_define_class`][] API defines a JavaScript class with constructor,
@@ -4635,9 +4635,9 @@ case, the database handle instance can appear as a query handle instance, and it
will pass the `napi_instanceof()` test for a query handle instance, while still
containing a pointer to a database handle.
To this end, N-API provides type-tagging capabilities.
To this end, Node-API provides type-tagging capabilities.
A type tag is a 128-bit integer unique to the addon. N-API provides the
A type tag is a 128-bit integer unique to the addon. Node-API provides the
`napi_type_tag` structure for storing a type tag. When such a value is passed
along with a JavaScript object stored in a `napi_value` to
`napi_type_tag_object()`, the JavaScript object will be "marked" with the
@@ -5011,10 +5011,10 @@ implementation. This allows them to schedule work to be executed asynchronously
so that their methods can return in advance of the work being completed. This
allows them to avoid blocking overall execution of the Node.js application.
N-API provides an ABI-stable interface for these
Node-API provides an ABI-stable interface for these
supporting functions which covers the most common asynchronous use cases.
N-API defines the `napi_async_work` structure which is used to manage
Node-API defines the `napi_async_work` structure which is used to manage
asynchronous workers. Instances are created/deleted with
[`napi_create_async_work`][] and [`napi_delete_async_work`][].
@@ -5022,9 +5022,9 @@ The `execute` and `complete` callbacks are functions that will be
invoked when the executor is ready to execute and when it completes its
task respectively.
The `execute` function should avoid making any N-API calls
The `execute` function should avoid making any Node-API calls
that could result in the execution of JavaScript or interaction with
JavaScript objects. Most often, any code that needs to make N-API
JavaScript objects. Most often, any code that needs to make Node-API
calls should be made in `complete` callback instead.
Avoid using the `napi_env` parameter in the execute callback as
it will likely execute JavaScript.
@@ -5316,7 +5316,7 @@ NAPI_EXTERN napi_status napi_open_callback_scope(napi_env env,
There are cases (for example, resolving promises) where it is
necessary to have the equivalent of the scope associated with a callback
in place when making certain N-API calls. If there is no other script on
in place when making certain Node-API calls. If there is no other script on
the stack the [`napi_open_callback_scope`][] and
[`napi_close_callback_scope`][] functions can be used to open/close
the required scope.
@@ -5380,12 +5380,12 @@ napi_status napi_get_version(napi_env env,
```
* `[in] env`: The environment that the API is invoked under.
* `[out] result`: The highest version of N-API supported.
* `[out] result`: The highest version of Node-API supported.
Returns `napi_ok` if the API succeeded.
This API returns the highest N-API version supported by the
Node.js runtime. N-API is planned to be additive such that
This API returns the highest Node-API version supported by the
Node.js runtime. Node-API is planned to be additive such that
newer releases of Node.js may support additional API functions.
In order to allow an addon to use a newer function when running with
versions of Node.js that support it, while providing
@@ -5427,7 +5427,7 @@ often than it would otherwise.
## Promises
N-API provides facilities for creating `Promise` objects as described in
Node-API provides facilities for creating `Promise` objects as described in
[Section 25.4][] of the ECMA specification. It implements promises as a pair of
objects. When a promise is created by `napi_create_promise()`, a "deferred"
object is created and returned alongside the `Promise`. The deferred object is
@@ -5572,7 +5572,7 @@ napi_status napi_is_promise(napi_env env,
## Script execution
N-API provides an API for executing a string containing JavaScript using the
Node-API provides an API for executing a string containing JavaScript using the
underlying JavaScript engine.
### napi_run_script
@@ -5606,7 +5606,7 @@ the following caveats:
## libuv event loop
N-API provides a function for getting the current event loop associated with
Node-API provides a function for getting the current event loop associated with
a specific `napi_env`.
### napi_get_uv_event_loop
@@ -5628,7 +5628,7 @@ NAPI_EXTERN napi_status napi_get_uv_event_loop(napi_env env,
## Asynchronous thread-safe function calls
JavaScript functions can normally only be called from a native addon's main
thread. If an addon creates additional threads, then N-API functions that
thread. If an addon creates additional threads, then Node-API functions that
require a `napi_env`, `napi_value`, or `napi_ref` must not be called from those
threads.
@@ -5690,7 +5690,7 @@ remain in the queue that may need to be freed. This normally occurs when the
Node.js process exits while there is a thread-safe function still active.
It is not necessary to call into JavaScript via `napi_make_callback()` because
N-API runs `call_js_cb` in a context appropriate for callbacks.
Node-API runs `call_js_cb` in a context appropriate for callbacks.
### Reference counting of thread-safe functions

14
doc/guides/adding-new-napi-api.md
View File

@@ -1,11 +1,11 @@
# Contributing a new API to N-API
# Contributing a new API to Node-API
N-API is the next-generation ABI-stable API for native modules.
Node-API is the next-generation ABI-stable API for native modules.
While improving the API surface is encouraged and welcomed, the following are
a set of principles and guidelines to keep in mind while adding a new
N-API API.
Node-API.
* A new API **must** adhere to N-API API shape and spirit.
* A new API **must** adhere to Node-API API shape and spirit.
* **Must** be a C API.
* **Must** not throw exceptions.
* **Must** return `napi_status`.
@@ -14,7 +14,7 @@ N-API API.
datatypes or opaque handles.
* **Must** be a necessary API and not a nice to have. Convenience APIs
belong in node-addon-api.
* **Must** not change the signature of an existing N-API API or break
* **Must** not change the signature of an existing Node-API API or break
ABI compatibility with other versions of Node.js.
* New API **should** be agnostic towards the underlying JavaScript VM.
* New API PRs **must** have a corresponding documentation update.
@@ -23,9 +23,9 @@ N-API API.
* There **should** be at least one test case per interesting use of the API.
* There **should** be a sample provided that operates in a realistic way
(operating how a real addon would be written).
* A new API **should** be discussed at the N-API team meeting.
* A new API **should** be discussed at the Node-API team meeting.
* A new API addition **must** be signed off by at least two members of
the N-API team.
the Node-API team.
* A new API addition **should** be simultaneously implemented in at least
one other VM implementation of Node.js.
* A new API **must** be considered experimental for at least one minor

12
doc/guides/collaborator-guide.md
View File

@@ -22,7 +22,7 @@
* [Unintended breaking changes](#unintended-breaking-changes)
* [Reverting commits](#reverting-commits)
* [Introducing new modules](#introducing-new-modules)
* [Additions to N-API](#additions-to-n-api)
* [Additions to Node-API](#additions-to-n-api)
* [Deprecations](#deprecations)
* [Involving the TSC](#involving-the-tsc)
* [Landing pull requests](#landing-pull-requests)
@@ -373,12 +373,12 @@ For pull requests introducing new core modules:
* Land with a [Stability Index][] of Experimental. The module must remain
Experimental until a semver-major release.
### Additions to N-API
### Additions to Node-API
N-API provides an ABI-stable API guaranteed for future Node.js versions. N-API
additions call for unusual care and scrutiny. If a change adds to `node_api.h`,
`js_native_api.h`, `node_api_types.h`, or `js_native_api_types.h`, consult [the relevant
guide](https://github.com/nodejs/node/blob/master/doc/guides/adding-new-napi-api.md).
Node-API provides an ABI-stable API guaranteed for future Node.js versions.
Node-API additions call for unusual care and scrutiny. If a change adds to
`node_api.h`, `js_native_api.h`, `node_api_types.h`, or `js_native_api_types.h`,
consult [the relevant guide](https://github.com/nodejs/node/blob/master/doc/guides/adding-new-napi-api.md).
### Deprecations