Node.js JavaScript runtime 🐢🚀
Go to file
William Marlow 1af70548bd build: fix various shared library build issues
Node.js unofficially supports a shared library variant where the
main node executable is a thin wrapper around node.dll/libnode.so.
The key benefit of this is to support embedding Node.js in other
applications.

Since Node.js 12 there have been a number of issues preventing the
shared library build from working correctly, primarily on Windows:

* A number of functions used executables such as `mksnapshot` are
    not exported from `libnode.dll` using a `NODE_EXTERN` attribute
* A dependency on the `Winmm` system library is missing
* Incorrect defines on executable targets leads to `node.exe`
    claiming to export a number of functions that are actually in
    `libnode.dll`
* Because `node.exe` attempts to export symbols, `node.lib` gets
    generated causing native extensions to try to link against
    `node.exe` not `libnode.dll`.
* Similarly, because `node.dll` was renamed to `libnode.dll`,
    native extensions don't know to look for `libnode.lib` rather
    than `node.lib`.
* On macOS an RPATH is added to find `libnode.dylib` relative to
    `node` in the same folder. This works fine from the
    `out/Release` folder but not from an installed prefix, where
    `node` will be in `bin/` and `libnode.dylib` will be in `lib/`.
* Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs
    setting correctly for `bin/node` to find `lib/libnode.so`.

For the `libnode.lib` vs `node.lib` issue there are two possible
options:

1. Ensure `node.lib` from `node.exe` does not get generated, and
    instead copy `libnode.lib` to `node.lib`. This means addons
    compiled when referencing the correct `node.lib` file will
    correctly depend on `libnode.dll`. The down side is that
    native addons compiled with stock Node.js will still try to
    resolve symbols against node.exe rather than libnode.dll.
2. After building `libnode.dll`, dump the exports using `dumpbin`,
    and process this to generate a `node.def` file to be linked into
    `node.exe` with the `/DEF:node.def` flag. The export entries
    in `node.def` will all read
    ```
    my_symbol=libnode.my_symbol
    ```
    so that `node.exe` will redirect all exported symbols back to
    `libnode.dll`. This has the benefit that addons compiled with
    stock Node.js will load correctly into `node.exe` from a shared
    library build, but means that every embedding executable also
    needs to perform this same trick.

I went with the first option as it is the cleaner of the two
solutions in my opinion. Projects wishing to generate a shared
library variant of Node.js can now, for example,
```
.\vcbuild dll package vs
```
to generate a full node installation including `libnode.dll`,
`Release\node.lib`, and all the necessary headers. Native addons
can then be built against the shared library build easily by
specifying the correct `nodedir` option.

For example
```
>npx node-gyp configure --nodedir
   C:\Users\User\node\Release\node-v18.0.0-win-x64
...
>npx node-gyp build
...
>dumpbin /dependents build\Release\binding.node
Microsoft (R) COFF/PE Dumper Version 14.29.30136.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file build\Release\binding.node

File Type: DLL

  Image has the following dependencies:

    KERNEL32.dll
    libnode.dll
    VCRUNTIME140.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
...
```

PR-URL: https://github.com/nodejs/node/pull/41850
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
2022-05-06 17:24:46 -04:00
.github build: fix format-cpp 2022-04-20 16:00:22 +01:00
benchmark benchmark: fix misc/startup failure 2022-04-17 15:37:21 +01:00
deps deps: upgrade npm to 8.9.0 2022-05-05 10:55:34 +01:00
doc doc: improve commit message example for releases 2022-05-06 17:16:28 +01:00
lib lib,test: enable wasm/webapi/empty-body WPT 2022-05-05 22:57:31 +01:00
src build: fix various shared library build issues 2022-05-06 17:24:46 -04:00
test lib,test: enable wasm/webapi/empty-body WPT 2022-05-05 22:57:31 +01:00
tools build: fix various shared library build issues 2022-05-06 17:24:46 -04:00
typings async_hooks: remove destroyed symbol on Promises 2022-03-21 20:35:05 +00:00
.clang-format
.cpplint
.editorconfig
.eslintignore doc: make header smaller and dropdown click-driven when JS is on 2022-03-22 21:31:56 +00:00
.eslintrc.js src: add initial shadow realm support 2022-05-02 18:46:31 +02:00
.flake8
.gitattributes
.gitignore tools: add compile_commands to ignore file 2022-01-24 14:39:31 +00:00
.mailmap meta: update AUTHORS 2022-04-24 09:18:55 -07:00
.nycrc
.yamllint.yaml build: extend yamllint configuration 2022-02-14 19:09:26 +01:00
android-configure
AUTHORS meta: update AUTHORS 2022-04-24 09:18:55 -07:00
BSDmakefile
BUILDING.md doc: reword "test directory" 2022-04-28 18:58:48 +00:00
CHANGELOG.md 2022-05-04, Version 14.19.2 'Fermium' (LTS) 2022-05-04 12:05:24 -05:00
CODE_OF_CONDUCT.md
codecov.yml
common.gypi deps: make V8 10.2 ABI-compatible with 10.1 2022-04-21 11:56:00 +02:00
configure
configure.py build: fix indeterminacy of icu_locales value 2022-05-06 12:20:44 +01:00
CONTRIBUTING.md doc: make contributing info more discoverable 2022-01-18 14:24:30 -05:00
glossary.md
GOVERNANCE.md doc: make contributing info more discoverable 2022-01-18 14:24:30 -05:00
LICENSE deps: update ICU to 71.1 2022-04-10 10:13:52 +01:00
Makefile build: run V8 tests with detected Python version 2022-04-21 11:56:01 +02:00
node.gyp build: fix various shared library build issues 2022-05-06 17:24:46 -04:00
node.gypi build: fix various shared library build issues 2022-05-06 17:24:46 -04:00
onboarding.md doc: make contributing info more discoverable 2022-01-18 14:24:30 -05:00
README.md meta: move one or more collaborators to emeritus 2022-05-05 19:38:59 -07:00
SECURITY.md doc: remove reference to obsolete security program 2022-03-01 04:40:12 +00:00
tsconfig.json
vcbuild.bat build: fix various shared library build issues 2022-05-06 17:24:46 -04:00

