Dre4m Shell
Server IP : 85.214.239.14  /  Your IP : 18.118.144.239
Web Server : Apache/2.4.62 (Debian)
System : Linux h2886529.stratoserver.net 4.9.0 #1 SMP Tue Jan 9 19:45:01 MSK 2024 x86_64
User : www-data ( 33)
PHP Version : 7.4.18
Disable Function : pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare,
MySQL : OFF  |  cURL : OFF  |  WGET : ON  |  Perl : ON  |  Python : ON  |  Sudo : ON  |  Pkexec : OFF
Directory :  /proc/3/root/proc/3/task/3/root/usr/share/doc/nodejs/contributing/

Upload File :
current_dir [ Writeable ] document_root [ Writeable ]

 

Command :


[ HOME SHELL ]     

Current File : /proc/3/root/proc/3/task/3/root/usr/share/doc/nodejs/contributing//adding-new-napi-api.md
# Contributing a new API to Node-API

Node-API is the ABI-stable API for native addons. We encourage contributions to enhance the API,
while also ensuring compatibility and adherence to guidelines. When adding a new API to Node-API,
please follow these principles and guidelines:

## Core principles

1. **Adherence to Node-API standards**
   * **Must** be a C API.
   * **Must** not throw exceptions.
   * **Must** return `napi_status`.
   * **Should** consume `napi_env`.
   * **Must** operate on primitive data types, pointers to primitive data types, or opaque handles.
   * **Must** be a necessary API, not a convenience API (which belongs in node-addon-api).
   * **Must** not break ABI compatibility with other Node.js versions.

2. **Maintaining VM agnosticism**
   * New APIs **should** be compatible with various JavaScript VMs.

## Documentation and testing

1. **Documentation**
   * PRs introducing new APIs **must** include corresponding documentation updates.
   * Experimental APIs **must** be clearly documented as experimental and require an explicit compile-time flag
     to opt-in (`#define`).

2. **Testing**
   * PRs **must** include at least one test case demonstrating API usage.
   * **Should** include test cases for various interesting uses of the API.
   * **Should** provide a sample demonstrating realistic usage, similar to a real-world addon.

## Process and approval

1. **Team discussion**
   * New APIs **should** be discussed in a Node-API team meeting.

2. **Review and approval**
   * A new API addition **must** be signed off by at least two Node-API team members.
   * **Should** be implemented in at least one other VM implementation of Node.js.

3. **Experimental phase**
   * New APIs **must** be marked as experimental for at least one minor Node.js release before promotion.
   * **Must** have a feature flag (`NODE_API_EXPERIMENTAL_HAS_<FEATURE>`) for distinguishing experimental
     feature existence.
   * **Must** be considered for backporting.
   * Exit criteria from experimental status include:
     * Opening a PR in `nodejs/node` to remove experimental status, tagged as **node-api** and **semver-minor**.
     * Approval by the Node-API team.
     * Availability of a down-level implementation if backporting is needed.
     * Usage by a published real-world module.
     * Implementation in an alternative VM.

Anon7 - 2022
AnonSec Team