This is a fun mod of Node.JS that initially embedded a modified version of dcodeIO’s defunct pre-processor.js, to allow use of simple C++ like preprocessor directives in CJS modules. Subsequently, it also embedded CoffeeScript and TypeScript.

Thanks to the inspiration from dcodeIO et al =D

• Update to Node.JS 24.9.0 baseline and TypeScript v5.9.3.

It embeds:

• DS v1.2.2.
• CS v2.7.0.
• TS v5.9.3.

Refer to prior readmes for old changes.

• --experimental-strip-types is disabled (in favour of full TS transpiler), although Node.JS 23.6.0 enables it by default.

The mod thus allows Node.JS+ to run .ds, .cs and .ts scripts directly for D Script, CoffeeScript and TypeScript directly. D being just a simple moniker for preprocessor sprinkled scripts.

• Preprocessor directives are only available for D at the moment, but not for CS & TS.
  • v1.2.0: #import/#cs/#ts/#include code blocks can now use preprocessor directives within.
    • Each code block is transpiled (recursively) at the point of inclusion, and uses the #define'd variables at that point in time.
    • The effects of #define and #undef within the code blocks carry back to the main/parent code.
  • D transpiler does Not parse JS et al syntax, so it does Not recognise comments, and Will evaluate preprocessor directives in comment blocks as well.
• #ds: D scripts can be identified by file extension of .ds, or CJS files with initial 3 characters of #ds.
  • From v1.2.0, ESM modules can also specify #ds to use preprocessor directives.
  • #ds colors: declares a D script file and imports colors with basic color mapping:

  require('colors').setTheme({
      silly: 'rainbow',
      input: 'grey',
      verbose: 'cyan',
      prompt: 'grey',
      info: 'green',
      data: 'grey',
      help: 'cyan',
      warn: 'yellow',
      debug: 'blue',
      error: 'red'
  });

  • #ds seapp: [from v19.7.0] for embedding as single executable app, seapp 'restores' the normal 'require()'. Code inject:

  require = require('module').createRequire(__filename);

  which is the shortened form of the doc suggested:

  const { createRequire } = require('module');
  require = createRequire(__filename);

  • Note: original doc suggests require('node:module') but that throw an error as 'node:' is unrecognized! Simply use require('module') instead.
• #cs, #ts, #end: CS & TS code fragments/blocks can be embedded in D using #cs & #ts respectively, and terminated by #end.

  #ds colors This is a D example 
  #cs
  # this is a sample CoffeeScript code block in D
  square = (x) -> x * x
  #end
  console.log('2 squared='.bold.info, square(2));
  

  • To allow for #private_member syntax in TypeScript, all preprocessor directives must start the line. I.e. #'s that are not the 1st character of a line are ignored and not evaluated as preprocessor directives.
• #define: declares preprocessor variables for use with #ifdefs et al.
  • Does not support elaborate C++ like marco function definitions.
  • Can declare variables via DS_DEFINES environment variable.
    • Windows OS example: set DS_DEFINES=VERBOSE=false;DETAILS=true
  • Evaluation is simplistic: all #define and #undef for the same variable are tallied till the end, where the final value is used to evaluate #if's et al.
• #undef: (Since v1.2.0) undefines/removes preprocessor variables.
• #ifdef, #ifndef, #if, #elif, #else, #endif: conditional code blocks
• #put: pre-processor.js' version of inline expressions.
• #include, #include_once: inline one or more files, using simple path or glob pattern.
  • Root path defaults to '.' but can be specified via 'DS_ROOT' environment variable.

• #import: asychonously import a ESM module.
  • Example 1:

  #import exported_name '<ESM module path>'
  <callback content>
  #end
  

  expands to:

  (async () => {
      const exported_name = await import('<ESM module path>');
      <callback content>
  })();

  • Example 2:

  #import {exported_names} '<ESM module path>'
  <callback content>
  #end
  

  expands to:

  (async () => {
      const {exported_names} = await import('<ESM module path>');
      <callback content>
  })();

• #inflate: inline base64 encoded and zipped code block.
• others in the form #name where name is not a reserved directive keyword: exapnds to module.exports.name; ## expands to module.exports.

The transpilers are made available in global.transpiler. I.e. the transpiler functions are: transpiler.dscript.transpile, transpiler.coffeescript.compile, and transpiler.typescript.transpile. Example:

