GeezerVison

Node-API#

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 Node-API are used.

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 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 napi_value.
• In case of an error status code, additional information can be obtained using napi_get_last_error_info. More information can be found in the error handling section Error handling.

Writing addons in various programming languages#

Node-API is a C API that ensures ABI stability across Node.js versions and different compiler levels. With this stability guarantee, it is possible to write addons in other programming languages on top of Node-API. Refer to language and engine bindings for more programming languages and engines support details.

node-addon-api is the official C++ binding that provides a more efficient way to write C++ code that calls Node-API. This wrapper is a header-only library that offers an inlinable C++ API. Binaries built with node-addon-api will depend on the symbols of the Node-API C-based functions exported by Node.js. The following code snippet is an example of node-addon-api:

Object obj = Object::New(env);
obj["foo"] = String::New(env, "bar");
cpp

The above node-addon-api C++ code is equivalent to the following C-based Node-API code:

napi_status status;
napi_value object, string;
status = napi_create_object(env, &object);
if (status != napi_ok) {
  napi_throw_error(env, ...);
  return;
}

status = napi_create_string_utf8(env, "bar", NAPI_AUTO_LENGTH, &string);
if (status != napi_ok) {
  napi_throw_error(env, ...);
  return;
}

status = napi_set_named_property(env, object, "foo", string);
if (status != napi_ok) {
  napi_throw_error(env, ...);
  return;
}
cpp

The end result is that the addon only uses the exported C APIs. Even though the addon is written in C++, it still gets the benefits of the ABI stability provided by the C Node-API.

When using node-addon-api instead of the C APIs, start with the API docs for node-addon-api.

The Node-API Resource offers an excellent orientation and tips for developers just getting started with Node-API and node-addon-api. Additional media resources can be found on the Node-API Media page.

Implications of ABI stability#

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:

• the Node.js C++ APIs available via any of

  #include <node.h>
  #include <node_buffer.h>
  #include <node_version.h>
  #include <node_object_wrap.h>
  cpp

• the libuv APIs which are also included with Node.js and available via

  #include <uv.h>
  cpp

• the V8 API available via

  #include <v8.h>
  cpp

Thus, for an addon to remain ABI-compatible across Node.js major versions, it must use Node-API exclusively by restricting itself to using

#include <node_api.h>
c

and by checking, for all external libraries that it uses, that the external library makes ABI stability guarantees similar to Node-API.

Enum values in ABI stability#

All enum data types defined in Node-API should be considered as a fixed size int32_t value. Bit flag enum types should be explicitly documented, and they work with bit operators like bit-OR (|) as a bit value. Unless otherwise documented, an enum type should be considered to be extensible.

A new enum value will be added at the end of the enum definition. An enum value will not be removed or renamed.

For an enum type returned from a Node-API function, or provided as an out parameter of a Node-API function, the value is an integer value and an addon should handle unknown values. New values are allowed to be introduced without a version guard. For example, when checking napi_status in switch statements, an addon should include a default branch, as new status codes may be introduced in newer Node.js versions.

For an enum type used in an in-parameter, the result of passing an unknown integer value to Node-API functions is undefined unless otherwise documented. A new value is added with a version guard to indicate the Node-API version in which it was introduced. For example, napi_get_all_property_names can be extended with new enum value of napi_key_filter.

For an enum type used in both in-parameters and out-parameters, new values are allowed to be introduced without a version guard.

Building#

Unlike modules written in JavaScript, developing and deploying Node.js 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 the native addon will also need to have a C/C++ toolchain installed.

For Linux developers, the necessary C/C++ toolchain packages are readily available. GCC is widely used in the Node.js community to build and test across a variety of platforms. For many developers, the LLVM compiler infrastructure is also a good choice.

For Mac developers, Xcode offers all the required compiler tools. However, it is not necessary to install the entire Xcode IDE. The following command installs the necessary toolchain:

xcode-select --install
bash

For Windows developers, Visual Studio offers all the required compiler tools. However, it is not necessary to install the entire Visual Studio IDE. The following command installs the necessary toolchain:

npm install --global windows-build-tools
bash

The sections below describe the additional tools available for developing and deploying Node.js native addons.

Build tools#

Both the tools listed here require that users of the native addon have a C/C++ toolchain installed in order to successfully install the native addon.

node-gyp#

node-gyp is a build system based on the gyp-next tool and comes bundled with npm. node-gyp requires that Python be installed.

Historically, node-gyp has been the tool of choice for building native addons. It has widespread adoption and documentation. However, some developers have run into limitations in node-gyp.

CMake.js#

CMake.js is an alternative build system based on CMake.

CMake.js is a good choice for projects that already use CMake or for developers affected by limitations in node-gyp. build_with_cmake is an example of a CMake-based native addon project.

Uploading precompiled binaries#

The three tools listed here permit native addon developers and maintainers to create and upload binaries to public or private servers. These tools are typically integrated with CI/CD build systems like Travis CI and AppVeyor to build and upload binaries for a variety of platforms and architectures. These binaries are then available for download by users who do not need to have a C/C++ toolchain installed.

node-pre-gyp#

node-pre-gyp is a tool based on node-gyp that adds the ability to upload binaries to a server of the developer's choice. node-pre-gyp has particularly good support for uploading binaries to Amazon S3.

prebuild#

prebuild is a tool that supports builds using either node-gyp or CMake.js. Unlike node-pre-gyp which supports a variety of servers, prebuild uploads binaries only to GitHub releases. prebuild is a good choice for GitHub projects using CMake.js.

prebuildify#

prebuildify is a tool based on node-gyp. The advantage of prebuildify is that the built binaries are bundled with the native addon when it's uploaded to npm. The binaries are downloaded from npm and are immediately available to the module user when the native addon is installed.

Usage#

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:

#include <node_api.h>
c

This will opt into the default NAPI_VERSION for the given release of Node.js. In order to ensure compatibility with specific versions of Node-API, the version can be specified explicitly when including the header:

#define NAPI_VERSION 3
#include <node_api.h>
c

This restricts the Node-API surface to just the functionality that was available in the specified (and earlier) versions.

Some of the Node-API surface is experimental and requires explicit opt-in:

#define NAPI_EXPERIMENTAL
#include <node_api.h>
c

In this case the entire API surface, including any experimental APIs, will be available to the module code.

Occasionally, experimental features are introduced that affect already-released and stable APIs. These features can be disabled by an opt-out:

#define NAPI_EXPERIMENTAL
#define NODE_API_EXPERIMENTAL_<FEATURE_NAME>_OPT_OUT
#include <node_api.h>
c

where <FEATURE_NAME> is the name of an experimental feature that affects both experimental and stable APIs.

Node-API version matrix#

Up until version 9, Node-API versions were additive and versioned independently from Node.js. This meant that any version was an extension to the previous version in that it had all of the APIs from the previous version with some additions. Each Node.js version only supported a single Node-API version. For example v18.15.0 supports only Node-API version 8. ABI stability was achieved because 8 was a strict superset of all previous versions.

As of version 9, while Node-API versions continue to be versioned independently, an add-on that ran with Node-API version 9 may need code updates to run with Node-API version 10. ABI stability is maintained, however, because Node.js versions that support Node-API versions higher than 8 will support all versions between 8 and the highest version they support and will default to providing the version 8 APIs unless an add-on opts into a higher Node-API version. This approach provides the flexibility of better optimizing existing Node-API functions while maintaining ABI stability. Existing add-ons can continue to run without recompilation using an earlier version of Node-API. If an add-on needs functionality from a newer Node-API version, changes to existing code and recompilation will be needed to use those new functions anyway.

In versions of Node.js that support Node-API version 9 and later, defining NAPI_VERSION=X and using the existing add-on initialization macros will bake in the requested Node-API version that will be used at runtime into the add-on. If NAPI_VERSION is not set it will default to 8.

This table may not be up to date in older streams, the most up to date information is in the latest API documentation in: Node-API version matrix

* Node-API was experimental.

** 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 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 Node-API version shown in Node-API version: or higher. When using a Node.js version that does not support the 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 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 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 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 addon is loaded into a Node.js environment.

// addon.h
#ifndef _ADDON_H_
#define _ADDON_H_
#include <js_native_api.h>
napi_value create_addon(napi_env env);
#endif  // _ADDON_H_
c

// addon.c
#include "addon.h"

#define NODE_API_CALL(env, call)                                  \
  do {                                                            \
    napi_status status = (call);                                  \
    if (status != napi_ok) {                                      \
      const napi_extended_error_info* error_info = NULL;          \
      napi_get_last_error_info((env), &error_info);               \
      const char* err_message = error_info->error_message;        \
      bool is_pending;                                            \
      napi_is_exception_pending((env), &is_pending);              \
      /* If an exception is already pending, don't rethrow it */  \
      if (!is_pending) {                                          \
        const char* message = (err_message == NULL)               \
            ? "empty error message"                               \
            : err_message;                                        \
        napi_throw_error((env), NULL, message);                   \
      }                                                           \
      return NULL;                                                \
    }                                                             \
  } while(0)

static napi_value
DoSomethingUseful(napi_env env, napi_callback_info info) {
  // Do something useful.
  return NULL;
}

napi_value create_addon(napi_env env) {
  napi_value result;
  NODE_API_CALL(env, napi_create_object(env, &result));

  napi_value exported_function;
  NODE_API_CALL(env, napi_create_function(env,
                                          "doSomethingUseful",
                                          NAPI_AUTO_LENGTH,
                                          DoSomethingUseful,
                                          NULL,
                                          &exported_function));

  NODE_API_CALL(env, napi_set_named_property(env,
                                             result,
                                             "doSomethingUseful",
                                             exported_function));

  return result;
}
c

// addon_node.c
#include <node_api.h>
#include "addon.h"

NAPI_MODULE_INIT(/* napi_env env, napi_value exports */) {
  // This function body is expected to return a `napi_value`.
  // The variables `napi_env env` and `napi_value exports` may be used within
  // the body, as they are provided by the definition of `NAPI_MODULE_INIT()`.
  return create_addon(env);
}
c

Environment life cycle APIs#

Section Agents of the ECMAScript Language Specification defines the concept of an "Agent" as a self-contained environment in which JavaScript code runs. Multiple such Agents may be started and terminated either concurrently or in sequence by the process.

A Node.js environment corresponds to an ECMAScript Agent. In the main process, an environment is created at startup, and additional environments can be created on separate threads to serve as worker threads. When Node.js is embedded in another application, the main thread of the application may also construct and destroy a Node.js environment multiple times during the life cycle of the application process such that each Node.js environment created by the application may, in turn, during its life cycle create and destroy additional environments as worker threads.

From the perspective of a native addon this means that the bindings it provides may be called multiple times, from multiple contexts, and even concurrently from multiple threads.

Native addons may need to allocate global state which they use during their life cycle of an Node.js environment such that the state can be unique to each instance of the addon.

To this end, Node-API provides a way to associate data such that its life cycle is tied to the life cycle of a Node.js environment.

napi_set_instance_data#

napi_status napi_set_instance_data(node_api_basic_env env,
                                   void* data,
                                   napi_finalize finalize_cb,
                                   void* finalize_hint);