Node.js

Node.js is an open-source, cross-platform, JavaScript runtime environment.

For information on using Node.js, see the Node.js website.

The Node.js project uses an open governance model. The OpenJS Foundation provides support for the project.

This project has a Code of Conduct.

Table of contents

Support

Looking for help? Check out the instructions for getting support.

Release types

  • Current: Under active development. Code for the Current release is in the branch for its major version number (for example, v15.x). Node.js releases a new major version every 6 months, allowing for breaking changes. This happens in April and October every year. Releases appearing each October have a support life of 8 months. Releases appearing each April convert to LTS (see below) each October.
  • LTS: Releases that receive Long Term Support, with a focus on stability and security. Every even-numbered major version will become an LTS release. LTS releases receive 12 months of Active LTS support and a further 18 months of Maintenance. LTS release lines have alphabetically-ordered code names, beginning with v4 Argon. There are no breaking changes or feature additions, except in some special circumstances.
  • Nightly: Code from the Current branch built every 24-hours when there are changes. Use with caution.

Current and LTS releases follow semantic versioning. A member of the Release Team signs each Current and LTS release. For more information, see the Release README.

Download

Binaries, installers, and source tarballs are available at https://nodejs.org/en/download/.

Current and LTS releases

https://nodejs.org/download/release/

The latest directory is an alias for the latest Current release. The latest-codename directory is an alias for the latest release from an LTS line. For example, the latest-fermium directory contains the latest Fermium (Node.js 14) release.

Nightly releases

https://nodejs.org/download/nightly/

Each directory name and filename contains a date (in UTC) and the commit SHA at the HEAD of the release.

API documentation

Documentation for the latest Current release is at https://nodejs.org/api/. Version-specific documentation is available in each release directory in the docs subdirectory. Version-specific documentation is also at https://nodejs.org/download/docs/.

Verifying binaries

Download directories contain a SHASUMS256.txt file with SHA checksums for the files.

To download SHASUMS256.txt using curl:

$ curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt

To check that a downloaded file matches the checksum, run it through sha256sum with a command such as:

$ grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c -

For Current and LTS, the GPG detached signature of SHASUMS256.txt is in SHASUMS256.txt.sig. You can use it with gpg to verify the integrity of SHASUMS256.txt. You will first need to import the GPG keys of individuals authorized to create releases. To import the keys:

$ gpg --keyserver hkps://keys.openpgp.org --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D

See Release keys for a script to import active release keys.

Next, download the SHASUMS256.txt.sig for the release:

$ curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt.sig

Then use gpg --verify SHASUMS256.txt.sig SHASUMS256.txt to verify the file's signature.

Building Node.js

See BUILDING.md for instructions on how to build Node.js from source and a list of supported platforms.

Security

For information on reporting security vulnerabilities in Node.js, see SECURITY.md.

Contributing to Node.js

Current project team members

For information about the governance of the Node.js project, see GOVERNANCE.md.

TSC (Technical Steering Committee)

Emeriti

TSC emeriti

Collaborators

Emeriti

Collaborator emeriti

Collaborators follow the Collaborator Guide in maintaining the Node.js project.

Triagers

Release keys

Primary GPG keys for Node.js Releasers (some Releasers sign with subkeys):

To import the full set of trusted release keys (including subkeys possibly used to sign releases):

gpg --keyserver hkps://keys.openpgp.org --recv-keys 4ED778F539E3634C779C87C6D7062848A1AB005C
gpg --keyserver hkps://keys.openpgp.org --recv-keys 141F07595B7B3FFE74309A937405533BE57C7D57
gpg --keyserver hkps://keys.openpgp.org --recv-keys 94AE36675C464D64BAFA68DD7434390BDBE9B9C5
gpg --keyserver hkps://keys.openpgp.org --recv-keys 74F12602B6F1C4E913FAA37AD3A89613643B6201
gpg --keyserver hkps://keys.openpgp.org --recv-keys 71DCFD284A79C3B38668286BC97EC7A07EDE3FC1
gpg --keyserver hkps://keys.openpgp.org --recv-keys 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600
gpg --keyserver hkps://keys.openpgp.org --recv-keys C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8
gpg --keyserver hkps://keys.openpgp.org --recv-keys C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C
gpg --keyserver hkps://keys.openpgp.org --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D
gpg --keyserver hkps://keys.openpgp.org --recv-keys A48C2BEE680E841632CD4E44F07496B3EB3C1762
gpg --keyserver hkps://keys.openpgp.org --recv-keys 108F52B48DB57BB0CC439B2997B01419BD92F80A
gpg --keyserver hkps://keys.openpgp.org --recv-keys B9E2F5981AA6E0CD28160D9FF13993A75599653C

See Verifying binaries for how to use these keys to verify a downloaded file.

Other keys used to sign some previous releases

Security release stewards

When possible, the commitment to take slots in the security release steward rotation is made by companies in order to ensure individuals who act as security stewards have the support and recognition from their employer to be able to prioritize security releases. Security release stewards manage security releases on a rotation basis as outlined in the security release process.

License

Node.js is available under the MIT license. Node.js also includes external libraries that are available under a variety of licenses. See LICENSE for the full license text.