node-gyp
- Node.js native addon build tool
node-gyp
is a cross-platform command-line tool written in Node.js for compiling native addon modules for Node.js. It contains a vendored copy of the gyp-next project that was previously used by the Chromium team and extended to support the development of Node.js native addons.
Note that node-gyp
is not used to build Node.js itself.
All current and LTS target versions of Node.js are supported. Depending on what version of Node.js is actually installed on your system node-gyp
downloads the necessary development files or headers for the target version. List of stable Node.js versions can be found on Node.js website.
Important
Python >= v3.12 requires node-gyp
>= v10
You can install node-gyp
using npm
:
Depending on your operating system, you will need to install:
make
Xcode Command Line Tools
which will install clang
, clang++
, and make
.
Xcode Command Line Tools
standalone by running xcode-select --install
. -- OR --Xcode -> Open Developer Tool -> More Developer Tools...
.Install tools with Chocolatey:
choco install python visualstudio2022-workload-vctools -y
Or install and configure Python and Visual Studio tools manually:
Install the current version of Python from the Microsoft Store.
Install Visual C++ Build Environment: For Visual Studio 2019 or later, use the Desktop development with C++
workload from Visual Studio Community. For a version older than Visual Studio 2019, install Visual Studio Build Tools with the Visual C++ build tools
option.
If the above steps didn't work for you, please visit Microsoft's Node.js Guidelines for Windows for additional tips.
To target native ARM64 Node.js on Windows on ARM, add the components "Visual C++ compilers and libraries for ARM64" and "Visual C++ ATL for ARM64".
To use the native ARM64 C++ compiler on Windows on ARM, ensure that you have Visual Studio 2022 17.4 or later installed.
It's advised to install following Powershell module: VSSetup using Install-Module VSSetup -Scope CurrentUser
. This will make Visual Studio detection logic to use more flexible and accessible method, avoiding Powershell's ConstrainedLanguage
mode.
node-gyp
requires that you have installed a supported version of Python. If you have multiple versions of Python installed, you can identify which version node-gyp
should use in one of the following ways:
--python
command-line option, e.g.:node-gyp <command> --python /path/to/executable/python
node-gyp
is called by way of npm
, and you have multiple versions of Python installed, then you can set the npm_config_python
environment variable to the appropriate path:export npm_config_python=/path/to/executable/python
Or on Windows:
py --list-paths # To see the installed Python versions set npm_config_python=C:\path\to\python.exe # CMD $Env:npm_config_python="C:\path\to\python.exe" # PowerShell
If the PYTHON
environment variable is set to the path of a Python executable, then that version will be used if it is a supported version.
If the NODE_GYP_FORCE_PYTHON
environment variable is set to the path of a Python executable, it will be used instead of any of the other configured or built-in Python search paths. If it's not a compatible version, no further searching will be done.
When building modules for third-party Node.js runtimes like Electron, which have different build configurations from the official Node.js distribution, you should use --dist-url
or --nodedir
flags to specify the headers of the runtime to build for.
Also when --dist-url
or --nodedir
flags are passed, node-gyp will use the config.gypi
shipped in the headers distribution to generate build configurations, which is different from the default mode that would use the process.config
object of the running Node.js instance.
Some old versions of Electron shipped malformed config.gypi
in their headers distributions, and you might need to pass --force-process-config
to node-gyp to work around configuration errors.
To compile your native addon first go to its root directory:
The next step is to generate the appropriate project build files for the current platform. Use configure
for that:
Auto-detection fails for Visual C++ Build Tools 2015, so --msvs_version=2015
needs to be added (not needed when run by npm as configured above):
node-gyp configure --msvs_version=2015
Note: The configure
step looks for a binding.gyp
file in the current directory to process. See below for instructions on creating a binding.gyp
file.
Now you will have either a Makefile
(on Unix platforms) or a vcxproj
file (on Windows) in the build/
directory. Next, invoke the build
command:
Now you have your compiled .node
bindings file! The compiled bindings end up in build/Debug/
or build/Release/
, depending on the build mode. At this point, you can require the .node
file with Node.js and run your tests!
Note: To create a Debug build of the bindings file, pass the --debug
(or -d
) switch when running either the configure
, build
or rebuild
commands.
A binding.gyp
file describes the configuration to build your module, in a JSON-like format. This file gets placed in the root of your package, alongside package.json
.
A barebones gyp
file appropriate for building a Node.js addon could look like:
{ "targets": [ { "target_name": "binding", "sources": [ "src/binding.cc" ] } ] }
The docs directory contains additional documentation on specific node-gyp topics that may be useful if you are experiencing problems installing or building addons using node-gyp.
Some additional resources for Node.js native addons and writing gyp
configuration files:
node-gyp
responds to the following commands:
help
Shows the help dialog build
Invokes make
/msbuild.exe
and builds the native addon clean
Removes the build
directory if it exists configure
Generates project build files for the current platform rebuild
Runs clean
, configure
and build
all in a row install
Installs Node.js header files for the given version list
Lists the currently installed Node.js header versions remove
Removes the Node.js header files for the given version
node-gyp
accepts the following command options:
-j n
, --jobs n
Run make
in parallel. The value max
will use all available CPU cores --target=v6.2.1
Node.js version to build for (default is process.version
) --silly
, --loglevel=silly
Log all progress to console --verbose
, --loglevel=verbose
Log most progress to console --silent
, --loglevel=silent
Don't log anything to console debug
, --debug
Make Debug build (default is Release
) --release
, --no-debug
Make Release build -C $dir
, --directory=$dir
Run command in different directory --make=$make
Override make
command (e.g. gmake
) --thin=yes
Enable thin static libraries --arch=$arch
Set target architecture (e.g. ia32) --tarball=$path
Get headers from a local tarball --devdir=$path
SDK download directory (default is OS cache directory) --ensure
Don't reinstall headers if already present --dist-url=$url
Download header tarball from custom URL --proxy=$url
Set HTTP(S) proxy for downloading header tarball --noproxy=$urls
Set urls to ignore proxies when downloading header tarball --cafile=$cafile
Override default CA chain (to download tarball) --nodedir=$path
Set the path to the node source code --python=$path
Set path to the Python binary --msvs_version=$version
Set Visual Studio version (Windows only) --solution=$solution
Set Visual Studio Solution version (Windows only) --force-process-config
Force using runtime's process.config
object to generate config.gypi
file
Use the form npm_config_OPTION_NAME
for any of the command options listed above (dashes in option names should be replaced by underscores).
For example, to set devdir
equal to /tmp/.gyp
, you would:
Run this on Unix:
export npm_config_devdir=/tmp/.gyp
Or this on Windows:
set npm_config_devdir=c:\temp\.gyp
npm
configuration for npm versions before v9
Use the form OPTION_NAME
for any of the command options listed above.
For example, to set devdir
equal to /tmp/.gyp
, you would run:
npm config set [--global] devdir /tmp/.gyp
Note: Configuration set via npm
will only be used when node-gyp
is run via npm
, not when node-gyp
is run directly.
node-gyp
is available under the MIT license. See the LICENSE file for details.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4