c

• [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. napi_finalize provides more details.
• [in] finalize_hint: Optional hint to pass to the finalize callback during collection.

Returns napi_ok if the API succeeded.

This API associates data with the currently running Node.js environment. data can later be retrieved using napi_get_instance_data(). Any existing data associated with the currently running Node.js environment which was set by means of a previous call to napi_set_instance_data() will be overwritten. If a finalize_cb was provided by the previous call, it will not be called.

napi_get_instance_data#

napi_status napi_get_instance_data(node_api_basic_env env,
                                   void** data);
c

• [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 Node.js environment by a call to napi_set_instance_data().

Returns napi_ok if the API succeeded.

This API retrieves data that was previously associated with the currently running Node.js environment via napi_set_instance_data(). If no data is set, the call will succeed and data will be set to NULL.

Basic Node-API data types#

Node-API exposes the following fundamental data types as abstractions that are consumed by the various APIs. These APIs should be treated as opaque, introspectable only with other Node-API calls.

napi_status#

Integral status code indicating the success or failure of a Node-API call. Currently, the following status codes are supported.

typedef enum {
  napi_ok,
  napi_invalid_arg,
  napi_object_expected,
  napi_string_expected,
  napi_name_expected,
  napi_function_expected,
  napi_number_expected,
  napi_boolean_expected,
  napi_array_expected,
  napi_generic_failure,
  napi_pending_exception,
  napi_cancelled,
  napi_escape_called_twice,
  napi_handle_scope_mismatch,
  napi_callback_scope_mismatch,
  napi_queue_full,
  napi_closing,
  napi_bigint_expected,
  napi_date_expected,
  napi_arraybuffer_expected,
  napi_detachable_arraybuffer_expected,
  napi_would_deadlock,  /* unused */
  napi_no_external_buffers_allowed,
  napi_cannot_run_js
} napi_status;
c

If additional information is required upon an API returning a failed status, it can be obtained by calling napi_get_last_error_info.

napi_extended_error_info#

typedef struct {
  const char* error_message;
  void* engine_reserved;
  uint32_t engine_error_code;
  napi_status error_code;
} napi_extended_error_info;
c

• error_message: UTF8-encoded string containing a VM-neutral description of the error.
• engine_reserved: Reserved for VM-specific error details. This is currently not implemented for any VM.
• engine_error_code: VM-specific error code. This is currently not implemented for any VM.
• 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 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 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 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 delivered through the callbacks given to napi_add_env_cleanup_hook and napi_set_instance_data.

node_api_basic_env#

This variant of napi_env is passed to synchronous finalizers (node_api_basic_finalize). There is a subset of Node-APIs which accept a parameter of type node_api_basic_env as their first argument. These APIs do not access the state of the JavaScript engine and are thus safe to call from synchronous finalizers. Passing a parameter of type napi_env to these APIs is allowed, however, passing a parameter of type node_api_basic_env to APIs that access the JavaScript engine state is not allowed. Attempting to do so without a cast will produce a compiler warning or an error when add-ons are compiled with flags which cause them to emit warnings and/or errors when incorrect pointer types are passed into a function. Calling such APIs from a synchronous finalizer will ultimately result in the termination of the application.

napi_value#

This is an opaque pointer that is used to represent a JavaScript value.

napi_threadsafe_function#

This is an opaque pointer that represents a JavaScript function which can be called asynchronously from multiple threads via napi_call_threadsafe_function().

napi_threadsafe_function_release_mode#

A value to be given to napi_release_threadsafe_function() to indicate whether the thread-safe function is to be closed immediately (napi_tsfn_abort) or merely released (napi_tsfn_release) and thus available for subsequent use via napi_acquire_threadsafe_function() and napi_call_threadsafe_function().

typedef enum {
  napi_tsfn_release,
  napi_tsfn_abort
} napi_threadsafe_function_release_mode;
c

napi_threadsafe_function_call_mode#

A value to be given to napi_call_threadsafe_function() to indicate whether the call should block whenever the queue associated with the thread-safe function is full.

typedef enum {
  napi_tsfn_nonblocking,
  napi_tsfn_blocking
} napi_threadsafe_function_call_mode;
c

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, 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, 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 of JavaScript values.

Handle scopes are created using napi_open_handle_scope and are destroyed using napi_close_handle_scope. Closing the scope can indicate to the GC that all napi_values created during the lifetime of the handle scope are no longer referenced from the current stack frame.

For more details, review the Object lifetime management.

napi_escapable_handle_scope#

Escapable handle scopes are a special type of handle scope to return values created within a particular handle scope to a parent scope.

napi_ref#

This is the abstraction to use to reference a napi_value. This allows for users to manage the lifetimes of JavaScript values, including defining their minimum lifetimes explicitly.

For more details, review the Object lifetime management.

napi_type_tag#

A 128-bit value stored as two unsigned 64-bit integers. It serves as a UUID with which JavaScript objects or externals can be "tagged" in order to ensure that they are of a certain type. This is a stronger check than napi_instanceof, because the latter can report a false positive if the object's prototype has been manipulated. Type-tagging is most useful in conjunction with napi_wrap because it ensures that the pointer retrieved from a wrapped object can be safely cast to the native type corresponding to the type tag that had been previously applied to the JavaScript object.

typedef struct {
  uint64_t lower;
  uint64_t upper;
} napi_type_tag;
c

napi_async_cleanup_hook_handle#

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.

Node-API callback types#

napi_callback_info#

Opaque datatype that is passed to a callback function. It can be used for getting additional information about the context in which the callback was invoked.

napi_callback#

Function pointer type for user-provided native functions which are to be exposed to JavaScript via Node-API. Callback functions should satisfy the following signature:

typedef napi_value (*napi_callback)(napi_env, napi_callback_info);
c

Unless for reasons discussed in Object Lifetime Management, creating a handle and/or callback scope inside a napi_callback is not necessary.

node_api_basic_finalize#

Function pointer type for add-on provided functions that allow the user to be notified when externally-owned data is ready to be cleaned up because the object it was associated with has been garbage-collected. The user must provide a function satisfying the following signature which would get called upon the object's collection. Currently, node_api_basic_finalize can be used for finding out when objects that have external data are collected.

typedef void (*node_api_basic_finalize)(node_api_basic_env env,
                                      void* finalize_data,
                                      void* finalize_hint);
c

Unless for reasons discussed in Object Lifetime Management, creating a handle and/or callback scope inside the function body is not necessary.

Since these functions may be called while the JavaScript engine is in a state where it cannot execute JavaScript code, only Node-APIs which accept a node_api_basic_env as their first parameter may be called. node_api_post_finalizer can be used to schedule Node-API calls that require access to the JavaScript engine's state to run after the current garbage collection cycle has completed.

In the case of node_api_create_external_string_latin1 and node_api_create_external_string_utf16 the env parameter may be null, because external strings can be collected during the latter part of environment shutdown.

Change History:

• experimental (NAPI_EXPERIMENTAL):

  Only Node-API calls that accept a node_api_basic_env as their first parameter may be called, otherwise the application will be terminated with an appropriate error message. This feature can be turned off by defining NODE_API_EXPERIMENTAL_BASIC_ENV_OPT_OUT.

napi_finalize#

Function pointer type for add-on provided function that allow the user to schedule a group of calls to Node-APIs in response to a garbage collection event, after the garbage collection cycle has completed. These function pointers can be used with node_api_post_finalizer.

typedef void (*napi_finalize)(napi_env env,
                              void* finalize_data,
                              void* finalize_hint);
c

Change History:

• experimental (NAPI_EXPERIMENTAL is defined):

  A function of this type may no longer be used as a finalizer, except with node_api_post_finalizer. node_api_basic_finalize must be used instead. This feature can be turned off by defining NODE_API_EXPERIMENTAL_BASIC_ENV_OPT_OUT.

napi_async_execute_callback#

Function pointer used with functions that support asynchronous operations. Callback functions must satisfy the following signature:

typedef void (*napi_async_execute_callback)(napi_env env, void* data);
c

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.

napi_async_complete_callback#

Function pointer used with functions that support asynchronous operations. Callback functions must satisfy the following signature:

typedef void (*napi_async_complete_callback)(napi_env env,
                                             napi_status status,
                                             void* data);
c

Unless for reasons discussed in Object Lifetime Management, creating a handle and/or callback scope inside the function body is not necessary.

napi_threadsafe_function_call_js#

Function pointer used with asynchronous thread-safe function calls. The callback will be called on the main thread. Its purpose is to use a data item arriving via the queue from one of the secondary threads to construct the parameters necessary for a call into JavaScript, usually via napi_call_function, and then make the call into JavaScript.

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.

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.

Callback functions must satisfy the following signature:

typedef void (*napi_threadsafe_function_call_js)(napi_env env,
                                                 napi_value js_callback,
                                                 void* context,
                                                 void* data);
c

• [in] env: The environment to use for API calls, or NULL if the thread-safe function is being torn down and data may need to be freed.
• [in] js_callback: The JavaScript function to call, or NULL if the thread-safe function is being torn down and data may need to be freed. It may also be NULL if the thread-safe function was created without js_callback.
• [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 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.

Unless for reasons discussed in Object Lifetime Management, creating a handle and/or callback scope inside the function body is not necessary.

napi_cleanup_hook#

Function pointer used with napi_add_env_cleanup_hook. It will be called when the environment is being torn down.

Callback functions must satisfy the following signature:

typedef void (*napi_cleanup_hook)(void* data);
c

• [in] data: The data that was passed to napi_add_env_cleanup_hook.

napi_async_cleanup_hook#

Function pointer used with napi_add_async_cleanup_hook. It will be called when the environment is being torn down.

Callback functions must satisfy the following signature:

typedef void (*napi_async_cleanup_hook)(napi_async_cleanup_hook_handle handle,
                                        void* data);
c

• [in] handle: The handle that must be passed to napi_remove_async_cleanup_hook after completion of the asynchronous cleanup.
• [in] data: The data that was passed to napi_add_async_cleanup_hook.

The body of the function should initiate the asynchronous cleanup actions at the end of which handle must be passed in a call to napi_remove_async_cleanup_hook.

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 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 no uncaught JavaScript exception was thrown. If an error occurred AND an exception was thrown, the napi_status value for the error will be returned. If an exception was thrown, and no error occurred, napi_pending_exception will be returned.

In cases where a return value other than napi_ok or napi_pending_exception is returned, napi_is_exception_pending must be called to check if an exception is pending. See the section on exceptions for more details.

The full set of possible napi_status values is defined in napi_api_types.h.

The napi_status return value provides a VM-independent representation of the error which occurred. In some cases it is useful to be able to get more detailed information, including a string representing the error as well as VM (engine)-specific information.

In order to retrieve this information napi_get_last_error_info is provided which returns a napi_extended_error_info structure. The format of the napi_extended_error_info structure is as follows:

typedef struct napi_extended_error_info {
  const char* error_message;
  void* engine_reserved;
  uint32_t engine_error_code;
  napi_status error_code;
};
c

• 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: Node-API status code for the last error.

napi_get_last_error_info returns the information for the last 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 logging purposes.

napi_get_last_error_info#

napi_status
napi_get_last_error_info(node_api_basic_env env,
                         const napi_extended_error_info** result);
c

• [in] env: The environment that the API is invoked under.
• [out] result: The napi_extended_error_info structure with more information about the error.

Returns napi_ok if the API succeeded.

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 a Node-API function is called on the same env. This includes a call to napi_is_exception_pending so it may often be necessary to make a copy of the information so that it can be used later. The pointer returned in error_message points to a statically-defined string so it is safe to use that pointer if you have copied it out of the error_message field (which will be overwritten) before another Node-API function was called.

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 logging purposes.

This API can be called even if there is a pending JavaScript exception.

Exceptions#

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.

If the napi_status returned by a function is napi_ok then no exception is pending and no additional action is required. If the napi_status returned is anything other than napi_ok or napi_pending_exception, in order to try to recover and continue 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 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. 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 the error status after every function call.

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 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.

The second approach is to try to handle the exception. There will be cases where the native code can catch the exception, take the appropriate action, and then continue. This is only recommended in specific cases where it is known that the exception can be safely handled. In these cases napi_get_and_clear_last_exception can be used to get and clear the exception. On success, result will contain the handle to the last JavaScript Object thrown. If it is determined, after retrieving the exception, the exception cannot be handled after all it can be re-thrown it with napi_throw where error is the JavaScript value to be thrown.

The following utility functions are also available in case native code needs to throw an exception or determine if a napi_value is an instance of a JavaScript Error object: napi_throw_error, napi_throw_type_error, napi_throw_range_error, node_api_throw_syntax_error and napi_is_error.

The following utility functions are also available in case native code needs to create an Error object: napi_create_error, napi_create_type_error, napi_create_range_error and node_api_create_syntax_error, where result is the napi_value that refers to the newly created JavaScript Error object.

The Node.js project is adding error codes to all of the errors 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 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 to be added to the error object. If the optional parameter is NULL then no code will be associated with the error. If a code is provided, the name associated with the error is also updated to be:

originalName [code]
text

where originalName is the original name associated with the error and code is the code that was provided. For example, if the code is 'ERR_ERROR_1' and a TypeError is being created the name will be:

TypeError [ERR_ERROR_1]
text

napi_throw#

NAPI_EXTERN napi_status napi_throw(napi_env env, napi_value error);
c

• [in] env: The environment that the API is invoked under.
• [in] error: The JavaScript value to be thrown.

Returns napi_ok if the API succeeded.

This API throws the JavaScript value provided.

napi_throw_error#

NAPI_EXTERN napi_status napi_throw_error(napi_env env,
                                         const char* code,
                                         const char* msg);
c

• [in] env: The environment that the API is invoked under.
• [in] code: Optional error code to be set on the error.
• [in] msg: C string representing the text to be associated with the error.

Returns napi_ok if the API succeeded.

This API throws a JavaScript Error with the text provided.

napi_throw_type_error#

NAPI_EXTERN napi_status napi_throw_type_error(napi_env env,
                                              const char* code,
                                              const char* msg);
c

• [in] env: The environment that the API is invoked under.
• [in] code: Optional error code to be set on the error.
• [in] msg: C string representing the text to be associated with the error.

Returns napi_ok if the API succeeded.

This API throws a JavaScript TypeError with the text provided.

napi_throw_range_error#

NAPI_EXTERN napi_status napi_throw_range_error(napi_env env,
                                               const char* code,
                                               const char* msg);
c

• [in] env: The environment that the API is invoked under.
• [in] code: Optional error code to be set on the error.
• [in] msg: C string representing the text to be associated with the error.

Returns napi_ok if the API succeeded.

This API throws a JavaScript RangeError with the text provided.

node_api_throw_syntax_error#

NAPI_EXTERN napi_status node_api_throw_syntax_error(napi_env env,
                                                    const char* code,
                                                    const char* msg);
c

• [in] env: The environment that the API is invoked under.
• [in] code: Optional error code to be set on the error.
• [in] msg: C string representing the text to be associated with the error.

Returns napi_ok if the API succeeded.

This API throws a JavaScript SyntaxError with the text provided.

napi_is_error#

NAPI_EXTERN napi_status napi_is_error(napi_env env,
                                      napi_value value,
                                      bool* result);
c

• [in] env: The environment that the API is invoked under.
• [in] value: The napi_value to be checked.
• [out] result: Boolean value that is set to true if napi_value represents an error, false otherwise.

Returns napi_ok if the API succeeded.

This API queries a napi_value to check if it represents an error object.

napi_create_error#

NAPI_EXTERN napi_status napi_create_error(napi_env env,
                                          napi_value code,
                                          napi_value msg,
                                          napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] code: Optional napi_value with the string for the error code to be associated with the error.
• [in] msg: napi_value that references a JavaScript string to be used as the message for the Error.
• [out] result: napi_value representing the error created.

Returns napi_ok if the API succeeded.

This API returns a JavaScript Error with the text provided.

napi_create_type_error#

NAPI_EXTERN napi_status napi_create_type_error(napi_env env,
                                               napi_value code,
                                               napi_value msg,
                                               napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] code: Optional napi_value with the string for the error code to be associated with the error.
• [in] msg: napi_value that references a JavaScript string to be used as the message for the Error.
• [out] result: napi_value representing the error created.

Returns napi_ok if the API succeeded.

This API returns a JavaScript TypeError with the text provided.

napi_create_range_error#

NAPI_EXTERN napi_status napi_create_range_error(napi_env env,
                                                napi_value code,
                                                napi_value msg,
                                                napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] code: Optional napi_value with the string for the error code to be associated with the error.
• [in] msg: napi_value that references a JavaScript string to be used as the message for the Error.
• [out] result: napi_value representing the error created.

Returns napi_ok if the API succeeded.

This API returns a JavaScript RangeError with the text provided.

node_api_create_syntax_error#

NAPI_EXTERN napi_status node_api_create_syntax_error(napi_env env,
                                                     napi_value code,
                                                     napi_value msg,
                                                     napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] code: Optional napi_value with the string for the error code to be associated with the error.
• [in] msg: napi_value that references a JavaScript string to be used as the message for the Error.
• [out] result: napi_value representing the error created.

Returns napi_ok if the API succeeded.

This API returns a JavaScript SyntaxError with the text provided.

napi_get_and_clear_last_exception#

napi_status napi_get_and_clear_last_exception(napi_env env,
                                              napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [out] result: The exception if one is pending, NULL otherwise.

Returns napi_ok if the API succeeded.

This API can be called even if there is a pending JavaScript exception.

napi_is_exception_pending#

napi_status napi_is_exception_pending(napi_env env, bool* result);
c

• [in] env: The environment that the API is invoked under.
• [out] result: Boolean value that is set to true if an exception is pending.

Returns napi_ok if the API succeeded.

This API can be called even if there is a pending JavaScript exception.

napi_fatal_exception#

napi_status napi_fatal_exception(napi_env env, napi_value err);
c

• [in] env: The environment that the API is invoked under.
• [in] err: The error that is passed to 'uncaughtException'.

Trigger an 'uncaughtException' in JavaScript. Useful if an async callback throws an exception with no way to recover.

Fatal errors#

In the event of an unrecoverable error in a native addon, a fatal error can be thrown to immediately terminate the process.

napi_fatal_error#

NAPI_NO_RETURN void napi_fatal_error(const char* location,
                                     size_t location_len,
                                     const char* message,
                                     size_t message_len);
c

• [in] location: Optional location at which the error occurred.
• [in] location_len: The length of the location in bytes, or NAPI_AUTO_LENGTH if it is null-terminated.
• [in] message: The message associated with the error.
• [in] message_len: The length of the message in bytes, or NAPI_AUTO_LENGTH if it is null-terminated.

The function call does not return, the process will be terminated.

This API can be called even if there is a pending JavaScript exception.

Object lifetime management#

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 finished using them.

As object handles are returned they are associated with a 'scope'. The lifespan for the default scope is tied to the lifespan of the native method call. The result is that, by default, handles remain valid and the objects associated with these handles will be 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 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#

It is often necessary to make the lifespan of handles shorter than the lifespan of a native method. For example, consider a native method that has a loop which iterates through the elements in a large array:

for (int i = 0; i < 1000000; i++) {
  napi_value result;
  napi_status status = napi_get_element(env, object, i, &result);
  if (status != napi_ok) {
    break;
  }
  // do something with element
}
c

This would result in a large number of handles being created, consuming 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, 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.

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 must be closed before returning from that method.

Taking the earlier example, adding calls to napi_open_handle_scope and napi_close_handle_scope would ensure that at most a single handle is valid throughout the execution of the loop:

for (int i = 0; i < 1000000; i++) {
  napi_handle_scope scope;
  napi_status status = napi_open_handle_scope(env, &scope);
  if (status != napi_ok) {
    break;
  }
  napi_value result;
  status = napi_get_element(env, object, i, &result);
  if (status != napi_ok) {
    break;
  }
  // do something with element
  status = napi_close_handle_scope(env, scope);
  if (status != napi_ok) {
    break;
  }
}
c

When nesting scopes, there are cases where a handle from an 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.

The methods available to open/close escapable scopes are napi_open_escapable_handle_scope and napi_close_escapable_handle_scope.

The request to promote a handle is made through napi_escape_handle which can only be called once.

napi_open_handle_scope#

NAPI_EXTERN napi_status napi_open_handle_scope(napi_env env,
                                               napi_handle_scope* result);
c

• [in] env: The environment that the API is invoked under.
• [out] result: napi_value representing the new scope.

Returns napi_ok if the API succeeded.

This API opens a new scope.

napi_close_handle_scope#

NAPI_EXTERN napi_status napi_close_handle_scope(napi_env env,
                                                napi_handle_scope scope);
c

• [in] env: The environment that the API is invoked under.
• [in] scope: napi_value representing the scope to be closed.

Returns napi_ok if the API succeeded.

This API closes the scope passed in. Scopes must be closed in the reverse order from which they were created.

This API can be called even if there is a pending JavaScript exception.

napi_open_escapable_handle_scope#

NAPI_EXTERN napi_status
    napi_open_escapable_handle_scope(napi_env env,
                                     napi_handle_scope* result);
c

• [in] env: The environment that the API is invoked under.
• [out] result: napi_value representing the new scope.

Returns napi_ok if the API succeeded.

This API opens a new scope from which one object can be promoted to the outer scope.

napi_close_escapable_handle_scope#

NAPI_EXTERN napi_status
    napi_close_escapable_handle_scope(napi_env env,
                                      napi_handle_scope scope);
c

• [in] env: The environment that the API is invoked under.
• [in] scope: napi_value representing the scope to be closed.

Returns napi_ok if the API succeeded.

This API closes the scope passed in. Scopes must be closed in the reverse order from which they were created.

This API can be called even if there is a pending JavaScript exception.

napi_escape_handle#

napi_status napi_escape_handle(napi_env env,
                               napi_escapable_handle_scope scope,
                               napi_value escapee,
                               napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] scope: napi_value representing the current scope.
• [in] escapee: napi_value representing the JavaScript Object to be escaped.
• [out] result: napi_value representing the handle to the escaped Object in the outer scope.

Returns napi_ok if the API succeeded.

This API promotes the handle to the JavaScript object so that it is valid for the lifetime of the outer scope. It can only be called once per scope. If it is called more than once an error will be returned.

This API can be called even if there is a pending JavaScript exception.

References to values with a lifespan longer than that of the native method#

In some cases, an addon will need to be able to create and reference values with a lifespan longer than that of a single native method invocation. For example, to create a constructor and later use that constructor in a request to create instances, it must be possible to reference the constructor object across many different instance creation requests. This would not be possible with a normal handle returned as a napi_value as 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.

Node-API provides methods for creating persistent references to values. Currently Node-API only allows references to be created for a limited set of value types, including object, external, function, and symbol.

Each reference has an associated count with a value of 0 or higher, which determines whether the reference will keep the corresponding value alive. References with a count of 0 do not prevent values from being collected. Values of object (object, function, external) and symbol types are becoming 'weak' references and can still be accessed while they are not collected. Any count greater than 0 will prevent the values from being collected.

Symbol values have different flavors. The true weak reference behavior is only supported by local symbols created with the napi_create_symbol function or the JavaScript Symbol() constructor calls. Globally registered symbols created with the node_api_symbol_for function or JavaScript Symbol.for() function calls remain always strong references because the garbage collector does not collect them. The same is true for well-known symbols such as Symbol.iterator. They are also never collected by the garbage collector.

References can be created with an initial reference count. The count can then be modified through napi_reference_ref and napi_reference_unref. If an object is collected while the count for a reference is 0, all subsequent calls to get the object associated with the reference napi_get_reference_value will return NULL for the returned napi_value. An attempt to call napi_reference_ref for a reference whose object has been collected results in an error.

References must be deleted once they are no longer required by the addon. When a reference is deleted, it will no longer prevent the corresponding object from being collected. Failure to delete a persistent reference results in a 'memory leak' with both the native memory for the persistent reference and the corresponding object on the heap being retained forever.

There can be multiple persistent references created which refer to the same object, each of which will either keep the object live or not based on its individual count. Multiple persistent references to the same object can result in unexpectedly keeping alive native memory. The native structures for a persistent reference must be kept alive until finalizers for the referenced object are executed. If a new persistent reference is created for the same object, the finalizers for that object will not be run and the native memory pointed by the earlier persistent reference will not be freed. This can be avoided by calling napi_delete_reference in addition to napi_reference_unref when possible.

Change History:

• Version 10 (NAPI_VERSION is defined as 10 or higher):

  References can be created for all value types. The new supported value types do not support weak reference semantic and the values of these types are released when the reference count becomes 0 and cannot be accessed from the reference anymore.

napi_create_reference#

NAPI_EXTERN napi_status napi_create_reference(napi_env env,
                                              napi_value value,
                                              uint32_t initial_refcount,
                                              napi_ref* result);
c

• [in] env: The environment that the API is invoked under.
• [in] value: The napi_value for which a reference is being created.
• [in] initial_refcount: Initial reference count for the new reference.
• [out] result: napi_ref pointing to the new reference.

Returns napi_ok if the API succeeded.

This API creates a new reference with the specified reference count to the value passed in.

napi_delete_reference#

NAPI_EXTERN napi_status napi_delete_reference(napi_env env, napi_ref ref);
c

• [in] env: The environment that the API is invoked under.
• [in] ref: napi_ref to be deleted.

Returns napi_ok if the API succeeded.

This API deletes the reference passed in.

This API can be called even if there is a pending JavaScript exception.

napi_reference_ref#

NAPI_EXTERN napi_status napi_reference_ref(napi_env env,
                                           napi_ref ref,
                                           uint32_t* result);
c

• [in] env: The environment that the API is invoked under.
• [in] ref: napi_ref for which the reference count will be incremented.
• [out] result: The new reference count.

Returns napi_ok if the API succeeded.

This API increments the reference count for the reference passed in and returns the resulting reference count.

napi_reference_unref#

NAPI_EXTERN napi_status napi_reference_unref(napi_env env,
                                             napi_ref ref,
                                             uint32_t* result);
c

• [in] env: The environment that the API is invoked under.
• [in] ref: napi_ref for which the reference count will be decremented.
• [out] result: The new reference count.

Returns napi_ok if the API succeeded.

This API decrements the reference count for the reference passed in and returns the resulting reference count.

napi_get_reference_value#

NAPI_EXTERN napi_status napi_get_reference_value(napi_env env,
                                                 napi_ref ref,
                                                 napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] ref: The napi_ref for which the corresponding value is being requested.
• [out] result: The napi_value referenced by the napi_ref.

Returns napi_ok if the API succeeded.

If still valid, this API returns the napi_value representing the JavaScript value associated with the napi_ref. Otherwise, result will be NULL.

Cleanup on exit of the current Node.js environment#

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 environment exits.

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.

napi_add_env_cleanup_hook#

NODE_EXTERN napi_status napi_add_env_cleanup_hook(node_api_basic_env env,
                                                  napi_cleanup_hook fun,
                                                  void* arg);
c

Registers fun as a function to be run with the arg parameter once the current Node.js environment exits.

A function can safely be specified multiple times with different arg values. In that case, it will be called multiple times as well. Providing the same fun and arg values multiple times is not allowed and will lead the process to abort.

The hooks will be called in reverse order, i.e. the most recently added one will be called first.

Removing this hook can be done by using napi_remove_env_cleanup_hook. Typically, that happens when the resource for which this hook was added is being torn down anyway.

For asynchronous cleanup, napi_add_async_cleanup_hook is available.

napi_remove_env_cleanup_hook#

NAPI_EXTERN napi_status napi_remove_env_cleanup_hook(node_api_basic_env env,
                                                     void (*fun)(void* arg),
                                                     void* arg);
c

Unregisters fun as a function to be run with the arg parameter once the current Node.js environment exits. Both the argument and the function value need to be exact matches.

The function must have originally been registered with napi_add_env_cleanup_hook, otherwise the process will abort.

napi_add_async_cleanup_hook#

NAPI_EXTERN napi_status napi_add_async_cleanup_hook(
    node_api_basic_env env,
    napi_async_cleanup_hook hook,
    void* arg,
    napi_async_cleanup_hook_handle* remove_handle);
c

• [in] env: The environment that the API is invoked under.
• [in] hook: The function pointer to call at environment teardown.
• [in] arg: The pointer to pass to hook when it gets called.
• [out] remove_handle: Optional handle that refers to the asynchronous cleanup hook.

Registers hook, which is a function of type napi_async_cleanup_hook, as a function to be run with the remove_handle and arg parameters once the current Node.js environment exits.

Unlike napi_add_env_cleanup_hook, the hook is allowed to be asynchronous.

Otherwise, behavior generally matches that of napi_add_env_cleanup_hook.

If remove_handle is not NULL, an opaque value will be stored in it that must later be passed to napi_remove_async_cleanup_hook, regardless of whether the hook has already been invoked. Typically, that happens when the resource for which this hook was added is being torn down anyway.

napi_remove_async_cleanup_hook#

NAPI_EXTERN napi_status napi_remove_async_cleanup_hook(
    napi_async_cleanup_hook_handle remove_handle);
c

• [in] remove_handle: The handle to an asynchronous cleanup hook that was created with napi_add_async_cleanup_hook.

Unregisters the cleanup hook corresponding to remove_handle. This will prevent the hook from being executed, unless it has already started executing. This must be called on any napi_async_cleanup_hook_handle value obtained from napi_add_async_cleanup_hook.

Finalization on the exit of the Node.js environment#

The Node.js environment may be torn down at an arbitrary time as soon as possible with JavaScript execution disallowed, like on the request of worker.terminate(). When the environment is being torn down, the registered napi_finalize callbacks of JavaScript objects, thread-safe functions and environment instance data are invoked immediately and independently.

The invocation of napi_finalize callbacks is scheduled after the manually registered cleanup hooks. In order to ensure a proper order of addon finalization during environment shutdown to avoid use-after-free in the napi_finalize callback, addons should register a cleanup hook with napi_add_env_cleanup_hook and napi_add_async_cleanup_hook to manually release the allocated resource in a proper order.

Module registration#

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:

NAPI_MODULE(NODE_GYP_MODULE_NAME, Init)
c

The next difference is the signature for the Init method. For a Node-API module it is as follows:

napi_value Init(napi_env env, napi_value exports);
c

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. 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:

napi_value Init(napi_env env, napi_value exports) {
  napi_status status;
  napi_property_descriptor desc = {
    "hello",
    NULL,
    Method,
    NULL,
    NULL,
    NULL,
    napi_writable | napi_enumerable | napi_configurable,
    NULL
  };
  status = napi_define_properties(env, exports, 1, &desc);
  if (status != napi_ok) return NULL;
  return exports;
}
c

To set a function to be returned by the require() for the addon:

napi_value Init(napi_env env, napi_value exports) {
  napi_value method;
  napi_status status;
  status = napi_create_function(env, "exports", NAPI_AUTO_LENGTH, Method, NULL, &method);
  if (status != napi_ok) return NULL;
  return method;
}
c

To define a class so that new instances can be created (often used with Object wrap):

// NOTE: partial example, not all referenced code is included
napi_value Init(napi_env env, napi_value exports) {
  napi_status status;
  napi_property_descriptor properties[] = {
    { "value", NULL, NULL, GetValue, SetValue, NULL, napi_writable | napi_configurable, NULL },
    DECLARE_NAPI_METHOD("plusOne", PlusOne),
    DECLARE_NAPI_METHOD("multiply", Multiply),
  };

  napi_value cons;
  status =
      napi_define_class(env, "MyObject", New, NULL, 3, properties, &cons);
  if (status != napi_ok) return NULL;

  status = napi_create_reference(env, cons, 1, &constructor);
  if (status != napi_ok) return NULL;

  status = napi_set_named_property(env, exports, "MyObject", cons);
  if (status != napi_ok) return NULL;

  return exports;
}
c

You can also use the NAPI_MODULE_INIT macro, which acts as a shorthand for NAPI_MODULE and defining an Init function:

NAPI_MODULE_INIT(/* napi_env env, napi_value exports */) {
  napi_value answer;
  napi_status result;

  status = napi_create_int64(env, 42, &answer);
  if (status != napi_ok) return NULL;

  status = napi_set_named_property(env, exports, "answer", answer);
  if (status != napi_ok) return NULL;

  return exports;
}
c

The parameters env and exports are provided to the body of the NAPI_MODULE_INIT macro.

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.

The variables env and exports will be available inside the function body following the macro invocation.

For more details on setting properties on objects, see the section on Working with JavaScript properties.

For more details on building addon modules in general, refer to the existing API.

Working with JavaScript values#

Node-API exposes a set of APIs to create all types of JavaScript values. Some of these types are documented under Section language types 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 a Node-API value
3. Convert from Node-API value to a primitive C type
4. Get global instances including undefined and null

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.

Enum types#

napi_key_collection_mode#

typedef enum {
  napi_key_include_prototypes,
  napi_key_own_only
} napi_key_collection_mode;
c

Describes the Keys/Properties filter enums:

napi_key_collection_mode limits the range of collected properties.

napi_key_own_only limits the collected properties to the given object only. napi_key_include_prototypes will include all keys of the objects's prototype chain as well.

napi_key_filter#

typedef enum {
  napi_key_all_properties = 0,
  napi_key_writable = 1,
  napi_key_enumerable = 1 << 1,
  napi_key_configurable = 1 << 2,
  napi_key_skip_strings = 1 << 3,
  napi_key_skip_symbols = 1 << 4
} napi_key_filter;
c

Property filter bit flag. This works with bit operators to build a composite filter.

napi_key_conversion#

typedef enum {
  napi_key_keep_numbers,
  napi_key_numbers_to_strings
} napi_key_conversion;
c

napi_key_numbers_to_strings will convert integer indexes to strings. napi_key_keep_numbers will return numbers for integer indexes.

napi_valuetype#

typedef enum {
  // ES6 types (corresponds to typeof)
  napi_undefined,
  napi_null,
  napi_boolean,
  napi_number,
  napi_string,
  napi_symbol,
  napi_object,
  napi_function,
  napi_external,
  napi_bigint,
} napi_valuetype;
c

Describes the type of a napi_value. This generally corresponds to the types described in Section language types of the ECMAScript Language Specification. In addition to types in that section, napi_valuetype can also represent Functions and Objects with external data.

A JavaScript value of type napi_external appears in JavaScript as a plain object such that no properties can be set on it, and no prototype.

napi_typedarray_type#

typedef enum {
  napi_int8_array,
  napi_uint8_array,
  napi_uint8_clamped_array,
  napi_int16_array,
  napi_uint16_array,
  napi_int32_array,
  napi_uint32_array,
  napi_float32_array,
  napi_float64_array,
  napi_bigint64_array,
  napi_biguint64_array,
  napi_float16_array,
} napi_typedarray_type;
c

This represents the underlying binary scalar datatype of the TypedArray. Elements of this enum correspond to Section TypedArray objects of the ECMAScript Language Specification.

Object creation functions#

napi_create_array#

napi_status napi_create_array(napi_env env, napi_value* result)
c

• [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 a Node-API value corresponding to a JavaScript Array type. JavaScript arrays are described in Section Array objects of the ECMAScript Language Specification.

napi_create_array_with_length#

napi_status napi_create_array_with_length(napi_env env,
                                          size_t length,
                                          napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] length: The initial length of the Array.
• [out] result: A napi_value representing a JavaScript Array.

Returns napi_ok if the API succeeded.

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 implementation. If the buffer must be a contiguous block of memory that can be directly read and/or written via C, consider using napi_create_external_arraybuffer.

JavaScript arrays are described in Section Array objects of the ECMAScript Language Specification.

napi_create_arraybuffer#

napi_status napi_create_arraybuffer(napi_env env,
                                    size_t byte_length,
                                    void** data,
                                    napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] length: The length in bytes of the array buffer to create.
• [out] data: Pointer to the underlying byte buffer of the ArrayBuffer. data can optionally be ignored by passing NULL.
• [out] result: A napi_value representing a JavaScript ArrayBuffer.

Returns napi_ok if the API succeeded.

This API returns a Node-API value corresponding to a JavaScript ArrayBuffer. ArrayBuffers 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 determined by the length parameter that's passed in. The underlying buffer is optionally returned back to the caller in case the caller wants to directly manipulate the buffer. This buffer can only be written to directly from native code. To write to this buffer from JavaScript, a typed array or DataView object would need to be created.

JavaScript ArrayBuffer objects are described in Section ArrayBuffer objects of the ECMAScript Language Specification.

napi_create_buffer#

napi_status napi_create_buffer(napi_env env,
                               size_t size,
                               void** data,
                               napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] size: Size in bytes of the underlying buffer.
• [out] data: Raw pointer to the underlying buffer. data can optionally be ignored by passing NULL.
• [out] result: A napi_value representing a node::Buffer.

Returns napi_ok if the API succeeded.

This API allocates a node::Buffer object. While this is still a fully-supported data structure, in most cases using a TypedArray will suffice.

napi_create_buffer_copy#

napi_status napi_create_buffer_copy(napi_env env,
                                    size_t length,
                                    const void* data,
                                    void** result_data,
                                    napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] size: Size in bytes of the input buffer (should be the same as the size of the new buffer).
• [in] data: Raw pointer to the underlying buffer to copy from.
• [out] result_data: Pointer to the new Buffer's underlying data buffer. result_data can optionally be ignored by passing NULL.
• [out] result: A napi_value representing a node::Buffer.

Returns napi_ok if the API succeeded.

This API allocates a node::Buffer object and initializes it with data copied from the passed-in buffer. While this is still a fully-supported data structure, in most cases using a TypedArray will suffice.

napi_create_date#

napi_status napi_create_date(napi_env env,
                             double time,
                             napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] time: ECMAScript time value in milliseconds since 01 January, 1970 UTC.
• [out] result: A napi_value representing a JavaScript Date.

Returns napi_ok if the API succeeded.

This API does not observe leap seconds; they are ignored, as ECMAScript aligns with POSIX time specification.

This API allocates a JavaScript Date object.

JavaScript Date objects are described in Section Date objects of the ECMAScript Language Specification.

napi_create_external#

napi_status napi_create_external(napi_env env,
                                 void* data,
                                 napi_finalize finalize_cb,
                                 void* finalize_hint,
                                 napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] data: Raw pointer to the external data.
• [in] finalize_cb: Optional callback to call when the external value is being collected. napi_finalize provides more details.
• [in] finalize_hint: Optional hint to pass to the finalize callback during collection.
• [out] result: A napi_value representing an external value.

Returns napi_ok if the API succeeded.

This API allocates a JavaScript value with external data attached to it. This is used to pass external data through JavaScript code, so it can be retrieved later by native code using napi_get_value_external.

The API adds a napi_finalize callback which will be called when the JavaScript object just created has been garbage collected.

The created value is not an object, and therefore does not support additional properties. It is considered a distinct value type: calling napi_typeof() with an external value yields napi_external.

napi_create_external_arraybuffer#

napi_status
napi_create_external_arraybuffer(napi_env env,
                                 void* external_data,
                                 size_t byte_length,
                                 napi_finalize finalize_cb,
                                 void* finalize_hint,
                                 napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] external_data: Pointer to the underlying byte buffer of the ArrayBuffer.
• [in] byte_length: The length in bytes of the underlying buffer.
• [in] finalize_cb: Optional callback to call when the ArrayBuffer is being collected. napi_finalize provides more details.
• [in] finalize_hint: Optional hint to pass to the finalize callback during collection.
• [out] result: A napi_value representing a JavaScript ArrayBuffer.

Returns napi_ok if the API succeeded.

Some runtimes other than Node.js have dropped support for external buffers. On runtimes other than Node.js this method may return napi_no_external_buffers_allowed to indicate that external buffers are not supported. One such runtime is Electron as described in this issue electron/issues/35801.

In order to maintain broadest compatibility with all runtimes you may define NODE_API_NO_EXTERNAL_BUFFERS_ALLOWED in your addon before includes for the node-api headers. Doing so will hide the 2 functions that create external buffers. This will ensure a compilation error occurs if you accidentally use one of these methods.

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.

The API adds a napi_finalize callback which will be called when the JavaScript object just created has been garbage collected.

JavaScript ArrayBuffers are described in Section ArrayBuffer objects of the ECMAScript Language Specification.

node_api_create_external_sharedarraybuffer#

napi_status
node_api_create_external_sharedarraybuffer(napi_env env,
                                           void* external_data,
                                           size_t byte_length,
                                           node_api_noenv_finalize finalize_cb,
                                           void* finalize_hint,
                                           napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] external_data: Pointer to the underlying byte buffer of the SharedArrayBuffer.
• [in] byte_length: The length in bytes of the underlying buffer.
• [in] finalize_cb: Optional callback to call when the SharedArrayBuffer is being collected. Called on an arbitrary thread. Because a SharedArrayBuffer can outlive the environment it's created in, the callback does not receive a reference to env.
• [in] finalize_hint: Optional hint to pass to the finalize callback during collection.
• [out] result: A napi_value representing a JavaScript SharedArrayBuffer.

Returns napi_ok if the API succeeded.

Create a SharedArrayBuffer with externally managed memory.

See the entry on napi_create_external_arraybuffer for runtime compatibility.

napi_create_external_buffer#

napi_status napi_create_external_buffer(napi_env env,
                                        size_t length,
                                        void* data,
                                        napi_finalize finalize_cb,
                                        void* finalize_hint,
                                        napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] length: Size in bytes of the input buffer (should be the same as the size of the new buffer).
• [in] data: Raw pointer to the underlying buffer to expose to JavaScript.
• [in] finalize_cb: Optional callback to call when the ArrayBuffer is being collected. napi_finalize provides more details.
• [in] finalize_hint: Optional hint to pass to the finalize callback during collection.
• [out] result: A napi_value representing a node::Buffer.

Returns napi_ok if the API succeeded.

Some runtimes other than Node.js have dropped support for external buffers. On runtimes other than Node.js this method may return napi_no_external_buffers_allowed to indicate that external buffers are not supported. One such runtime is Electron as described in this issue electron/issues/35801.

In order to maintain broadest compatibility with all runtimes you may define NODE_API_NO_EXTERNAL_BUFFERS_ALLOWED in your addon before includes for the node-api headers. Doing so will hide the 2 functions that create external buffers. This will ensure a compilation error occurs if you accidentally use one of these methods.

This API allocates a node::Buffer object and initializes it with data backed by the passed in buffer. While this is still a fully-supported data structure, in most cases using a TypedArray will suffice.

The API adds a napi_finalize callback which will be called when the JavaScript object just created has been garbage collected.

For Node.js >=4 Buffers are Uint8Arrays.

napi_create_object#

napi_status napi_create_object(napi_env env, napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [out] result: A napi_value representing a JavaScript Object.

Returns napi_ok if the API succeeded.

This API allocates a default JavaScript Object. It is the equivalent of doing new Object() in JavaScript.

The JavaScript Object type is described in Section object type of the ECMAScript Language Specification.

node_api_create_object_with_properties#

napi_status node_api_create_object_with_properties(napi_env env,
                                                   napi_value prototype_or_null,
                                                   const napi_value* property_names,
                                                   const napi_value* property_values,
                                                   size_t property_count,
                                                   napi_value* result)
cpp

• [in] env: The environment that the API is invoked under.
• [in] prototype_or_null: The prototype object for the new object. Can be a napi_value representing a JavaScript object to use as the prototype, a napi_value representing JavaScript null, or a nullptr that will be converted to null.
• [in] property_names: Array of napi_value representing the property names.
• [in] property_values: Array of napi_value representing the property values.
• [in] property_count: Number of properties in the arrays.
• [out] result: A napi_value representing a JavaScript Object.

Returns napi_ok if the API succeeded.

This API creates a JavaScript Object with the specified prototype and properties. This is more efficient than calling napi_create_object followed by multiple napi_set_property calls, as it can create the object with all properties atomically, avoiding potential V8 map transitions.

The arrays property_names and property_values must have the same length specified by property_count. The properties are added to the object in the order they appear in the arrays.

napi_create_symbol#

napi_status napi_create_symbol(napi_env env,
                               napi_value description,
                               napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] description: Optional napi_value which refers to a JavaScript string to be set as the description for the symbol.
• [out] result: A napi_value representing a JavaScript symbol.

Returns napi_ok if the API succeeded.

This API creates a JavaScript symbol value from a UTF8-encoded C string.

The JavaScript symbol type is described in Section symbol type of the ECMAScript Language Specification.

node_api_symbol_for#

napi_status node_api_symbol_for(napi_env env,
                                const char* utf8description,
                                size_t length,
                                napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] utf8description: UTF-8 C string representing the text to be used as the description for the symbol.
• [in] length: The length of the description string in bytes, or NAPI_AUTO_LENGTH if it is null-terminated.
• [out] result: A napi_value representing a JavaScript symbol.

Returns napi_ok if the API succeeded.

This API searches in the global registry for an existing symbol with the given description. If the symbol already exists it will be returned, otherwise a new symbol will be created in the registry.

The JavaScript symbol type is described in Section symbol type of the ECMAScript Language Specification.

napi_create_typedarray#

napi_status napi_create_typedarray(napi_env env,
                                   napi_typedarray_type type,
                                   size_t length,
                                   napi_value arraybuffer,
                                   size_t byte_offset,
                                   napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] type: Scalar datatype of the elements within the TypedArray.
• [in] length: Number of elements in the TypedArray.
• [in] arraybuffer: ArrayBuffer or SharedArrayBuffer underlying the typed array.
• [in] byte_offset: The byte offset within the ArrayBuffer or SharedArrayBuffer from which to start projecting the TypedArray.
• [out] result: A napi_value representing a JavaScript TypedArray.

Returns napi_ok if the API succeeded.

This API creates a JavaScript TypedArray object over an existing ArrayBuffer or SharedArrayBuffer. TypedArray objects provide an array-like view over an underlying data buffer where each element has the same underlying binary scalar datatype.

It is required that (length * size_of_element) + byte_offset is less than or equal to the size in bytes of the ArrayBuffer or SharedArrayBuffer passed in. If not, a RangeError exception is raised.

For element sizes greater than 1, byte_offset is required to be a multiple of the element size. If not, a RangeError exception is raised.

JavaScript TypedArray objects are described in Section TypedArray objects of the ECMAScript Language Specification.

node_api_create_buffer_from_arraybuffer#

napi_status NAPI_CDECL node_api_create_buffer_from_arraybuffer(napi_env env,
                                                              napi_value arraybuffer,
                                                              size_t byte_offset,
                                                              size_t byte_length,
                                                              napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] arraybuffer: The ArrayBuffer from which the buffer will be created.
• [in] byte_offset: The byte offset within the ArrayBuffer from which to start creating the buffer.
• [in] byte_length: The length in bytes of the buffer to be created from the ArrayBuffer.
• [out] result: A napi_value representing the created JavaScript Buffer object.

Returns napi_ok if the API succeeded.

This API creates a JavaScript Buffer object from an existing ArrayBuffer. The Buffer object is a Node.js-specific class that provides a way to work with binary data directly in JavaScript.

The byte range [byte_offset, byte_offset + byte_length) must be within the bounds of the ArrayBuffer. If byte_offset + byte_length exceeds the size of the ArrayBuffer, a RangeError exception is raised.

napi_create_dataview#

napi_status napi_create_dataview(napi_env env,
                                 size_t byte_length,
                                 napi_value arraybuffer,
                                 size_t byte_offset,
                                 napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] length: Number of elements in the DataView.
• [in] arraybuffer: ArrayBuffer or SharedArrayBuffer underlying the DataView.
• [in] byte_offset: The byte offset within the ArrayBuffer from which to start projecting the DataView.
• [out] result: A napi_value representing a JavaScript DataView.

Returns napi_ok if the API succeeded.

This API creates a JavaScript DataView object over an existing ArrayBuffer or SharedArrayBuffer. DataView objects provide an array-like view over an underlying data buffer, but one which allows items of different size and type in the ArrayBuffer or SharedArrayBuffer.

It is required that byte_length + byte_offset is less than or equal to the size in bytes of the array passed in. If not, a RangeError exception is raised.

JavaScript DataView objects are described in Section DataView objects of the ECMAScript Language Specification.

Functions to convert from C types to Node-API#

napi_create_int32#

napi_status napi_create_int32(napi_env env, int32_t value, napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: Integer value to be represented in JavaScript.
• [out] result: A napi_value representing a JavaScript number.

Returns napi_ok if the API succeeded.

This API is used to convert from the C int32_t type to the JavaScript number type.

The JavaScript number type is described in Section number type of the ECMAScript Language Specification.

napi_create_uint32#

napi_status napi_create_uint32(napi_env env, uint32_t value, napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: Unsigned integer value to be represented in JavaScript.
• [out] result: A napi_value representing a JavaScript number.

Returns napi_ok if the API succeeded.

This API is used to convert from the C uint32_t type to the JavaScript number type.

The JavaScript number type is described in Section number type of the ECMAScript Language Specification.

napi_create_int64#

napi_status napi_create_int64(napi_env env, int64_t value, napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: Integer value to be represented in JavaScript.
• [out] result: A napi_value representing a JavaScript number.

Returns napi_ok if the API succeeded.

This API is used to convert from the C int64_t type to the JavaScript number type.

The JavaScript number type is described in Section number type of the ECMAScript Language Specification. Note the complete range of int64_t cannot be represented with full precision in JavaScript. Integer values outside the range of Number.MIN_SAFE_INTEGER -(2**53 - 1) - Number.MAX_SAFE_INTEGER (2**53 - 1) will lose precision.

napi_create_double#

napi_status napi_create_double(napi_env env, double value, napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: Double-precision value to be represented in JavaScript.
• [out] result: A napi_value representing a JavaScript number.

Returns napi_ok if the API succeeded.

This API is used to convert from the C double type to the JavaScript number type.

The JavaScript number type is described in Section number type of the ECMAScript Language Specification.

napi_create_bigint_int64#

napi_status napi_create_bigint_int64(napi_env env,
                                     int64_t value,
                                     napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] value: Integer value to be represented in JavaScript.
• [out] result: A napi_value representing a JavaScript BigInt.

Returns napi_ok if the API succeeded.

This API converts the C int64_t type to the JavaScript BigInt type.

napi_create_bigint_uint64#

napi_status napi_create_bigint_uint64(napi_env env,
                                      uint64_t value,
                                      napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] value: Unsigned integer value to be represented in JavaScript.
• [out] result: A napi_value representing a JavaScript BigInt.

Returns napi_ok if the API succeeded.

This API converts the C uint64_t type to the JavaScript BigInt type.

napi_create_bigint_words#

napi_status napi_create_bigint_words(napi_env env,
                                     int sign_bit,
                                     size_t word_count,
                                     const uint64_t* words,
                                     napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] sign_bit: Determines if the resulting BigInt will be positive or negative.
• [in] word_count: The length of the words array.
• [in] words: An array of uint64_t little-endian 64-bit words.
• [out] result: A napi_value representing a JavaScript BigInt.

Returns napi_ok if the API succeeded.

This API converts an array of unsigned 64-bit words into a single BigInt value.

The resulting BigInt is calculated as: (–1)^sign_bit (words[0] × (2⁶⁴)⁰ + words[1] × (2⁶⁴)¹ + …)

napi_create_string_latin1#

napi_status napi_create_string_latin1(napi_env env,
                                      const char* str,
                                      size_t length,
                                      napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] str: Character buffer representing an ISO-8859-1-encoded string.
• [in] length: The length of the string in bytes, or NAPI_AUTO_LENGTH if it is null-terminated.
• [out] result: A napi_value representing a JavaScript string.

Returns napi_ok if the API succeeded.

This API creates a JavaScript string value from an ISO-8859-1-encoded C string. The native string is copied.

The JavaScript string type is described in Section string type of the ECMAScript Language Specification.

node_api_create_external_string_latin1#

napi_status
node_api_create_external_string_latin1(napi_env env,
                                       char* str,
                                       size_t length,
                                       napi_finalize finalize_callback,
                                       void* finalize_hint,
                                       napi_value* result,
                                       bool* copied);
c

• [in] env: The environment that the API is invoked under.
• [in] str: Character buffer representing an ISO-8859-1-encoded string.
• [in] length: The length of the string in bytes, or NAPI_AUTO_LENGTH if it is null-terminated.
• [in] finalize_callback: The function to call when the string is being collected. The function will be called with the following parameters:
  • [in] env: The environment in which the add-on is running. This value may be null if the string is being collected as part of the termination of the worker or the main Node.js instance.
  • [in] data: This is the value str as a void* pointer.
  • [in] finalize_hint: This is the value finalize_hint that was given to the API. napi_finalize provides more details. This parameter is optional. Passing a null value means that the add-on doesn't need to be notified when the corresponding JavaScript string is collected.
• [in] finalize_hint: Optional hint to pass to the finalize callback during collection.
• [out] result: A napi_value representing a JavaScript string.
• [out] copied: Whether the string was copied. If it was, the finalizer will already have been invoked to destroy str.

Returns napi_ok if the API succeeded.

This API creates a JavaScript string value from an ISO-8859-1-encoded C string. The native string may not be copied and must thus exist for the entire life cycle of the JavaScript value.

The JavaScript string type is described in Section string type of the ECMAScript Language Specification.

napi_create_string_utf16#

napi_status napi_create_string_utf16(napi_env env,
                                     const char16_t* str,
                                     size_t length,
                                     napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] str: Character buffer representing a UTF16-LE-encoded string.
• [in] length: The length of the string in two-byte code units, or NAPI_AUTO_LENGTH if it is null-terminated.
• [out] result: A napi_value representing a JavaScript string.

Returns napi_ok if the API succeeded.

This API creates a JavaScript string value from a UTF16-LE-encoded C string. The native string is copied.

The JavaScript string type is described in Section string type of the ECMAScript Language Specification.

node_api_create_external_string_utf16#

napi_status
node_api_create_external_string_utf16(napi_env env,
                                      char16_t* str,
                                      size_t length,
                                      napi_finalize finalize_callback,
                                      void* finalize_hint,
                                      napi_value* result,
                                      bool* copied);
c

• [in] env: The environment that the API is invoked under.
• [in] str: Character buffer representing a UTF16-LE-encoded string.
• [in] length: The length of the string in two-byte code units, or NAPI_AUTO_LENGTH if it is null-terminated.
• [in] finalize_callback: The function to call when the string is being collected. The function will be called with the following parameters:
  • [in] env: The environment in which the add-on is running. This value may be null if the string is being collected as part of the termination of the worker or the main Node.js instance.
  • [in] data: This is the value str as a void* pointer.
  • [in] finalize_hint: This is the value finalize_hint that was given to the API. napi_finalize provides more details. This parameter is optional. Passing a null value means that the add-on doesn't need to be notified when the corresponding JavaScript string is collected.
• [in] finalize_hint: Optional hint to pass to the finalize callback during collection.
• [out] result: A napi_value representing a JavaScript string.
• [out] copied: Whether the string was copied. If it was, the finalizer will already have been invoked to destroy str.

Returns napi_ok if the API succeeded.

This API creates a JavaScript string value from a UTF16-LE-encoded C string. The native string may not be copied and must thus exist for the entire life cycle of the JavaScript value.

The JavaScript string type is described in Section string type of the ECMAScript Language Specification.

napi_create_string_utf8#

napi_status napi_create_string_utf8(napi_env env,
                                    const char* str,
                                    size_t length,
                                    napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] str: Character buffer representing a UTF8-encoded string.
• [in] length: The length of the string in bytes, or NAPI_AUTO_LENGTH if it is null-terminated.
• [out] result: A napi_value representing a JavaScript string.

Returns napi_ok if the API succeeded.

This API creates a JavaScript string value from a UTF8-encoded C string. The native string is copied.

The JavaScript string type is described in Section string type of the ECMAScript Language Specification.

Functions to create optimized property keys#

Many JavaScript engines including V8 use internalized strings as keys to set and get property values. They typically use a hash table to create and lookup such strings. While it adds some cost per key creation, it improves the performance after that by enabling comparison of string pointers instead of the whole strings.

If a new JavaScript string is intended to be used as a property key, then for some JavaScript engines it will be more efficient to use the functions in this section. Otherwise, use the napi_create_string_utf8 or node_api_create_external_string_utf8 series functions as there may be additional overhead in creating/storing strings with the property key creation methods.

node_api_create_property_key_latin1#

napi_status NAPI_CDECL node_api_create_property_key_latin1(napi_env env,
                                                           const char* str,
                                                           size_t length,
                                                           napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] str: Character buffer representing an ISO-8859-1-encoded string.
• [in] length: The length of the string in bytes, or NAPI_AUTO_LENGTH if it is null-terminated.
• [out] result: A napi_value representing an optimized JavaScript string to be used as a property key for objects.

Returns napi_ok if the API succeeded.

This API creates an optimized JavaScript string value from an ISO-8859-1-encoded C string to be used as a property key for objects. The native string is copied. In contrast with napi_create_string_latin1, subsequent calls to this function with the same str pointer may benefit from a speedup in the creation of the requested napi_value, depending on the engine.

The JavaScript string type is described in Section string type of the ECMAScript Language Specification.

node_api_create_property_key_utf16#

napi_status NAPI_CDECL node_api_create_property_key_utf16(napi_env env,
                                                          const char16_t* str,
                                                          size_t length,
                                                          napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] str: Character buffer representing a UTF16-LE-encoded string.
• [in] length: The length of the string in two-byte code units, or NAPI_AUTO_LENGTH if it is null-terminated.
• [out] result: A napi_value representing an optimized JavaScript string to be used as a property key for objects.

Returns napi_ok if the API succeeded.

This API creates an optimized JavaScript string value from a UTF16-LE-encoded C string to be used as a property key for objects. The native string is copied.

The JavaScript string type is described in Section string type of the ECMAScript Language Specification.

node_api_create_property_key_utf8#

napi_status NAPI_CDECL node_api_create_property_key_utf8(napi_env env,
                                                         const char* str,
                                                         size_t length,
                                                         napi_value* result);
c

• [in] env: The environment that the API is invoked under.
• [in] str: Character buffer representing a UTF8-encoded string.
• [in] length: The length of the string in two-byte code units, or NAPI_AUTO_LENGTH if it is null-terminated.
• [out] result: A napi_value representing an optimized JavaScript string to be used as a property key for objects.

Returns napi_ok if the API succeeded.

This API creates an optimized JavaScript string value from a UTF8-encoded C string to be used as a property key for objects. The native string is copied.

The JavaScript string type is described in Section string type of the ECMAScript Language Specification.

Functions to convert from Node-API to C types#

napi_get_array_length#

napi_status napi_get_array_length(napi_env env,
                                  napi_value value,
                                  uint32_t* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing the JavaScript Array whose length is being queried.
• [out] result: uint32 representing length of the array.

Returns napi_ok if the API succeeded.

This API returns the length of an array.

Array length is described in Section Array instance length of the ECMAScript Language Specification.

napi_get_arraybuffer_info#

napi_status napi_get_arraybuffer_info(napi_env env,
                                      napi_value arraybuffer,
                                      void** data,
                                      size_t* byte_length)
c

• [in] env: The environment that the API is invoked under.
• [in] arraybuffer: napi_value representing the ArrayBuffer or SharedArrayBuffer being queried.
• [out] data: The underlying data buffer of the ArrayBuffer or SharedArrayBuffer is 0, this may be NULL or any other pointer value.
• [out] byte_length: Length in bytes of the underlying data buffer.

Returns napi_ok if the API succeeded.

This API is used to retrieve the underlying data buffer of an ArrayBuffer or SharedArrayBuffer and its length.

WARNING: Use caution while using this API. The lifetime of the underlying data buffer is managed by the ArrayBuffer or SharedArrayBuffer even after it's returned. A possible safe way to use this API is in conjunction with napi_create_reference, which can be used to guarantee control over the lifetime of the ArrayBuffer or SharedArrayBuffer. It's also safe to use the returned data buffer within the same callback as long as there are no calls to other APIs that might trigger a GC.

napi_get_buffer_info#

napi_status napi_get_buffer_info(napi_env env,
                                 napi_value value,
                                 void** data,
                                 size_t* length)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing the node::Buffer or Uint8Array being queried.
• [out] data: The underlying data buffer of the node::Buffer or Uint8Array. If length is 0, this may be NULL or any other pointer value.
• [out] length: Length in bytes of the underlying data buffer.

Returns napi_ok if the API succeeded.

This method returns the identical data and byte_length as napi_get_typedarray_info. And napi_get_typedarray_info accepts a node::Buffer (a Uint8Array) as the value too.

This API is used to retrieve the underlying data buffer of a node::Buffer and its length.

Warning: Use caution while using this API since the underlying data buffer's lifetime is not guaranteed if it's managed by the VM.

napi_get_prototype#

napi_status napi_get_prototype(napi_env env,
                               napi_value object,
                               napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] object: napi_value representing JavaScript Object whose prototype to return. This returns the equivalent of Object.getPrototypeOf (which is not the same as the function's prototype property).
• [out] result: napi_value representing prototype of the given object.

Returns napi_ok if the API succeeded.

napi_get_typedarray_info#

napi_status napi_get_typedarray_info(napi_env env,
                                     napi_value typedarray,
                                     napi_typedarray_type* type,
                                     size_t* length,
                                     void** data,
                                     napi_value* arraybuffer,
                                     size_t* byte_offset)
c

• [in] env: The environment that the API is invoked under.
• [in] typedarray: napi_value representing the TypedArray whose properties to query.
• [out] type: Scalar datatype of the elements within the TypedArray.
• [out] length: The number of elements in the TypedArray.
• [out] data: The data buffer underlying the TypedArray adjusted by the byte_offset value so that it points to the first element in the TypedArray. If the length of the array is 0, this may be NULL or any other pointer value.
• [out] arraybuffer: The ArrayBuffer or SharedArrayBuffer underlying the TypedArray.
• [out] byte_offset: The byte offset within the underlying native array at which the first element of the arrays is located. The value for the data parameter has already been adjusted so that data points to the first element in the array. Therefore, the first byte of the native array would be at data - byte_offset.

Returns napi_ok if the API succeeded.

This API returns various properties of a typed array.

Any of the out parameters may be NULL if that property is unneeded.

Warning: Use caution while using this API since the underlying data buffer is managed by the VM.

napi_get_dataview_info#

napi_status napi_get_dataview_info(napi_env env,
                                   napi_value dataview,
                                   size_t* byte_length,
                                   void** data,
                                   napi_value* arraybuffer,
                                   size_t* byte_offset)
c

• [in] env: The environment that the API is invoked under.
• [in] dataview: napi_value representing the DataView whose properties to query.
• [out] byte_length: Number of bytes in the DataView.
• [out] data: The data buffer underlying the DataView. If byte_length is 0, this may be NULL or any other pointer value.
• [out] arraybuffer: ArrayBuffer underlying the DataView.
• [out] byte_offset: The byte offset within the data buffer from which to start projecting the DataView.

Returns napi_ok if the API succeeded.

Any of the out parameters may be NULL if that property is unneeded.

This API returns various properties of a DataView.

napi_get_date_value#

napi_status napi_get_date_value(napi_env env,
                                napi_value value,
                                double* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing a JavaScript Date.
• [out] result: Time value as a double represented as milliseconds since midnight at the beginning of 01 January, 1970 UTC.

This API does not observe leap seconds; they are ignored, as ECMAScript aligns with POSIX time specification.

Returns napi_ok if the API succeeded. If a non-date napi_value is passed in it returns napi_date_expected.

This API returns the C double primitive of time value for the given JavaScript Date.

napi_get_value_bool#

napi_status napi_get_value_bool(napi_env env, napi_value value, bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript Boolean.
• [out] result: C boolean primitive equivalent of the given JavaScript Boolean.

Returns napi_ok if the API succeeded. If a non-boolean napi_value is passed in it returns napi_boolean_expected.

This API returns the C boolean primitive equivalent of the given JavaScript Boolean.

napi_get_value_double#

napi_status napi_get_value_double(napi_env env,
                                  napi_value value,
                                  double* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript number.
• [out] result: C double primitive equivalent of the given JavaScript number.

Returns napi_ok if the API succeeded. If a non-number napi_value is passed in it returns napi_number_expected.

This API returns the C double primitive equivalent of the given JavaScript number.

napi_get_value_bigint_int64#

napi_status napi_get_value_bigint_int64(napi_env env,
                                        napi_value value,
                                        int64_t* result,
                                        bool* lossless);
c

• [in] env: The environment that the API is invoked under
• [in] value: napi_value representing JavaScript BigInt.
• [out] result: C int64_t primitive equivalent of the given JavaScript BigInt.
• [out] lossless: Indicates whether the BigInt value was converted losslessly.

Returns napi_ok if the API succeeded. If a non-BigInt is passed in it returns napi_bigint_expected.

This API returns the C int64_t primitive equivalent of the given JavaScript BigInt. If needed it will truncate the value, setting lossless to false.

napi_get_value_bigint_uint64#

napi_status napi_get_value_bigint_uint64(napi_env env,
                                        napi_value value,
                                        uint64_t* result,
                                        bool* lossless);
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript BigInt.
• [out] result: C uint64_t primitive equivalent of the given JavaScript BigInt.
• [out] lossless: Indicates whether the BigInt value was converted losslessly.

Returns napi_ok if the API succeeded. If a non-BigInt is passed in it returns napi_bigint_expected.

This API returns the C uint64_t primitive equivalent of the given JavaScript BigInt. If needed it will truncate the value, setting lossless to false.

napi_get_value_bigint_words#

napi_status napi_get_value_bigint_words(napi_env env,
                                        napi_value value,
                                        int* sign_bit,
                                        size_t* word_count,
                                        uint64_t* words);
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript BigInt.
• [out] sign_bit: Integer representing if the JavaScript BigInt is positive or negative.
• [in/out] word_count: Must be initialized to the length of the words array. Upon return, it will be set to the actual number of words that would be needed to store this BigInt.
• [out] words: Pointer to a pre-allocated 64-bit word array.

Returns napi_ok if the API succeeded.

This API converts a single BigInt value into a sign bit, 64-bit little-endian array, and the number of elements in the array. sign_bit and words may be both set to NULL, in order to get only word_count.

napi_get_value_external#

napi_status napi_get_value_external(napi_env env,
                                    napi_value value,
                                    void** result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript external value.
• [out] result: Pointer to the data wrapped by the JavaScript external value.

Returns napi_ok if the API succeeded. If a non-external napi_value is passed in it returns napi_invalid_arg.

This API retrieves the external data pointer that was previously passed to napi_create_external().

napi_get_value_int32#

napi_status napi_get_value_int32(napi_env env,
                                 napi_value value,
                                 int32_t* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript number.
• [out] result: C int32 primitive equivalent of the given JavaScript number.

Returns napi_ok if the API succeeded. If a non-number napi_value is passed in napi_number_expected.

This API returns the C int32 primitive equivalent of the given JavaScript number.

If the number exceeds the range of the 32 bit integer, then the result is truncated to the equivalent of the bottom 32 bits. This can result in a large positive number becoming a negative number if the value is > 2³¹ - 1.

Non-finite number values (NaN, +Infinity, or -Infinity) set the result to zero.

napi_get_value_int64#

napi_status napi_get_value_int64(napi_env env,
                                 napi_value value,
                                 int64_t* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript number.
• [out] result: C int64 primitive equivalent of the given JavaScript number.

Returns napi_ok if the API succeeded. If a non-number napi_value is passed in it returns napi_number_expected.

This API returns the C int64 primitive equivalent of the given JavaScript number.

number values outside the range of Number.MIN_SAFE_INTEGER -(2**53 - 1) - Number.MAX_SAFE_INTEGER (2**53 - 1) will lose precision.

Non-finite number values (NaN, +Infinity, or -Infinity) set the result to zero.

napi_get_value_string_latin1#

napi_status napi_get_value_string_latin1(napi_env env,
                                         napi_value value,
                                         char* buf,
                                         size_t bufsize,
                                         size_t* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript string.
• [in] buf: Buffer to write the ISO-8859-1-encoded string into. If NULL is passed in, the length of the string in bytes and excluding the null terminator is returned in result.
• [in] bufsize: Size of the destination buffer. When this value is insufficient, the returned string is truncated and null-terminated. If this value is zero, then the string is not returned and no changes are done to the buffer.
• [out] result: Number of bytes copied into the buffer, excluding the null terminator.

Returns napi_ok if the API succeeded. If a non-string napi_value is passed in it returns napi_string_expected.

This API returns the ISO-8859-1-encoded string corresponding the value passed in.

napi_get_value_string_utf8#

napi_status napi_get_value_string_utf8(napi_env env,
                                       napi_value value,
                                       char* buf,
                                       size_t bufsize,
                                       size_t* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript string.
• [in] buf: Buffer to write the UTF8-encoded string into. If NULL is passed in, the length of the string in bytes and excluding the null terminator is returned in result.
• [in] bufsize: Size of the destination buffer. When this value is insufficient, the returned string is truncated and null-terminated. If this value is zero, then the string is not returned and no changes are done to the buffer.
• [out] result: Number of bytes copied into the buffer, excluding the null terminator.

Returns napi_ok if the API succeeded. If a non-string napi_value is passed in it returns napi_string_expected.

This API returns the UTF8-encoded string corresponding the value passed in.

napi_get_value_string_utf16#

napi_status napi_get_value_string_utf16(napi_env env,
                                        napi_value value,
                                        char16_t* buf,
                                        size_t bufsize,
                                        size_t* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript string.
• [in] buf: Buffer to write the UTF16-LE-encoded string into. If NULL is passed in, the length of the string in 2-byte code units and excluding the null terminator is returned.
• [in] bufsize: Size of the destination buffer. When this value is insufficient, the returned string is truncated and null-terminated. If this value is zero, then the string is not returned and no changes are done to the buffer.
• [out] result: Number of 2-byte code units copied into the buffer, excluding the null terminator.

Returns napi_ok if the API succeeded. If a non-string napi_value is passed in it returns napi_string_expected.

This API returns the UTF16-encoded string corresponding the value passed in.

napi_get_value_uint32#

napi_status napi_get_value_uint32(napi_env env,
                                  napi_value value,
                                  uint32_t* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: napi_value representing JavaScript number.
• [out] result: C primitive equivalent of the given napi_value as a uint32_t.

Returns napi_ok if the API succeeded. If a non-number napi_value is passed in it returns napi_number_expected.

This API returns the C primitive equivalent of the given napi_value as a uint32_t.

Functions to get global instances#

napi_get_boolean#

napi_status napi_get_boolean(napi_env env, bool value, napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The value of the boolean to retrieve.
• [out] result: napi_value representing JavaScript Boolean singleton to retrieve.

Returns napi_ok if the API succeeded.

This API is used to return the JavaScript singleton object that is used to represent the given boolean value.

napi_get_global#

napi_status napi_get_global(napi_env env, napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [out] result: napi_value representing JavaScript global object.

Returns napi_ok if the API succeeded.

This API returns the global object.

napi_get_null#

napi_status napi_get_null(napi_env env, napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [out] result: napi_value representing JavaScript null object.

Returns napi_ok if the API succeeded.

This API returns the null object.

napi_get_undefined#

napi_status napi_get_undefined(napi_env env, napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [out] result: napi_value representing JavaScript Undefined value.

Returns napi_ok if the API succeeded.

This API returns the Undefined object.

Working with JavaScript values and abstract operations#

Node-API exposes a set of APIs to perform some abstract operations on JavaScript values.

These APIs support doing one of the following:

1. Coerce JavaScript values to specific JavaScript types (such as number or string).
2. Check the type of a JavaScript value.
3. Check for equality between two JavaScript values.

napi_coerce_to_bool#

napi_status napi_coerce_to_bool(napi_env env,
                                napi_value value,
                                napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to coerce.
• [out] result: napi_value representing the coerced JavaScript Boolean.

Returns napi_ok if the API succeeded.

This API implements the abstract operation ToBoolean() as defined in Section ToBoolean of the ECMAScript Language Specification.

napi_coerce_to_number#

napi_status napi_coerce_to_number(napi_env env,
                                  napi_value value,
                                  napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to coerce.
• [out] result: napi_value representing the coerced JavaScript number.

Returns napi_ok if the API succeeded.

This API implements the abstract operation ToNumber() as defined in Section ToNumber of the ECMAScript Language Specification. This function potentially runs JS code if the passed-in value is an object.

napi_coerce_to_object#

napi_status napi_coerce_to_object(napi_env env,
                                  napi_value value,
                                  napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to coerce.
• [out] result: napi_value representing the coerced JavaScript Object.

Returns napi_ok if the API succeeded.

This API implements the abstract operation ToObject() as defined in Section ToObject of the ECMAScript Language Specification.

napi_coerce_to_string#

napi_status napi_coerce_to_string(napi_env env,
                                  napi_value value,
                                  napi_value* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to coerce.
• [out] result: napi_value representing the coerced JavaScript string.

Returns napi_ok if the API succeeded.

This API implements the abstract operation ToString() as defined in Section ToString of the ECMAScript Language Specification. This function potentially runs JS code if the passed-in value is an object.

napi_typeof#

napi_status napi_typeof(napi_env env, napi_value value, napi_valuetype* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value whose type to query.
• [out] result: The type of the JavaScript value.

Returns napi_ok if the API succeeded.

• napi_invalid_arg if the type of value is not a known ECMAScript type and value is not an External value.

This API represents behavior similar to invoking the typeof Operator on the object as defined in Section typeof operator of the ECMAScript Language Specification. However, there are some differences:

1. It has support for detecting an External value.
2. It detects null as a separate type, while ECMAScript typeof would detect object.

If value has a type that is invalid, an error is returned.

napi_instanceof#

napi_status napi_instanceof(napi_env env,
                            napi_value object,
                            napi_value constructor,
                            bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] object: The JavaScript value to check.
• [in] constructor: The JavaScript function object of the constructor function to check against.
• [out] result: Boolean that is set to true if object instanceof constructor is true.

Returns napi_ok if the API succeeded.

This API represents invoking the instanceof Operator on the object as defined in Section instanceof operator of the ECMAScript Language Specification.

napi_is_array#

napi_status napi_is_array(napi_env env, napi_value value, bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to check.
• [out] result: Whether the given object is an array.

Returns napi_ok if the API succeeded.

This API represents invoking the IsArray operation on the object as defined in Section IsArray of the ECMAScript Language Specification.

napi_is_arraybuffer#

napi_status napi_is_arraybuffer(napi_env env, napi_value value, bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to check.
• [out] result: Whether the given object is an ArrayBuffer.

Returns napi_ok if the API succeeded.

This API checks if the Object passed in is an array buffer.

napi_is_buffer#

napi_status napi_is_buffer(napi_env env, napi_value value, bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to check.
• [out] result: Whether the given napi_value represents a node::Buffer or Uint8Array object.

Returns napi_ok if the API succeeded.

This API checks if the Object passed in is a buffer or Uint8Array. napi_is_typedarray should be preferred if the caller needs to check if the value is a Uint8Array.

napi_is_date#

napi_status napi_is_date(napi_env env, napi_value value, bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to check.
• [out] result: Whether the given napi_value represents a JavaScript Date object.

Returns napi_ok if the API succeeded.

This API checks if the Object passed in is a date.

napi_is_error#

napi_status napi_is_error(napi_env env, napi_value value, bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to check.
• [out] result: Whether the given napi_value represents an Error object.

Returns napi_ok if the API succeeded.

This API checks if the Object passed in is an Error.

napi_is_typedarray#

napi_status napi_is_typedarray(napi_env env, napi_value value, bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to check.
• [out] result: Whether the given napi_value represents a TypedArray.

Returns napi_ok if the API succeeded.

This API checks if the Object passed in is a typed array.

napi_is_dataview#

napi_status napi_is_dataview(napi_env env, napi_value value, bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] value: The JavaScript value to check.
• [out] result: Whether the given napi_value represents a DataView.

Returns napi_ok if the API succeeded.

This API checks if the Object passed in is a DataView.

napi_strict_equals#

napi_status napi_strict_equals(napi_env env,
                               napi_value lhs,
                               napi_value rhs,
                               bool* result)
c

• [in] env: The environment that the API is invoked under.
• [in] lhs: The JavaScript value to check.
• [in] rhs: The JavaScript value to check against.
• [out] result: Whether the two napi_value objects are equal.