const dCode = '...'; //<- your code goes here
const outputCode = global.transpiler.dscript.transpile(dCode);

Example:

const coffeeCode = '...'; //<- your code goes here
const outputCode = global.transpiler.coffeescript.compile(
    coffeeCode,
    { bare: true }); //<- this option is to exclude function wrapper

Example:

const typescriptCode = '...'; //<- your code goes here
const outputCode = global.transpiler.typescript.transpile(typescriptCode);

You can replace the cs & ts transpilers at runtime, say if you wish to try different versions other than the latest embedded in Node.JS+. A few versions are provided in src_packs folder.

• *.packed.js are the non-minified ones good for digging into the innards of the transpiler.
• *.packed.min.js are the compact, minified ones.

To make the swap, for example in REPL, simple do this:

//backup if need to restore latest later:
global.transpiler.typescript_latest = global.transpiler.typescript;

//override with alternate version:
require('path_to_alternate_src/src_packs/ts/4.2.3/TypeScript.packed.min.js');

src_packs folder is not used in Node.JS build. It's purely provided for playing around with.

Use --experimental-external-dscript command-line option to override the internal D Script transpiler with that in external dscript.js file in current working directory. This is loaded before running your main code. An example is provided in src-packs/ds

REPL mode for D Script, CoffeeScript and TypeScript is activated by:

• Setting environment variable NODE_REPL_SCRIPT to 'ds', 'cs' or 'ts' respectively.
  • You can even change mode during REPL.
    • E.g. enter this command in REPL to switch to CoffeeScript: process.env.NODE_REPL_SCRIPT = 'cs'
  • You should also use editor mode for entering multi-lines code blocks.
    • Simply enter this command in REPL: .editor
    • Paste or type in your code.
    • To end and execute the code block, use shortcut: CTRL-D
    • To cancel and exit editor, use shortcut: CTRL-C
• Or running with commandline option '--repl=<script_type>'.
  • E.g.: node.exe --repl=ds

This mode is not available/valid for nodejs4Cpp DLL (node.DLL).

If you use bundled modules (packed for example by browserify or Webpack), the modules can now be registered using global.registerPackedModule(name, module) and subsequently obtained via require(name). require() will work as usual in typical Node.JS module-scoped style. If it (actually is require.resolve) fails, then it will try to find in bundled modules, and return it if found. If not the require.resolve's error is rethrown.

Example Register the modules to be exposed, in your WebPacked codes by calling registerPackedModule:

