ReactFlow前端拖拽模型与参数配置功能MVP

This commit is contained in:
ljz committed 2026-07-11 10:49:11 +08:00
1 parent 70c91ed019
commit d3b99304fb
2001 files changed
+349044 -548

No files matched your search

+5
View File
@@ -12,6 +12,11 @@ htmlcov/
# Local virtual environments
.venv/
.venv-win/
PythonModels/runs/
app/data/
frontend/node_modules/
frontend/dist/
frontend/.vite/
venv/
env/
Binary file not shown.
File diff suppressed because it is too large. Load diff
File diff suppressed because it is too large. Load diff
+907
View File
@@ -0,0 +1,907 @@
# 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](./GOVERNANCE.md). 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](./GOVERNANCE.md#technical-steering-committee)
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][].**
## Table of contents
* [Support](#support)
* [Release types](#release-types)
* [Download](#download)
* [Current and LTS releases](#current-and-lts-releases)
* [Nightly releases](#nightly-releases)
* [API documentation](#api-documentation)
* [Verifying binaries](#verifying-binaries)
* [Building Node.js](#building-nodejs)
* [Security](#security)
* [Contributing to Node.js](#contributing-to-nodejs)
* [Current project team members](#current-project-team-members)
* [TSC (Technical Steering Committee)](#tsc-technical-steering-committee)
* [Collaborators](#collaborators)
* [Triagers](#triagers)
* [Release keys](#release-keys)
* [License](#license)
## Support
Looking for help? Check out the
[instructions for getting support](.github/SUPPORT.md).
## Release types
* **Current**: Under active development. Code for the Current release is in the
branch for its major version number (for example,
[v22.x](https://github.com/nodejs/node/tree/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](https://semver.org). A
member of the Release Team [signs](#release-keys) each Current and LTS release.
For more information, see the
[Release README](https://github.com/nodejs/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](https://nodejs.org/download/release/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](https://nodejs.org/download/release/latest-hydrogen/)
directory contains the latest Hydrogen (Node.js 18) release.
#### Nightly releases
<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`.
#### 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.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`:
```bash
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](#release-keys) for commands on 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"`):
```bash
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
```
## Building Node.js
See [BUILDING.md](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](./SECURITY.md).
## Contributing to Node.js
* [Contributing to the project][]
* [Working Groups][]
* [Strategic initiatives][]
* [Technical values and prioritization][]
## Current project team members
For information about the governance of the Node.js project, see
[GOVERNANCE.md](./GOVERNANCE.md).
<!-- node-core-utils and find-inactive-tsc.mjs depend on the format of the TSC
list. If the format changes, those utilities need to be tested and
updated. -->
### TSC (Technical Steering Committee)
#### TSC voting members
<!--lint disable prohibited-strings-->
* [aduh95](https://github.com/aduh95) -
**Antoine du Hamel** <<duhamelantoine1995@gmail.com>> (he/him)
* [anonrig](https://github.com/anonrig) -
**Yagiz Nizipli** <<yagiz@nizipli.com>> (he/him)
* [benjamingr](https://github.com/benjamingr) -
**Benjamin Gruenbaum** <<benjamingr@gmail.com>>
* [BridgeAR](https://github.com/BridgeAR) -
**Ruben Bridgewater** <<ruben@bridgewater.de>> (he/him)
* [gireeshpunathil](https://github.com/gireeshpunathil) -
**Gireesh Punathil** <<gpunathi@in.ibm.com>> (he/him)
* [jasnell](https://github.com/jasnell) -
**James M Snell** <<jasnell@gmail.com>> (he/him)
* [joyeecheung](https://github.com/joyeecheung) -
**Joyee Cheung** <<joyeec9h3@gmail.com>> (she/her)
* [legendecas](https://github.com/legendecas) -
**Chengzhong Wu** <<legendecas@gmail.com>> (he/him)
* [marco-ippolito](https://github.com/marco-ippolito) -
**Marco Ippolito** <<marcoippolito54@gmail.com>> (he/him)
* [mcollina](https://github.com/mcollina) -
**Matteo Collina** <<matteo.collina@gmail.com>> (he/him)
* [panva](https://github.com/panva) -
**Filip Skokan** <<panva.ip@gmail.com>> (he/him)
* [RafaelGSS](https://github.com/RafaelGSS) -
**Rafael Gonzaga** <<rafael.nunu@hotmail.com>> (he/him)
* [RaisinTen](https://github.com/RaisinTen) -
**Darshan Sen** <<raisinten@gmail.com>> (he/him)
* [richardlau](https://github.com/richardlau) -
**Richard Lau** <<richard.lau@ibm.com>>
* [ronag](https://github.com/ronag) -
**Robert Nagy** <<ronagy@icloud.com>>
* [ruyadorno](https://github.com/ruyadorno) -
**Ruy Adorno** <<ruy@vlt.sh>> (he/him)
* [ShogunPanda](https://github.com/ShogunPanda) -
**Paolo Insogna** <<paolo@cowtech.it>> (he/him)
* [targos](https://github.com/targos) -
**Michaël Zasso** <<targos@protonmail.com>> (he/him)
* [tniessen](https://github.com/tniessen) -
**Tobias Nießen** <<tniessen@tnie.de>> (he/him)
#### TSC regular members
* [BethGriggs](https://github.com/BethGriggs) -
**Beth Griggs** <<bethanyngriggs@gmail.com>> (she/her)
* [bnoordhuis](https://github.com/bnoordhuis) -
**Ben Noordhuis** <<info@bnoordhuis.nl>>
* [cjihrig](https://github.com/cjihrig) -
**Colin Ihrig** <<cjihrig@gmail.com>> (he/him)
* [codebytere](https://github.com/codebytere) -
**Shelley Vohr** <<shelley.vohr@gmail.com>> (she/her)
* [GeoffreyBooth](https://github.com/GeoffreyBooth) -
**Geoffrey Booth** <<webadmin@geoffreybooth.com>> (he/him)
* [MoLow](https://github.com/MoLow) -
**Moshe Atlow** <<moshe@atlow.co.il>> (he/him)
* [Trott](https://github.com/Trott) -
**Rich Trott** <<rtrott@gmail.com>> (he/him)
<details>
<summary>TSC emeriti members</summary>
#### TSC emeriti members
* [addaleax](https://github.com/addaleax) -
**Anna Henningsen** <<anna@addaleax.net>> (she/her)
* [apapirovski](https://github.com/apapirovski) -
**Anatoli Papirovski** <<apapirovski@mac.com>> (he/him)
* [ChALkeR](https://github.com/ChALkeR) -
**Сковорода Никита Андреевич** <<chalkerx@gmail.com>> (he/him)
* [chrisdickinson](https://github.com/chrisdickinson) -
**Chris Dickinson** <<christopher.s.dickinson@gmail.com>>
* [danbev](https://github.com/danbev) -
**Daniel Bevenius** <<daniel.bevenius@gmail.com>> (he/him)
* [danielleadams](https://github.com/danielleadams) -
**Danielle Adams** <<adamzdanielle@gmail.com>> (she/her)
* [evanlucas](https://github.com/evanlucas) -
**Evan Lucas** <<evanlucas@me.com>> (he/him)
* [fhinkel](https://github.com/fhinkel) -
**Franziska Hinkelmann** <<franziska.hinkelmann@gmail.com>> (she/her)
* [Fishrock123](https://github.com/Fishrock123) -
**Jeremiah Senkpiel** <<fishrock123@rocketmail.com>> (he/they)
* [gabrielschulhof](https://github.com/gabrielschulhof) -
**Gabriel Schulhof** <<gabrielschulhof@gmail.com>>
* [gibfahn](https://github.com/gibfahn) -
**Gibson Fahnestock** <<gibfahn@gmail.com>> (he/him)
* [indutny](https://github.com/indutny) -
**Fedor Indutny** <<fedor@indutny.com>>
* [isaacs](https://github.com/isaacs) -
**Isaac Z. Schlueter** <<i@izs.me>>
* [joshgav](https://github.com/joshgav) -
**Josh Gavant** <<josh.gavant@outlook.com>>
* [mhdawson](https://github.com/mhdawson) -
**Michael Dawson** <<midawson@redhat.com>> (he/him)
* [mmarchini](https://github.com/mmarchini) -
**Mary Marchini** <<oss@mmarchini.me>> (she/her)
* [mscdex](https://github.com/mscdex) -
**Brian White** <<mscdex@mscdex.net>>
* [MylesBorins](https://github.com/MylesBorins) -
**Myles Borins** <<myles.borins@gmail.com>> (he/him)
* [nebrius](https://github.com/nebrius) -
**Bryan Hughes** <<bryan@nebri.us>>
* [ofrobots](https://github.com/ofrobots) -
**Ali Ijaz Sheikh** <<ofrobots@google.com>> (he/him)
* [orangemocha](https://github.com/orangemocha) -
**Alexis Campailla** <<orangemocha@nodejs.org>>
* [piscisaureus](https://github.com/piscisaureus) -
**Bert Belder** <<bertbelder@gmail.com>>
* [rvagg](https://github.com/rvagg) -
**Rod Vagg** <<r@va.gg>>
* [sam-github](https://github.com/sam-github) -
**Sam Roberts** <<vieuxtech@gmail.com>>
* [shigeki](https://github.com/shigeki) -
**Shigeki Ohtsu** <<ohtsu@ohtsu.org>> (he/him)
* [thefourtheye](https://github.com/thefourtheye) -
**Sakthipriyan Vairamani** <<thechargingvolcano@gmail.com>> (he/him)
* [TimothyGu](https://github.com/TimothyGu) -
**Tiancheng "Timothy" Gu** <<timothygu99@gmail.com>> (he/him)
* [trevnorris](https://github.com/trevnorris) -
**Trevor Norris** <<trev.norris@gmail.com>>
</details>
<!-- node-core-utils and find-inactive-collaborators.mjs depend on the format
of the collaborator list. If the format changes, those utilities need to be
tested and updated. -->
### Collaborators
* [abmusse](https://github.com/abmusse) -
**Abdirahim Musse** <<abdirahim.musse@ibm.com>>
* [addaleax](https://github.com/addaleax) -
**Anna Henningsen** <<anna@addaleax.net>> (she/her)
* [Aditi-1400](https://github.com/Aditi-1400) -
**Aditi Singh** <<aditisingh1400@gmail.com>> (she/her)
* [aduh95](https://github.com/aduh95) -
**Antoine du Hamel** <<duhamelantoine1995@gmail.com>> (he/him) - [Support me](https://github.com/sponsors/aduh95)
* [anonrig](https://github.com/anonrig) -
**Yagiz Nizipli** <<yagiz@nizipli.com>> (he/him) - [Support me](https://github.com/sponsors/anonrig)
* [atlowChemi](https://github.com/atlowChemi) -
**Chemi Atlow** <<chemi@atlow.co.il>> (he/him)
* [avivkeller](https://github.com/avivkeller) -
**Aviv Keller** <<me@aviv.sh>> (he/him) - [Support me](https://github.com/sponsors/avivkeller)
* [Ayase-252](https://github.com/Ayase-252) -
**Qingyu Deng** <<i@ayase-lab.com>>
* [bengl](https://github.com/bengl) -
**Bryan English** <<bryan@bryanenglish.com>> (he/him)
* [benjamingr](https://github.com/benjamingr) -
**Benjamin Gruenbaum** <<benjamingr@gmail.com>>
* [BethGriggs](https://github.com/BethGriggs) -
**Beth Griggs** <<bethanyngriggs@gmail.com>> (she/her)
* [bnb](https://github.com/bnb) -
**Tierney Cyren** <<hello@bnb.im>> (they/them)
* [bnoordhuis](https://github.com/bnoordhuis) -
**Ben Noordhuis** <<info@bnoordhuis.nl>>
* [BridgeAR](https://github.com/BridgeAR) -
**Ruben Bridgewater** <<ruben@bridgewater.de>> (he/him)
* [cclauss](https://github.com/cclauss) -
**Christian Clauss** <<cclauss@me.com>> (he/him)
* [ChALkeR](https://github.com/ChALkeR) -
**Сковорода Никита Андреевич** <<chalkerx@gmail.com>> (he/him)
* [cjihrig](https://github.com/cjihrig) -
**Colin Ihrig** <<cjihrig@gmail.com>> (he/him)
* [codebytere](https://github.com/codebytere) -
**Shelley Vohr** <<shelley.vohr@gmail.com>> (she/her)
* [cola119](https://github.com/cola119) -
**Kohei Ueno** <<kohei.ueno119@gmail.com>> (he/him)
* [daeyeon](https://github.com/daeyeon) -
**Daeyeon Jeong** <<daeyeon.dev@gmail.com>> (he/him)
* [dario-piotrowicz](https://github.com/dario-piotrowicz) -
**Dario Piotrowicz** <<dario.piotrowicz@gmail.com>> (he/him)
* [deokjinkim](https://github.com/deokjinkim) -
**Deokjin Kim** <<deokjin81.kim@gmail.com>> (he/him)
* [edsadr](https://github.com/edsadr) -
**Adrian Estrada** <<edsadr@gmail.com>> (he/him)
* [ErickWendel](https://github.com/ErickWendel) -
**Erick Wendel** <<erick.workspace@gmail.com>> (he/him)
* [Ethan-Arrowood](https://github.com/Ethan-Arrowood) -
**Ethan Arrowood** <<ethan@arrowood.dev>> (he/him)
* [fhinkel](https://github.com/fhinkel) -
**Franziska Hinkelmann** <<franziska.hinkelmann@gmail.com>> (she/her)
* [Flarna](https://github.com/Flarna) -
**Gerhard Stöbich** <<deb2001-github@yahoo.de>> (he/they)
* [gabrielschulhof](https://github.com/gabrielschulhof) -
**Gabriel Schulhof** <<gabrielschulhof@gmail.com>>
* [geeksilva97](https://github.com/geeksilva97) -
**Edy Silva** <<edigleyssonsilva@gmail.com>> (he/him)
* [gengjiawen](https://github.com/gengjiawen) -
**Jiawen Geng** <<technicalcute@gmail.com>>
* [GeoffreyBooth](https://github.com/GeoffreyBooth) -
**Geoffrey Booth** <<webadmin@geoffreybooth.com>> (he/him)
* [gireeshpunathil](https://github.com/gireeshpunathil) -
**Gireesh Punathil** <<gpunathi@in.ibm.com>> (he/him)
* [gurgunday](https://github.com/gurgunday) -
**Gürgün Dayıoğlu** <<hey@gurgun.day>> (he/him)
* [guybedford](https://github.com/guybedford) -
**Guy Bedford** <<guybedford@gmail.com>> (he/him)
* [H4ad](https://github.com/H4ad) -
**Vinícius Lourenço Claro Cardoso** <<contact@viniciusl.com.br>> (he/him)
* [HarshithaKP](https://github.com/HarshithaKP) -
**Harshitha K P** <<harshitha014@gmail.com>> (she/her)
* [himself65](https://github.com/himself65) -
**Zeyu "Alex" Yang** <<himself65@outlook.com>> (he/him)
* [hybrist](https://github.com/hybrist) -
**Jan Martin** <<jan.krems@gmail.com>> (he/him)
* [IlyasShabi](https://github.com/IlyasShabi) -
**Ilyas Shabi** <<ilyasshabi94@gmail.com>> (he/him)
* [islandryu](https://github.com/islandryu) -
**Ryuhei Shima** <<shimaryuhei@gmail.com>> (he/him)
* [jakecastelli](https://github.com/jakecastelli) -
**Jake Yuesong Li** <<jake.yuesong@gmail.com>> (he/him)
* [JakobJingleheimer](https://github.com/JakobJingleheimer) -
**Jacob Smith** <<jacob@frende.me>> (he/him)
* [jasnell](https://github.com/jasnell) -
**James M Snell** <<jasnell@gmail.com>> (he/him)
* [jazelly](https://github.com/jazelly) -
**Jason Zhang** <<xzha4350@gmail.com>> (he/him)
* [joyeecheung](https://github.com/joyeecheung) -
**Joyee Cheung** <<joyeec9h3@gmail.com>> (she/her)
* [juanarbol](https://github.com/juanarbol) -
**Juan José Arboleda** <<soyjuanarbol@gmail.com>> (he/him)
* [JungMinu](https://github.com/JungMinu) -
**Minwoo Jung** <<nodecorelab@gmail.com>> (he/him)
* [KhafraDev](https://github.com/KhafraDev) -
**Matthew Aitken** <<maitken033380023@gmail.com>> (he/him)
* [legendecas](https://github.com/legendecas) -
**Chengzhong Wu** <<legendecas@gmail.com>> (he/him)
* [lemire](https://github.com/lemire) -
**Daniel Lemire** <<daniel@lemire.me>>
* [LiviaMedeiros](https://github.com/LiviaMedeiros) -
**LiviaMedeiros** <<livia@cirno.name>>
* [ljharb](https://github.com/ljharb) -
**Jordan Harband** <<ljharb@gmail.com>>
* [lpinca](https://github.com/lpinca) -
**Luigi Pinca** <<luigipinca@gmail.com>> (he/him)
* [Lxxyx](https://github.com/Lxxyx) -
**Zijian Liu** <<lxxyxzj@gmail.com>> (he/him)
* [marco-ippolito](https://github.com/marco-ippolito) -
**Marco Ippolito** <<marcoippolito54@gmail.com>> (he/him) - [Support me](https://github.com/sponsors/marco-ippolito)
* [marsonya](https://github.com/marsonya) -
**Akhil Marsonya** <<akhil.marsonya27@gmail.com>> (he/him)
* [MattiasBuelens](https://github.com/MattiasBuelens) -
**Mattias Buelens** <<mattias@buelens.com>> (he/him)
* [mcollina](https://github.com/mcollina) -
**Matteo Collina** <<matteo.collina@gmail.com>> (he/him) - [Support me](https://github.com/sponsors/mcollina)
* [meixg](https://github.com/meixg) -
**Xuguang Mei** <<meixuguang@gmail.com>> (he/him)
* [MoLow](https://github.com/MoLow) -
**Moshe Atlow** <<moshe@atlow.co.il>> (he/him)
* [MrJithil](https://github.com/MrJithil) -
**Jithil P Ponnan** <<jithil@outlook.com>> (he/him)
* [ovflowd](https://github.com/ovflowd) -
**Claudio Wunder** <<cwunder@gnome.org>> (he/they)
* [panva](https://github.com/panva) -
**Filip Skokan** <<panva.ip@gmail.com>> (he/him) - [Support me](https://github.com/sponsors/panva)
* [pimterry](https://github.com/pimterry) -
**Tim Perry** <<pimterry@gmail.com>> (he/him)
* [pmarchini](https://github.com/pmarchini) -
**Pietro Marchini** <<pietro.marchini94@gmail.com>> (he/him)
* [puskin](https://github.com/puskin) -
**Giovanni Bucci** <<github@puskin.it>> (he/him)
* [Qard](https://github.com/Qard) -
**Stephen Belanger** <<admin@stephenbelanger.com>> (he/him)
* [RafaelGSS](https://github.com/RafaelGSS) -
**Rafael Gonzaga** <<rafael.nunu@hotmail.com>> (he/him) - [Support me](https://github.com/sponsors/RafaelGSS)
* [RaisinTen](https://github.com/RaisinTen) -
**Darshan Sen** <<raisinten@gmail.com>> (he/him) - [Support me](https://github.com/sponsors/RaisinTen)
* [Renegade334](https://github.com/Renegade334) -
**René** <<contact.9a5d6388@renegade334.me.uk>>
* [richardlau](https://github.com/richardlau) -
**Richard Lau** <<richard.lau@ibm.com>>
* [rluvaton](https://github.com/rluvaton) -
**Raz Luvaton** <<rluvaton@gmail.com>> (he/him)
* [ronag](https://github.com/ronag) -
**Robert Nagy** <<ronagy@icloud.com>>
* [ruyadorno](https://github.com/ruyadorno) -
**Ruy Adorno** <<ruy@vlt.sh>> (he/him)
* [santigimeno](https://github.com/santigimeno) -
**Santiago Gimeno** <<santiago.gimeno@gmail.com>>
* [ShogunPanda](https://github.com/ShogunPanda) -
**Paolo Insogna** <<paolo@cowtech.it>> (he/him)
* [srl295](https://github.com/srl295) -
**Steven R Loomis** <<srl295@gmail.com>>
* [StefanStojanovic](https://github.com/StefanStojanovic) -
**Stefan Stojanovic** <<stefan.stojanovic@janeasystems.com>> (he/him)
* [sxa](https://github.com/sxa) -
**Stewart X Addison** <<sxa@redhat.com>> (he/him)
* [targos](https://github.com/targos) -
**Michaël Zasso** <<targos@protonmail.com>> (he/him)
* [theanarkh](https://github.com/theanarkh) -
**theanarkh** <<theratliter@gmail.com>> (he/him)
* [tniessen](https://github.com/tniessen) -
**Tobias Nießen** <<tniessen@tnie.de>> (he/him)
* [trivikr](https://github.com/trivikr) -
**Trivikram Kamat** <<trivikr.dev@gmail.com>>
* [Trott](https://github.com/Trott) -
**Rich Trott** <<rtrott@gmail.com>> (he/him)
* [UlisesGascon](https://github.com/UlisesGascon) -
**Ulises Gascón** <<ulisesgascongonzalez@gmail.com>> (he/him)
* [vmoroz](https://github.com/vmoroz) -
**Vladimir Morozov** <<vmorozov@microsoft.com>> (he/him)
* [watilde](https://github.com/watilde) -
**Daijiro Wachi** <<daijiro.wachi@gmail.com>> (he/him)
* [ZYSzys](https://github.com/ZYSzys) -
**Yongsheng Zhang** <<zyszys98@gmail.com>> (he/him)
<details>
<summary>Emeriti</summary>
<!-- find-inactive-collaborators.mjs depends on the format of the emeriti list.
If the format changes, those utilities need to be tested and updated. -->
### Collaborator emeriti
* [ak239](https://github.com/ak239) -
**Aleksei Koziatinskii** <<ak239spb@gmail.com>>
* [andrasq](https://github.com/andrasq) -
**Andras** <<andras@kinvey.com>>
* [AndreasMadsen](https://github.com/AndreasMadsen) -
**Andreas Madsen** <<amwebdk@gmail.com>> (he/him)
* [AnnaMag](https://github.com/AnnaMag) -
**Anna M. Kedzierska** <<anna.m.kedzierska@gmail.com>>
* [antsmartian](https://github.com/antsmartian) -
**Anto Aravinth** <<anto.aravinth.cse@gmail.com>> (he/him)
* [apapirovski](https://github.com/apapirovski) -
**Anatoli Papirovski** <<apapirovski@mac.com>> (he/him)
* [aqrln](https://github.com/aqrln) -
**Alexey Orlenko** <<eaglexrlnk@gmail.com>> (he/him)
* [AshCripps](https://github.com/AshCripps) -
**Ash Cripps** <<email@ashleycripps.co.uk>>
* [bcoe](https://github.com/bcoe) -
**Ben Coe** <<bencoe@gmail.com>> (he/him)
* [bmeck](https://github.com/bmeck) -
**Bradley Farias** <<bradley.meck@gmail.com>>
* [bmeurer](https://github.com/bmeurer) -
**Benedikt Meurer** <<benedikt.meurer@gmail.com>>
* [boneskull](https://github.com/boneskull) -
**Christopher Hiller** <<boneskull@boneskull.com>> (he/him)
* [brendanashworth](https://github.com/brendanashworth) -
**Brendan Ashworth** <<brendan.ashworth@me.com>>
* [bzoz](https://github.com/bzoz) -
**Bartosz Sosnowski** <<bartosz@janeasystems.com>>
* [calvinmetcalf](https://github.com/calvinmetcalf) -
**Calvin Metcalf** <<calvin.metcalf@gmail.com>>
* [chrisdickinson](https://github.com/chrisdickinson) -
**Chris Dickinson** <<christopher.s.dickinson@gmail.com>>
* [claudiorodriguez](https://github.com/claudiorodriguez) -
**Claudio Rodriguez** <<cjrodr@yahoo.com>>
* [danbev](https://github.com/danbev) -
**Daniel Bevenius** <<daniel.bevenius@gmail.com>> (he/him)
* [danielleadams](https://github.com/danielleadams) -
**Danielle Adams** <<adamzdanielle@gmail.com>> (she/her)
* [DavidCai1111](https://github.com/DavidCai1111) -
**David Cai** <<davidcai1993@yahoo.com>> (he/him)
* [davisjam](https://github.com/davisjam) -
**Jamie Davis** <<davisjam@vt.edu>> (he/him)
* [debadree25](https://github.com/debadree25) -
**Debadree Chatterjee** <<debadree333@gmail.com>> (he/him)
* [devnexen](https://github.com/devnexen) -
**David Carlier** <<devnexen@gmail.com>>
* [devsnek](https://github.com/devsnek) -
**Gus Caplan** <<me@gus.host>> (they/them)
* [digitalinfinity](https://github.com/digitalinfinity) -
**Hitesh Kanwathirtha** <<digitalinfinity@gmail.com>> (he/him)
* [dmabupt](https://github.com/dmabupt) -
**Xu Meng** <<dmabupt@gmail.com>> (he/him)
* [dnlup](https://github.com/dnlup) -
**dnlup** <<dnlup.dev@gmail.com>>
* [eljefedelrodeodeljefe](https://github.com/eljefedelrodeodeljefe) -
**Robert Jefe Lindstaedt** <<robert.lindstaedt@gmail.com>>
* [estliberitas](https://github.com/estliberitas) -
**Alexander Makarenko** <<estliberitas@gmail.com>>
* [eugeneo](https://github.com/eugeneo) -
**Eugene Ostroukhov** <<eostroukhov@google.com>>
* [evanlucas](https://github.com/evanlucas) -
**Evan Lucas** <<evanlucas@me.com>> (he/him)
* [F3n67u](https://github.com/F3n67u) -
**Feng Yu** <<F3n67u@outlook.com>> (he/him)
* [firedfox](https://github.com/firedfox) -
**Daniel Wang** <<wangyang0123@gmail.com>>
* [Fishrock123](https://github.com/Fishrock123) -
**Jeremiah Senkpiel** <<fishrock123@rocketmail.com>> (he/they)
* [gdams](https://github.com/gdams) -
**George Adams** <<gadams@microsoft.com>> (he/him)
* [geek](https://github.com/geek) -
**Wyatt Preul** <<wpreul@gmail.com>>
* [gibfahn](https://github.com/gibfahn) -
**Gibson Fahnestock** <<gibfahn@gmail.com>> (he/him)
* [glentiki](https://github.com/glentiki) -
**Glen Keane** <<glenkeane.94@gmail.com>> (he/him)
* [hashseed](https://github.com/hashseed) -
**Yang Guo** <<yangguo@chromium.org>> (he/him)
* [hiroppy](https://github.com/hiroppy) -
**Yuta Hiroto** <<hello@hiroppy.me>> (he/him)
* [iansu](https://github.com/iansu) -
**Ian Sutherland** <<ian@iansutherland.ca>>
* [iarna](https://github.com/iarna) -
**Rebecca Turner** <<me@re-becca.org>>
* [imran-iq](https://github.com/imran-iq) -
**Imran Iqbal** <<imran@imraniqbal.org>>
* [imyller](https://github.com/imyller) -
**Ilkka Myller** <<ilkka.myller@nodefield.com>>
* [indutny](https://github.com/indutny) -
**Fedor Indutny** <<fedor@indutny.com>>
* [isaacs](https://github.com/isaacs) -
**Isaac Z. Schlueter** <<i@izs.me>>
* [italoacasas](https://github.com/italoacasas) -
**Italo A. Casas** <<me@italoacasas.com>> (he/him)
* [JacksonTian](https://github.com/JacksonTian) -
**Jackson Tian** <<shyvo1987@gmail.com>>
* [jasongin](https://github.com/jasongin) -
**Jason Ginchereau** <<jasongin@microsoft.com>>
* [jbergstroem](https://github.com/jbergstroem) -
**Johan Bergström** <<bugs@bergstroem.nu>>
* [jdalton](https://github.com/jdalton) -
**John-David Dalton** <<john.david.dalton@gmail.com>>
* [jhamhader](https://github.com/jhamhader) -
**Yuval Brik** <<yuval@brik.org.il>>
* [joaocgreis](https://github.com/joaocgreis) -
**João Reis** <<reis@janeasystems.com>>
* [joesepi](https://github.com/joesepi) -
**Joe Sepi** <<sepi@joesepi.com>> (he/him)
* [JonasBa](https://github.com/JonasBa) -
**Jonas Badalic** <<jonas.badalic@gmail.com>> (he/him)
* [joshgav](https://github.com/joshgav) -
**Josh Gavant** <<josh.gavant@outlook.com>>
* [julianduque](https://github.com/julianduque) -
**Julian Duque** <<julianduquej@gmail.com>> (he/him)
* [kfarnung](https://github.com/kfarnung) -
**Kyle Farnung** <<kfarnung@microsoft.com>> (he/him)
* [kunalspathak](https://github.com/kunalspathak) -
**Kunal Pathak** <<kunal.pathak@microsoft.com>>
* [kuriyosh](https://github.com/kuriyosh) -
**Yoshiki Kurihara** <<yosyos0306@gmail.com>> (he/him)
* [kvakil](https://github.com/kvakil) -
**Keyhan Vakil** <<kvakil@sylph.kvakil.me>>
* [lance](https://github.com/lance) -
**Lance Ball** <<lball@redhat.com>> (he/him)
* [Leko](https://github.com/Leko) -
**Shingo Inoue** <<leko.noor@gmail.com>> (he/him)
* [Linkgoron](https://github.com/Linkgoron) -
**Nitzan Uziely** <<linkgoron@gmail.com>>
* [lucamaraschi](https://github.com/lucamaraschi) -
**Luca Maraschi** <<luca.maraschi@gmail.com>> (he/him)
* [lukekarrys](https://github.com/lukekarrys) -
**Luke Karrys** <<luke@lukekarrys.com>> (he/him)
* [lundibundi](https://github.com/lundibundi) -
**Denys Otrishko** <<shishugi@gmail.com>> (he/him)
* [lxe](https://github.com/lxe) -
**Aleksey Smolenchuk** <<lxe@lxe.co>>
* [maclover7](https://github.com/maclover7) -
**Jon Moss** <<me@jonathanmoss.me>> (he/him)
* [mafintosh](https://github.com/mafintosh) -
**Mathias Buus** <<mathiasbuus@gmail.com>> (he/him)
* [matthewloring](https://github.com/matthewloring) -
**Matthew Loring** <<mattloring@google.com>>
* [Mesteery](https://github.com/Mesteery) -
**Mestery** <<mestery@protonmail.com>> (he/him)
* [mhdawson](https://github.com/mhdawson) -
**Michael Dawson** <<midawson@redhat.com>> (he/him)
* [micnic](https://github.com/micnic) -
**Nicu Micleușanu** <<micnic90@gmail.com>> (he/him)
* [mikeal](https://github.com/mikeal) -
**Mikeal Rogers** <<mikeal.rogers@gmail.com>>
* [miladfarca](https://github.com/miladfarca) -
**Milad Fa** <<mfarazma@redhat.com>> (he/him)
* [mildsunrise](https://github.com/mildsunrise) -
**Alba Mendez** <<me@alba.sh>> (she/her)
* [misterdjules](https://github.com/misterdjules) -
**Julien Gilli** <<jgilli@netflix.com>>
* [mmarchini](https://github.com/mmarchini) -
**Mary Marchini** <<oss@mmarchini.me>> (she/her)
* [monsanto](https://github.com/monsanto) -
**Christopher Monsanto** <<chris@monsan.to>>
* [MoonBall](https://github.com/MoonBall) -
**Chen Gang** <<gangc.cxy@foxmail.com>>
* [mscdex](https://github.com/mscdex) -
**Brian White** <<mscdex@mscdex.net>>
* [MylesBorins](https://github.com/MylesBorins) -
**Myles Borins** <<myles.borins@gmail.com>> (he/him)
* [not-an-aardvark](https://github.com/not-an-aardvark) -
**Teddy Katz** <<teddy.katz@gmail.com>> (he/him)
* [ofrobots](https://github.com/ofrobots) -
**Ali Ijaz Sheikh** <<ofrobots@google.com>> (he/him)
* [Olegas](https://github.com/Olegas) -
**Oleg Elifantiev** <<oleg@elifantiev.ru>>
* [orangemocha](https://github.com/orangemocha) -
**Alexis Campailla** <<orangemocha@nodejs.org>>
* [othiym23](https://github.com/othiym23) -
**Forrest L Norvell** <<ogd@aoaioxxysz.net>> (they/them/themself)
* [oyyd](https://github.com/oyyd) -
**Ouyang Yadong** <<oyydoibh@gmail.com>> (he/him)
* [petkaantonov](https://github.com/petkaantonov) -
**Petka Antonov** <<petka_antonov@hotmail.com>>
* [phillipj](https://github.com/phillipj) -
**Phillip Johnsen** <<johphi@gmail.com>>
* [piscisaureus](https://github.com/piscisaureus) -
**Bert Belder** <<bertbelder@gmail.com>>
* [pmq20](https://github.com/pmq20) -
**Minqi Pan** <<pmq2001@gmail.com>>
* [PoojaDurgad](https://github.com/PoojaDurgad) -
**Pooja D P** <<Pooja.D.P@ibm.com>> (she/her)
* [princejwesley](https://github.com/princejwesley) -
**Prince John Wesley** <<princejohnwesley@gmail.com>>
* [psmarshall](https://github.com/psmarshall) -
**Peter Marshall** <<petermarshall@chromium.org>> (he/him)
* [puzpuzpuz](https://github.com/puzpuzpuz) -
**Andrey Pechkurov** <<apechkurov@gmail.com>> (he/him)
* [refack](https://github.com/refack) -
**Refael Ackermann (רפאל פלחי)** <<refack@gmail.com>> (he/him/הוא/אתה)
* [rexagod](https://github.com/rexagod) -
**Pranshu Srivastava** <<rexagod@gmail.com>> (he/him)
* [rickyes](https://github.com/rickyes) -
**Ricky Zhou** <<0x19951125@gmail.com>> (he/him)
* [rlidwka](https://github.com/rlidwka) -
**Alex Kocharin** <<alex@kocharin.ru>>
* [rmg](https://github.com/rmg) -
**Ryan Graham** <<r.m.graham@gmail.com>>
* [robertkowalski](https://github.com/robertkowalski) -
**Robert Kowalski** <<rok@kowalski.gd>>
* [romankl](https://github.com/romankl) -
**Roman Klauke** <<romaaan.git@gmail.com>>
* [ronkorving](https://github.com/ronkorving) -
**Ron Korving** <<ron@ronkorving.nl>>
* [RReverser](https://github.com/RReverser) -
**Ingvar Stepanyan** <<me@rreverser.com>>
* [rubys](https://github.com/rubys) -
**Sam Ruby** <<rubys@intertwingly.net>>
* [rvagg](https://github.com/rvagg) -
**Rod Vagg** <<rod@vagg.org>>
* [ryzokuken](https://github.com/ryzokuken) -
**Ujjwal Sharma** <<ryzokuken@disroot.org>> (he/him)
* [saghul](https://github.com/saghul) -
**Saúl Ibarra Corretgé** <<s@saghul.net>>
* [sam-github](https://github.com/sam-github) -
**Sam Roberts** <<vieuxtech@gmail.com>>
* [sebdeckers](https://github.com/sebdeckers) -
**Sebastiaan Deckers** <<sebdeckers83@gmail.com>>
* [seishun](https://github.com/seishun) -
**Nikolai Vavilov** <<vvnicholas@gmail.com>>
* [shigeki](https://github.com/shigeki) -
**Shigeki Ohtsu** <<ohtsu@ohtsu.org>> (he/him)
* [shisama](https://github.com/shisama) -
**Masashi Hirano** <<shisama07@gmail.com>> (he/him)
* [silverwind](https://github.com/silverwind) -
**Roman Reiss** <<me@silverwind.io>>
* [starkwang](https://github.com/starkwang) -
**Weijia Wang** <<starkwang@126.com>>
* [stefanmb](https://github.com/stefanmb) -
**Stefan Budeanu** <<stefan@budeanu.com>>
* [tellnes](https://github.com/tellnes) -
**Christian Tellnes** <<christian@tellnes.no>>
* [thefourtheye](https://github.com/thefourtheye) -
**Sakthipriyan Vairamani** <<thechargingvolcano@gmail.com>> (he/him)
* [thlorenz](https://github.com/thlorenz) -
**Thorsten Lorenz** <<thlorenz@gmx.de>>
* [TimothyGu](https://github.com/TimothyGu) -
**Tiancheng "Timothy" Gu** <<timothygu99@gmail.com>> (he/him)
* [trevnorris](https://github.com/trevnorris) -
**Trevor Norris** <<trev.norris@gmail.com>>
* [tunniclm](https://github.com/tunniclm) -
**Mike Tunnicliffe** <<m.j.tunnicliffe@gmail.com>>
* [vdeturckheim](https://github.com/vdeturckheim) -
**Vladimir de Turckheim** <<vlad2t@hotmail.com>> (he/him)
* [vkurchatkin](https://github.com/vkurchatkin) -
**Vladimir Kurchatkin** <<vladimir.kurchatkin@gmail.com>>
* [VoltrexKeyva](https://github.com/VoltrexKeyva) -
**Mohammed Keyvanzadeh** <<mohammadkeyvanzade94@gmail.com>> (he/him)
* [vsemozhetbyt](https://github.com/vsemozhetbyt) -
**Vse Mozhet Byt** <<vsemozhetbyt@gmail.com>> (he/him)
* [watson](https://github.com/watson) -
**Thomas Watson** <<w@tson.dk>>
* [whitlockjc](https://github.com/whitlockjc) -
**Jeremy Whitlock** <<jwhitlock@apache.org>>
* [XadillaX](https://github.com/XadillaX) -
**Khaidi Chu** <<i@2333.moe>> (he/him)
* [yashLadha](https://github.com/yashLadha) -
**Yash Ladha** <<yash@yashladha.in>> (he/him)
* [yhwang](https://github.com/yhwang) -
**Yihong Wang** <<yh.wang@ibm.com>>
* [yorkie](https://github.com/yorkie) -
**Yorkie Liu** <<yorkiefixer@gmail.com>>
* [yosuke-furukawa](https://github.com/yosuke-furukawa) -
**Yosuke Furukawa** <<yosuke.furukawa@gmail.com>>
* [zcbenz](https://github.com/zcbenz) -
**Cheng Zhao** <<zcbenz@gmail.com>> (he/him)
</details>
<!--lint enable prohibited-strings-->
Collaborators follow the [Collaborator Guide](./doc/contributing/collaborator-guide.md) in
maintaining the Node.js project.
### Triagers
* [1ilsang](https://github.com/1ilsang) -
**Sangchul Lee** <<1ilsang.dev@gmail.com>> (he/him)
* [bjohansebas](https://github.com/bjohansebas) -
**Sebastian Beltran** <<bjohansebas@gmail.com>>
* [bmuenzenmeyer](https://github.com/bmuenzenmeyer) -
**Brian Muenzenmeyer** <<brian.muenzenmeyer@gmail.com>> (he/him)
* [efekrskl](https://github.com/efekrskl) -
**Efe Karasakal** <<hi@efe.dev>> (he/him)
* [gireeshpunathil](https://github.com/gireeshpunathil) -
**Gireesh Punathil** <<gpunathi@in.ibm.com>> (he/him)
* [haramj](https://github.com/haramj) -
**Haram Jeong** <<haramj.dev@gmail.com>>
* [HBSPS](https://github.com/HBSPS) -
**Wiyeong Seo** <<hbsps.dev@gmail.com>>
* [iam-frankqiu](https://github.com/iam-frankqiu) -
**Frank Qiu** <<iam.frankqiu@gmail.com>> (he/him)
* [milesguicent](https://github.com/milesguicent) -
**Miles Guicent** <<guicent@pm.me>> (he/him)
* [preveen-stack](https://github.com/preveen-stack) -
**Preveen Padmanabhan** <<wide4head@gmail.com>> (he/him)
Triagers follow the [Triage Guide](./doc/contributing/issues.md#triaging-a-bug-report) when
responding to new issues.
### Release keys
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.
```bash
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](#verifying-binaries) for how to use these keys to
verify a downloaded file.
<details>
<summary>Other keys used to sign some previous releases</summary>
* **Antoine du Hamel** <<duhamelantoine1995@gmail.com>>
`C0D6248439F1D5604AAFFB4021D900FFDB233756`
* **Beth Griggs** <<bethanyngriggs@gmail.com>>
`4ED778F539E3634C779C87C6D7062848A1AB005C`
* **Bryan English** <<bryan@bryanenglish.com>>
`141F07595B7B3FFE74309A937405533BE57C7D57`
* **Chris Dickinson** <<christopher.s.dickinson@gmail.com>>
`9554F04D7259F04124DE6B476D5A82AC7E37093B`
* **Colin Ihrig** <<cjihrig@gmail.com>>
`94AE36675C464D64BAFA68DD7434390BDBE9B9C5`
* **Danielle Adams** <<adamzdanielle@gmail.com>>
`1C050899334244A8AF75E53792EF661D867B9DFA`
`74F12602B6F1C4E913FAA37AD3A89613643B6201`
* **Evan Lucas** <<evanlucas@me.com>>
`B9AE9905FFD7803F25714661B63B535A4C206CA9`
* **Gibson Fahnestock** <<gibfahn@gmail.com>>
`77984A986EBC2AA786BC0F66B01FBB92821C587A`
* **Isaac Z. Schlueter** <<i@izs.me>>
`93C7E9E91B49E432C2F75674B0A78B0A6C481CF6`
* **Italo A. Casas** <<me@italoacasas.com>>
`56730D5401028683275BD23C23EFEFE93C4CFFFE`
* **James M Snell** <<jasnell@keybase.io>>
`71DCFD284A79C3B38668286BC97EC7A07EDE3FC1`
* **Jeremiah Senkpiel** <<fishrock@keybase.io>>
`FD3A5288F042B6850C66B31F09FE44734EB7990E`
* **Juan José Arboleda** <<soyjuanarbol@gmail.com>>
`61FC681DFB92A079F1685E77973F295594EC4689`
* **Julien Gilli** <<jgilli@fastmail.fm>>
`114F43EE0176B71C7BC219DD50A3051F888C628D`
* **Myles Borins** <<myles.borins@gmail.com>>
`C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8`
* **Rod Vagg** <<rod@vagg.org>>
`DD8F2338BAE7501E3DD5AC78C273792F7D83545D`
* **Ruben Bridgewater** <<ruben@bridgewater.de>>
`A48C2BEE680E841632CD4E44F07496B3EB3C1762`
* **Shelley Vohr** <<shelley.vohr@gmail.com>>
`B9E2F5981AA6E0CD28160D9FF13993A75599653C`
* **Timothy J Fontaine** <<tjfontaine@gmail.com>>
`7937DFD2AB06298B2293C3187D33FF9D0246406D`
The project maintains a keyring able to verify all past releases of Node.js at
<https://github.com/nodejs/release-keys/raw/refs/heads/main/gpg/pubring.kbx>.
</details>
### 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](./doc/contributing/security-release-process.md).
* [Datadog](https://www.datadoghq.com/)
* [bengl](https://github.com/bengl) -
**Bryan English** <<bryan@bryanenglish.com>> (he/him)
* [HeroDevs](https://www.herodevs.com/)
* [juanarbol](https://github.com/juanarbol) - OpenJS Slack handle: `juanarbol`
**Juan José Arboleda** <<soyjuanarbol@gmail.com>> (he/him)
* [marco-ippolito](https://github.com/marco-ippolito) - OpenJS Slack handle: `Marco Ippolito`
**Marco Ippolito** <<marcoippolito54@gmail.com>> (he/him)
* [NodeSource](https://nodesource.com/)
* [RafaelGSS](https://github.com/RafaelGSS) - OpenJS Slack handle: `RafaelGSS`
**Rafael Gonzaga** <<rafael.nunu@hotmail.com>> (he/him)
* [Platformatic](https://platformatic.dev/)
* [mcollina](https://github.com/mcollina) - OpenJS Slack handle: `mcollina`
**Matteo Collina** <<matteo.collina@gmail.com>> (he/him)
* [Red Hat](https://redhat.com) / [IBM](https://ibm.com)
* [BethGriggs](https://github.com/BethGriggs) -
**Beth Griggs** <<bethanyngriggs@gmail.com>> (she/her)
* [sxa](https://github.com/sxa) -
**Stewart X Addison** <<sxa@redhat.com>> (he/him)
## License
Node.js is licensed under the [MIT License](https://opensource.org/licenses/MIT).
This project also depends on external libraries that may use different open-source
licenses. For a complete list of included licenses, please see the
[LICENSE](https://github.com/nodejs/node/blob/main/LICENSE) file.
If you are contributing documentation or source changes, please ensure your
additions comply with the project’s license guidelines.
[Code of Conduct]: https://github.com/nodejs/admin/blob/HEAD/CODE_OF_CONDUCT.md
[Contributing to the project]: CONTRIBUTING.md
[Node.js website]: https://nodejs.org/
[OpenJS Foundation]: https://openjsf.org/
[Strategic initiatives]: doc/contributing/strategic-initiatives.md
[Technical values and prioritization]: doc/contributing/technical-values.md
[Working Groups]: https://github.com/nodejs/TSC/blob/HEAD/WORKING_GROUPS.md
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/node_modules/corepack/dist/corepack.js" "$@"
else
exec node "$basedir/node_modules/corepack/dist/corepack.js" "$@"
fi
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\corepack\dist\corepack.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\corepack\dist\corepack.js" %*
)
@@ -0,0 +1,66 @@
@echo off
setlocal
title Install Additional Tools for Node.js
cls
echo ====================================================
echo Tools for Node.js Native Modules Installation Script
echo ====================================================
echo.
echo This script will install Python and the Visual Studio Build Tools, necessary
echo to compile Node.js native modules. Note that Chocolatey and required Windows
echo updates will also be installed.
echo.
echo This will require about 7 GiB of free disk space, plus any space necessary to
echo install Windows updates. This will take a while to run.
echo.
echo Please close all open programs for the duration of the installation. If the
echo installation fails, please ensure Windows is fully updated, reboot your
echo computer and try to run this again. This script can be found in the
echo Start menu under Node.js.
echo.
echo You can close this window to stop now. Detailed instructions to install these
echo tools manually are available at https://github.com/nodejs/node-gyp#on-windows
echo.
pause
cls
REM Adapted from https://github.com/Microsoft/windows-dev-box-setup-scripts/blob/79bbe5bdc4867088b3e074f9610932f8e4e192c2/README.md#legal
echo Using this script downloads third party software
echo ------------------------------------------------
echo This script will direct to Chocolatey to install packages. By using
echo Chocolatey to install a package, you are accepting the license for the
echo application, executable(s), or other artifacts delivered to your machine as a
echo result of a Chocolatey install. This acceptance occurs whether you know the
echo license terms or not. Read and understand the license terms of the packages
echo being installed and their dependencies prior to installation:
echo - https://chocolatey.org/packages/chocolatey
echo - https://chocolatey.org/packages/python
echo - https://chocolatey.org/packages/visualstudio2026-workload-vctools
echo.
echo This script is provided AS-IS without any warranties of any kind
echo ----------------------------------------------------------------
echo Chocolatey has implemented security safeguards in their process to help
echo protect the community from malicious or pirated software, but any use of this
echo script is at your own risk. Please read the Chocolatey's legal terms of use
echo as well as how the community repository for Chocolatey.org is maintained.
echo.
pause
cls
"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" ^
-NoProfile ^
-InputFormat None ^
-ExecutionPolicy Bypass ^
-Command Start-Process ^
'%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe' ^
-ArgumentList '-NoProfile -InputFormat None -ExecutionPolicy Bypass -Command ^
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; ^
iex ((New-Object System.Net.WebClient).DownloadString(''https://chocolatey.org/install.ps1'')); ^
choco upgrade -y python visualstudio2026-workload-vctools; ^
Read-Host ''Type ENTER to exit'' ' ^
-Verb RunAs
Binary file not shown.
+621
View File
@@ -0,0 +1,621 @@
# Changelog
## [0.35.0](https://github.com/nodejs/corepack/compare/v0.34.7...v0.35.0) (2026-05-15)
### ⚠ BREAKING CHANGES
* Drop support for Node.js 20 and Node.js 25.
* Switching to Node.js built-in proxy support, meaning that proxy support is now
gated by having `NODE_USE_ENV_PROXY` set as an environment variable.
### Features
* update package manager versions ([#820](https://github.com/nodejs/corepack/issues/820)) ([fdbd751](https://github.com/nodejs/corepack/commit/fdbd751d9851a50730925de053e9722963c2e135))
### Bug Fixes
* target node 22.22.2 in esbuild ([#845](https://github.com/nodejs/corepack/issues/845)) ([0f01502](https://github.com/nodejs/corepack/commit/0f01502fd8832649a573bc68e1851128f547646d))
### Miscellaneous Chores
* **deps:** bump engine support matrix ([88c602a](https://github.com/nodejs/corepack/commit/88c602a6ea3f75bf30dc1d071bdb488fae2c8276))
* **deps:** drop Undici and `proxy-from-env` ([8167b0d](https://github.com/nodejs/corepack/commit/8167b0d65acc091af464ead019f7485cb512082f))
## [0.34.7](https://github.com/nodejs/corepack/compare/v0.34.6...v0.34.7) (2026-04-17)
### Bug Fixes
* update package manager versions ([#790](https://github.com/nodejs/corepack/issues/790)) ([e8961d6](https://github.com/nodejs/corepack/commit/e8961d6bdc14b8141fbda008febdd3649022862c))
## [0.34.6](https://github.com/nodejs/corepack/compare/v0.34.5...v0.34.6) (2026-01-23)
### Bug Fixes
* **docs:** fix PowerShell functions suggestions ([#784](https://github.com/nodejs/corepack/issues/784)) ([b1544c8](https://github.com/nodejs/corepack/commit/b1544c82a63781bd77d49f7b566fefd0104b7d6d))
* update package manager versions ([#778](https://github.com/nodejs/corepack/issues/778)) ([efed597](https://github.com/nodejs/corepack/commit/efed59797d30caa362a1fa8475cd7d17dc3b7282))
## [0.34.5](https://github.com/nodejs/corepack/compare/v0.34.4...v0.34.5) (2025-11-24)
### Bug Fixes
* **pnpm:** fix bin path for v11 ([#776](https://github.com/nodejs/corepack/issues/776)) ([0c8048a](https://github.com/nodejs/corepack/commit/0c8048adc61651f6eb798448675d3ecc4a7e26a9))
* update package manager versions ([#773](https://github.com/nodejs/corepack/issues/773)) ([06c286b](https://github.com/nodejs/corepack/commit/06c286b5fc171e43090b5eed5cd501bc9580927f))
## [0.34.4](https://github.com/nodejs/corepack/compare/v0.34.3...v0.34.4) (2025-11-14)
### Bug Fixes
* bump pnpm version in `config.json` ([#768](https://github.com/nodejs/corepack/issues/768)) ([99a9a6e](https://github.com/nodejs/corepack/commit/99a9a6eb1b6e918ceb896b3d558bb5ed583bdc70))
* ignore devEngines version range when CLI provides a version ([#762](https://github.com/nodejs/corepack/issues/762)) ([ac518c4](https://github.com/nodejs/corepack/commit/ac518c4106f8d9ceb4e85e6c3614b1eba5d03fcb))
* use `lstatSync` in `generatePosixLink` ([#767](https://github.com/nodejs/corepack/issues/767)) ([a02bea0](https://github.com/nodejs/corepack/commit/a02bea078eb584ed7492ec561626987e35386bae))
## [0.34.3](https://github.com/nodejs/corepack/compare/v0.34.2...v0.34.3) (2025-11-07)
### Bug Fixes
* update package manager versions ([#765](https://github.com/nodejs/corepack/issues/765)) ([13a2e98](https://github.com/nodejs/corepack/commit/13a2e989ee37694a7ec1b1d60acdaa28f90642d1))
* Yarn switch install support and tests ([#761](https://github.com/nodejs/corepack/issues/761)) ([d04d483](https://github.com/nodejs/corepack/commit/d04d4839aeecaf4fca989c577f6c000dc90be933))
## [0.34.2](https://github.com/nodejs/corepack/compare/v0.34.1...v0.34.2) (2025-10-31)
### Bug Fixes
* bump package manager versions ([#754](https://github.com/nodejs/corepack/issues/754)) ([35e3869](https://github.com/nodejs/corepack/commit/35e3869f3f4d21bbfccdf78ea564ab0723d6f36f))
* fix potential race condition in `node-tar` ([#757](https://github.com/nodejs/corepack/pull/757)) ([78808a7](78808a72691655fe5140c02ae41d4baef88cd9fa))
## [0.34.1](https://github.com/nodejs/corepack/compare/v0.34.0...v0.34.1) (2025-10-17)
### Bug Fixes
* incorrect registry origin check ([#743](https://github.com/nodejs/corepack/issues/743)) ([cc840b2](https://github.com/nodejs/corepack/commit/cc840b2d232a29c225d2436d350640f0035ed28b))
* update package manager versions ([#728](https://github.com/nodejs/corepack/issues/728)) ([78ce029](https://github.com/nodejs/corepack/commit/78ce0297a9152bb5c68f724821a9a0095b408334))
## [0.34.0](https://github.com/nodejs/corepack/compare/v0.33.0...v0.34.0) (2025-07-19)
### ⚠ BREAKING CHANGES
* drop Node.js 18.x and 23.x support
### Features
* update package manager versions ([#719](https://github.com/nodejs/corepack/issues/719)) ([7707ea7](https://github.com/nodejs/corepack/commit/7707ea7350c129ad3aae8ca08e9e80fcf164dcb6))
### Miscellaneous Chores
* remove Node.js 18.x and 23.x usage, add 24.x ([#718](https://github.com/nodejs/corepack/issues/718)) ([783a42f](https://github.com/nodejs/corepack/commit/783a42fbe35371964e9dde75e2263b179f53bc0c))
## [0.33.0](https://github.com/nodejs/corepack/compare/v0.32.0...v0.33.0) (2025-06-02)
### Features
* Adds guard to avoid stepping on Yarn's feet ([#714](https://github.com/nodejs/corepack/issues/714)) ([5fc3691](https://github.com/nodejs/corepack/commit/5fc3691354eb5bdeca17a9495b234584353f0151))
* update package manager versions ([#671](https://github.com/nodejs/corepack/issues/671)) ([b45b3a3](https://github.com/nodejs/corepack/commit/b45b3a3244bacfbaf65188ae8c04209a1e98307d))
### Bug Fixes
* debug text typo ([#698](https://github.com/nodejs/corepack/issues/698)) ([0b94797](https://github.com/nodejs/corepack/commit/0b94797f96e30e46e466873fe7d437d0471cd92c))
## [0.32.0](https://github.com/nodejs/corepack/compare/v0.31.0...v0.32.0) (2025-02-28)
### Features
* add limited support for `devEngines` ([#643](https://github.com/nodejs/corepack/issues/643)) ([b456268](https://github.com/nodejs/corepack/commit/b4562688513f23e37e37b0d69a0daff33ca84c8d))
* add more informative error when fetching latest stable fails ([#644](https://github.com/nodejs/corepack/issues/644)) ([53b1fe7](https://github.com/nodejs/corepack/commit/53b1fe75c47c06bd72a8b8f8bb699a47c9ca32fb))
* add support for `.corepack.env` ([#642](https://github.com/nodejs/corepack/issues/642)) ([9b95b46](https://github.com/nodejs/corepack/commit/9b95b46f05e50fe1c60f05309c210ba8fe4e23c5))
* update package manager versions ([#617](https://github.com/nodejs/corepack/issues/617)) ([b83bb5e](https://github.com/nodejs/corepack/commit/b83bb5ec150980c998b9c7053dff307d912cb508))
### Bug Fixes
* do not resolve fallback descriptor when `packageManager` is defined ([#632](https://github.com/nodejs/corepack/issues/632)) ([12e77e5](https://github.com/nodejs/corepack/commit/12e77e506946d42a0de9ce8e68d75af8454d6776))
* **doc:** fix link to proxy library ([#636](https://github.com/nodejs/corepack/issues/636)) ([bae0839](https://github.com/nodejs/corepack/commit/bae08397943d4b99437389b4286546361091f4b3))
* replace explicit with specify as verb ([#665](https://github.com/nodejs/corepack/issues/665)) ([351d86c](https://github.com/nodejs/corepack/commit/351d86c20226a8c18bfe212be27401f2908b1595))
* **use:** do not throw on invalid `packageManager` ([#663](https://github.com/nodejs/corepack/issues/663)) ([4be72f6](https://github.com/nodejs/corepack/commit/4be72f6941afa0c9b2b7d26635016bb7b560df8a))
## [0.31.0](https://github.com/nodejs/corepack/compare/v0.30.0...v0.31.0) (2025-01-27)
### ⚠ BREAKING CHANGES
* drop support for Node.js 21.x ([#594](https://github.com/nodejs/corepack/issues/594))
### Features
* update package manager versions ([#595](https://github.com/nodejs/corepack/issues/595)) ([c7a9bde](https://github.com/nodejs/corepack/commit/c7a9bde16dcbbb7e6ef03fef740656cde7ade360))
### Bug Fixes
* only print message for `UsageError`s ([#602](https://github.com/nodejs/corepack/issues/602)) ([72a588c](https://github.com/nodejs/corepack/commit/72a588c2370c17e415b24fe389efdafb3c84e90b))
* update npm registry keys ([#614](https://github.com/nodejs/corepack/issues/614)) ([8c90caa](https://github.com/nodejs/corepack/commit/8c90caab7f1c5c9b89f1de113bc1dfc441bf25d2))
### Miscellaneous Chores
* drop support for Node.js 21.x ([#594](https://github.com/nodejs/corepack/issues/594)) ([8bebc0c](https://github.com/nodejs/corepack/commit/8bebc0c0a5cbcdeec41673dcbaf581e6e1c1be11))
## [0.30.0](https://github.com/nodejs/corepack/compare/v0.29.4...v0.30.0) (2024-11-23)
### Features
* update package manager versions ([#578](https://github.com/nodejs/corepack/issues/578)) ([a286c8f](https://github.com/nodejs/corepack/commit/a286c8f5537ea9ecf9b6ff53c7bc3e8da4e3c8bb))
### Performance Improvements
* prefer `module.enableCompileCache` over `v8-compile-cache` ([#574](https://github.com/nodejs/corepack/issues/574)) ([cba6905](https://github.com/nodejs/corepack/commit/cba690575bd606faeee54bd512ccb8797d49055f))
## [0.29.4](https://github.com/nodejs/corepack/compare/v0.29.3...v0.29.4) (2024-09-07)
### Features
* update package manager versions ([#543](https://github.com/nodejs/corepack/issues/543)) ([b819e40](https://github.com/nodejs/corepack/commit/b819e404dbb23c4ae3d5dbe55e21de74d714ee9c))
## [0.29.3](https://github.com/nodejs/corepack/compare/v0.29.2...v0.29.3) (2024-07-21)
### Bug Fixes
* fallback to `shasum` when `integrity` is not defined ([#542](https://github.com/nodejs/corepack/issues/542)) ([eb63873](https://github.com/nodejs/corepack/commit/eb63873c6c617a2f8ac7106e26ccfe8aa3ae1fb9))
* make `DEBUG=corepack` more useful ([#538](https://github.com/nodejs/corepack/issues/538)) ([6019d7b](https://github.com/nodejs/corepack/commit/6019d7b56e85bd8b7b58a1a487922c707e70e30e))
## [0.29.2](https://github.com/nodejs/corepack/compare/v0.29.1...v0.29.2) (2024-07-13)
### Bug Fixes
* trigger release after 0.29.1 failed to publish ([18e29ce](https://github.com/nodejs/corepack/commit/18e29ce3c465b64d48ccf3feef7cd1be94da70b0))
## [0.29.1](https://github.com/nodejs/corepack/compare/v0.29.0...v0.29.1) (2024-07-13)
### Bug Fixes
* trigger release after 0.29.0 failed to publish ([e6ba066](https://github.com/nodejs/corepack/commit/e6ba06657b0985c112f288932ca39c0562129566))
## [0.29.0](https://github.com/nodejs/corepack/compare/v0.28.2...v0.29.0) (2024-07-12)
### Features
* parallelize linking, unlinking and installing ([#524](https://github.com/nodejs/corepack/issues/524)) ([f0734e6](https://github.com/nodejs/corepack/commit/f0734e6e8023ff361dac179c0d8656740d550c27))
* update package manager versions ([#492](https://github.com/nodejs/corepack/issues/492)) ([3e3b046](https://github.com/nodejs/corepack/commit/3e3b04619cb4a91f207a72fb450f6fc4e2f01aec))
### Bug Fixes
* replace npm registry domain in tarball URL ([#502](https://github.com/nodejs/corepack/issues/502)) ([db6fae5](https://github.com/nodejs/corepack/commit/db6fae50cf44884d1e9a6f7e99402e7e807ba3ca))
* selectively import required semver functions ([#511](https://github.com/nodejs/corepack/issues/511)) ([e7ad533](https://github.com/nodejs/corepack/commit/e7ad533d43dc9495493f0d883c3cbbb94caa1d41))
## [0.28.2](https://github.com/nodejs/corepack/compare/v0.28.1...v0.28.2) (2024-05-31)
### Features
* update package manager versions ([#481](https://github.com/nodejs/corepack/issues/481)) ([e1abb83](https://github.com/nodejs/corepack/commit/e1abb832416a793b490b2b51b4082fe822fc932c))
## [0.28.1](https://github.com/nodejs/corepack/compare/v0.28.0...v0.28.1) (2024-05-10)
### Features
* add support for `COREPACK_INTEGRITY_KEYS=0` ([#470](https://github.com/nodejs/corepack/issues/470)) ([f15ebc2](https://github.com/nodejs/corepack/commit/f15ebc289ebcd6a86580f15ae3c4ef0e1be37c4b))
* update package manager versions ([#469](https://github.com/nodejs/corepack/issues/469)) ([985895b](https://github.com/nodejs/corepack/commit/985895bccb5ec68b3645c540d8500c572e1ccadb))
### Bug Fixes
* COREPACK_NPM_REGISTRY should allow for username/password auth ([#466](https://github.com/nodejs/corepack/issues/466)) ([6efa349](https://github.com/nodejs/corepack/commit/6efa34988229918debe6e881d45ba6715282f283))
## [0.28.0](https://github.com/nodejs/corepack/compare/v0.27.0...v0.28.0) (2024-04-20)
### ⚠ BREAKING CHANGES
* call `executePackageManagerRequest` directly ([#430](https://github.com/nodejs/corepack/issues/430))
### Bug Fixes
* call `executePackageManagerRequest` directly ([#430](https://github.com/nodejs/corepack/issues/430)) ([0f9b748](https://github.com/nodejs/corepack/commit/0f9b74864048d5dc150a63cc582966af0c5f363f))
## [0.27.0](https://github.com/nodejs/corepack/compare/v0.26.0...v0.27.0) (2024-04-19)
### ⚠ BREAKING CHANGES
* attempting to download a version from the npm registry (or a mirror) that was published using the now deprecated PGP signature without providing a hash will trigger an error. Users can disable the signature verification using a environment variable.
### Features
* separate read and write operations on lastKnownGood.json ([#446](https://github.com/nodejs/corepack/issues/446)) ([c449adc](https://github.com/nodejs/corepack/commit/c449adc81822a604ee8f00ae2b53fc411535f96d))
* update package manager versions ([#425](https://github.com/nodejs/corepack/issues/425)) ([1423190](https://github.com/nodejs/corepack/commit/142319056424b1e0da2bdbe801c52c5910023707))
* update package manager versions ([#462](https://github.com/nodejs/corepack/issues/462)) ([56816c2](https://github.com/nodejs/corepack/commit/56816c2b7ebc9926f07048b0ec4ff6025bb4e293))
* verify integrity signature when downloading from npm registry ([#432](https://github.com/nodejs/corepack/issues/432)) ([e561dd0](https://github.com/nodejs/corepack/commit/e561dd00bbacc5bc15a492fc36574fa0e37bff7b))
### Bug Fixes
* add path to `package.json` in error message ([#456](https://github.com/nodejs/corepack/issues/456)) ([32a93ea](https://github.com/nodejs/corepack/commit/32a93ea4f51eb7db7dc95a16c5719695edf4b53e))
* correctly set `Dispatcher` prototype for `ProxyAgent` ([#451](https://github.com/nodejs/corepack/issues/451)) ([73d9a1e](https://github.com/nodejs/corepack/commit/73d9a1e2d2f84906bf01952f1dca8adab576b7bf))
* download fewer metadata from npm registry ([#436](https://github.com/nodejs/corepack/issues/436)) ([082fabf](https://github.com/nodejs/corepack/commit/082fabf8b15658e69e4fb62bb854fe9aace78b70))
* hash check when downloading Yarn Berry from npm ([#439](https://github.com/nodejs/corepack/issues/439)) ([4672162](https://github.com/nodejs/corepack/commit/467216281e1719a739d0eeea370b335adfb37b8d))
* Incorrect authorization prefix for basic auth, and undocumented env var ([#454](https://github.com/nodejs/corepack/issues/454)) ([2d63536](https://github.com/nodejs/corepack/commit/2d63536413971d43f570deb035845aa0bd5202f0))
* re-add support for custom registries with auth ([#397](https://github.com/nodejs/corepack/issues/397)) ([d267753](https://github.com/nodejs/corepack/commit/d2677538cdb613fcab6d2a45bb07f349bdc65c2b))
## [0.26.0](https://github.com/nodejs/corepack/compare/v0.25.2...v0.26.0) (2024-03-08)
### Features
* Pins the package manager as it's used for the first time ([#413](https://github.com/nodejs/corepack/issues/413)) ([8b6c6d4](https://github.com/nodejs/corepack/commit/8b6c6d4b2b7a9d61ae6c33c07e12354bd5afc2ba))
* update package manager versions ([#415](https://github.com/nodejs/corepack/issues/415)) ([e8edba7](https://github.com/nodejs/corepack/commit/e8edba771bca6fb10c855c04eee8102ffa792d58))
### Bug Fixes
* group the download prompt together ([#391](https://github.com/nodejs/corepack/issues/391)) ([00506b2](https://github.com/nodejs/corepack/commit/00506b2a15dd87ec03240578077a35b7980e00c1))
* ignore `EROFS` errors ([#421](https://github.com/nodejs/corepack/issues/421)) ([b7ec137](https://github.com/nodejs/corepack/commit/b7ec137210efd35c3461321b6434e3e13a87d42f))
* improve support for `COREPACK_NPM_REGISTRY` with Yarn Berry ([#396](https://github.com/nodejs/corepack/issues/396)) ([47be27c](https://github.com/nodejs/corepack/commit/47be27c9db988e10f651d23b3f53bcf55318a894))
* Windows malicious file analysis waiting problem ([#398](https://github.com/nodejs/corepack/issues/398)) ([295a1cd](https://github.com/nodejs/corepack/commit/295a1cdb9cbbbce8434e8d82b96eb63e57c46c1a))
## [0.25.2](https://github.com/nodejs/corepack/compare/v0.25.1...v0.25.2) (2024-02-21)
### Features
* update package manager versions ([#362](https://github.com/nodejs/corepack/issues/362)) ([1423312](https://github.com/nodejs/corepack/commit/1423312a0eb7844dcdd43ae8a63cf12dcacedb2b))
### Bug Fixes
* do not hard fail if Corepack home folder cannot be created ([#382](https://github.com/nodejs/corepack/issues/382)) ([9834f57](https://github.com/nodejs/corepack/commit/9834f5790a99ce2c6c283321bb38b02e5561b7ca))
* do not show download prompt when downloading JSON ([#383](https://github.com/nodejs/corepack/issues/383)) ([bc137a0](https://github.com/nodejs/corepack/commit/bc137a0073c3343ce2d552b6e13bfd2a48f08351))
## [0.25.1](https://github.com/nodejs/corepack/compare/v0.25.0...v0.25.1) (2024-02-20)
### Bug Fixes
* use valid semver range for `engines.node` ([#378](https://github.com/nodejs/corepack/issues/378)) ([f2185fe](https://github.com/nodejs/corepack/commit/f2185fefa145cc75fca082acc169f8aaef637ca2))
## [0.25.0](https://github.com/nodejs/corepack/compare/v0.24.1...v0.25.0) (2024-02-20)
### ⚠ BREAKING CHANGES
* remove `--all` flag ([#351](https://github.com/nodejs/corepack/issues/351))
* remove Node.js 19.x from the range of supported versions ([#375](https://github.com/nodejs/corepack/issues/375))
* use `fetch` ([#365](https://github.com/nodejs/corepack/issues/365))
* remove old install folder migration ([#373](https://github.com/nodejs/corepack/issues/373))
* prompt user before downloading software ([#360](https://github.com/nodejs/corepack/issues/360))
### Features
* add `corepack cache` command ([#363](https://github.com/nodejs/corepack/issues/363)) ([f442366](https://github.com/nodejs/corepack/commit/f442366c1c00d0c3f388b757c3797504f9a6b62e))
* add support for URL in `"packageManager"` ([#359](https://github.com/nodejs/corepack/issues/359)) ([4a8ce6d](https://github.com/nodejs/corepack/commit/4a8ce6d42f081047a341f36067696346c9f3e1ea))
* bump Known Good Release when downloading new version ([#364](https://github.com/nodejs/corepack/issues/364)) ([a56c13b](https://github.com/nodejs/corepack/commit/a56c13bd0b1c11e50361b8b4b6f8a53571e3981a))
* prompt user before downloading software ([#360](https://github.com/nodejs/corepack/issues/360)) ([6b8d87f](https://github.com/nodejs/corepack/commit/6b8d87f2374f79855b24d659f2a2579d6b39f54f))
* remove `--all` flag ([#351](https://github.com/nodejs/corepack/issues/351)) ([d9c70b9](https://github.com/nodejs/corepack/commit/d9c70b91f698787d693406626a73dc95cb18bc1d))
* remove old install folder migration ([#373](https://github.com/nodejs/corepack/issues/373)) ([54e9510](https://github.com/nodejs/corepack/commit/54e9510cdaf6ed08c9dea1ed3999fa65116cb4c7))
* use `fetch` ([#365](https://github.com/nodejs/corepack/issues/365)) ([fe6a307](https://github.com/nodejs/corepack/commit/fe6a3072f64efa810b90e4ee52e0b3ff14c63184))
### Bug Fixes
* remove unsafe remove of install folder ([#372](https://github.com/nodejs/corepack/issues/372)) ([65880ca](https://github.com/nodejs/corepack/commit/65880cafed5f4195f8e7656ca9af4cbcbb7682d3))
### Miscellaneous Chores
* remove Node.js 19.x from the range of supported versions ([#375](https://github.com/nodejs/corepack/issues/375)) ([9a1cb38](https://github.com/nodejs/corepack/commit/9a1cb385bba9ade8e9fbf5517c2bdff60295f9ed))
## [0.24.1](https://github.com/nodejs/corepack/compare/v0.24.0...v0.24.1) (2024-01-13)
### Features
* update package manager versions ([#348](https://github.com/nodejs/corepack/issues/348)) ([cc3ada7](https://github.com/nodejs/corepack/commit/cc3ada73bccd0a5b0ff16834e518efa521c9eea4))
### Bug Fixes
* **use:** create `package.json` when calling `corepack use` on empty dir ([#350](https://github.com/nodejs/corepack/issues/350)) ([2950a8a](https://github.com/nodejs/corepack/commit/2950a8a30b64b4598abc354e45400e83d56e541b))
## [0.24.0](https://github.com/nodejs/corepack/compare/v0.23.0...v0.24.0) (2023-12-29)
### Features
* add support for HTTP redirect ([#341](https://github.com/nodejs/corepack/issues/341)) ([6df5063](https://github.com/nodejs/corepack/commit/6df5063b14868ff21499a051e5122fa7211be6ed))
* add support for rangeless commands ([#338](https://github.com/nodejs/corepack/issues/338)) ([9bee415](https://github.com/nodejs/corepack/commit/9bee4150815113d97f0bd77d62c8d999cfd68ad3))
* update package manager versions ([#330](https://github.com/nodejs/corepack/issues/330)) ([cfcc280](https://github.com/nodejs/corepack/commit/cfcc28047a788daeef2c0b15ee35a8b1a8149bb6))
* **yarn:** fallback to npm when `COREPACK_NPM_REGISTRY` is set ([#339](https://github.com/nodejs/corepack/issues/339)) ([0717c6a](https://github.com/nodejs/corepack/commit/0717c6af898e075f57c5694d699a3c51e79a024c))
### Bug Fixes
* clarify `EACCES` errors ([#343](https://github.com/nodejs/corepack/issues/343)) ([518bed8](https://github.com/nodejs/corepack/commit/518bed8b7d7c313163c79d31cb9bbc023dba6560))
## [0.23.0](https://github.com/nodejs/corepack/compare/v0.22.0...v0.23.0) (2023-11-05)
### Features
* update package manager versions ([#325](https://github.com/nodejs/corepack/issues/325)) ([450cd33](https://github.com/nodejs/corepack/commit/450cd332d00d3428f49ed09a4235bd12139931c9))
## [0.22.0](https://github.com/nodejs/corepack/compare/v0.21.0...v0.22.0) (2023-10-21)
### Features
* allow fallback to application/json for custom registries ([#314](https://github.com/nodejs/corepack/issues/314)) ([92f8e71](https://github.com/nodejs/corepack/commit/92f8e71f8c97c44f404ce9b7df8787a4292e6830))
* update package manager versions ([#318](https://github.com/nodejs/corepack/issues/318)) ([0bd2577](https://github.com/nodejs/corepack/commit/0bd2577bb4c6c3a5a33ecdb3b6ca2ff244c54f28))
## [0.21.0](https://github.com/nodejs/corepack/compare/v0.20.0...v0.21.0) (2023-10-08)
### ⚠ BREAKING CHANGES
* remove support for Node.js 16.x
### Features
* update package manager versions ([#297](https://github.com/nodejs/corepack/issues/297)) ([503e135](https://github.com/nodejs/corepack/commit/503e135878935cc881ebd94b48d5eca94ec4c27b))
### Miscellaneous Chores
* update supported Node.js versions ([#309](https://github.com/nodejs/corepack/issues/309)) ([787e24d](https://github.com/nodejs/corepack/commit/787e24df609513702eafcd8c6a5f03544d7d45cc))
## [0.20.0](https://github.com/nodejs/corepack/compare/v0.19.0...v0.20.0) (2023-08-29)
### Features
* refactor the CLI interface ([#291](https://github.com/nodejs/corepack/issues/291)) ([fe3e5cd](https://github.com/nodejs/corepack/commit/fe3e5cd86c45db0d87c7fdea87d57d59b0bdcb78))
* update package manager versions ([#292](https://github.com/nodejs/corepack/issues/292)) ([be9c286](https://github.com/nodejs/corepack/commit/be9c286846443ff03081e736fdf4a0ff031fbd38))
## [0.19.0](https://github.com/nodejs/corepack/compare/v0.18.1...v0.19.0) (2023-06-24)
### Features
* support ESM ([#270](https://github.com/nodejs/corepack/issues/270)) ([be2489c](https://github.com/nodejs/corepack/commit/be2489cd0aaabf26a019e1c089a3c8bcc329e94a))
* update package manager versions ([#280](https://github.com/nodejs/corepack/issues/280)) ([4188f2b](https://github.com/nodejs/corepack/commit/4188f2b4671228339fe16f9f566e7bac0c2c4f6d))
## [0.18.1](https://github.com/nodejs/corepack/compare/v0.18.0...v0.18.1) (2023-06-13)
### Features
* update package manager versions ([#272](https://github.com/nodejs/corepack/issues/272)) ([5345774](https://github.com/nodejs/corepack/commit/53457747a26a5de3debbd0d9282b338186bbd7c3))
### Bug Fixes
* disable `v8-compile-cache` when using `npm@&gt;=9.7.0` ([#276](https://github.com/nodejs/corepack/issues/276)) ([2f3678c](https://github.com/nodejs/corepack/commit/2f3678cd7915978f4e2ce7a32cbe5db58e9d0b8d))
* don't override `process.exitCode` ([#268](https://github.com/nodejs/corepack/issues/268)) ([17d1f3d](https://github.com/nodejs/corepack/commit/17d1f3dd41ef6127228d427fd5cca373d6c97f0f))
## [0.18.0](https://github.com/nodejs/corepack/compare/v0.17.2...v0.18.0) (2023-05-19)
### ⚠ BREAKING CHANGES
* remove support for Node.js 14.x
### Features
* update package manager versions ([#256](https://github.com/nodejs/corepack/issues/256)) ([7b61ff6](https://github.com/nodejs/corepack/commit/7b61ff6bc797ec4ed50c2ba1e1f1689264cbf4fc))
### Bug Fixes
* **doc:** add a note about troubleshooting network errors ([#259](https://github.com/nodejs/corepack/issues/259)) ([aa3cbdb](https://github.com/nodejs/corepack/commit/aa3cbdb54fb21b8e0adde96dc781cdf750932843))
### Miscellaneous Chores
* update supported Node.js versions ([#258](https://github.com/nodejs/corepack/issues/258)) ([74f679d](https://github.com/nodejs/corepack/commit/74f679d8a72cc10a3720fc679b95e9bd086d95be))
## [0.17.2](https://github.com/nodejs/corepack/compare/v0.17.1...v0.17.2) (2023-04-07)
### Features
* update package manager versions ([#249](https://github.com/nodejs/corepack/issues/249)) ([2507e9b](https://github.com/nodejs/corepack/commit/2507e9b317eacdeb939aee086de5711218ebd794))
## [0.17.1](https://github.com/nodejs/corepack/compare/v0.17.0...v0.17.1) (2023-03-17)
### Features
* update package manager versions ([#245](https://github.com/nodejs/corepack/issues/245)) ([673f3b7](https://github.com/nodejs/corepack/commit/673f3b7f18421a49da1e2c55656666a74ce94474))
## [0.17.0](https://github.com/nodejs/corepack/compare/v0.16.0...v0.17.0) (2023-02-24)
### ⚠ BREAKING CHANGES
* add `"exports"` to the `package.json` ([#239](https://github.com/nodejs/corepack/issues/239))
### Features
* update package manager versions ([#242](https://github.com/nodejs/corepack/issues/242)) ([5141639](https://github.com/nodejs/corepack/commit/5141639af8198a343105be1e98a74f7c9e152472))
### Bug Fixes
* add `"exports"` to the `package.json` ([#239](https://github.com/nodejs/corepack/issues/239)) ([8e12d08](https://github.com/nodejs/corepack/commit/8e12d088dec171c03e90f623895a1fbf867130e6))
## [0.16.0](https://github.com/nodejs/corepack/compare/v0.15.3...v0.16.0) (2023-02-17)
### Features
* update package manager versions ([#228](https://github.com/nodejs/corepack/issues/228)) ([bb000f9](https://github.com/nodejs/corepack/commit/bb000f9c10a1fbd85f2c15a90218d90b42473130))
* build: migrate to ESBuild ([#229](https://github.com/nodejs/corepack/pull/229)) ([15ceb83](https://github.com/nodejs/corepack/commit/15ceb832a34a223efbe3d3f9cb792d9101a7022a))
### Bug Fixes
* npm registry override ([#219](https://github.com/nodejs/corepack/issues/219)) ([1b35362](https://github.com/nodejs/corepack/commit/1b353624e644874d9ef6c9acaf6d1254bff3015a))
## [0.15.3](https://github.com/nodejs/corepack/compare/v0.15.2...v0.15.3) (2022-12-30)
### Features
* update package manager versions ([#215](https://github.com/nodejs/corepack/issues/215)) ([f84cfcb](https://github.com/nodejs/corepack/commit/f84cfcb00ffb985d44b6aa0b563b2b4056a8f0d0))
## [0.15.2](https://github.com/nodejs/corepack/compare/v0.15.1...v0.15.2) (2022-11-25)
### Features
* update package manager versions ([#211](https://github.com/nodejs/corepack/issues/211)) ([c536c0c](https://github.com/nodejs/corepack/commit/c536c0c27c137c87a14487a2c2a63a1fe6bf88ec))
## [0.15.1](https://github.com/nodejs/corepack/compare/v0.15.0...v0.15.1) (2022-11-04)
### Features
* update package manager versions ([#205](https://github.com/nodejs/corepack/issues/205)) ([5bfac11](https://github.com/nodejs/corepack/commit/5bfac11715474a4318c67fc806fd1ff4252c683a))
## [0.15.0](https://github.com/nodejs/corepack/compare/v0.14.2...v0.15.0) (2022-10-28)
### Features
* add support for configurable registries and applicable auth options ([#186](https://github.com/nodejs/corepack/issues/186)) ([662ae90](https://github.com/nodejs/corepack/commit/662ae9057c7360cb05e9476914e611a9bf0074db))
* update package manager versions ([#193](https://github.com/nodejs/corepack/issues/193)) ([0ec3a73](https://github.com/nodejs/corepack/commit/0ec3a7384729c5cf4ac566d91f1a4bb74e08a64f))
* when strict checking is off, treat like transparent ([#197](https://github.com/nodejs/corepack/issues/197)) ([5eadc50](https://github.com/nodejs/corepack/commit/5eadc50192e205c60bfb1cad91854e9014a747b8))
### Bug Fixes
* **doc:** add package configuration instruction to readme ([#188](https://github.com/nodejs/corepack/issues/188)) ([0b7abb9](https://github.com/nodejs/corepack/commit/0b7abb9833d332bad97902260d31652482c274a0))
* recreate cache folder if necessary ([#200](https://github.com/nodejs/corepack/issues/200)) ([7b5f2f9](https://github.com/nodejs/corepack/commit/7b5f2f9fcb24fe3fe517a96deaac7f32854f3124))
## [0.14.2](https://github.com/nodejs/corepack/compare/v0.14.1...v0.14.2) (2022-09-24)
### Features
* update package manager versions ([#184](https://github.com/nodejs/corepack/issues/184)) ([84ae313](https://github.com/nodejs/corepack/commit/84ae3139e4b9a86d97465e36b50beb9201fda732))
## [0.14.1](https://github.com/nodejs/corepack/compare/v0.14.0...v0.14.1) (2022-09-16)
### Features
* update package manager versions ([#179](https://github.com/nodejs/corepack/issues/179)) ([0b88dcb](https://github.com/nodejs/corepack/commit/0b88dcbaaf190117c6f407b6632a4b3b10da8ad9))
## [0.14.0](https://github.com/nodejs/corepack/compare/v0.13.0...v0.14.0) (2022-09-02)
### Features
* add `COREPACK_ENABLE_STRICT` env variable ([#167](https://github.com/nodejs/corepack/issues/167)) ([92b52f6](https://github.com/nodejs/corepack/commit/92b52f6b4918aff968c0942b89fc722ebf57bce2))
* update package manager versions ([#170](https://github.com/nodejs/corepack/issues/170)) ([6f70bfc](https://github.com/nodejs/corepack/commit/6f70bfc4b6a8a57cccb1ff9cbf2f49240648f1ed))
### Bug Fixes
* handle tags including numbers in `prepare` command ([#165](https://github.com/nodejs/corepack/issues/165)) ([5a0727b](https://github.com/nodejs/corepack/commit/5a0727b43976e0dc299151876c0dde2c4a85174d))
## [0.13.0](https://github.com/nodejs/corepack/compare/v0.12.3...v0.13.0) (2022-08-19)
### Features
* do not use `~/.node` as default value for `COREPACK_HOME` ([#152](https://github.com/nodejs/corepack/issues/152)) ([09e24cf](https://github.com/nodejs/corepack/commit/09e24cf497de27fe92668cf0a8e555f2c7e2530d))
* download the latest version instead of a pinned one ([#134](https://github.com/nodejs/corepack/issues/134)) ([055b928](https://github.com/nodejs/corepack/commit/055b92807f711b5c8c8be6e62b8d3ce83e1ff002))
* update package manager versions ([#163](https://github.com/nodejs/corepack/issues/163)) ([af38d5a](https://github.com/nodejs/corepack/commit/af38d5afbbc10d61265b2f4687c5cc498b059b41))
## [0.12.3](https://github.com/nodejs/corepack/compare/v0.12.2...v0.12.3) (2022-08-12)
### Features
* update package manager versions ([#160](https://github.com/nodejs/corepack/issues/160)) ([ad092a7](https://github.com/nodejs/corepack/commit/ad092a7fb4296143fa5224c04dbd628451b3c158))
## [0.12.2](https://github.com/nodejs/corepack/compare/v0.12.1...v0.12.2) (2022-08-05)
### Features
* update package manager versions ([#154](https://github.com/nodejs/corepack/issues/154)) ([4b95fd3](https://github.com/nodejs/corepack/commit/4b95fd3b926659855970a887c893c10db0b98e5d))
## [0.12.1](https://github.com/nodejs/corepack/compare/v0.12.0...v0.12.1) (2022-07-21)
### Bug Fixes
* **doc:** update DESIGN.md s/engines.pm/packageManager/ ([#141](https://github.com/nodejs/corepack/issues/141)) ([d6039c5](https://github.com/nodejs/corepack/commit/d6039c5b16cdddb33069b9aa864854ed16d17e4e))
* update package manager versions ([#146](https://github.com/nodejs/corepack/issues/146)) ([fdb187a](https://github.com/nodejs/corepack/commit/fdb187a640de77df9b3688623ba510bdafda8702))
## [0.12.0](https://github.com/nodejs/corepack/compare/v0.11.2...v0.12.0) (2022-07-09)
### Features
* add support for hash checking ([#133](https://github.com/nodejs/corepack/issues/133)) ([6a480a7](https://github.com/nodejs/corepack/commit/6a480a72c2e9fc6725f2ab6dfaf4c52e4d3d2ade))
* add support for tags and ranges in `prepare` command ([#136](https://github.com/nodejs/corepack/issues/136)) ([29da06c](https://github.com/nodejs/corepack/commit/29da06c515e917829e5ffbedb34284a6597e9d56))
* update package manager versions ([#129](https://github.com/nodejs/corepack/issues/129)) ([2470f58](https://github.com/nodejs/corepack/commit/2470f58b74491a1301221df643c55be5adf1d349))
* update package manager versions ([#139](https://github.com/nodejs/corepack/issues/139)) ([cd0dcad](https://github.com/nodejs/corepack/commit/cd0dcade85621199048d7ca30dfc3efce11e1f37))
### Bug Fixes
* streamline the cache exploration ([#135](https://github.com/nodejs/corepack/issues/135)) ([185da44](https://github.com/nodejs/corepack/commit/185da44078fd1ca34aec2e4e6f8a52ecffcf3c11))
## [0.11.2](https://github.com/nodejs/corepack/compare/v0.11.1...v0.11.2) (2022-06-13)
### Bug Fixes
* only set bins on pack ([#127](https://github.com/nodejs/corepack/issues/127)) ([7ae489a](https://github.com/nodejs/corepack/commit/7ae489a86c3fe584b9915f4ec57deb7c316c1a25))
## [0.11.1](https://github.com/nodejs/corepack/compare/v0.11.0...v0.11.1) (2022-06-12)
### Bug Fixes
* **ci:** YAML formatting in publish workflow ([#124](https://github.com/nodejs/corepack/issues/124)) ([01c7d63](https://github.com/nodejs/corepack/commit/01c7d638b04a1340b3939a7985e24b586e344995))
## 0.11.0 (2022-06-12)
### Features
* auto setup proxy for http requests ([#69](https://github.com/nodejs/corepack/issues/69)) ([876ce02](https://github.com/nodejs/corepack/commit/876ce02fe7385ea5bc896b2dc93d1fb320361c64))
### Bug Fixes
* avoid symlinks to work on Windows ([#13](https://github.com/nodejs/corepack/issues/13)) ([b56df30](https://github.com/nodejs/corepack/commit/b56df30796da9c7cb0ba5e1bb7152c81582abba6))
* avoid using eval to get the corepack version ([#45](https://github.com/nodejs/corepack/issues/45)) ([78d94eb](https://github.com/nodejs/corepack/commit/78d94eb297444d7558e8b4395f0108c97117f8ab))
* bin file name for pnpm >=6.0 ([#35](https://github.com/nodejs/corepack/issues/35)) ([8ff2499](https://github.com/nodejs/corepack/commit/8ff2499e831c8cf2dea604ea985d830afc8a479e))
* generate cmd shim files ([a900b4d](https://github.com/nodejs/corepack/commit/a900b4db12fcd4d99c0a4d011b426cdc6485d323))
* handle package managers with a bin array correctly ([#20](https://github.com/nodejs/corepack/issues/20)) ([1836d17](https://github.com/nodejs/corepack/commit/1836d17b4fc4c0164df2fe1ccaca4d2f16f6f2d1))
* handle parallel installs ([#84](https://github.com/nodejs/corepack/issues/84)) ([5cfc6c9](https://github.com/nodejs/corepack/commit/5cfc6c9df0dbec8e4de4324be37aa0a54a300552))
* handle prereleases ([#32](https://github.com/nodejs/corepack/issues/32)) ([2a46b6d](https://github.com/nodejs/corepack/commit/2a46b6d13adae139141012254ef670d6ddcb5d11))
### Performance Improvements
* load binaries in the same process ([#97](https://github.com/nodejs/corepack/issues/97)) ([5ff6e82](https://github.com/nodejs/corepack/commit/5ff6e82028e58448ba5ba986854b61ecdc69885b))
+7
View File
@@ -0,0 +1,7 @@
**Copyright © Corepack contributors**
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+379
View File
@@ -0,0 +1,379 @@
# <img src="./icon.svg" height="25" /> corepack
[![Join us on OpenJS slack (channel #nodejs-corepack)](https://img.shields.io/badge/OpenJS%20Slack-%23nodejs--corepack-blue)](https://slack-invite.openjsf.org/)
Corepack is a zero-runtime-dependency Node.js script that acts as a bridge
between Node.js projects and the package managers they are intended to be used
with during development. In practical terms, **Corepack lets you use Yarn, npm,
and pnpm without having to install them**.
## How to Install
### Default Installs
Corepack is distributed with Node.js from version 14.19.0 up to (but not including) 25.0.0.
Run `corepack enable` to install the required Yarn and pnpm binaries on your path.
### Manual Installs
<details>
<summary>Install Corepack using npm</summary>
First uninstall your global Yarn and pnpm binaries (just leave npm). In general,
you'd do this by running the following command:
```shell
npm uninstall -g yarn pnpm
# That should be enough, but if you installed Yarn without going through npm it might
# be more tedious - for example, you might need to run `brew uninstall yarn` as well.
```
Then install Corepack:
```shell
npm install -g corepack
```
We do acknowledge the irony and overhead of using npm to install Corepack, which
is at least part of why the preferred option is to use the Corepack version that
is distributed along with Node.js itself.
</details>
<details><summary>Update Corepack using npm</summary>
To install the latest version of Corepack, use:
```shell
npm install -g corepack@latest
```
If Corepack was installed on your system using a Node.js Windows Installer
`.msi` package then you might need to remove it before attempting to install a
different version of Corepack using npm. You can select the Modify option of the
Node.js app settings to access the Windows Installer feature selection, and on
the "corepack manager" feature of the Node.js `.msi` package by selecting
"Entire feature will be unavailable". See
[Repair apps and programs in Windows](https://support.microsoft.com/en-us/windows/repair-apps-and-programs-in-windows-e90eefe4-d0a2-7c1b-dd59-949a9030f317)
for instructions on accessing the Windows apps page to modify settings.
</details>
<details><summary>Install Corepack from source</summary>
See [`CONTRIBUTING.md`](./CONTRIBUTING.md).
</details>
## Usage
### When Building Packages
Just use your package managers as you usually would. Run `yarn install` in Yarn
projects, `pnpm install` in pnpm projects, and `npm` in npm projects. Corepack
will catch these calls, and depending on the situation:
- **If the local project is configured for the package manager you're using**,
Corepack will download and cache the latest compatible version.
- **If the local project is configured for a different package manager**,
Corepack will request you to run the command again using the right package
manager - thus avoiding corruptions of your install artifacts.
- **If the local project isn't configured for any package manager**, Corepack
will assume that you know what you're doing, and will use whatever package
manager version has been pinned as "known good release". Check the relevant
section for more details.
### When Authoring Packages
Set your package's manager with the `packageManager` field in `package.json`:
```json
{
"packageManager": "yarn@3.2.3+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa"
}
```
Here, `yarn` is the name of the package manager, specified at version `3.2.3`,
along with the SHA-224 hash of this version for validation.
`packageManager@x.y.z` is required. The hash is optional but strongly
recommended as a security practice. Permitted values for the package manager are
`yarn`, `npm`, and `pnpm`.
You can also provide a URL to a `.js` file (which will be interpreted as a
CommonJS module) or a `.tgz` file (which will be interpreted as a package, and
the `"bin"` field of the `package.json` will be used to determine which file to
use in the archive).
```json
{
"packageManager": "yarn@https://registry.npmjs.org/@yarnpkg/cli-dist/-/cli-dist-3.2.3.tgz#sha224.16a0797d1710d1fb7ec40ab5c3801b68370a612a9b66ba117ad9924b"
}
```
#### `devEngines.packageManager`
When a `devEngines.packageManager` field is defined, and is an object containing
a `"name"` field (can also optionally contain `version` and `onFail` fields),
Corepack will use it to validate you're using a compatible package manager.
Depending on the value of `devEngines.packageManager.onFail`:
- if set to `ignore`, Corepack won't print any warning or error.
- if unset or set to `error`, Corepack will throw an error in case of a mismatch.
- if set to `warn` or some other value, Corepack will print a warning in case
of mismatch.
If the top-level `packageManager` field is missing, Corepack will use the
package manager defined in `devEngines.packageManager` – in which case you must
provide a specific version in `devEngines.packageManager.version`, ideally with
a hash, as explained in the previous section:
```json
{
"devEngines":{
"packageManager": {
"name": "yarn",
"version": "3.2.3+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa"
}
}
}
```
## Known Good Releases
When running Corepack within projects that don't list a supported package
manager, it will default to a set of Known Good Releases.
If there is no Known Good Release for the requested package manager, Corepack
looks up the npm registry for the latest available version and cache it for
future use.
The Known Good Releases can be updated system-wide using `corepack install -g`.
When Corepack downloads a new version of a given package manager on the same
major line as the Known Good Release, it auto-updates it by default.
## Offline Workflow
The utility commands detailed in the next section.
- Either you can use the network while building your container image, in which
case you'll simply run `corepack pack` to make sure that your image
includes the Last Known Good release for the specified package manager.
- Or you're publishing your project to a system where the network is
unavailable, in which case you'll preemptively generate a package manager
archive from your local computer (using `corepack pack -o`) before storing
it somewhere your container will be able to access (for example within your
repository). After that it'll just be a matter of running
`corepack install -g --cache-only <path/to/corepack.tgz>` to setup the cache.
## Utility Commands
### `corepack <binary name>[@<version>] [... args]`
This meta-command runs the specified package manager in the local folder. You
can use it to force an install to run with a given version, which can be useful
when looking for regressions.
Note that those commands still check whether the local project is configured for
the given package manager (ie you won't be able to run `corepack yarn install`
on a project where the `packageManager` field references `pnpm`).
### `corepack cache clean`
Clears the local `COREPACK_HOME` cache directory.
### `corepack cache clear`
Clears the local `COREPACK_HOME` cache directory.
### `corepack enable [... name]`
| Option | Description |
| --------------------- | --------------------------------------- |
| `--install-directory` | Add the shims to the specified location |
This command will detect where Corepack is installed and will create shims next
to it for each of the specified package managers (or all of them if the command
is called without parameters). Note that the npm shims will not be installed
unless explicitly requested, as npm is currently distributed with Node.js
through other means.
If the file system where the `corepack` binary is located is read-only, this
command will fail. A workaround is to add the binaries as alias in your
shell configuration file (e.g. in `~/.bash_aliases`):
```sh
alias yarn="corepack yarn"
alias yarnpkg="corepack yarnpkg"
alias pnpm="corepack pnpm"
alias pnpx="corepack pnpx"
alias npm="corepack npm"
alias npx="corepack npx"
```
On Windows PowerShell, you can add functions using the `$PROFILE` automatic
variable:
```powershell
echo 'function yarn { corepack yarn @args }' >> $PROFILE
echo 'function yarnpkg { corepack yarnpkg @args }' >> $PROFILE
echo 'function pnpm { corepack pnpm @args }' >> $PROFILE
echo 'function pnpx { corepack pnpx @args }' >> $PROFILE
echo 'function npm { corepack npm @args }' >> $PROFILE
echo 'function npx { corepack npx @args }' >> $PROFILE
```
### `corepack disable [... name]`
| Option | Description |
| --------------------- | ------------------------------------------ |
| `--install-directory` | Remove the shims to the specified location |
This command will detect where Node.js is installed and will remove the shims
from there.
### `corepack install`
Download and install the package manager configured in the local project.
This command doesn't change the global version used when running the package
manager from outside the project (use the \`-g,--global\` flag if you wish
to do this).
### `corepack install <-g,--global> [... name[@<version>]]`
Install the selected package managers and install them on the system.
Package managers thus installed will be configured as the new default when
calling their respective binaries outside of projects defining the
`packageManager` field.
### `corepack pack [... name[@<version>]]`
| Option | Description |
| --------------------- | ------------------------------------------ |
| `--json ` | Print the output folder rather than logs |
| `-o,--output ` | Path where to generate the archive |
Download the selected package managers and store them inside a tarball
suitable for use with `corepack install -g`.
### `corepack use <name[@<version>]>`
When run, this command will retrieve the latest release matching the provided
descriptor, assign it to the project's package.json file, and automatically
perform an install.
### `corepack up`
Retrieve the latest available version for the current major release line of
the package manager used in the local project, and update the project to use
it.
Unlike `corepack use` this command doesn't take a package manager name nor a
version range, as it will always select the latest available version from the
range specified in `devEngines.packageManager.version`, or fallback to the
same major line. Should you need to upgrade to a new major, use an explicit
`corepack use {name}@latest` call (or simply `corepack use {name}`).
## Environment Variables
- `COREPACK_DEFAULT_TO_LATEST` can be set to `0` in order to instruct Corepack
not to lookup on the remote registry for the latest version of the selected
package manager, and to not update the Last Known Good version when it
downloads a new version of the same major line.
- `COREPACK_ENABLE_AUTO_PIN` can be set to `1` to instruct Corepack to
update the `packageManager` field when it detects that the local package
doesn't list it. In general we recommend to always list a `packageManager`
field (which you can easily set through `corepack use [name]@[version]`), as
it ensures that your project installs are always deterministic.
- `COREPACK_ENABLE_DOWNLOAD_PROMPT` can be set to `0` to
prevent Corepack showing the URL when it needs to download software, or can be
set to `1` to have the URL shown. By default, when Corepack is called
explicitly (e.g. `corepack pnpm …`), it is set to `0`; when Corepack is called
implicitly (e.g. `pnpm …`), it is set to `1`.
The default value cannot be overridden in a `.corepack.env` file.
When standard input is a TTY and no CI environment is detected, Corepack will
ask for user input before starting the download.
- `COREPACK_ENABLE_UNSAFE_CUSTOM_URLS` can be set to `1` to allow use of
custom URLs to load a package manager known by Corepack (`yarn`, `npm`, and
`pnpm`).
- `COREPACK_ENABLE_NETWORK` can be set to `0` to prevent Corepack from accessing
the network (in which case you'll be responsible for hydrating the package
manager versions that will be required for the projects you'll run, using
`corepack install -g --cache-only`).
- `COREPACK_ENABLE_STRICT` can be set to `0` to prevent Corepack from throwing
error if the package manager does not correspond to the one defined for the
current project. This means that if a user is using the package manager
specified in the current project, it will use the version specified by the
project's `packageManager` field. But if the user is using other package
manager different from the one specified for the current project, it will use
the system-wide package manager version.
- `COREPACK_ENABLE_PROJECT_SPEC` can be set to `0` to prevent Corepack from
checking if the package manager corresponds to the one defined for the current
project. This means that it will always use the system-wide package manager
regardless of what is being specified in the project's `packageManager` field.
- `COREPACK_ENV_FILE` can be set to `0` to request Corepack to not attempt to
load `.corepack.env`; it can be set to a path to specify a different env file.
Only keys that start with `COREPACK_` and are not in the exception list
(`COREPACK_ENABLE_DOWNLOAD_PROMPT` and `COREPACK_ENV_FILE` are ignored)
will be taken into account.
- `COREPACK_HOME` can be set in order to define where Corepack should install
the package managers. By default it is set to `%LOCALAPPDATA%\node\corepack`
on Windows, and to `$HOME/.cache/node/corepack` everywhere else.
- `COREPACK_ROOT` has no functional impact on Corepack itself; it's
automatically being set in your environment by Corepack when it shells out to
the underlying package managers, so that they can feature-detect its presence
(useful for commands like `yarn init`).
- `COREPACK_NPM_REGISTRY` sets the registry base url used when retrieving
package managers from npm. Default value is `https://registry.npmjs.org`
- `COREPACK_NPM_TOKEN` sets a Bearer token authorization header when connecting
to a npm type registry.
- `COREPACK_NPM_USERNAME` and `COREPACK_NPM_PASSWORD` to set a Basic
authorization header when connecting to a npm type registry. Note that both
environment variables are required and as plain text. If you want to send an
empty password, explicitly set `COREPACK_NPM_PASSWORD` to an empty string.
- `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` are supported through
[`NODE_USE_ENV_PROXY=1`](https://nodejs.org/api/cli.html#node_use_env_proxy1).
- `COREPACK_INTEGRITY_KEYS` can be set to an empty string or `0` to
instruct Corepack to skip integrity checks, or to a JSON string containing
custom keys.
## Troubleshooting
The environment variable `DEBUG` can be set to `corepack` to enable additional debug logging.
### Networking
There are a wide variety of networking issues that can occur while running
`corepack` commands. Things to check:
- Make sure your network connection is active.
- Make sure the host for your request can be resolved by your DNS; try using
`curl [URL]` (ipv4) and `curl -6 [URL]` (ipv6) from your shell.
- Check your proxy settings (see [Environment Variables](#environment-variables)).
## Contributing
See [`CONTRIBUTING.md`](./CONTRIBUTING.md).
## License (MIT)
See [`LICENSE.md`](./LICENSE.md).
+4
View File
@@ -0,0 +1,4 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='0';
require('module').enableCompileCache?.();
require('./lib/corepack.cjs').runMain(process.argv.slice(2));
File diff suppressed because it is too large. Load diff
+4
View File
@@ -0,0 +1,4 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('module').enableCompileCache?.();
require('./lib/corepack.cjs').runMain(['npm', ...process.argv.slice(2)]);
+4
View File
@@ -0,0 +1,4 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('module').enableCompileCache?.();
require('./lib/corepack.cjs').runMain(['npx', ...process.argv.slice(2)]);
+4
View File
@@ -0,0 +1,4 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('module').enableCompileCache?.();
require('./lib/corepack.cjs').runMain(['pnpm', ...process.argv.slice(2)]);
+4
View File
@@ -0,0 +1,4 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('module').enableCompileCache?.();
require('./lib/corepack.cjs').runMain(['pnpx', ...process.argv.slice(2)]);
+4
View File
@@ -0,0 +1,4 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('module').enableCompileCache?.();
require('./lib/corepack.cjs').runMain(['yarn', ...process.argv.slice(2)]);
+4
View File
@@ -0,0 +1,4 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('module').enableCompileCache?.();
require('./lib/corepack.cjs').runMain(['yarnpkg', ...process.argv.slice(2)]);
+101
View File
@@ -0,0 +1,101 @@
{
"name": "corepack",
"version": "0.35.0",
"homepage": "https://github.com/nodejs/corepack#readme",
"bugs": {
"url": "https://github.com/nodejs/corepack/issues"
},
"repository": {
"type": "git",
"url": "https://github.com/nodejs/corepack.git"
},
"engines": {
"node": "^22.22.2 || ^24.15.0 || >=26.0.0"
},
"exports": {
"./package.json": "./package.json"
},
"license": "MIT",
"packageManager": "yarn@4.14.1+sha224.88b7a7244bbd9040380c417f7eb556d85c67640b651f113cb4c72113",
"devDependencies": {
"@types/debug": "^4.1.5",
"@types/node": "^22.0.0",
"@types/proxy-from-env": "^1",
"@types/semver": "^7.1.0",
"@types/which": "^3.0.0",
"@yarnpkg/eslint-config": "^3.0.0",
"@yarnpkg/fslib": "^3.0.0-rc.48",
"@zkochan/cmd-shim": "^6.0.0",
"clipanion": "patch:clipanion@npm%3A3.2.1#~/.yarn/patches/clipanion-npm-3.2.1-fc9187f56c.patch",
"debug": "^4.1.1",
"esbuild": "^0.28.0",
"eslint": "^9.22.0",
"semver": "^7.6.3",
"supports-color": "^10.0.0",
"tar": "^7.5.11",
"tsx": "^4.16.2",
"typescript": "^5.7.3",
"v8-compile-cache": "^2.3.0",
"vitest": "^4.0.5",
"which": "^7.0.0"
},
"dependenciesMeta": {
"esbuild": {
"built": true
}
},
"scripts": {
"build": "run clean && run build:bundle && tsx ./mkshims.ts",
"build:bundle": "esbuild ./sources/_lib.ts --bundle --platform=node --target=node22.22.2 --external:corepack --outfile='./dist/lib/corepack.cjs' --resolve-extensions='.ts,.mjs,.js'",
"clean": "run rimraf dist shims",
"corepack": "tsx ./sources/_cli.ts",
"lint": "eslint .",
"prepack": "yarn build",
"postpack": "run clean",
"rimraf": "node -e 'for(let i=2;i<process.argv.length;i++)fs.rmSync(process.argv[i],{recursive:true,force:true});'",
"typecheck": "tsc --noEmit",
"test": "vitest"
},
"files": [
"dist",
"shims",
"LICENSE.md"
],
"publishConfig": {
"bin": {
"corepack": "./dist/corepack.js",
"pnpm": "./dist/pnpm.js",
"pnpx": "./dist/pnpx.js",
"yarn": "./dist/yarn.js",
"yarnpkg": "./dist/yarnpkg.js"
},
"executableFiles": [
"./dist/npm.js",
"./dist/npx.js",
"./dist/pnpm.js",
"./dist/pnpx.js",
"./dist/yarn.js",
"./dist/yarnpkg.js",
"./dist/corepack.js",
"./shims/npm",
"./shims/npm.ps1",
"./shims/npx",
"./shims/npx.ps1",
"./shims/pnpm",
"./shims/pnpm.ps1",
"./shims/pnpx",
"./shims/pnpx.ps1",
"./shims/yarn",
"./shims/yarn.ps1",
"./shims/yarnpkg",
"./shims/yarnpkg.ps1"
]
},
"bin": {
"corepack": "./dist/corepack.js",
"pnpm": "./dist/pnpm.js",
"pnpx": "./dist/pnpx.js",
"yarn": "./dist/yarn.js",
"yarnpkg": "./dist/yarnpkg.js"
}
}
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/../dist/corepack.js" "$@"
else
exec node "$basedir/../dist/corepack.js" "$@"
fi
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\corepack.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\corepack.js" %*
)
+28
View File
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/../dist/corepack.js" $args
} else {
& "$basedir/node$exe" "$basedir/../dist/corepack.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/../dist/corepack.js" $args
} else {
& "node$exe" "$basedir/../dist/corepack.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/node_modules/corepack/dist/corepack.js" "$@"
else
exec node "$basedir/node_modules/corepack/dist/corepack.js" "$@"
fi
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\corepack\dist\corepack.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\corepack\dist\corepack.js" %*
)
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/node_modules/corepack/dist/corepack.js" $args
} else {
& "$basedir/node$exe" "$basedir/node_modules/corepack/dist/corepack.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/node_modules/corepack/dist/corepack.js" $args
} else {
& "node$exe" "$basedir/node_modules/corepack/dist/corepack.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/node_modules/corepack/dist/npm.js" "$@"
else
exec node "$basedir/node_modules/corepack/dist/npm.js" "$@"
fi
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\corepack\dist\npm.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\corepack\dist\npm.js" %*
)
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/node_modules/corepack/dist/npm.js" $args
} else {
& "$basedir/node$exe" "$basedir/node_modules/corepack/dist/npm.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/node_modules/corepack/dist/npm.js" $args
} else {
& "node$exe" "$basedir/node_modules/corepack/dist/npm.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/node_modules/corepack/dist/npx.js" "$@"
else
exec node "$basedir/node_modules/corepack/dist/npx.js" "$@"
fi
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\corepack\dist\npx.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\corepack\dist\npx.js" %*
)
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/node_modules/corepack/dist/npx.js" $args
} else {
& "$basedir/node$exe" "$basedir/node_modules/corepack/dist/npx.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/node_modules/corepack/dist/npx.js" $args
} else {
& "node$exe" "$basedir/node_modules/corepack/dist/npx.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/node_modules/corepack/dist/pnpm.js" "$@"
else
exec node "$basedir/node_modules/corepack/dist/pnpm.js" "$@"
fi
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\corepack\dist\pnpm.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\corepack\dist\pnpm.js" %*
)
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/node_modules/corepack/dist/pnpm.js" $args
} else {
& "$basedir/node$exe" "$basedir/node_modules/corepack/dist/pnpm.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/node_modules/corepack/dist/pnpm.js" $args
} else {
& "node$exe" "$basedir/node_modules/corepack/dist/pnpm.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/node_modules/corepack/dist/pnpx.js" "$@"
else
exec node "$basedir/node_modules/corepack/dist/pnpx.js" "$@"
fi
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\corepack\dist\pnpx.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\corepack\dist\pnpx.js" %*
)
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/node_modules/corepack/dist/pnpx.js" $args
} else {
& "$basedir/node$exe" "$basedir/node_modules/corepack/dist/pnpx.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/node_modules/corepack/dist/pnpx.js" $args
} else {
& "node$exe" "$basedir/node_modules/corepack/dist/pnpx.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/node_modules/corepack/dist/yarn.js" "$@"
else
exec node "$basedir/node_modules/corepack/dist/yarn.js" "$@"
fi
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\corepack\dist\yarn.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\corepack\dist\yarn.js" %*
)
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/node_modules/corepack/dist/yarn.js" $args
} else {
& "$basedir/node$exe" "$basedir/node_modules/corepack/dist/yarn.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/node_modules/corepack/dist/yarn.js" $args
} else {
& "node$exe" "$basedir/node_modules/corepack/dist/yarn.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/node_modules/corepack/dist/yarnpkg.js" "$@"
else
exec node "$basedir/node_modules/corepack/dist/yarnpkg.js" "$@"
fi
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\corepack\dist\yarnpkg.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\node_modules\corepack\dist\yarnpkg.js" %*
)
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/node_modules/corepack/dist/yarnpkg.js" $args
} else {
& "$basedir/node$exe" "$basedir/node_modules/corepack/dist/yarnpkg.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/node_modules/corepack/dist/yarnpkg.js" $args
} else {
& "node$exe" "$basedir/node_modules/corepack/dist/yarnpkg.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/../dist/npm.js" "$@"
else
exec node "$basedir/../dist/npm.js" "$@"
fi
+7
View File
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\npm.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\npm.js" %*
)
+28
View File
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/../dist/npm.js" $args
} else {
& "$basedir/node$exe" "$basedir/../dist/npm.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/../dist/npm.js" $args
} else {
& "node$exe" "$basedir/../dist/npm.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/../dist/npx.js" "$@"
else
exec node "$basedir/../dist/npx.js" "$@"
fi
+7
View File
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\npx.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\npx.js" %*
)
+28
View File
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/../dist/npx.js" $args
} else {
& "$basedir/node$exe" "$basedir/../dist/npx.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/../dist/npx.js" $args
} else {
& "node$exe" "$basedir/../dist/npx.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/../dist/pnpm.js" "$@"
else
exec node "$basedir/../dist/pnpm.js" "$@"
fi
+7
View File
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\pnpm.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\pnpm.js" %*
)
+28
View File
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/../dist/pnpm.js" $args
} else {
& "$basedir/node$exe" "$basedir/../dist/pnpm.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/../dist/pnpm.js" $args
} else {
& "node$exe" "$basedir/../dist/pnpm.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/../dist/pnpx.js" "$@"
else
exec node "$basedir/../dist/pnpx.js" "$@"
fi
+7
View File
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\pnpx.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\pnpx.js" %*
)
+28
View File
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/../dist/pnpx.js" $args
} else {
& "$basedir/node$exe" "$basedir/../dist/pnpx.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/../dist/pnpx.js" $args
} else {
& "node$exe" "$basedir/../dist/pnpx.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/../dist/yarn.js" "$@"
else
exec node "$basedir/../dist/yarn.js" "$@"
fi
+7
View File
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\yarn.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\yarn.js" %*
)
+28
View File
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/../dist/yarn.js" $args
} else {
& "$basedir/node$exe" "$basedir/../dist/yarn.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/../dist/yarn.js" $args
} else {
& "node$exe" "$basedir/../dist/yarn.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
+12
View File
@@ -0,0 +1,12 @@
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/../dist/yarnpkg.js" "$@"
else
exec node "$basedir/../dist/yarnpkg.js" "$@"
fi
+7
View File
@@ -0,0 +1,7 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\yarnpkg.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\yarnpkg.js" %*
)
+28
View File
@@ -0,0 +1,28 @@
#!/usr/bin/env pwsh
$basedir=Split-Path $MyInvocation.MyCommand.Definition -Parent
$exe=""
if ($PSVersionTable.PSVersion -lt "6.0" -or $IsWindows) {
# Fix case when both the Windows and Linux builds of Node
# are installed in the same directory
$exe=".exe"
}
$ret=0
if (Test-Path "$basedir/node$exe") {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "$basedir/node$exe" "$basedir/../dist/yarnpkg.js" $args
} else {
& "$basedir/node$exe" "$basedir/../dist/yarnpkg.js" $args
}
$ret=$LASTEXITCODE
} else {
# Support pipeline input
if ($MyInvocation.ExpectingInput) {
$input | & "node$exe" "$basedir/../dist/yarnpkg.js" $args
} else {
& "node$exe" "$basedir/../dist/yarnpkg.js" $args
}
$ret=$LASTEXITCODE
}
exit $ret
View File
Whitespace-only changes.
+235
View File
@@ -0,0 +1,235 @@
The npm application
Copyright (c) npm, Inc. and Contributors
Licensed on the terms of The Artistic License 2.0
Node package dependencies of the npm application
Copyright (c) their respective copyright owners
Licensed on their respective license terms
The npm public registry at https://registry.npmjs.org
and the npm website at https://www.npmjs.com
Operated by npm, Inc.
Use governed by terms published on https://www.npmjs.com
"Node.js"
Trademark Joyent, Inc., https://joyent.com
Neither npm nor npm, Inc. are affiliated with Joyent, Inc.
The Node.js application
Project of Node Foundation, https://nodejs.org
The npm Logo
Copyright (c) Mathias Pettersson and Brian Hammond
"Gubblebum Blocky" typeface
Copyright (c) Tjarda Koster, https://jelloween.deviantart.com
Used with permission
--------
The Artistic License 2.0
Copyright (c) 2000-2006, The Perl Foundation.
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
This license establishes the terms under which a given free software
Package may be copied, modified, distributed, and/or redistributed.
The intent is that the Copyright Holder maintains some artistic
control over the development of that Package while still keeping the
Package available as open source and free software.
You are always permitted to make arrangements wholly outside of this
license directly with the Copyright Holder of a given Package. If the
terms of this license do not permit the full use that you propose to
make of the Package, you should contact the Copyright Holder and seek
a different licensing arrangement.
Definitions
"Copyright Holder" means the individual(s) or organization(s)
named in the copyright notice for the entire Package.
"Contributor" means any party that has contributed code or other
material to the Package, in accordance with the Copyright Holder's
procedures.
"You" and "your" means any person who would like to copy,
distribute, or modify the Package.
"Package" means the collection of files distributed by the
Copyright Holder, and derivatives of that collection and/or of
those files. A given Package may consist of either the Standard
Version, or a Modified Version.
"Distribute" means providing a copy of the Package or making it
accessible to anyone else, or in the case of a company or
organization, to others outside of your company or organization.
"Distributor Fee" means any fee that you charge for Distributing
this Package or providing support for this Package to another
party. It does not mean licensing fees.
"Standard Version" refers to the Package if it has not been
modified, or has been modified only in ways explicitly requested
by the Copyright Holder.
"Modified Version" means the Package, if it has been changed, and
such changes were not explicitly requested by the Copyright
Holder.
"Original License" means this Artistic License as Distributed with
the Standard Version of the Package, in its current version or as
it may be modified by The Perl Foundation in the future.
"Source" form means the source code, documentation source, and
configuration files for the Package.
"Compiled" form means the compiled bytecode, object code, binary,
or any other form resulting from mechanical transformation or
translation of the Source form.
Permission for Use and Modification Without Distribution
(1) You are permitted to use the Standard Version and create and use
Modified Versions for any purpose without restriction, provided that
you do not Distribute the Modified Version.
Permissions for Redistribution of the Standard Version
(2) You may Distribute verbatim copies of the Source form of the
Standard Version of this Package in any medium without restriction,
either gratis or for a Distributor Fee, provided that you duplicate
all of the original copyright notices and associated disclaimers. At
your discretion, such verbatim copies may or may not include a
Compiled form of the Package.
(3) You may apply any bug fixes, portability changes, and other
modifications made available from the Copyright Holder. The resulting
Package will still be considered the Standard Version, and as such
will be subject to the Original License.
Distribution of Modified Versions of the Package as Source
(4) You may Distribute your Modified Version as Source (either gratis
or for a Distributor Fee, and with or without a Compiled form of the
Modified Version) provided that you clearly document how it differs
from the Standard Version, including, but not limited to, documenting
any non-standard features, executables, or modules, and provided that
you do at least ONE of the following:
(a) make the Modified Version available to the Copyright Holder
of the Standard Version, under the Original License, so that the
Copyright Holder may include your modifications in the Standard
Version.
(b) ensure that installation of your Modified Version does not
prevent the user installing or running the Standard Version. In
addition, the Modified Version must bear a name that is different
from the name of the Standard Version.
(c) allow anyone who receives a copy of the Modified Version to
make the Source form of the Modified Version available to others
under
(i) the Original License or
(ii) a license that permits the licensee to freely copy,
modify and redistribute the Modified Version using the same
licensing terms that apply to the copy that the licensee
received, and requires that the Source form of the Modified
Version, and of any works derived from it, be made freely
available in that license fees are prohibited but Distributor
Fees are allowed.
Distribution of Compiled Forms of the Standard Version
or Modified Versions without the Source
(5) You may Distribute Compiled forms of the Standard Version without
the Source, provided that you include complete instructions on how to
get the Source of the Standard Version. Such instructions must be
valid at the time of your distribution. If these instructions, at any
time while you are carrying out such distribution, become invalid, you
must provide new instructions on demand or cease further distribution.
If you provide valid instructions or cease distribution within thirty
days after you become aware that the instructions are invalid, then
you do not forfeit any of your rights under this license.
(6) You may Distribute a Modified Version in Compiled form without
the Source, provided that you comply with Section 4 with respect to
the Source of the Modified Version.
Aggregating or Linking the Package
(7) You may aggregate the Package (either the Standard Version or
Modified Version) with other packages and Distribute the resulting
aggregation provided that you do not charge a licensing fee for the
Package. Distributor Fees are permitted, and licensing fees for other
components in the aggregation are permitted. The terms of this license
apply to the use and Distribution of the Standard or Modified Versions
as included in the aggregation.
(8) You are permitted to link Modified and Standard Versions with
other works, to embed the Package in a larger work of your own, or to
build stand-alone binary or bytecode versions of applications that
include the Package, and Distribute the result without restriction,
provided the result does not expose a direct interface to the Package.
Items That are Not Considered Part of a Modified Version
(9) Works (including, but not limited to, modules and scripts) that
merely extend or make use of the Package, do not, by themselves, cause
the Package to be a Modified Version. In addition, such works are not
considered parts of the Package itself, and are not subject to the
terms of this license.
General Provisions
(10) Any use, modification, and distribution of the Standard or
Modified Versions is governed by this Artistic License. By using,
modifying or distributing the Package, you accept this license. Do not
use, modify, or distribute the Package, if you do not accept this
license.
(11) If your Modified Version has been derived from a Modified
Version made by someone other than you, you are nevertheless required
to ensure that your Modified Version complies with the requirements of
this license.
(12) This license does not grant you the right to use any trademark,
service mark, tradename, or logo of the Copyright Holder.
(13) This license includes the non-exclusive, worldwide,
free-of-charge patent license to make, have made, use, offer to sell,
sell, import and otherwise transfer the Package with respect to any
patent claims licensable by the Copyright Holder that are necessarily
infringed by the Package. If you institute patent litigation
(including a cross-claim or counterclaim) against any party alleging
that the Package constitutes direct or contributory patent
infringement, then this Artistic License to you shall terminate on the
date that such litigation is filed.
(14) Disclaimer of Warranty:
THE PACKAGE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTORS "AS
IS' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES. THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT ARE DISCLAIMED TO THE EXTENT PERMITTED BY YOUR LOCAL
LAW. UNLESS REQUIRED BY LAW, NO COPYRIGHT HOLDER OR CONTRIBUTOR WILL
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THE PACKAGE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--------
+53
View File
@@ -0,0 +1,53 @@
# npm - a JavaScript package manager
### Requirements
You should be running a currently supported version of [Node.js](https://nodejs.org/en/download/) to run **`npm`**. For a list of which versions of Node.js are currently supported, please see the [Node.js releases](https://nodejs.org/en/about/previous-releases) page.
### Installation
**`npm`** comes bundled with [**`node`**](https://nodejs.org/), & most third-party distributions, by default. Officially supported downloads/distributions can be found at: [nodejs.org/en/download](https://nodejs.org/en/download)
#### Direct Download
You can download & install **`npm`** directly from [**npmjs**.com](https://npmjs.com/) using our custom `install.sh` script:
```bash
curl -qL https://www.npmjs.com/install.sh | sh
```
#### Node Version Managers
If you're looking to manage multiple versions of **`Node.js`** &/or **`npm`**, consider using a [node version manager](https://github.com/search?q=node+version+manager+archived%3Afalse&type=repositories&ref=advsearch)
### Usage
```bash
npm <command>
```
### Links & Resources
* [**Documentation**](https://docs.npmjs.com/) - Official docs & how-tos for all things **npm**
* Note: you can also search docs locally with `npm help-search <query>`
* [**Bug Tracker**](https://github.com/npm/cli/issues) - Search or submit bugs against the CLI
* [**Community Feedback and Discussions**](https://github.com/orgs/community/discussions/categories/npm) - Contribute ideas & discussion around the npm registry, website & CLI
* [**RFCs**](https://github.com/npm/rfcs) - Contribute ideas & specifications for the API/design of the npm CLI
* [**Service Status**](https://status.npmjs.org/) - Monitor the current status & see incident reports for the website & registry
* [**Project Status**](https://npm.github.io/statusboard/) - See the health of all our maintained OSS projects in one view
* [**Support**](https://www.npmjs.com/support) - Experiencing problems with the **npm** [website](https://npmjs.com) or [registry](https://registry.npmjs.org)? [File a ticket](https://www.npmjs.com/support)
### Acknowledgments
* `npm` is configured to use the **npm Public Registry** at [https://registry.npmjs.org](https://registry.npmjs.org) by default; Usage of this registry is subject to **Terms of Use** available at [https://npmjs.com/policies/terms](https://npmjs.com/policies/terms)
* You can configure `npm` to use any other compatible registry you prefer. You can read more about [configuring third-party registries](https://docs.npmjs.com/cli/v7/using-npm/registry)
### FAQ on Branding
#### Is it "npm" or "NPM" or "Npm"?
**`npm`** should never be capitalized unless it is being displayed in a location that is customarily all-capitals (ex. titles on `man` pages).
#### Is "npm" an acronym for "Node Package Manager"?
Contrary to popular belief, **`npm`** **is not** an acronym for "Node Package Manager." It is a recursive backronymic abbreviation for **"npm is not an acronym"** (if the project were named "ninaa," then it would be an acronym). The precursor to **`npm`** was actually a bash utility named **"pm"**, which was the shortform name of **"pkgmakeinst"** - a bash function that installed various things on various platforms. If **`npm`** were ever considered an acronym, it would be as "node pm" or, potentially, "new pm".
@@ -0,0 +1,6 @@
#!/usr/bin/env sh
if [ "x$npm_config_node_gyp" = "x" ]; then
node "`dirname "$0"`/../../node_modules/node-gyp/bin/node-gyp.js" "$@"
else
"$npm_config_node_gyp" "$@"
fi
@@ -0,0 +1,5 @@
if not defined npm_config_node_gyp (
node "%~dp0\..\..\node_modules\node-gyp\bin\node-gyp.js" %*
) else (
node "%npm_config_node_gyp%" %*
)
+65
View File
@@ -0,0 +1,65 @@
#!/usr/bin/env bash
# This is used by the Node.js installer, which expects the cygwin/mingw
# shell script to already be present in the npm dependency folder.
(set -o igncr) 2>/dev/null && set -o igncr; # cygwin encoding fix
basedir=`dirname "$0"`
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ `uname` = 'Linux' ] && type wslpath &>/dev/null ; then
IS_WSL="true"
fi
function no_node_dir {
# if this didn't work, then everything else below will fail
echo "Could not determine Node.js install directory" >&2
exit 1
}
NODE_EXE="$basedir/node.exe"
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE="$basedir/node"
fi
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE=node
fi
# this path is passed to node.exe, so it needs to match whatever
# kind of paths Node.js thinks it's using, typically win32 paths.
CLI_BASEDIR="$("$NODE_EXE" -p 'require("path").dirname(process.execPath)' 2> /dev/null)"
if [ $? -ne 0 ]; then
# this fails under WSL 1 so add an additional message. we also suppress stderr above
# because the actual error raised is not helpful. in WSL 1 node.exe cannot handle
# output redirection properly. See https://github.com/microsoft/WSL/issues/2370
if [ "$IS_WSL" == "true" ]; then
echo "WSL 1 is not supported. Please upgrade to WSL 2 or above." >&2
fi
no_node_dir
fi
NPM_PREFIX_JS="$CLI_BASEDIR/node_modules/npm/bin/npm-prefix.js"
NPM_CLI_JS="$CLI_BASEDIR/node_modules/npm/bin/npm-cli.js"
NPM_PREFIX=`"$NODE_EXE" "$NPM_PREFIX_JS"`
if [ $? -ne 0 ]; then
no_node_dir
fi
NPM_PREFIX_NPM_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npm-cli.js"
# a path that will fail -f test on any posix bash
NPM_WSL_PATH="/.."
# WSL can run Windows binaries, so we have to give it the win32 path
# however, WSL bash tests against posix paths, so we need to construct that
# to know if npm is installed globally.
if [ "$IS_WSL" == "true" ]; then
NPM_WSL_PATH=`wslpath "$NPM_PREFIX_NPM_CLI_JS"`
fi
if [ -f "$NPM_PREFIX_NPM_CLI_JS" ] || [ -f "$NPM_WSL_PATH" ]; then
NPM_CLI_JS="$NPM_PREFIX_NPM_CLI_JS"
fi
"$NODE_EXE" "$NPM_CLI_JS" "$@"
+2
View File
@@ -0,0 +1,2 @@
#!/usr/bin/env node
require('../lib/cli.js')(process)
+30
View File
@@ -0,0 +1,30 @@
#!/usr/bin/env node
// This is a single-use bin to help windows discover the proper prefix for npm
// without having to load all of npm first
// It does not accept argv params
const path = require('node:path')
const Config = require('@npmcli/config')
const { definitions, flatten, shorthands } = require('@npmcli/config/lib/definitions')
const config = new Config({
npmPath: path.dirname(__dirname),
// argv is explicitly not looked at since prefix is not something that can be changed via argv
argv: [],
definitions,
flatten,
shorthands,
excludeNpmCwd: false,
})
async function main () {
try {
await config.load()
// eslint-disable-next-line no-console
console.log(config.globalPrefix)
} catch (err) {
// eslint-disable-next-line no-console
console.error(err)
process.exit(1)
}
}
main()
+20
View File
@@ -0,0 +1,20 @@
:: Created by npm, please don't edit manually.
@ECHO OFF
SETLOCAL
SET "NODE_EXE=%~dp0\node.exe"
IF NOT EXIST "%NODE_EXE%" (
SET "NODE_EXE=node"
)
SET "NPM_PREFIX_JS=%~dp0\node_modules\npm\bin\npm-prefix.js"
SET "NPM_CLI_JS=%~dp0\node_modules\npm\bin\npm-cli.js"
FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPM_PREFIX_JS%"') DO (
SET "NPM_PREFIX_NPM_CLI_JS=%%F\node_modules\npm\bin\npm-cli.js"
)
IF EXIST "%NPM_PREFIX_NPM_CLI_JS%" (
SET "NPM_CLI_JS=%NPM_PREFIX_NPM_CLI_JS%"
)
"%NODE_EXE%" "%NPM_CLI_JS%" %*
+50
View File
@@ -0,0 +1,50 @@
#!/usr/bin/env pwsh
Set-StrictMode -Version 'Latest'
$NODE_EXE="$PSScriptRoot/node.exe"
if (-not (Test-Path $NODE_EXE)) {
$NODE_EXE="$PSScriptRoot/node"
}
if (-not (Test-Path $NODE_EXE)) {
$NODE_EXE="node"
}
$NPM_PREFIX_JS="$PSScriptRoot/node_modules/npm/bin/npm-prefix.js"
$NPM_CLI_JS="$PSScriptRoot/node_modules/npm/bin/npm-cli.js"
$NPM_PREFIX=(& $NODE_EXE $NPM_PREFIX_JS)
if ($LASTEXITCODE -ne 0) {
Write-Host "Could not determine Node.js install directory"
exit 1
}
$NPM_PREFIX_NPM_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npm-cli.js"
if (Test-Path $NPM_PREFIX_NPM_CLI_JS) {
$NPM_CLI_JS=$NPM_PREFIX_NPM_CLI_JS
}
if ($MyInvocation.ExpectingInput) { # takes pipeline input
$input | & $NODE_EXE $NPM_CLI_JS $args
} elseif (-not $MyInvocation.Line) { # used "-File" argument
& $NODE_EXE $NPM_CLI_JS $args
} else { # used "-Command" argument
if (($MyInvocation | Get-Member -Name 'Statement') -and $MyInvocation.Statement) {
$NPM_ORIGINAL_COMMAND = $MyInvocation.Statement
} else {
$NPM_ORIGINAL_COMMAND = (
[Management.Automation.InvocationInfo].GetProperty('ScriptPosition', [Reflection.BindingFlags] 'Instance, NonPublic')
).GetValue($MyInvocation).Text
}
$NODE_EXE = $NODE_EXE.Replace("``", "````")
$NPM_CLI_JS = $NPM_CLI_JS.Replace("``", "````")
$NPM_COMMAND_ARRAY = [Management.Automation.Language.Parser]::ParseInput($NPM_ORIGINAL_COMMAND, [ref] $null, [ref] $null).
EndBlock.Statements.PipelineElements.CommandElements.Extent.Text
$NPM_ARGS = ($NPM_COMMAND_ARRAY | Select-Object -Skip 1) -join ' '
Invoke-Expression "& `"$NODE_EXE`" `"$NPM_CLI_JS`" $NPM_ARGS"
}
exit $LASTEXITCODE
+65
View File
@@ -0,0 +1,65 @@
#!/usr/bin/env bash
# This is used by the Node.js installer, which expects the cygwin/mingw
# shell script to already be present in the npm dependency folder.
(set -o igncr) 2>/dev/null && set -o igncr; # cygwin encoding fix
basedir=`dirname "$0"`
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ `uname` = 'Linux' ] && type wslpath &>/dev/null ; then
IS_WSL="true"
fi
function no_node_dir {
# if this didn't work, then everything else below will fail
echo "Could not determine Node.js install directory" >&2
exit 1
}
NODE_EXE="$basedir/node.exe"
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE="$basedir/node"
fi
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE=node
fi
# this path is passed to node.exe, so it needs to match whatever
# kind of paths Node.js thinks it's using, typically win32 paths.
CLI_BASEDIR="$("$NODE_EXE" -p 'require("path").dirname(process.execPath)' 2> /dev/null)"
if [ $? -ne 0 ]; then
# this fails under WSL 1 so add an additional message. we also suppress stderr above
# because the actual error raised is not helpful. in WSL 1 node.exe cannot handle
# output redirection properly. See https://github.com/microsoft/WSL/issues/2370
if [ "$IS_WSL" == "true" ]; then
echo "WSL 1 is not supported. Please upgrade to WSL 2 or above." >&2
fi
no_node_dir
fi
NPM_PREFIX_JS="$CLI_BASEDIR/node_modules/npm/bin/npm-prefix.js"
NPX_CLI_JS="$CLI_BASEDIR/node_modules/npm/bin/npx-cli.js"
NPM_PREFIX=`"$NODE_EXE" "$NPM_PREFIX_JS"`
if [ $? -ne 0 ]; then
no_node_dir
fi
NPM_PREFIX_NPX_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npx-cli.js"
# a path that will fail -f test on any posix bash
NPX_WSL_PATH="/.."
# WSL can run Windows binaries, so we have to give it the win32 path
# however, WSL bash tests against posix paths, so we need to construct that
# to know if npm is installed globally.
if [ "$IS_WSL" == "true" ]; then
NPX_WSL_PATH=`wslpath "$NPM_PREFIX_NPX_CLI_JS"`
fi
if [ -f "$NPM_PREFIX_NPX_CLI_JS" ] || [ -f "$NPX_WSL_PATH" ]; then
NPX_CLI_JS="$NPM_PREFIX_NPX_CLI_JS"
fi
"$NODE_EXE" "$NPX_CLI_JS" "$@"
+130
View File
@@ -0,0 +1,130 @@
#!/usr/bin/env node
const cli = require('../lib/cli.js')
// run the resulting command as `npm exec ...args`
process.argv[1] = require.resolve('./npm-cli.js')
process.argv.splice(2, 0, 'exec')
// TODO: remove the affordances for removed items in npm v9
const removedSwitches = new Set([
'always-spawn',
'ignore-existing',
'shell-auto-fallback',
])
const removedOpts = new Set([
'npm',
'node-arg',
'n',
])
const removed = new Set([
...removedSwitches,
...removedOpts,
])
const { definitions, shorthands } = require('@npmcli/config/lib/definitions')
const npmSwitches = Object.entries(definitions)
.filter(([, { type }]) => type === Boolean ||
(Array.isArray(type) && type.includes(Boolean)))
.map(([key]) => key)
// things that don't take a value
const switches = new Set([
...removedSwitches,
...npmSwitches,
'no-install',
'quiet',
'q',
'version',
'v',
'help',
'h',
])
// things that do take a value
const opts = new Set([
...removedOpts,
'package',
'p',
'cache',
'userconfig',
'call',
'c',
'shell',
'npm',
'node-arg',
'n',
])
// break out of loop when we find a positional argument or --
// If we find a positional arg, we shove -- in front of it, and
// let the normal npm cli handle the rest.
let i
let sawRemovedFlags = false
for (i = 3; i < process.argv.length; i++) {
const arg = process.argv[i]
if (arg === '--') {
break
} else if (/^-/.test(arg)) {
const [key, ...v] = arg.replace(/^-+/, '').split('=')
switch (key) {
case 'p':
process.argv[i] = ['--package', ...v].join('=')
break
case 'shell':
process.argv[i] = ['--script-shell', ...v].join('=')
break
case 'no-install':
process.argv[i] = '--yes=false'
break
default:
// resolve shorthands and run again
if (shorthands[key] && !removed.has(key)) {
const a = [...shorthands[key]]
if (v.length) {
a.push(v.join('='))
}
process.argv.splice(i, 1, ...a)
i--
continue
}
break
}
if (removed.has(key)) {
// eslint-disable-next-line no-console
console.error(`npx: the --${key} argument has been removed.`)
sawRemovedFlags = true
process.argv.splice(i, 1)
i--
}
if (v.length === 0 && !switches.has(key) &&
(opts.has(key) || !/^-/.test(process.argv[i + 1]))) {
// value will be next argument, skip over it.
if (removed.has(key)) {
// also remove the value for the cut key.
process.argv.splice(i + 1, 1)
} else {
i++
}
}
} else {
// found a positional arg, put -- in front of it, and we're done
process.argv.splice(i, 0, '--')
break
}
}
if (sawRemovedFlags) {
// eslint-disable-next-line no-console
console.error('See `npm help exec` for more information')
}
cli(process)
+20
View File
@@ -0,0 +1,20 @@
:: Created by npm, please don't edit manually.
@ECHO OFF
SETLOCAL
SET "NODE_EXE=%~dp0\node.exe"
IF NOT EXIST "%NODE_EXE%" (
SET "NODE_EXE=node"
)
SET "NPM_PREFIX_JS=%~dp0\node_modules\npm\bin\npm-prefix.js"
SET "NPX_CLI_JS=%~dp0\node_modules\npm\bin\npx-cli.js"
FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPM_PREFIX_JS%"') DO (
SET "NPM_PREFIX_NPX_CLI_JS=%%F\node_modules\npm\bin\npx-cli.js"
)
IF EXIST "%NPM_PREFIX_NPX_CLI_JS%" (
SET "NPX_CLI_JS=%NPM_PREFIX_NPX_CLI_JS%"
)
"%NODE_EXE%" "%NPX_CLI_JS%" %*
+50
View File
@@ -0,0 +1,50 @@
#!/usr/bin/env pwsh
Set-StrictMode -Version 'Latest'
$NODE_EXE="$PSScriptRoot/node.exe"
if (-not (Test-Path $NODE_EXE)) {
$NODE_EXE="$PSScriptRoot/node"
}
if (-not (Test-Path $NODE_EXE)) {
$NODE_EXE="node"
}
$NPM_PREFIX_JS="$PSScriptRoot/node_modules/npm/bin/npm-prefix.js"
$NPX_CLI_JS="$PSScriptRoot/node_modules/npm/bin/npx-cli.js"
$NPM_PREFIX=(& $NODE_EXE $NPM_PREFIX_JS)
if ($LASTEXITCODE -ne 0) {
Write-Host "Could not determine Node.js install directory"
exit 1
}
$NPM_PREFIX_NPX_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npx-cli.js"
if (Test-Path $NPM_PREFIX_NPX_CLI_JS) {
$NPX_CLI_JS=$NPM_PREFIX_NPX_CLI_JS
}
if ($MyInvocation.ExpectingInput) { # takes pipeline input
$input | & $NODE_EXE $NPX_CLI_JS $args
} elseif (-not $MyInvocation.Line) { # used "-File" argument
& $NODE_EXE $NPX_CLI_JS $args
} else { # used "-Command" argument
if (($MyInvocation | Get-Member -Name 'Statement') -and $MyInvocation.Statement) {
$NPX_ORIGINAL_COMMAND = $MyInvocation.Statement
} else {
$NPX_ORIGINAL_COMMAND = (
[Management.Automation.InvocationInfo].GetProperty('ScriptPosition', [Reflection.BindingFlags] 'Instance, NonPublic')
).GetValue($MyInvocation).Text
}
$NODE_EXE = $NODE_EXE.Replace("``", "````")
$NPX_CLI_JS = $NPX_CLI_JS.Replace("``", "````")
$NPX_COMMAND_ARRAY = [Management.Automation.Language.Parser]::ParseInput($NPX_ORIGINAL_COMMAND, [ref] $null, [ref] $null).
EndBlock.Statements.PipelineElements.CommandElements.Extent.Text
$NPX_ARGS = ($NPX_COMMAND_ARRAY | Select-Object -Skip 1) -join ' '
Invoke-Expression "& `"$NODE_EXE`" `"$NPX_CLI_JS`" $NPX_ARGS"
}
exit $LASTEXITCODE
@@ -0,0 +1,95 @@
---
title: npm-access
section: 1
description: Set access level on published packages
---
### Synopsis
```bash
npm access list packages [<user>|<scope>|<scope:team>] [<package>]
npm access list collaborators [<package> [<user>]]
npm access get status [<package>]
npm access set status=public|private [<package>]
npm access set mfa=none|publish|automation [<package>]
npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]
```
Note: This command is unaware of workspaces.
### Description
Used to set access controls on private packages.
For all of the subcommands, `npm access` will perform actions on the packages in the current working directory if no package name is passed to the subcommand.
* grant / revoke:
Add or remove the ability of users and teams to have read-only or read-write access to a package.
### Details
`npm access` always operates directly on the current registry, configurable from the command line using `--registry=<registry url>`.
Unscoped packages are *always public*.
Scoped packages *default to restricted*, but you can either publish them as public using `npm publish --access=public`, or set their access as public using `npm access set status=public` after the initial publish.
You must have privileges to set the access of a package:
* You are an owner of an unscoped or scoped package.
* You are a member of the team that owns a scope.
* You have been given read-write privileges for a package, either as a member of a team or directly as an owner.
If you have two-factor authentication enabled then you'll be prompted to provide a second factor, or may use the `--otp=...` option to specify it on the command line.
If your account is not paid, then attempts to publish scoped packages will fail with an HTTP 402 status code (logically enough), unless you use
`--access=public`.
Management of teams and team memberships is done with the `npm team` command.
### Configuration
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse() before
saving them to your `package.json`.
Not supported by all npm commands.
#### `otp`
* Default: null
* Type: null or String
This is a one-time password from a two-factor authenticator. It's needed
when publishing or changing package permissions with `npm access`.
If not set, and a registry response fails with a challenge for a one-time
password, npm will prompt on the command line for one.
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
### See Also
* [`libnpmaccess`](https://npm.im/libnpmaccess)
* [npm team](/commands/npm-team)
* [npm publish](/commands/npm-publish)
* [npm config](/commands/npm-config)
* [npm registry](/using-npm/registry)
@@ -0,0 +1,87 @@
---
title: npm-adduser
section: 1
description: Add a registry user account
---
### Synopsis
```bash
npm adduser
alias: add-user
```
Note: This command is unaware of workspaces.
### Description
Create a new user in the specified registry, and save the credentials to the `.npmrc` file.
If no registry is specified, the default registry will be used (see [`registry`](/using-npm/registry)).
When you run `npm adduser`, the CLI automatically generates a legacy token of `publish` type.
For more information, see [About legacy tokens](/about-access-tokens#about-legacy-tokens).
When using `legacy` for your `auth-type`, the username, password, and email are read in from prompts.
### Configuration
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
#### `scope`
* Default: the scope of the current project, if any, or ""
* Type: String
Associate an operation with a scope for a scoped registry.
Useful when logging in to or out of a private registry:
```
# log in, linking the scope to the custom registry
npm login --scope=@mycorp --registry=https://registry.mycorp.com
# log out, removing the link and the auth token
npm logout --scope=@mycorp
```
This will cause `@mycorp` to be mapped to the registry for future
installation of packages specified according to the pattern
`@mycorp/package`.
This will also cause `npm init` to create a scoped package.
```
# accept all defaults, and create a package named "@foo/whatever",
# instead of just named "whatever"
npm init --scope=@foo --yes
```
#### `auth-type`
* Default: "web"
* Type: "legacy" or "web"
What authentication strategy to use with `login`. Note that if an `otp`
config is given, this value will always be set to `legacy`.
### See Also
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm owner](/commands/npm-owner)
* [npm whoami](/commands/npm-whoami)
* [npm token](/commands/npm-token)
* [npm profile](/commands/npm-profile)
@@ -0,0 +1,125 @@
---
title: npm-approve-scripts
section: 1
description: Approve install scripts for specific dependencies
---
### Synopsis
```bash
npm approve-scripts <pkg> [<pkg> ...]
npm approve-scripts --all
npm approve-scripts --allow-scripts-pending
```
Note: This command is unaware of workspaces.
### Description
Manages the `allowScripts` field in your project's `package.json`, which
records which of your dependencies are permitted to run install scripts
(`preinstall`, `install`, `postinstall`, and `prepare` for non-registry
sources). This command is the recommended way to maintain that field.
In the current release, this field is advisory: install scripts still run
by default, but installs print a list of packages whose scripts have not
been reviewed. A future release will block unreviewed install scripts.
There are three modes:
```bash
npm approve-scripts <pkg> [<pkg> ...]
npm approve-scripts --all
npm approve-scripts --allow-scripts-pending
```
`<pkg>` matches every installed version of that package. By default the
command writes pinned entries (`pkg@1.2.3`), which keep their approval
narrowed to the specific version you reviewed. Pass `--no-allow-scripts-pin` to write
name-only entries that allow any future version.
`--all` approves every package with unreviewed install scripts in one go.
`--allow-scripts-pending` is read-only: it lists every package whose install scripts
are not yet covered by `allowScripts`, without modifying `package.json`.
`approve-scripts` honours the asymmetric pin rule: if you re-approve a
package whose installed version has changed, the existing pin is rewritten
to track the new installed version. Multi-version statements
(`pkg@1 || 2`) are left alone, since they likely capture intent that
the command cannot infer. Existing `false` entries always win;
`approve-scripts` will not silently re-allow a package you previously
denied.
### Examples
```bash
# Approve all currently-installed install scripts after reviewing them
npm approve-scripts --all
# Approve specific packages, pinned to their installed version
npm approve-scripts canvas sharp
# Approve name-only (any version of this package is allowed)
npm approve-scripts --no-allow-scripts-pin canvas
# Preview which packages still need review
npm approve-scripts --allow-scripts-pending
```
### Configuration
#### `all`
* Default: false
* Type: Boolean
When running `npm outdated` and `npm ls`, setting `--all` will show all
outdated or installed packages, rather than only those directly depended
upon by the current project.
#### `allow-scripts-pending`
* Default: false
* Type: Boolean
List packages with install scripts that are not yet covered by the
`allowScripts` policy, without modifying `package.json`. Only meaningful for
`npm approve-scripts`.
#### `allow-scripts-pin`
* Default: true
* Type: Boolean
Write pinned (`pkg@version`) entries when approving install scripts. Set to
`false` to write name-only entries that allow any version. Has no effect on
`npm deny-scripts`, which always writes name-only entries regardless of this
setting.
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse() before
saving them to your `package.json`.
Not supported by all npm commands.
### See Also
* [npm deny-scripts](/commands/npm-deny-scripts)
* [npm install](/commands/npm-install)
* [npm rebuild](/commands/npm-rebuild)
* [package.json](/configuring-npm/package-json)
@@ -0,0 +1,449 @@
---
title: npm-audit
section: 1
description: Run a security audit
---
### Synopsis
```bash
npm audit [fix|signatures]
```
### Description
The audit command submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities.
If any vulnerabilities are found, then the impact and appropriate remediation will be calculated.
If the `fix` argument is provided, then remediations will be applied to the package tree.
The command will exit with a 0 exit code if no vulnerabilities were found.
Note that some vulnerabilities cannot be fixed automatically and will require manual intervention or review.
Also note that since `npm audit fix` runs a full-fledged `npm install` under the hood, all configs that apply to the installer will also apply to `npm install` -- so things like `npm audit fix --package-lock-only` will work as expected.
By default, the audit command will exit with a non-zero code if any vulnerability is found.
It may be useful in CI environments to include the `--audit-level` parameter to specify the minimum vulnerability level that will cause the command to fail.
This option does not filter the report output, it simply changes the command's failure threshold.
### Package lock
By default npm requires a package-lock or shrinkwrap in order to run the audit.
You can bypass the package lock with `--no-package-lock` but be aware the results may be different with every run, since npm will re-build the dependency tree each time.
### Audit Signatures
To ensure the integrity of packages you download from the public npm registry, or any registry that supports signatures, you can verify the registry signatures of downloaded packages using the npm CLI.
Registry signatures can be verified using the following `audit` command:
```bash
$ npm audit signatures
```
The `audit signatures` command will also verify the provenance attestations of downloaded packages.
Because provenance attestations are such a new feature, security features may be added to (or changed in) the attestation format over time.
To ensure that you're always able to verify attestation signatures check that you're running the latest version of the npm CLI. Please note this often means updating npm beyond the version that ships with Node.js.
To include the full sigstore attestation bundles in JSON output, use:
```bash
$ npm audit signatures --json --include-attestations
```
This adds a `verified` array to the JSON output containing the attestation
bundles (DSSE envelopes, verification material, and transparency log entries)
for each verified package.
The npm CLI supports registry signatures and signing keys provided by any registry if the following conventions are followed:
1. Signatures are provided in the package's `packument` in each published version within the `dist` object:
```json
"dist":{
"..omitted..": "..omitted..",
"signatures": [{
"keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
"sig": "a312b9c3cb4a1b693e8ebac5ee1ca9cc01f2661c14391917dcb111517f72370809..."
}]
}
```
See this [example](https://registry.npmjs.org/light-cycle/1.4.3) of a signed package from the public npm registry.
The `sig` is generated using the following template: `${package.name}@${package.version}:${package.dist.integrity}` and the `keyid` has to match one of the public signing keys below.
2. Public signing keys are provided at `registry-host.tld/-/npm/v1/keys` in the following format:
```
{
"keys": [{
"expires": null,
"keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
"keytype": "ecdsa-sha2-nistp256",
"scheme": "ecdsa-sha2-nistp256",
"key": "{{B64_PUBLIC_KEY}}"
}]
}
```
Keys response:
- `expires`: null or a simplified extended [ISO 8601 format](https://en.wikipedia.org/wiki/ISO_8601): `YYYY-MM-DDTHH:mm:ss.sssZ`
- `keyid`: sha256 fingerprint of the public key
- `keytype`: only `ecdsa-sha2-nistp256` is currently supported by the npm CLI
- `scheme`: only `ecdsa-sha2-nistp256` is currently supported by the npm CLI
- `key`: base64 encoded public key
See this [example key's response from the public npm registry](https://registry.npmjs.org/-/npm/v1/keys).
### Audit Endpoints
There are two audit endpoints that npm may use to fetch vulnerability information: the `Bulk Advisory` endpoint and the `Quick Audit` endpoint.
#### Bulk Advisory Endpoint
As of version 7, npm uses the much faster `Bulk Advisory` endpoint to optimize the speed of calculating audit results.
npm will generate a JSON payload with the name and list of versions of each package in the tree, and POST it to the default configured registry at the path `/-/npm/v1/security/advisories/bulk`.
Any packages in the tree that do not have a `version` field in their package.json file will be ignored.
If any `--omit` options are specified (either via the [`--omit` config](/using-npm/config#omit), or one of the shorthands such as `--production`, `--only=dev`, and so on), then packages will be omitted from the submitted payload as appropriate.
If the registry responds with an error, or with an invalid response, then npm will attempt to load advisory data from the `Quick Audit` endpoint.
The expected result will contain a set of advisory objects for each dependency that matches the advisory range.
Each advisory object contains a `name`, `url`, `id`, `severity`, `vulnerable_versions`, and `title`.
npm then uses these advisory objects to calculate vulnerabilities and meta-vulnerabilities of the dependencies within the tree.
#### Quick Audit Endpoint
If the `Bulk Advisory` endpoint returns an error, or invalid data, npm will attempt to load advisory data from the `Quick Audit` endpoint, which is considerably slower in most cases.
The full package tree as found in `package-lock.json` is submitted, along with the following pieces of additional metadata:
* `npm_version`
* `node_version`
* `platform`
* `arch`
* `node_env`
All packages in the tree are submitted to the Quick Audit endpoint.
Omitted dependency types are skipped when generating the report.
#### Scrubbing
Out of an abundance of caution, npm versions 5 and 6 would "scrub" any packages from the submitted report if their name contained a `/` character, so as to avoid leaking the names of potentially private packages or git URLs.
However, in practice, this resulted in audits often failing to properly detect meta-vulnerabilities, because the tree would appear to be invalid due to missing dependencies, and prevented the detection of vulnerabilities in package trees that used git dependencies or private modules.
This scrubbing has been removed from npm as of version 7.
#### Calculating Meta-Vulnerabilities and Remediations
npm uses the [`@npmcli/metavuln-calculator`](http://npm.im/@npmcli/metavuln-calculator) module to turn a set of security advisories into a set of "vulnerability" objects.
A "meta-vulnerability" is a dependency that is vulnerable by virtue of dependence on vulnerable versions of a vulnerable package.
For example, if the package `foo` is vulnerable in the range `>=1.0.2 <2.0.0`, and the package `bar` depends on `foo@^1.1.0`, then that version of `bar` can only be installed by installing a vulnerable version of `foo`.
In this case, `bar` is a "metavulnerability".
Once metavulnerabilities for a given package are calculated, they are cached in the `~/.npm` folder and only re-evaluated if the advisory range changes, or a new version of the package is published (in which case, the new version is checked for metavulnerable status as well).
If the chain of metavulnerabilities extends all the way to the root project, and it cannot be updated without changing its dependency ranges, then `npm audit fix` will require the `--force` option to apply the remediation.
If remediations do not require changes to the dependency ranges, then all vulnerable packages will be updated to a version that does not have an advisory or metavulnerability posted against it.
### Exit Code
The `npm audit` command will exit with a 0 exit code if no vulnerabilities were found.
The `npm audit fix` command will exit with 0 exit code if no vulnerabilities are found _or_ if the remediation is able to successfully fix all vulnerabilities.
If vulnerabilities were found the exit code will depend on the [`audit-level` config](/using-npm/config#audit-level).
### Examples
Scan your project for vulnerabilities and automatically install any compatible updates to vulnerable dependencies:
```bash
$ npm audit fix
```
Run `audit fix` without modifying `node_modules`, but still updating the pkglock:
```bash
$ npm audit fix --package-lock-only
```
Skip updating `devDependencies`:
```bash
$ npm audit fix --only=prod
```
Have `audit fix` install SemVer-major updates to toplevel dependencies, not just SemVer-compatible ones:
```bash
$ npm audit fix --force
```
Do a dry run to get an idea of what `audit fix` will do, and _also_ output install information in JSON format:
```bash
$ npm audit fix --dry-run --json
```
Scan your project for vulnerabilities and just show the details, without fixing anything:
```bash
$ npm audit
```
Get the detailed audit report in JSON format:
```bash
$ npm audit --json
```
Fail an audit only if the results include a vulnerability with a level of moderate or higher:
```bash
$ npm audit --audit-level=moderate
```
### Configuration
#### `audit-level`
* Default: null
* Type: null, "info", "low", "moderate", "high", "critical", or "none"
The minimum level of vulnerability for `npm audit` to exit with a non-zero
exit code.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it should
only report what it would have done. This can be passed into any of the
commands that modify your local installation, eg, `install`, `update`,
`dedupe`, `uninstall`, as well as `pack` and `publish`.
Note: This is NOT honored by other network related commands, eg `dist-tags`,
`owner`, etc.
#### `force`
* Default: false
* Type: Boolean
Removes various protections against unfortunate side effects, common
mistakes, unnecessary performance degradation, and malicious input.
* Allow clobbering non-npm files in global installs.
* Allow the `npm version` command to work on an unclean git repository.
* Allow deleting the cache folder with `npm cache clean`.
* Allow installing packages that have an `engines` declaration requiring a
different version of npm.
* Allow installing packages that have an `engines` declaration requiring a
different version of `node`, even if `--engine-strict` is enabled.
* Allow `npm audit fix` to install modules outside your stated dependency
range (including SemVer-major changes).
* Allow unpublishing all versions of a published package.
* Allow conflicting peerDependencies to be installed in the root project.
* Implicitly set `--yes` during `npm init`.
* Allow clobbering existing values in `npm pkg`
* Allow unpublishing of entire packages (not just a single version).
If you don't have a clear idea of what you want to do, it is strongly
recommended that you do not use this option!
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse() before
saving them to your `package.json`.
Not supported by all npm commands.
#### `package-lock-only`
* Default: false
* Type: Boolean
If set to true, the current operation will only use the `package-lock.json`,
ignoring `node_modules`.
For `update` this means only the `package-lock.json` will be updated,
instead of checking `node_modules` and downloading dependencies.
For `list` this means the output will be based on the tree described by the
`package-lock.json`, rather than the contents of `node_modules`.
#### `package-lock`
* Default: true
* Type: Boolean
If set to false, then ignore `package-lock.json` files when installing. This
will also prevent _writing_ `package-lock.json` if `save` is true.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists, then
it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment
variable will be set to `'production'` for all lifecycle scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
Option that allows for defining which types of dependencies to install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted, regardless of
the order in which omit/include are specified on the command-line.
#### `foreground-scripts`
* Default: `false` unless when using `npm pack` or `npm publish` where it
defaults to `true`
* Type: Boolean
Run all build scripts (ie, `preinstall`, `install`, and `postinstall`)
scripts for installed packages in the foreground process, sharing standard
input, output, and error with the main npm process.
Note that this will generally make installs run slower, and be much noisier,
but can be useful for debugging.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script, such as
`npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run` will still
run their intended script if `ignore-scripts` is set, but they will *not*
run any pre- or post-scripts.
#### `include-attestations`
* Default: false
* Type: Boolean
When used with `npm audit signatures --json`, includes the full sigstore
attestation bundles in the JSON output for each verified package. The
bundles contain DSSE envelopes, verification material, and transparency log
entries.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install` to
ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update, etc.)
will link workspaces into the `node_modules` folder. - Commands that do
other things (test, exec, publish, etc.) will operate on the root project,
_unless_ one or more workspaces are specified in the `workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace` config, or
all workspaces via the `workspaces` flag, will cause npm to operate only on
the specified workspaces, and not on the root project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as regular
dependencies instead of creating a symlink. This option has no effect on
workspaces.
### See Also
* [npm install](/commands/npm-install)
* [config](/using-npm/config)
@@ -0,0 +1,106 @@
---
title: npm-bugs
section: 1
description: Report bugs for a package in a web browser
---
### Synopsis
```bash
npm bugs [<pkgname> [<pkgname> ...]]
alias: issues
```
### Description
This command tries to guess at the likely location of a package's bug tracker URL or the `mailto` URL of the support email, and then tries to open it using the [`--browser` config](/using-npm/config#browser) param.
If no package name is provided, it will search for a `package.json` in the current folder and use the `name` property.
### Configuration
#### `browser`
* Default: macOS: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: null, Boolean, or String
The browser that is called by npm commands to open websites.
Set to `false` to suppress browser behavior and instead print urls to
terminal.
Set to `true` to use default system URL opener.
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install` to
ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update, etc.)
will link workspaces into the `node_modules` folder. - Commands that do
other things (test, exec, publish, etc.) will operate on the root project,
_unless_ one or more workspaces are specified in the `workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace` config, or
all workspaces via the `workspaces` flag, will cause npm to operate only on
the specified workspaces, and not on the root project.
This value is not exported to the environment for child processes.
### See Also
* [npm docs](/commands/npm-docs)
* [npm view](/commands/npm-view)
* [npm publish](/commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)
@@ -0,0 +1,100 @@
---
title: npm-cache
section: 1
description: Manipulates packages cache
---
### Synopsis
```bash
npm cache add <package-spec>
npm cache clean [<key>]
npm cache ls [<name>@<version>]
npm cache verify
npm cache npx ls
npm cache npx rm [<key>...]
npm cache npx info <key>...
```
Note: This command is unaware of workspaces.
### Description
Used to add, list, or clean the `npm cache` folder.
Also used to view info about entries in the `npm exec` (aka `npx`) cache folder.
#### `npm cache`
* add:
Add the specified packages to the local cache.
This command is primarily intended to be used internally by npm, but it can provide a way to add data to the local installation cache explicitly.
* clean:
Delete a single entry or all entries out of the cache folder.
Note that this is typically unnecessary, as npm's cache is self-healing and resistant to data corruption issues.
* ls:
List given entries or all entries in the local cache.
* verify:
Verify the contents of the cache folder, garbage collecting any unneeded data, and verifying the integrity of the cache index and all cached data.
#### `npm cache npx`
* ls:
List all entries in the npx cache.
* rm:
Remove given entries or all entries from the npx cache.
* info:
Get detailed information about given entries in the npx cache.
### Details
npm stores cache data in an opaque directory within the configured `cache`, named `_cacache`.
This directory is a [`cacache`](http://npm.im/cacache)-based content-addressable cache that stores all http request data as well as other package-related data.
This directory is primarily accessed through `pacote`, the library responsible for all package fetching as of npm@5.
All data that passes through the cache is fully verified for integrity on both insertion and extraction.
Cache corruption will either trigger an error, or signal to `pacote` that the data must be refetched, which it will do automatically.
For this reason, it should never be necessary to clear the cache for any reason other than reclaiming disk space, thus why `clean` now requires `--force` to run.
There is currently no method exposed through npm to inspect or directly manage the contents of this cache.
In order to access it, `cacache` must be used directly.
npm will not remove data by itself: the cache will grow as new packages are installed.
### A note about the cache's design
The npm cache is strictly a cache: it should not be relied upon as a persistent and reliable data store for package data.
npm makes no guarantee that a previously-cached piece of data will be available later, and will automatically delete corrupted contents.
The primary guarantee that the cache makes is that, if it does return data, that data will be exactly the data that was inserted.
To run an offline verification of existing cache contents, use `npm cache verify`.
### Configuration
#### `cache`
* Default: Windows: `%LocalAppData%\npm-cache`, Posix: `~/.npm`
* Type: Path
The location of npm's cache directory.
### See Also
* [package spec](/using-npm/package-spec)
* [npm folders](/configuring-npm/folders)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm install](/commands/npm-install)
* [npm publish](/commands/npm-publish)
* [npm pack](/commands/npm-pack)
* [npm exec](/commands/npm-exec)
* https://npm.im/cacache
* https://npm.im/pacote
* https://npm.im/@npmcli/arborist
* https://npm.im/make-fetch-happen
@@ -0,0 +1,434 @@
---
title: npm-ci
section: 1
description: Clean install a project
---
### Synopsis
```bash
npm ci
aliases: clean-install, ic, install-clean, isntall-clean
```
### Description
This command is similar to [`npm install`](/commands/npm-install), except it's meant to be used in automated environments such as test platforms, continuous integration, and deployment -- or any situation where you want to make sure you're doing a clean install of your dependencies.
The main differences between using `npm install` and `npm ci` are:
* The project **must** have an existing `package-lock.json` or
`npm-shrinkwrap.json`.
* If dependencies in the package lock do not match those in `package.json`,
`npm ci` will exit with an error, instead of updating the package lock.
* `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.
* If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
* It will never write to `package.json` or any of the package-locks:
installs are essentially frozen.
NOTE: If you create your `package-lock.json` file by running `npm install` with flags that can affect the shape of your dependency tree, such as
`--legacy-peer-deps` or `--install-links`, you _must_ provide the same flags to `npm ci` or you are likely to encounter errors.
An easy way to do this is to run, for example,
`npm config set legacy-peer-deps=true --location=project` and commit the
`.npmrc` file to your repo.
### Example
Make sure you have a package-lock and an up-to-date install:
```bash
$ cd ./my/npm/project
$ npm install
added 154 packages in 10s
$ ls | grep package-lock
```
Run `npm ci` in that project
```bash
$ npm ci
added 154 packages in 5s
```
Configure Travis CI to build using `npm ci` instead of `npm install`:
```bash
# .travis.yml
install:
- npm ci
# keep the npm cache around to speed up installs
cache:
directories:
- "$HOME/.npm"
```
### Configuration
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as necessary
within directory structure. nested: (formerly --legacy-bundling) install in
place, no hoisting. shallow (formerly --global-style) only install direct
deps at top-level. linked: (experimental) install in node_modules/.store,
link in place, unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install packages in
the same manner that they are depended on. This may cause very deep
directory structures and duplicate package installs as there is no
de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but hoist
on deeper dependencies. Sets `--install-strategy=shallow`.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists, then
it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment
variable will be set to `'production'` for all lifecycle scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
Option that allows for defining which types of dependencies to install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted, regardless of
the order in which omit/include are specified on the command-line.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure, even
if npm could reasonably guess the appropriate resolution based on non-peer
dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency graph will
be resolved using the nearest non-peer dependency specification, even if
doing so will result in some packages receiving a peer dependency outside
the range set in their package's `peerDependencies` object.
When such an override is performed, a warning is printed, explaining the
conflict and the packages involved. If `--strict-peer-deps` is set, then
this warning is treated as a failure.
#### `foreground-scripts`
* Default: `false` unless when using `npm pack` or `npm publish` where it
defaults to `true`
* Type: Boolean
Run all build scripts (ie, `preinstall`, `install`, and `postinstall`)
scripts for installed packages in the foreground process, sharing standard
input, output, and error with the main npm process.
Note that this will generally make installs run slower, and be much noisier,
but can be useful for debugging.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script, such as
`npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run` will still
run their intended script if `ignore-scripts` is set, but they will *not*
run any pre- or post-scripts.
#### `allow-directory`
* Default: "all"
* Type: "all", "none", or "root"
Limits the ability for npm to install dependencies from directories. That
is, dependencies that point to a directory instead of a version or semver
range. Please note that this could leave your tree incomplete and some
packages may not function as intended or designed. Changing this setting
will not remove dependencies that are already installed.
`all` allows any directories to be installed. `none` prevents any
directories from being installed. `root` only allows directories defined in
your project's package.json to be installed. Also allows directory
dependencies to be used for other commands like `npm view`
#### `allow-file`
* Default: "all"
* Type: "all", "none", or "root"
Limits the ability for npm to install dependencies from tarball files. That
is, dependencies that point to a local tarball file instead of a version or
semver range. Please note that this could leave your tree incomplete and
some packages may not function as intended or designed. Changing this
setting will not remove dependencies that are already installed.
`all` allows any tarball file to be installed. `none` prevents any tarball
file from being installed. `root` only allows tarball files defined in your
project's package.json to be installed. Also allows tarball file
dependencies to be used for other commands like `npm view`
#### `allow-git`
* Default: "all"
* Type: "all", "none", or "root"
Limits the ability for npm to fetch dependencies from git references. That
is, dependencies that point to a git repo instead of a version or semver
range. Please note that this could leave your tree incomplete and some
packages may not function as intended or designed. Changing this setting
will not remove dependencies that are already installed.
`all` allows any git dependencies to be fetched and installed. `none`
prevents any git dependencies from being fetched and installed. `root` only
allows git dependencies defined in your project's package.json to be fetched
and installed. Also allows git dependencies to be fetched for other commands
like `npm view`
#### `allow-remote`
* Default: "all"
* Type: "all", "none", or "root"
Limits the ability for npm to fetch dependencies from urls. That is,
dependencies that point to a tarball url instead of a version or semver
range. Please note that this could leave your tree incomplete and some
packages may not function as intended or designed. Changing this setting
will not remove dependencies that are already installed.
`all` allows any url to be installed. `none` prevents any url from being
installed. `root` only allows urls defined in your project's package.json to
be installed. Also allows url dependencies to be used for other commands
like `npm view`
#### `allow-scripts`
* Default: ""
* Type: String (can be set multiple times)
Comma-separated list of packages whose install-time lifecycle scripts
(`preinstall`, `install`, `postinstall`, and `prepare` for non-registry
dependencies) are allowed to run.
This setting is intended for one-off and global contexts: `npm exec`, `npx`,
and `npm install -g`, where no project `package.json` is involved. For
team-wide policy in a project, use the `allowScripts` field in
`package.json` (which also supports explicit denials), or configure it in
`.npmrc`. Passing `--allow-scripts` on the command line during a
project-scoped `npm install`, `ci`, `update`, or `rebuild` is an error.
Each name is matched against a dependency's resolved identity, not against
the package's self-reported name. `--ignore-scripts` and
`--dangerously-allow-all-scripts` both override this setting.
#### `strict-allow-scripts`
* Default: false
* Type: Boolean
If `true`, turn the install-script policy from a warning into a hard error:
any dependency with install scripts not covered by `allowScripts` will fail
the install instead of running with a notice.
Dependencies explicitly denied with `false` in `allowScripts` are always
silently skipped; this setting only affects unreviewed entries.
`--ignore-scripts` and `--dangerously-allow-all-scripts` both override this
setting.
#### `dangerously-allow-all-scripts`
* Default: false
* Type: Boolean
If `true`, bypass the `allowScripts` policy entirely and run every
dependency install script regardless of whether it was approved or denied.
Intended as a migration escape hatch only; its use is strongly discouraged.
`--ignore-scripts` still takes precedence over this setting.
#### `audit`
* Default: true
* Type: Boolean
When "true" submit audit reports alongside the current npm command to the
default registry and all registries configured for scopes. See the
documentation for [`npm audit`](/commands/npm-audit) for details on what is
submitted.
#### `bin-links`
* Default: true
* Type: Boolean
Tells npm to create symlinks (or `.cmd` shims on Windows) for package
executables.
Set to false to have it not do this. This can be used to work around the
fact that some file systems don't support symlinks, even on ostensibly Unix
systems.
#### `fund`
* Default: true
* Type: Boolean
When "true" displays the message at the end of each `npm install`
acknowledging the number of dependencies looking for funding. See [`npm
fund`](/commands/npm-fund) for details.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it should
only report what it would have done. This can be passed into any of the
commands that modify your local installation, eg, `install`, `update`,
`dedupe`, `uninstall`, as well as `pack` and `publish`.
Note: This is NOT honored by other network related commands, eg `dist-tags`,
`owner`, etc.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install` to
ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update, etc.)
will link workspaces into the `node_modules` folder. - Commands that do
other things (test, exec, publish, etc.) will operate on the root project,
_unless_ one or more workspaces are specified in the `workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace` config, or
all workspaces via the `workspaces` flag, will cause npm to operate only on
the specified workspaces, and not on the root project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as regular
dependencies instead of creating a symlink. This option has no effect on
workspaces.
### See Also
* [npm install](/commands/npm-install)
* [package-lock.json](/configuring-npm/package-lock-json)
@@ -0,0 +1,36 @@
---
title: npm-completion
section: 1
description: Tab Completion for npm
---
### Synopsis
```bash
npm completion
```
Note: This command is unaware of workspaces.
### Description
Enables tab-completion in all npm commands.
The synopsis above loads the completions into your current shell.
Adding it to your ~/.bashrc or ~/.zshrc will make the completions available everywhere:
```bash
npm completion >> ~/.bashrc
npm completion >> ~/.zshrc
```
You may of course also pipe the output of `npm completion` to a file such as `/usr/local/etc/bash_completion.d/npm` or
`/etc/bash_completion.d/npm` if you have a system that will read
that file for you.
When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the environment, `npm completion` acts in "plumbing mode", and outputs completions based on the arguments.
### See Also
* [npm developers](/using-npm/developers)
* [npm](/commands/npm)
@@ -0,0 +1,176 @@
---
title: npm-config
section: 1
description: Manage the npm configuration files
---
### Synopsis
```bash
npm config set <key>=<value> [<key>=<value> ...]
npm config get [<key> [<key> ...]]
npm config delete <key> [<key> ...]
npm config list [--json]
npm config edit
npm config fix
alias: c
```
Note: This command is unaware of workspaces.
### Description
npm gets its config settings from the command line, environment variables, `npmrc` files, and in some cases, the `package.json` file.
See [npmrc](/configuring-npm/npmrc) for more information about the npmrc files.
See [config](/using-npm/config) for a more thorough explanation of the mechanisms involved, and a full list of config options available.
The `npm config` command can be used to update and edit the contents of the user and global npmrc files.
### Sub-commands
Config supports the following sub-commands:
#### set
```bash
npm config set key=value [key=value...]
npm set key=value [key=value...]
```
Sets each of the config keys to the value provided.
Modifies the user configuration file unless [`location`](/commands/npm-config#location) is passed.
If value is omitted, the key will be removed from your config file entirely.
Note: for backwards compatibility, `npm config set key value` is supported as an alias for `npm config set key=value`.
#### get
```bash
npm config get [key ...]
npm get [key ...]
```
Echo the config value(s) to stdout.
If multiple keys are provided, then the values will be prefixed with the key names.
If no keys are provided, then this command behaves the same as `npm config list`.
#### list
```bash
npm config list
```
Show all the config settings.
Use `-l` to also show defaults.
Use `--json` to show the settings in json format.
#### delete
```bash
npm config delete key [key ...]
```
Deletes the specified keys from all configuration files.
#### edit
```bash
npm config edit
```
Opens the config file in an editor.
Use the `--global` flag to edit the global config.
#### fix
```bash
npm config fix
```
Attempts to repair invalid configuration items.
Usually this means attaching authentication config (i.e.
`_auth`, `_authToken`) to the configured `registry`.
### Configuration
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse() before
saving them to your `package.json`.
Not supported by all npm commands.
#### `global`
* Default: false
* Type: Boolean
Operates in "global" mode, so that packages are installed into the `prefix`
folder instead of the current working directory. See
[folders](/configuring-npm/folders) for more on the differences in behavior.
* packages are installed into the `{prefix}/lib/node_modules` folder, instead
of the current working directory.
* bin files are linked to `{prefix}/bin`
* man pages are linked to `{prefix}/share/man`
#### `editor`
* Default: The EDITOR or VISUAL environment variables, or
'%SYSTEMROOT%\notepad.exe' on Windows, or 'vi' on Unix systems
* Type: String
The command to run for `npm edit` and `npm config edit`.
#### `location`
* Default: "user" unless `--global` is passed, which will also set this value
to "global"
* Type: "global", "user", or "project"
When passed to `npm config` this refers to which config file to use.
When set to "global" mode, packages are installed into the `prefix` folder
instead of the current working directory. See
[folders](/configuring-npm/folders) for more on the differences in behavior.
* packages are installed into the `{prefix}/lib/node_modules` folder, instead
of the current working directory.
* bin files are linked to `{prefix}/bin`
* man pages are linked to `{prefix}/share/man`
#### `long`
* Default: false
* Type: Boolean
Show extended information in `ls`, `search`, and `help-search`.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm config](/commands/npm-config)
* [package.json](/configuring-npm/package-json)
* [npmrc](/configuring-npm/npmrc)
* [npm](/commands/npm)
@@ -0,0 +1,381 @@
---
title: npm-dedupe
section: 1
description: Reduce duplication in the package tree
---
### Synopsis
```bash
npm dedupe
alias: ddp
```
### Description
Searches the local package tree and attempts to simplify the overall structure by moving dependencies further up the tree, where they can be more effectively shared by multiple dependent packages.
For example, consider this dependency graph:
```
a
+-- b <-- depends on c@1.0.x
| `-- c@1.0.3
`-- d <-- depends on c@~1.0.9
`-- c@1.0.10
```
In this case, `npm dedupe` will transform the tree to:
```bash
a
+-- b
+-- d
`-- c@1.0.10
```
Because of the hierarchical nature of node's module lookup, b and d will both get their dependency met by the single c package at the root level of the tree.
In some cases, you may have a dependency graph like this:
```
a
+-- b <-- depends on c@1.0.x
+-- c@1.0.3
`-- d <-- depends on c@1.x
`-- c@1.9.9
```
During the installation process, the `c@1.0.3` dependency for `b` was placed in the root of the tree.
Though `d`'s dependency on `c@1.x` could have been satisfied by `c@1.0.3`, the newer `c@1.9.9` dependency was used, because npm favors updates by default, even when doing so causes duplication.
Running `npm dedupe` will cause npm to note the duplication and re-evaluate, deleting the nested `c` module, because the one in the root is sufficient.
To prefer deduplication over novelty during the installation process, run `npm install --prefer-dedupe` or `npm config set prefer-dedupe true`.
Arguments are ignored.
Dedupe always acts on the entire tree.
Note that this operation transforms the dependency tree, but will never result in new modules being installed.
Using `npm find-dupes` will run the command in `--dry-run` mode.
Note: `npm dedupe` will never update the semver values of direct dependencies in your project `package.json`, if you want to update values in `package.json` you can run: `npm update --save` instead.
### Configuration
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as necessary
within directory structure. nested: (formerly --legacy-bundling) install in
place, no hoisting. shallow (formerly --global-style) only install direct
deps at top-level. linked: (experimental) install in node_modules/.store,
link in place, unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install packages in
the same manner that they are depended on. This may cause very deep
directory structures and duplicate package installs as there is no
de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but hoist
on deeper dependencies. Sets `--install-strategy=shallow`.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure, even
if npm could reasonably guess the appropriate resolution based on non-peer
dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency graph will
be resolved using the nearest non-peer dependency specification, even if
doing so will result in some packages receiving a peer dependency outside
the range set in their package's `peerDependencies` object.
When such an override is performed, a warning is printed, explaining the
conflict and the packages involved. If `--strict-peer-deps` is set, then
this warning is treated as a failure.
#### `package-lock`
* Default: true
* Type: Boolean
If set to false, then ignore `package-lock.json` files when installing. This
will also prevent _writing_ `package-lock.json` if `save` is true.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists, then
it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment
variable will be set to `'production'` for all lifecycle scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
Option that allows for defining which types of dependencies to install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted, regardless of
the order in which omit/include are specified on the command-line.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script, such as
`npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run` will still
run their intended script if `ignore-scripts` is set, but they will *not*
run any pre- or post-scripts.
#### `allow-directory`
* Default: "all"
* Type: "all", "none", or "root"
Limits the ability for npm to install dependencies from directories. That
is, dependencies that point to a directory instead of a version or semver
range. Please note that this could leave your tree incomplete and some
packages may not function as intended or designed. Changing this setting
will not remove dependencies that are already installed.
`all` allows any directories to be installed. `none` prevents any
directories from being installed. `root` only allows directories defined in
your project's package.json to be installed. Also allows directory
dependencies to be used for other commands like `npm view`
#### `allow-file`
* Default: "all"
* Type: "all", "none", or "root"
Limits the ability for npm to install dependencies from tarball files. That
is, dependencies that point to a local tarball file instead of a version or
semver range. Please note that this could leave your tree incomplete and
some packages may not function as intended or designed. Changing this
setting will not remove dependencies that are already installed.
`all` allows any tarball file to be installed. `none` prevents any tarball
file from being installed. `root` only allows tarball files defined in your
project's package.json to be installed. Also allows tarball file
dependencies to be used for other commands like `npm view`
#### `allow-git`
* Default: "all"
* Type: "all", "none", or "root"
Limits the ability for npm to fetch dependencies from git references. That
is, dependencies that point to a git repo instead of a version or semver
range. Please note that this could leave your tree incomplete and some
packages may not function as intended or designed. Changing this setting
will not remove dependencies that are already installed.
`all` allows any git dependencies to be fetched and installed. `none`
prevents any git dependencies from being fetched and installed. `root` only
allows git dependencies defined in your project's package.json to be fetched
and installed. Also allows git dependencies to be fetched for other commands
like `npm view`
#### `allow-remote`
* Default: "all"
* Type: "all", "none", or "root"
Limits the ability for npm to fetch dependencies from urls. That is,
dependencies that point to a tarball url instead of a version or semver
range. Please note that this could leave your tree incomplete and some
packages may not function as intended or designed. Changing this setting
will not remove dependencies that are already installed.
`all` allows any url to be installed. `none` prevents any url from being
installed. `root` only allows urls defined in your project's package.json to
be installed. Also allows url dependencies to be used for other commands
like `npm view`
#### `audit`
* Default: true
* Type: Boolean
When "true" submit audit reports alongside the current npm command to the
default registry and all registries configured for scopes. See the
documentation for [`npm audit`](/commands/npm-audit) for details on what is
submitted.
#### `bin-links`
* Default: true
* Type: Boolean
Tells npm to create symlinks (or `.cmd` shims on Windows) for package
executables.
Set to false to have it not do this. This can be used to work around the
fact that some file systems don't support symlinks, even on ostensibly Unix
systems.
#### `fund`
* Default: true
* Type: Boolean
When "true" displays the message at the end of each `npm install`
acknowledging the number of dependencies looking for funding. See [`npm
fund`](/commands/npm-fund) for details.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it should
only report what it would have done. This can be passed into any of the
commands that modify your local installation, eg, `install`, `update`,
`dedupe`, `uninstall`, as well as `pack` and `publish`.
Note: This is NOT honored by other network related commands, eg `dist-tags`,
`owner`, etc.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install` to
ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update, etc.)
will link workspaces into the `node_modules` folder. - Commands that do
other things (test, exec, publish, etc.) will operate on the root project,
_unless_ one or more workspaces are specified in the `workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace` config, or
all workspaces via the `workspaces` flag, will cause npm to operate only on
the specified workspaces, and not on the root project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as regular
dependencies instead of creating a symlink. This option has no effect on
workspaces.
### See Also
* [npm find-dupes](/commands/npm-find-dupes)
* [npm ls](/commands/npm-ls)
* [npm update](/commands/npm-update)
* [npm install](/commands/npm-install)
@@ -0,0 +1,109 @@
---
title: npm-deny-scripts
section: 1
description: Deny install scripts for specific dependencies
---
### Synopsis
```bash
npm deny-scripts <pkg> [<pkg> ...]
npm deny-scripts --all
```
Note: This command is unaware of workspaces.
### Description
The companion command to [`npm approve-scripts`](/commands/npm-approve-scripts).
Writes `false` entries into the `allowScripts` field of your project's
`package.json`, recording that a dependency must not run install scripts
even if a future version would otherwise be eligible.
In the current release, install scripts still run by default, so `deny-scripts`
only affects how installs of denied packages are reported. A future release
will block unreviewed install scripts and respect deny entries at install
time.
```bash
npm deny-scripts <pkg> [<pkg> ...]
npm deny-scripts --all
```
`<pkg>` matches every installed version of that package. Denies are always
written name-only (`"pkg": false`), regardless of `--allow-scripts-pin`. Pinning a deny
to a specific version would silently re-allow scripts for any other version
of the same package, which defeats the purpose; the command picks the
safer default for you.
`--all` denies every package with unreviewed install scripts.
If a `true` (pinned or name-only) entry exists for a package and you then
deny it, the existing allow entries are removed so the name-only deny is
unambiguous.
### Examples
```bash
# Deny a specific package outright
npm deny-scripts telemetry-pkg
# Deny everything that has install scripts and isn't already approved
npm deny-scripts --all
```
### Configuration
#### `all`
* Default: false
* Type: Boolean
When running `npm outdated` and `npm ls`, setting `--all` will show all
outdated or installed packages, rather than only those directly depended
upon by the current project.
#### `allow-scripts-pending`
* Default: false
* Type: Boolean
List packages with install scripts that are not yet covered by the
`allowScripts` policy, without modifying `package.json`. Only meaningful for
`npm approve-scripts`.
#### `allow-scripts-pin`
* Default: true
* Type: Boolean
Write pinned (`pkg@version`) entries when approving install scripts. Set to
`false` to write name-only entries that allow any version. Has no effect on
`npm deny-scripts`, which always writes name-only entries regardless of this
setting.
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse() before
saving them to your `package.json`.
Not supported by all npm commands.
### See Also
* [npm approve-scripts](/commands/npm-approve-scripts)
* [npm install](/commands/npm-install)
* [package.json](/configuring-npm/package-json)
@@ -0,0 +1,85 @@
---
title: npm-deprecate
section: 1
description: Deprecate a version of a package
---
### Synopsis
```bash
npm deprecate <package-spec> <message>
```
Note: This command is unaware of workspaces.
### Description
This command will update the npm registry entry for a package, providing a deprecation warning to all who attempt to install it.
It works on [version ranges](https://semver.npmjs.com/) as well as specific versions, so you can do something like this:
```bash
npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
```
SemVer ranges passed to this command are interpreted such that they *do* include prerelease versions.
For example:
```bash
npm deprecate my-thing@1.x "1.x is no longer supported"
```
In this case, a version `my-thing@1.0.0-beta.0` will also be deprecated.
You must be the package owner to deprecate something.
See the `owner` and `adduser` help topics.
To un-deprecate a package, specify an empty string (`""`) for the `message` argument.
Note that you must use double quotes with no space between them to format an empty string.
### Configuration
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
#### `otp`
* Default: null
* Type: null or String
This is a one-time password from a two-factor authenticator. It's needed
when publishing or changing package permissions with `npm access`.
If not set, and a registry response fails with a challenge for a one-time
password, npm will prompt on the command line for one.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it should
only report what it would have done. This can be passed into any of the
commands that modify your local installation, eg, `install`, `update`,
`dedupe`, `uninstall`, as well as `pack` and `publish`.
Note: This is NOT honored by other network related commands, eg `dist-tags`,
`owner`, etc.
### See Also
* [package spec](/using-npm/package-spec)
* [npm publish](/commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm owner](/commands/npm-owner)
* [npm adduser](/commands/npm-adduser)
@@ -0,0 +1,282 @@
---
title: npm-diff
section: 1
description: The registry diff command
---
### Synopsis
```bash
npm diff [...<paths>]
```
### Description
Similar to its `git diff` counterpart, this command will print diff patches of files for packages published to the npm registry.
* `npm diff --diff=<spec-a> --diff=<spec-b>`
Compares two package versions using their registry specifiers, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0`.
It's also possible to compare across forks of any package, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0`.
Any valid spec can be used, so that it's also possible to compare directories or git repositories, e.g: `npm diff --diff=pkg@latest --diff=./packages/pkg`
Here's an example comparing two different versions of a package named `abbrev` from the registry:
```bash
npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1
```
On success, output looks like:
```bash
diff --git a/package.json b/package.json
index v1.1.0..v1.1.1 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
{
"name": "abbrev",
- "version": "1.1.0",
+ "version": "1.1.1",
"description": "Like ruby's abbrev module, but in js",
"author": "Isaac Z. Schlueter <i@izs.me>",
"main": "abbrev.js",
```
Given the flexible nature of npm specs, you can also target local directories or git repos just like when using `npm install`:
```bash
npm diff --diff=https://github.com/npm/libnpmdiff --diff=./local-path
```
In the example above we can compare the contents from the package installed from the git repo at `github.com/npm/libnpmdiff` with the contents of the `./local-path` that contains a valid package, such as a modified copy of the original.
* `npm diff` (in a package directory, no arguments):
If the package is published to the registry, `npm diff` will fetch the tarball version tagged as `latest` (this value can be configured using the `tag` option) and proceed to compare the contents of files present in that tarball, with the current files in your local file system.
This workflow provides a handy way for package authors to see what package-tracked files have been changed in comparison with the latest published version of that package.
* `npm diff --diff=<pkg-name>` (in a package directory):
When using a single package name (with no version or tag specifier) as an argument, `npm diff` will work in a similar way to [`npm-outdated`](npm-outdated) and reach for the registry to figure out what current published version of the package named `<pkg-name>` will satisfy its dependent declared semver-range.
Once that specific version is known `npm diff` will print diff patches comparing the current version of `<pkg-name>` found in the local file system with that specific version returned by the registry.
Given a package named `abbrev` that is currently installed:
```bash
npm diff --diff=abbrev
```
That will request from the registry its most up to date version and will print a diff output comparing the currently installed version to this newer one if the version numbers are not the same.
* `npm diff --diff=<spec-a>` (in a package directory):
Similar to using only a single package name, it's also possible to declare a full registry specifier version if you wish to compare the local version of an installed package with the specific version/tag/semver-range provided in `<spec-a>`.
An example: assuming `pkg@1.0.0` is installed in the current `node_modules` folder, running:
```bash
npm diff --diff=pkg@2.0.0
```
It will effectively be an alias to
`npm diff --diff=pkg@1.0.0 --diff=pkg@2.0.0`.
* `npm diff --diff=<semver-a> [--diff=<semver-b>]` (in a package directory):
Using `npm diff` along with semver-valid version numbers is a shorthand to compare different versions of the current package.
It needs to be run from a package directory, such that for a package named `pkg` running `npm diff --diff=1.0.0 --diff=1.0.1` is the same as running `npm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1`.
If only a single argument `<version-a>` is provided, then the current local file system is going to be compared against that version.
Here's an example comparing two specific versions (published to the configured registry) of the current project directory:
```bash
npm diff --diff=1.0.0 --diff=1.1.0
```
Note that tag names are not valid `--diff` argument values, if you wish to compare to a published tag, you must use the `pkg@tagname` syntax.
#### Filtering files
It's possible to also specify positional arguments using file names or globs pattern matching in order to limit the result of diff patches to only a subset of files for a given package, e.g:
```bash
npm diff --diff=pkg@2 ./lib/ CHANGELOG.md
```
In the example above the diff output is only going to print contents of files located within the folder `./lib/` and changed lines of code within the `CHANGELOG.md` file.
### Configuration
#### `diff`
* Default:
* Type: String (can be set multiple times)
Define arguments to compare in `npm diff`.
#### `diff-name-only`
* Default: false
* Type: Boolean
Prints only filenames when using `npm diff`.
#### `diff-unified`
* Default: 3
* Type: Number
The number of lines of context to print in `npm diff`.
#### `diff-ignore-all-space`
* Default: false
* Type: Boolean
Ignore whitespace when comparing lines in `npm diff`.
#### `diff-no-prefix`
* Default: false
* Type: Boolean
Do not show any source or destination prefix in `npm diff` output.
Note: this causes `npm diff` to ignore the `--diff-src-prefix` and
`--diff-dst-prefix` configs.
#### `diff-src-prefix`
* Default: "a/"
* Type: String
Source prefix to be used in `npm diff` output.
#### `diff-dst-prefix`
* Default: "b/"
* Type: String
Destination prefix to be used in `npm diff` output.
#### `diff-text`
* Default: false
* Type: Boolean
Treat all files as text in `npm diff`.
#### `global`
* Default: false
* Type: Boolean
Operates in "global" mode, so that packages are installed into the `prefix`
folder instead of the current working directory. See
[folders](/configuring-npm/folders) for more on the differences in behavior.
* packages are installed into the `{prefix}/lib/node_modules` folder, instead
of the current working directory.
* bin files are linked to `{prefix}/bin`
* man pages are linked to `{prefix}/share/man`
#### `tag`
* Default: "latest"
* Type: String
If you ask npm to install a package and don't tell it a specific version,
then it will install the specified tag.
It is the tag added to the package@version specified in the `npm dist-tag
add` command, if no explicit tag is given.
When used by the `npm diff` command, this is the tag used to fetch the
tarball that will be compared with the local files by default.
If used in the `npm publish` command, this is the tag that will be added to
the package submitted to the registry.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install` to
ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update, etc.)
will link workspaces into the `node_modules` folder. - Commands that do
other things (test, exec, publish, etc.) will operate on the root project,
_unless_ one or more workspaces are specified in the `workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace` config, or
all workspaces via the `workspaces` flag, will cause npm to operate only on
the specified workspaces, and not on the root project.
This value is not exported to the environment for child processes.
## See Also
* [npm outdated](/commands/npm-outdated)
* [npm install](/commands/npm-install)
* [npm config](/commands/npm-config)
* [npm registry](/using-npm/registry)
@@ -0,0 +1,138 @@
---
title: npm-dist-tag
section: 1
description: Modify package distribution tags
---
### Synopsis
```bash
npm dist-tag add <package-spec (with version)> [<tag>]
npm dist-tag rm <package-spec> <tag>
npm dist-tag ls [<package-spec>]
alias: dist-tags
```
### Description
Add, remove, and enumerate distribution tags on a package:
* add: Tags the specified version of the package with the specified tag, or the [`--tag` config](/using-npm/config#tag) if not specified.
If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp <one-time password>`, or go through a second factor flow based on your `authtype`.
* rm: Clear a tag that is no longer in use from the package.
If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp <one-time password>`, or go through a second factor flow based on your `authtype`
* ls: Show all of the dist-tags for a package, defaulting to the package in the current prefix.
This is the default action if none is specified.
A tag can be used when installing packages as a reference to a version instead of using a specific version number:
```bash
npm install <name>@<tag>
```
When installing dependencies, a preferred tagged version may be specified:
```bash
npm install --tag <tag>
```
(This also applies to any other commands that resolve and install dependencies, such as `npm dedupe`, `npm update`, and `npm audit fix`.)
Publishing a package sets the `latest` tag to the published version unless the `--tag` option is used.
For example, `npm publish --tag=beta`.
By default, `npm install <pkg>` (without any `@<version>` or `@<tag>` specifier) installs the `latest` tag.
### Purpose
Tags can be used to provide an alias instead of version numbers.
For example, a project might choose to have multiple streams of development and use a different tag for each stream, e.g., `stable`, `beta`, `dev`,
`canary`.
By default, the `latest` tag is used by npm to identify the current version of a package, and `npm install <pkg>` (without any `@<version>` or `@<tag>` specifier) installs the `latest` tag.
Typically, projects only use the `latest` tag for stable release versions, and use other tags for unstable versions such as prereleases.
The `next` tag is used by some projects to identify the upcoming version.
Other than `latest`, no tag has any special significance to npm itself.
### Caveats
This command used to be known as `npm tag`, which only created new tags, and so had a different syntax.
Tags must share a namespace with version numbers, because they are specified in the same slot: `npm install <pkg>@<version>` vs `npm install <pkg>@<tag>`.
Tags that can be interpreted as valid semver ranges will be rejected.
For example, `v1.4` cannot be used as a tag, because it is interpreted by semver as `>=1.4.0 <1.5.0`.
See <https://github.com/npm/npm/issues/6082>.
The simplest way to avoid semver problems with tags is to use tags that do not begin with a number or the letter `v`.
### Configuration
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install` to
ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update, etc.)
will link workspaces into the `node_modules` folder. - Commands that do
other things (test, exec, publish, etc.) will operate on the root project,
_unless_ one or more workspaces are specified in the `workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace` config, or
all workspaces via the `workspaces` flag, will cause npm to operate only on
the specified workspaces, and not on the root project.
This value is not exported to the environment for child processes.
### See Also
* [package spec](/using-npm/package-spec)
* [npm publish](/commands/npm-publish)
* [npm install](/commands/npm-install)
* [npm dedupe](/commands/npm-dedupe)
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
@@ -0,0 +1,106 @@
---
title: npm-docs
section: 1
description: Open documentation for a package in a web browser
---
### Synopsis
```bash
npm docs [<pkgname> [<pkgname> ...]]
alias: home
```
### Description
This command tries to guess at the likely location of a package's documentation URL, and then tries to open it using the [`--browser` config](/using-npm/config#browser) param.
You can pass multiple package names at once.
If no package name is provided, it will search for a `package.json` in the current folder and use the `name` property.
### Configuration
#### `browser`
* Default: macOS: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: null, Boolean, or String
The browser that is called by npm commands to open websites.
Set to `false` to suppress browser behavior and instead print urls to
terminal.
Set to `true` to use default system URL opener.
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install` to
ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update, etc.)
will link workspaces into the `node_modules` folder. - Commands that do
other things (test, exec, publish, etc.) will operate on the root project,
_unless_ one or more workspaces are specified in the `workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace` config, or
all workspaces via the `workspaces` flag, will cause npm to operate only on
the specified workspaces, and not on the root project.
This value is not exported to the environment for child processes.
### See Also
* [npm view](/commands/npm-view)
* [npm publish](/commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)
@@ -0,0 +1,98 @@
---
title: npm-doctor
section: 1
description: Check the health of your npm environment
---
### Synopsis
```bash
npm doctor [connection] [registry] [versions] [environment] [permissions] [cache]
```
Note: This command is unaware of workspaces.
### Description
`npm doctor` runs a set of checks to ensure that your npm installation has what it needs to manage your JavaScript packages.
npm is mostly a standalone tool, but it does have some basic requirements that must be met:
+ Node.js and git must be executable by npm.
+ The primary npm registry, `registry.npmjs.com`, or another service that uses the registry API, is available.
+ The directories that npm uses, `node_modules` (both locally and globally), exist and can be written by the current user.
+ The npm cache exists, and the package tarballs within it aren't corrupt.
Without all of these working properly, npm may not work properly.
Many issues are often attributable to things that are outside npm's code base, so `npm doctor` confirms that the npm installation is in a good state.
Also, in addition to this, there are also very many issue reports due to using old versions of npm.
Since npm is constantly improving, running `npm@latest` is better than an old version.
`npm doctor` verifies the following items in your environment, and if there are any recommended changes, it will display them.
By default npm runs all of these checks.
You can limit what checks are ran by specifying them as extra arguments.
#### `Connecting to the registry`
By default, npm installs from the primary npm registry,
`registry.npmjs.org`.
`npm doctor` hits a special connection testing endpoint within the registry.
This can also be checked with `npm ping`.
If this check fails, you may be using a proxy that needs to be configured, or may need to talk to your IT staff to get access over HTTPS to `registry.npmjs.org`.
This check is done against whichever registry you've configured (you can see what that is by running `npm config get registry`), and if you're using a private registry that doesn't support the `/whoami` endpoint supported by the primary registry, this check may fail.
#### `Checking npm version`
While Node.js may come bundled with a particular version of npm, it's the policy of the CLI team that we recommend all users run `npm@latest` if they can.
As the CLI is maintained by a small team of contributors, there are only resources for a single line of development, so npm's own long-term support releases typically only receive critical security and regression fixes.
The team believes that the latest tested version of npm is almost always likely to be the most functional and defect-free version of npm.
#### `Checking node version`
For most users, in most circumstances, the best version of Node will be the latest long-term support (LTS) release.
Those of you who want access to new ECMAscript features or bleeding-edge changes to Node's standard library may be running a newer version, and some may be required to run an older version of Node because of enterprise change control policies.
That's OK!
But in general, the npm team recommends that most users run Node.js LTS.
#### `Checking configured npm registry`
You may be installing from private package registries for your project or company.
That's great! Others may be following tutorials or StackOverflow questions in an effort to troubleshoot problems you may be having.
Sometimes, this may entail changing the registry you're pointing at.
This part of `npm doctor` just lets you, and maybe whoever's helping you with support, know that you're not using the default registry.
#### `Checking for git executable in PATH`
While it's documented in the README, it may not be obvious that npm needs Git installed to do many of the things that it does.
Also, in some cases – especially on Windows – you may have Git set up in such a way that it's not accessible via your `PATH` so that npm can find it.
This check ensures that Git is available.
#### Permissions checks
* Your cache must be readable and writable by the user running npm.
* Global package binaries must be writable by the user running npm.
* Your local `node_modules` path, if you're running `npm doctor` with a project directory, must be readable and writable by the user running npm.
#### Validate the checksums of cached packages
When an npm package is published, the publishing process generates a checksum that npm uses at install time to verify that the package didn't get corrupted in transit.
`npm doctor` uses these checksums to validate the package tarballs in your local cache (you can see where that cache is located with `npm config get cache`).
In the event that there are corrupt packages in your cache, you should probably run `npm cache clean -f` and reset the cache.
### Configuration
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
### See Also
* [npm bugs](/commands/npm-bugs)
* [npm help](/commands/npm-help)
* [npm ping](/commands/npm-ping)
@@ -0,0 +1,41 @@
---
title: npm-edit
section: 1
description: Edit an installed package
---
### Synopsis
```bash
npm edit <pkg>[/<subpkg>...]
```
Note: This command is unaware of workspaces.
### Description
Selects a dependency in the current project and opens the package folder in the default editor (or whatever you've configured as the npm `editor` config -- see [`npm-config`](npm-config).)
After it has been edited, the package is rebuilt so as to pick up any changes in compiled packages.
For instance, you can do `npm install connect` to install connect into your package, and then `npm edit connect` to make a few changes to your locally installed copy.
### Configuration
#### `editor`
* Default: The EDITOR or VISUAL environment variables, or
'%SYSTEMROOT%\notepad.exe' on Windows, or 'vi' on Unix systems
* Type: String
The command to run for `npm edit` and `npm config edit`.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm explore](/commands/npm-explore)
* [npm install](/commands/npm-install)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
@@ -0,0 +1,364 @@
---
title: npm-exec
section: 1
description: Run a command from a local or remote npm package
---
### Synopsis
```bash
npm exec -- <pkg>[@<version>] [args...]
npm exec --package=<pkg>[@<version>] -- <cmd> [args...]
npm exec -c '<cmd> [args...]'
npm exec --package=foo -c '<cmd> [args...]'
alias: x
```
### Description
This command allows you to run an arbitrary command from an npm package (either one installed locally, or fetched remotely), in a similar context as running it via `npm run`.
Run without positional arguments or `--call`, this allows you to interactively run commands in the same sort of shell environment that `package.json` scripts are run.
Interactive mode is not supported in CI environments when standard input is a TTY, to prevent hangs.
Whatever packages are specified by the `--package` option will be provided in the `PATH` of the executed command, along with any locally installed package executables.
The `--package` option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available.
If any requested packages are not present in the local project dependencies, then a prompt is printed, which can be suppressed by providing either `--yes` or `--no`.
When standard input is not a TTY or a CI environment is detected, `--yes` is assumed.
The requested packages are installed to a folder in the npm cache, which is added to the `PATH` environment variable in the executed process.
Package names provided without a specifier will be matched with whatever version exists in the local project.
Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency.
If no `-c` or `--call` option is provided, then the positional arguments are used to generate the command string.
If no `--package` options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic:
- If the package has a single entry in its `bin` field in `package.json`, or if all entries are aliases of the same command, then that command will be used.
- If the package has multiple `bin` entries, and one of them matches the unscoped portion of the `name` field, then that command will be used.
- If this does not result in exactly one option (either because there are no bin entries, or none of them match the `name` of the package), then `npm exec` exits with an error.
To run a binary _other than_ the named binary, specify one or more `--package` options, which will prevent npm from inferring the package from the first command argument.
### `npx` vs `npm exec`
When run via the `npx` binary, all flags and options *must* be set prior to any positional arguments.
When run via `npm exec`, a double-hyphen `--` flag can be used to suppress npm's parsing of switches and options that should be sent to the executed command.
For example:
```
$ npx foo@latest bar --package=@npmcli/foo
```
In this case, npm will resolve the `foo` package name, and run the following command:
```
$ foo bar --package=@npmcli/foo
```
Since the `--package` option comes _after_ the positional arguments, it is treated as an argument to the executed command.
In contrast, due to npm's argument parsing logic, running this command is different:
```
$ npm exec foo@latest bar --package=@npmcli/foo
```
In this case, npm will parse the `--package` option first, resolving the `@npmcli/foo` package.
Then, it will execute the following command in that context:
```
$ foo@latest bar
```
The double-hyphen character is recommended to explicitly tell npm to stop parsing command line options and switches.
The following command would thus be equivalent to the `npx` command above:
```
$ npm exec -- foo@latest bar --package=@npmcli/foo
```
### Configuration
#### `package`
* Default:
* Type: String (can be set multiple times)
The package or packages to install for [`npm exec`](/commands/npm-exec)
#### `call`
* Default: ""
* Type: String
Optional companion option for `npm exec`, `npx` that allows for specifying a
custom command to be run along with the installed packages.
```bash
npm exec --package yo --package generator-node --call "yo node"
```
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install` to
ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update, etc.)
will link workspaces into the `node_modules` folder. - Commands that do
other things (test, exec, publish, etc.) will operate on the root project,
_unless_ one or more workspaces are specified in the `workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace` config, or
all workspaces via the `workspaces` flag, will cause npm to operate only on
the specified workspaces, and not on the root project.
This value is not exported to the environment for child processes.
#### `allow-scripts`
* Default: ""
* Type: String (can be set multiple times)
Comma-separated list of packages whose install-time lifecycle scripts
(`preinstall`, `install`, `postinstall`, and `prepare` for non-registry
dependencies) are allowed to run.
This setting is intended for one-off and global contexts: `npm exec`, `npx`,
and `npm install -g`, where no project `package.json` is involved. For
team-wide policy in a project, use the `allowScripts` field in
`package.json` (which also supports explicit denials), or configure it in
`.npmrc`. Passing `--allow-scripts` on the command line during a
project-scoped `npm install`, `ci`, `update`, or `rebuild` is an error.
Each name is matched against a dependency's resolved identity, not against
the package's self-reported name. `--ignore-scripts` and
`--dangerously-allow-all-scripts` both override this setting.
#### `strict-allow-scripts`
* Default: false
* Type: Boolean
If `true`, turn the install-script policy from a warning into a hard error:
any dependency with install scripts not covered by `allowScripts` will fail
the install instead of running with a notice.
Dependencies explicitly denied with `false` in `allowScripts` are always
silently skipped; this setting only affects unreviewed entries.
`--ignore-scripts` and `--dangerously-allow-all-scripts` both override this
setting.
#### `dangerously-allow-all-scripts`
* Default: false
* Type: Boolean
If `true`, bypass the `allowScripts` policy entirely and run every
dependency install script regardless of whether it was approved or denied.
Intended as a migration escape hatch only; its use is strongly discouraged.
`--ignore-scripts` still takes precedence over this setting.
### Examples
Run the version of `tap` in the local dependencies, with the provided arguments:
```
$ npm exec -- tap --bail test/foo.js
$ npx tap --bail test/foo.js
```
Run a command _other than_ the command whose name matches the package name by specifying a `--package` option:
```
$ npm exec --package=foo -- bar --bar-argument
# ~ or ~
$ npx --package=foo bar --bar-argument
```
Run an arbitrary shell script, in the context of the current project:
```
$ npm x -c 'eslint && say "hooray, lint passed"'
$ npx -c 'eslint && say "hooray, lint passed"'
```
### Workspaces support
You may use the [`workspace`](/using-npm/config#workspace) or [`workspaces`](/using-npm/config#workspaces) configs in order to run an arbitrary command from an npm package (either one installed locally, or fetched remotely) in the context of the specified workspaces.
If no positional argument or `--call` option is provided, it will open an interactive subshell in the context of each of these configured workspaces one at a time.
Given a project with configured workspaces, e.g:
```
.
+-- package.json
`-- packages
+-- a
| `-- package.json
+-- b
| `-- package.json
`-- c
`-- package.json
```
Assuming the workspace configuration is properly set up at the root level `package.json` file.
e.g:
```
{
"workspaces": [ "./packages/*" ]
}
```
You can execute an arbitrary command from a package in the context of each of the configured workspaces when using the [`workspaces` config options](/using-npm/config#workspace), in this example we're using **eslint** to lint any js file found within each workspace folder:
```
npm exec --ws -- eslint ./*.js
```
#### Filtering workspaces
It's also possible to execute a command in a single workspace using the `workspace` config along with a name or directory path:
```
npm exec --workspace=a -- eslint ./*.js
```
The `workspace` config can also be specified multiple times in order to run a specific script in the context of multiple workspaces.
When defining values for the `workspace` config in the command line, it also possible to use `-w` as a shorthand, e.g:
```
npm exec -w a -w b -- eslint ./*.js
```
This last command will run the `eslint` command in both `./packages/a` and
`./packages/b` folders.
### Compatibility with Older npx Versions
The `npx` binary was rewritten in npm v7.0.0, and the standalone `npx` package deprecated at that time.
`npx` uses the `npm exec` command instead of a separate argument parser and install process, with some affordances to maintain backwards compatibility with the arguments it accepted in previous versions.
This resulted in some shifts in its functionality:
- Any `npm` config value may be provided.
- To prevent security and user-experience problems from mistyping package
names, `npx` prompts before installing anything.
Suppress this prompt with the `-y` or `--yes` option.
- The `--no-install` option is deprecated, and will be converted to `--no`.
- Shell fallback functionality is removed, as it is not advisable.
- The `-p` argument is a shorthand for `--parseable` in npm, but shorthand for `--package` in npx.
This is maintained, but only for the `npx` executable.
- The `--ignore-existing` option is removed.
Locally installed bins are always present in the executed process `PATH`.
- The `--npm` option is removed.
`npx` will always use the `npm` it ships with.
- The `--node-arg` and `-n` options are removed.
- The `--always-spawn` option is redundant, and thus removed.
- The `--shell` option is replaced with `--script-shell`, but maintained in the `npx` executable for backwards compatibility.
### A note on caching
The npm cli utilizes its internal package cache when using the package name specified.
You can use the following to change how and when the cli uses this cache.
See [`npm cache`](/commands/npm-cache) for more on how the cache works.
#### prefer-online
Forces staleness checks for packages, making the cli look for updates immediately even if the package is already in the cache.
#### prefer-offline
Bypasses staleness checks for packages.
Missing data will still be requested from the server.
To force full offline mode, use `offline`.
#### offline
Forces full offline mode.
Any packages not locally cached will result in an error.
#### workspace
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result to selecting all of the nested workspaces)
This value is not exported to the environment for child processes.
#### workspaces
* Alias: `--ws`
* Type: Boolean
* Default: `false`
Run scripts in the context of all configured workspaces for the current project.
### See Also
* [npm run](/commands/npm-run)
* [npm scripts](/using-npm/scripts)
* [npm test](/commands/npm-test)
* [npm start](/commands/npm-start)
* [npm restart](/commands/npm-restart)
* [npm stop](/commands/npm-stop)
* [npm config](/commands/npm-config)
* [npm workspaces](/using-npm/workspaces)
* [npx](/commands/npx)
@@ -0,0 +1,101 @@
---
title: npm-explain
section: 1
description: Explain installed packages
---
### Synopsis
```bash
npm explain <package-spec>
alias: why
```
### Description
This command will print the chain of dependencies causing a given package to be installed in the current project.
If one or more package specs are provided, then only packages matching one of the specifiers will have their relationships explained.
The package spec can also refer to a folder within `./node_modules`
For example, running `npm explain glob` within npm's source tree will show:
```bash
glob@7.1.6
node_modules/glob
glob@"^7.1.4" from the root project
glob@7.1.1 dev
node_modules/tacks/node_modules/glob
glob@"^7.0.5" from rimraf@2.6.2
node_modules/tacks/node_modules/rimraf
rimraf@"^2.6.2" from tacks@1.3.0
node_modules/tacks
dev tacks@"^1.3.0" from the root project
```
To explain just the package residing at a specific folder, pass that as the argument to the command.
This can be useful when trying to figure out exactly why a given dependency is being duplicated to satisfy conflicting version requirements within the project.
```bash
$ npm explain node_modules/nyc/node_modules/find-up
find-up@3.0.0 dev
node_modules/nyc/node_modules/find-up
find-up@"^3.0.0" from nyc@14.1.1
node_modules/nyc
nyc@"^14.1.1" from tap@14.10.8
node_modules/tap
dev tap@"^14.10.8" from the root project
```
### Configuration
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse() before
saving them to your `package.json`.
Not supported by all npm commands.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
### See Also
* [package spec](/using-npm/package-spec)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm folders](/configuring-npm/folders)
* [npm ls](/commands/npm-ls)
* [npm install](/commands/npm-install)
* [npm link](/commands/npm-link)
* [npm prune](/commands/npm-prune)
* [npm outdated](/commands/npm-outdated)
* [npm update](/commands/npm-update)
@@ -0,0 +1,46 @@
---
title: npm-explore
section: 1
description: Browse an installed package
---
### Synopsis
```bash
npm explore <pkg> [ -- <command>]
```
Note: This command is unaware of workspaces.
### Description
Spawn a subshell in the directory of the installed package specified.
If a command is specified, then it is run in the subshell, which then immediately terminates.
This is particularly handy in the case of git submodules in the `node_modules` folder:
```bash
npm explore some-dependency -- git pull origin master
```
Note that the package is *not* automatically rebuilt afterwards, so be sure to use `npm rebuild <pkg>` if you make any changes.
### Configuration
#### `shell`
* Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" on
Windows
* Type: String
The shell to run for the `npm explore` command.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm edit](/commands/npm-edit)
* [npm rebuild](/commands/npm-rebuild)
* [npm install](/commands/npm-install)
@@ -0,0 +1,245 @@
---
title: npm-find-dupes
section: 1
description: Find duplication in the package tree
---
### Synopsis
```bash
npm find-dupes
```
### Description
Runs `npm dedupe` in `--dry-run` mode, making npm only output the duplications, without actually changing the package tree.
### Configuration
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as necessary
within directory structure. nested: (formerly --legacy-bundling) install in
place, no hoisting. shallow (formerly --global-style) only install direct
deps at top-level. linked: (experimental) install in node_modules/.store,
link in place, unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install packages in
the same manner that they are depended on. This may cause very deep
directory structures and duplicate package installs as there is no
de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but hoist
on deeper dependencies. Sets `--install-strategy=shallow`.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure, even
if npm could reasonably guess the appropriate resolution based on non-peer
dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency graph will
be resolved using the nearest non-peer dependency specification, even if
doing so will result in some packages receiving a peer dependency outside
the range set in their package's `peerDependencies` object.
When such an override is performed, a warning is printed, explaining the
conflict and the packages involved. If `--strict-peer-deps` is set, then
this warning is treated as a failure.
#### `package-lock`
* Default: true
* Type: Boolean
If set to false, then ignore `package-lock.json` files when installing. This
will also prevent _writing_ `package-lock.json` if `save` is true.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists, then
it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment
variable will be set to `'production'` for all lifecycle scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
Option that allows for defining which types of dependencies to install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted, regardless of
the order in which omit/include are specified on the command-line.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script, such as
`npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run` will still
run their intended script if `ignore-scripts` is set, but they will *not*
run any pre- or post-scripts.
#### `audit`
* Default: true
* Type: Boolean
When "true" submit audit reports alongside the current npm command to the
default registry and all registries configured for scopes. See the
documentation for [`npm audit`](/commands/npm-audit) for details on what is
submitted.
#### `bin-links`
* Default: true
* Type: Boolean
Tells npm to create symlinks (or `.cmd` shims on Windows) for package
executables.
Set to false to have it not do this. This can be used to work around the
fact that some file systems don't support symlinks, even on ostensibly Unix
systems.
#### `fund`
* Default: true
* Type: Boolean
When "true" displays the message at the end of each `npm install`
acknowledging the number of dependencies looking for funding. See [`npm
fund`](/commands/npm-fund) for details.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install` to
ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update, etc.)
will link workspaces into the `node_modules` folder. - Commands that do
other things (test, exec, publish, etc.) will operate on the root project,
_unless_ one or more workspaces are specified in the `workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace` config, or
all workspaces via the `workspaces` flag, will cause npm to operate only on
the specified workspaces, and not on the root project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as regular
dependencies instead of creating a symlink. This option has no effect on
workspaces.
### See Also
* [npm dedupe](/commands/npm-dedupe)
* [npm ls](/commands/npm-ls)
* [npm update](/commands/npm-update)
* [npm install](/commands/npm-install)
@@ -0,0 +1,136 @@
---
title: npm-fund
section: 1
description: Retrieve funding information
---
### Synopsis
```bash
npm fund [<package-spec>]
```
### Description
This command retrieves information on how to fund the dependencies of a given project.
If no package name is provided, it will list all dependencies that are looking for funding in a tree structure, listing the type of funding and the url to visit.
If a package name is provided then it tries to open its funding url using the [`--browser` config](/using-npm/config#browser) param; if there are multiple funding sources for the package, the user will be instructed to pass the
`--which` option to disambiguate.
The list will avoid duplicated entries and will stack all packages that share the same url as a single entry.
Thus, the list does not have the same shape of the output from `npm ls`.
#### Example
### Workspaces support
It's possible to filter the results to only include a single workspace and its dependencies using the [`workspace` config](/using-npm/config#workspace) option.
#### Example:
Here's an example running `npm fund` in a project with a configured workspace `a`:
```bash
$ npm fund
test-workspaces-fund@1.0.0
+-- https://example.com/a
| | `-- a@1.0.0
| `-- https://example.com/maintainer
| `-- foo@1.0.0
+-- https://example.com/npmcli-funding
| `-- @npmcli/test-funding
`-- https://example.com/org
`-- bar@2.0.0
```
And here is an example of the expected result when filtering only by a specific workspace `a` in the same project:
```bash
$ npm fund -w a
test-workspaces-fund@1.0.0
`-- https://example.com/a
| `-- a@1.0.0
`-- https://example.com/maintainer
`-- foo@2.0.0
```
### Configuration
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse() before
saving them to your `package.json`.
Not supported by all npm commands.
#### `browser`
* Default: macOS: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: null, Boolean, or String
The browser that is called by npm commands to open websites.
Set to `false` to suppress browser behavior and instead print urls to
terminal.
Set to `true` to use default system URL opener.
#### `unicode`
* Default: false on windows, true on mac/unix systems with a unicode locale,
as defined by the `LC_ALL`, `LC_CTYPE`, or `LANG` environment variables.
* Type: Boolean
When set to true, npm uses unicode characters in the tree output. When
false, it uses ascii characters instead of unicode glyphs.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the
current project while filtering by running only the workspaces defined by
this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of a
workspace which does not yet exist, to create the folder and set it up as a
brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `which`
* Default: null
* Type: null or Number
If there are multiple funding sources, which 1-indexed source URL to open.
## See Also
* [package spec](/using-npm/package-spec)
* [npm install](/commands/npm-install)
* [npm docs](/commands/npm-docs)
* [npm ls](/commands/npm-ls)
* [npm config](/commands/npm-config)
* [npm workspaces](/using-npm/workspaces)
@@ -0,0 +1,32 @@
---
title: npm-get
section: 1
description: Get a value from the npm configuration
---
### Synopsis
```bash
npm get [<key> ...] (See `npm config`)
```
Note: This command is unaware of workspaces.
### Description
Get a value from the npm configuration
### Configuration
#### `long`
* Default: false
* Type: Boolean
Show extended information in `ls`, `search`, and `help-search`.
### See Also
* [npm help config](/commands/npm-config)
Loaded 100 of 2001 files, more files were not shown because too many files have changed in this diff. Show more