//webpacked_bundle.min.js
...
var __webpack_exports__ = {};
// This entry need to be wrapped in an IIFE because it need to be isolated against other modules in the chunk.
(() => {
function pack()
{
    registerPackedModule('@turf/turf', __webpack_require__(83855));
    registerPackedModule('moment', moment);
    registerPackedModule('express', __webpack_require__(26083));
    registerPackedModule('http-proxy', __webpack_require__(99528));
    registerPackedModule('abort-controller', __webpack_require__(44203));
    registerPackedModule('geo-coordinates-parser', __webpack_require__(33185));
}
pack();
...

Then in your app codes, use require as usual:

//your app
require('./webpacked_bundle.min.js'); //load the minified bundle
const turf = require('@turf/turf'),
    moment = require('moment'),
    ...
    { convert } = require('geo-coordinates-parser');

Usually when Node.JS launches, it gets locked into one of many modes, such as SEA, REPL or simple running a main script specified. From Node.JS 23.11.0+, these are added for switching to either REPL or run main script modes:

• process.runRepl(): Switch to REPL mode.

  • E.g.:

  ...
  console.log('End of main script, switching to REPL...');
  process.runRepl();

• process.runMain(scriptPath, ...argv): Switch to 'run main module' mode.

  • Inputs:
    • scriptPath: path to main script to run. It will be purged (if it exists; i.e. was loaded before) from require.cache and re-run.
    • argv: optional input argument strings.
  • E.g.:

  > process.runMain('./mainScript.js', 'argument 1', 'argument 2');
  

• Dev Notes:

  • The different modes are script in lib/internal/main/*.js.
    • Some codes in them have to be skipped to avoid crashing. For example, prepareMainThreadExecution() & markBootstrapComplete().
    • For REPL, internal/repl is modded to have a "Don't Exit" flag when closing REPL. The corresponding process.closeRepl() method added let's us to know if REPL mode is active, and is used to close the REPL without exiting Node.JS.
  • Tested OK switching back and forth between runRepl & runMain, and from SEA mode.
    • As noted, main module/script has to be purged from require.cache so as to let it be re-loaded and run again.

From Node.JS 22.x, VS2022 is needed; as VS2019 fails to compile some template syntax in V8 codes. CoffeeScript, TypeScript and Glob are now packed using Webpack.

If building for Windows 7, you'll need the deps\uv\src\win\util.c patch for uv_clock_gettime() to replace use of GetSystemTimePreciseAsFileTime() which is only available from Win8 onwards. If building for newer versions (>= 8.1), you may omit this patch.

It appears that chrome://inspect & --inspect-brk no longer respects breakpoints in Node.JS internals upon startup; i.e. will skip right to beginning of user code. Thus, you'll need to add debugger; statement (and build the EXE) to force a break to debug the internals!

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.

Contributors are expected to act in a collaborative manner to move the project forward. We encourage the constructive exchange of contrary opinions and compromise. The TSC reserves the right to limit or block contributors who repeatedly act in ways that discourage, exhaust, or otherwise negatively affect other participants.

This project has a Code of Conduct.

• Support
• Release types
  • Download
    • Current and LTS releases
    • Nightly releases
    • API documentation
  • Verifying binaries
• Building Node.js
• Security
• Contributing to Node.js
• Current project team members
  • TSC (Technical Steering Committee)
  • Collaborators
  • Triagers
  • Release keys
• License

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

• Current: Under active development. Code for the Current release is in the branch for its major version number (for example, v22.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.

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

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-hydrogen directory contains the latest Hydrogen (Node.js 18) release.

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

Each directory and filename includes the version (e.g., v22.0.0), followed by the UTC date (e.g., 20240424 for April 24, 2024), and the short commit SHA of the HEAD of the release (e.g., ddd0a9e494). For instance, a full directory name might look like v22.0.0-nightly20240424ddd0a9e494.

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

Download directories contain a SHASUMS256.txt.asc file with SHA checksums for the files and the releaser PGP signature.

You can get a trusted keyring from nodejs/release-keys, e.g. using curl:

curl -fsLo "/path/to/nodejs-keyring.kbx" "https://github.com/nodejs/release-keys/raw/HEAD/gpg/pubring.kbx"

Alternatively, you can import the releaser keys in your default keyring, see Release keys for commands to how to do that.

Then, you can verify the files you've downloaded locally (if you're using your default keyring, pass --keyring="${GNUPGHOME:-~/.gnupg}/pubring.kbx"):

curl -fsO "https://nodejs.org/dist/${VERSION}/SHASUMS256.txt.asc" \
&& gpgv --keyring="/path/to/nodejs-keyring.kbx" --output SHASUMS256.txt < SHASUMS256.txt.asc \
&& shasum --check SHASUMS256.txt --ignore-missing

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

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

• Contributing to the project
• Working Groups
• Strategic initiatives
• Technical values and prioritization

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

• aduh95 - Antoine du Hamel <duhamelantoine1995@gmail.com> (he/him)
• anonrig - Yagiz Nizipli <yagiz@nizipli.com> (he/him)
• benjamingr - Benjamin Gruenbaum <benjamingr@gmail.com>
• BridgeAR - Ruben Bridgewater <ruben@bridgewater.de> (he/him)
• gireeshpunathil - Gireesh Punathil <gpunathi@in.ibm.com> (he/him)
• jasnell - James M Snell <jasnell@gmail.com> (he/him)
• joyeecheung - Joyee Cheung <joyeec9h3@gmail.com> (she/her)
• legendecas - Chengzhong Wu <legendecas@gmail.com> (he/him)
• marco-ippolito - Marco Ippolito <marcoippolito54@gmail.com> (he/him)
• mcollina - Matteo Collina <matteo.collina@gmail.com> (he/him)
• mhdawson - Michael Dawson <midawson@redhat.com> (he/him)
• panva - Filip Skokan <panva.ip@gmail.com> (he/him)
• RafaelGSS - Rafael Gonzaga <rafael.nunu@hotmail.com> (he/him)
• RaisinTen - Darshan Sen <raisinten@gmail.com> (he/him)
• richardlau - Richard Lau <richard.lau@ibm.com>
• ronag - Robert Nagy <ronagy@icloud.com>
• ruyadorno - Ruy Adorno <ruy@vlt.sh> (he/him)
• ShogunPanda - Paolo Insogna <paolo@cowtech.it> (he/him)
• targos - Michaël Zasso <targos@protonmail.com> (he/him)
• tniessen - Tobias Nießen <tniessen@tnie.de> (he/him)

• BethGriggs - Beth Griggs <bethanyngriggs@gmail.com> (she/her)
• bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
• cjihrig - Colin Ihrig <cjihrig@gmail.com> (he/him)
• codebytere - Shelley Vohr <shelley.vohr@gmail.com> (she/her)
• GeoffreyBooth - Geoffrey Booth <webadmin@geoffreybooth.com> (he/him)
• MoLow - Moshe Atlow <moshe@atlow.co.il> (he/him)
• Trott - Rich Trott <rtrott@gmail.com> (he/him)

• abmusse - Abdirahim Musse <abdirahim.musse@ibm.com>
• addaleax - Anna Henningsen <anna@addaleax.net> (she/her)
• Aditi-1400 - Aditi Singh <aditisingh1400@gmail.com> (she/her)
• aduh95 - Antoine du Hamel <duhamelantoine1995@gmail.com> (he/him) - Support me
• anonrig - Yagiz Nizipli <yagiz@nizipli.com> (he/him) - Support me
• atlowChemi - Chemi Atlow <chemi@atlow.co.il> (he/him)
• Ayase-252 - Qingyu Deng <i@ayase-lab.com>
• bengl - Bryan English <bryan@bryanenglish.com> (he/him)
• benjamingr - Benjamin Gruenbaum <benjamingr@gmail.com>
• BethGriggs - Beth Griggs <bethanyngriggs@gmail.com> (she/her)
• bnb - Tierney Cyren <hello@bnb.im> (they/them)
• bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
• BridgeAR - Ruben Bridgewater <ruben@bridgewater.de> (he/him)
• cclauss - Christian Clauss <cclauss@me.com> (he/him)
• cjihrig - Colin Ihrig <cjihrig@gmail.com> (he/him)
• codebytere - Shelley Vohr <shelley.vohr@gmail.com> (she/her)
• cola119 - Kohei Ueno <kohei.ueno119@gmail.com> (he/him)
• daeyeon - Daeyeon Jeong <daeyeon.dev@gmail.com> (he/him)
• dario-piotrowicz - Dario Piotrowicz <dario.piotrowicz@gmail.com> (he/him)
• debadree25 - Debadree Chatterjee <debadree333@gmail.com> (he/him)
• deokjinkim - Deokjin Kim <deokjin81.kim@gmail.com> (he/him)
• edsadr - Adrian Estrada <edsadr@gmail.com> (he/him)
• ErickWendel - Erick Wendel <erick.workspace@gmail.com> (he/him)
• Ethan-Arrowood - Ethan Arrowood <ethan@arrowood.dev> (he/him)
• F3n67u - Feng Yu <F3n67u@outlook.com> (he/him)
• fhinkel - Franziska Hinkelmann <franziska.hinkelmann@gmail.com> (she/her)
• Flarna - Gerhard Stöbich <deb2001-github@yahoo.de> (he/they)
• gabrielschulhof - Gabriel Schulhof <gabrielschulhof@gmail.com>
• geeksilva97 - Edy Silva <edigleyssonsilva@gmail.com> (he/him)
• gengjiawen - Jiawen Geng <technicalcute@gmail.com>
• GeoffreyBooth - Geoffrey Booth <webadmin@geoffreybooth.com> (he/him)
• gireeshpunathil - Gireesh Punathil <gpunathi@in.ibm.com> (he/him)
• guybedford - Guy Bedford <guybedford@gmail.com> (he/him)
• H4ad - Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br> (he/him)
• HarshithaKP - Harshitha K P <harshitha014@gmail.com> (she/her)
• himself65 - Zeyu "Alex" Yang <himself65@outlook.com> (he/him)
• IlyasShabi - Ilyas Shabi <ilyasshabi94@gmail.com> (he/him)
• islandryu - Ryuhei Shima <shimaryuhei@gmail.com> (he/him)
• jakecastelli - Jake Yuesong Li <jake.yuesong@gmail.com> (he/him)
• JakobJingleheimer - Jacob Smith <jacob@frende.me> (he/him)
• jasnell - James M Snell <jasnell@gmail.com> (he/him)
• jazelly - Jason Zhang <xzha4350@gmail.com> (he/him)
• jkrems - Jan Martin <jan.krems@gmail.com> (he/him)
• JonasBa - Jonas Badalic <jonas.badalic@gmail.com> (he/him)
• joyeecheung - Joyee Cheung <joyeec9h3@gmail.com> (she/her)
• juanarbol - Juan José Arboleda <soyjuanarbol@gmail.com> (he/him)
• JungMinu - Minwoo Jung <nodecorelab@gmail.com> (he/him)
• KhafraDev - Matthew Aitken <maitken033380023@gmail.com> (he/him)
• legendecas - Chengzhong Wu <legendecas@gmail.com> (he/him)
• lemire - Daniel Lemire <daniel@lemire.me>
• LiviaMedeiros - LiviaMedeiros <livia@cirno.name>
• ljharb - Jordan Harband <ljharb@gmail.com>
• lpinca - Luigi Pinca <luigipinca@gmail.com> (he/him)
• lukekarrys - Luke Karrys <luke@lukekarrys.com> (he/him)
• Lxxyx - Zijian Liu <lxxyxzj@gmail.com> (he/him)
• marco-ippolito - Marco Ippolito <marcoippolito54@gmail.com> (he/him) - Support me
• marsonya - Akhil Marsonya <akhil.marsonya27@gmail.com> (he/him)
• MattiasBuelens - Mattias Buelens <mattias@buelens.com> (he/him)
• mcollina - Matteo Collina <matteo.collina@gmail.com> (he/him) - Support me
• meixg - Xuguang Mei <meixuguang@gmail.com> (he/him)
• mhdawson - Michael Dawson <midawson@redhat.com> (he/him)
• MoLow - Moshe Atlow <moshe@atlow.co.il> (he/him)
• MrJithil - Jithil P Ponnan <jithil@outlook.com> (he/him)
• ovflowd - Claudio Wunder <cwunder@gnome.org> (he/they)
• panva - Filip Skokan <panva.ip@gmail.com> (he/him) - Support me
• pimterry - Tim Perry <pimterry@gmail.com> (he/him)
• pmarchini - Pietro Marchini <pietro.marchini94@gmail.com> (he/him)
• puskin - Giovanni Bucci <github@puskin.it> (he/him)
• Qard - Stephen Belanger <admin@stephenbelanger.com> (he/him)
• RafaelGSS - Rafael Gonzaga <rafael.nunu@hotmail.com> (he/him) - Support me
• RaisinTen - Darshan Sen <raisinten@gmail.com> (he/him) - Support me
• richardlau - Richard Lau <richard.lau@ibm.com>
• rluvaton - Raz Luvaton <rluvaton@gmail.com> (he/him)
• ronag - Robert Nagy <ronagy@icloud.com>
• ruyadorno - Ruy Adorno <ruy@vlt.sh> (he/him)
• santigimeno - Santiago Gimeno <santiago.gimeno@gmail.com>
• ShogunPanda - Paolo Insogna <paolo@cowtech.it> (he/him)
• srl295 - Steven R Loomis <srl295@gmail.com>
• StefanStojanovic - Stefan Stojanovic <stefan.stojanovic@janeasystems.com> (he/him)
• sxa - Stewart X Addison <sxa@redhat.com> (he/him)
• targos - Michaël Zasso <targos@protonmail.com> (he/him)
• theanarkh - theanarkh <theratliter@gmail.com> (he/him)
• tniessen - Tobias Nießen <tniessen@tnie.de> (he/him)
• trivikr - Trivikram Kamat <trivikr.dev@gmail.com>
• Trott - Rich Trott <rtrott@gmail.com> (he/him)
• UlisesGascon - Ulises Gascón <ulisesgascongonzalez@gmail.com> (he/him)
• vmoroz - Vladimir Morozov <vmorozov@microsoft.com> (he/him)
• VoltrexKeyva - Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> (he/him)
• zcbenz - Cheng Zhao <zcbenz@gmail.com> (he/him)
• ZYSzys - Yongsheng Zhang <zyszys98@gmail.com> (he/him)

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

• 1ilsang - Sangchul Lee <1ilsang.dev@gmail.com> (he/him)
• atlowChemi - Chemi Atlow <chemi@atlow.co.il> (he/him)
• Ayase-252 - Qingyu Deng <i@ayase-lab.com>
• bjohansebas - Sebastian Beltran <bjohansebas@gmail.com>
• bmuenzenmeyer - Brian Muenzenmeyer <brian.muenzenmeyer@gmail.com> (he/him)
• CanadaHonk - Oliver Medhurst <honk@goose.icu> (they/them)
• daeyeon - Daeyeon Jeong <daeyeon.dev@gmail.com> (he/him)
• F3n67u - Feng Yu <F3n67u@outlook.com> (he/him)
• gireeshpunathil - Gireesh Punathil <gpunathi@in.ibm.com> (he/him)
• gurgunday - Gürgün Dayıoğlu <hey@gurgun.day>
• HBSPS - Wiyeong Seo <hbsps.dev@gmail.com>
• iam-frankqiu - Frank Qiu <iam.frankqiu@gmail.com> (he/him)
• KevinEady - Kevin Eady <kevin.c.eady@gmail.com> (he/him)
• marsonya - Akhil Marsonya <akhil.marsonya27@gmail.com> (he/him)
• meixg - Xuguang Mei <meixuguang@gmail.com> (he/him)
• milesguicent - Miles Guicent <guicent@pm.me> (he/him)
• preveen-stack - Preveen Padmanabhan <wide4head@gmail.com> (he/him)
• RaisinTen - Darshan Sen <raisinten@gmail.com> (he/him)
• VoltrexKeyva - Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> (he/him)

Triagers follow the Triage Guide when responding to new issues.

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

• Antoine du Hamel <duhamelantoine1995@gmail.com> 5BE8A3F6C8A5C01D106C0AD820B1A390B168D356
• Juan José Arboleda <soyjuanarbol@gmail.com> DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7
• Marco Ippolito <marcoippolito54@gmail.com> CC68F5A3106FF448322E48ED27F5E38D5B0A215F
• Michaël Zasso <targos@protonmail.com> 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600
• Rafael Gonzaga <rafael.nunu@hotmail.com> 890C08DB8579162FEE0DF9DB8BEAB4DFCF555EF4
• Richard Lau <richard.lau@ibm.com> C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C
• Ruy Adorno <ruyadorno@hotmail.com> 108F52B48DB57BB0CC439B2997B01419BD92F80A
• Ulises Gascón <ulisesgascongonzalez@gmail.com> A363A499291CBBC940DD62E41F10027AF002F8B0

You can use the keyring the project maintains at https://github.com/nodejs/release-keys/raw/refs/heads/main/gpg-only-active-keys/pubring.kbx. Alternatively, you can import them from a public key server. Have in mind that the project cannot guarantee the availability of the server nor the keys on that server.

gpg --keyserver hkps://keys.openpgp.org --recv-keys 5BE8A3F6C8A5C01D106C0AD820B1A390B168D356 # Antoine du Hamel
gpg --keyserver hkps://keys.openpgp.org --recv-keys DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7 # Juan José Arboleda
gpg --keyserver hkps://keys.openpgp.org --recv-keys CC68F5A3106FF448322E48ED27F5E38D5B0A215F # Marco Ippolito
gpg --keyserver hkps://keys.openpgp.org --recv-keys 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 # Michaël Zasso
gpg --keyserver hkps://keys.openpgp.org --recv-keys 890C08DB8579162FEE0DF9DB8BEAB4DFCF555EF4 # Rafael Gonzaga
gpg --keyserver hkps://keys.openpgp.org --recv-keys C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C # Richard Lau
gpg --keyserver hkps://keys.openpgp.org --recv-keys 108F52B48DB57BB0CC439B2997B01419BD92F80A # Ruy Adorno
gpg --keyserver hkps://keys.openpgp.org --recv-keys A363A499291CBBC940DD62E41F10027AF002F8B0 # Ulises Gascón

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

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.

• Datadog
  • bengl - Bryan English <bryan@bryanenglish.com> (he/him)
• HeroDevs
  • marco-ippolito - Marco Ippolito <marcoippolito54@gmail.com> (he/him)
• NodeSource
  • juanarbol - Juan José Arboleda <soyjuanarbol@gmail.com> (he/him)
  • RafaelGSS - Rafael Gonzaga <rafael.nunu@hotmail.com> (he/him)
• Platformatic
  • mcollina - Matteo Collina <matteo.collina@gmail.com> (he/him)
• Red Hat / IBM
  • joesepi - Joe Sepi <joesepi@ibm.com> (he/him)
  • mhdawson - Michael Dawson <midawson@redhat.com> (he/him)

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.