LiteLDev/node-binaries
5
0
Fork 0
Code Releases Activity

v22.12.0

Browse Source
This commit is contained in:
ShrBox 2025-01-07 23:51:36 +08:00
parent aacd55450c
commit beaede4a31
Signed by: ShrBox
GPG Key ID: E926367CC922FD88
3983 changed files with 329719 additions and 17078 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
node/libnode.dll
View File

Binary file not shown.

2255
node/node_modules/.package-lock.json generated vendored
View File

File diff suppressed because it is too large Load Diff

460
node/node_modules/corepack/CHANGELOG.md generated vendored Normal file
View File

@ -0,0 +1,460 @@
# Changelog
## [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@>=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
node/node_modules/corepack/LICENSE.md generated vendored Normal file
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.

321
node/node_modules/corepack/README.md generated vendored Normal file
View File

@ -0,0 +1,321 @@
# <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 by default with all recent Node.js versions](https://nodejs.org/api/corepack.html).
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>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"
}
```
## 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
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 `0` to prevent Corepack from
updating 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`.
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_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-proxy-agent`](https://github.com/TooTallNate/node-proxy-agent).
- `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
### 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).

3
node/node_modules/corepack/dist/corepack.js generated vendored Normal file
View File

@ -0,0 +1,3 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='0';
require('./lib/corepack.cjs').runMain(process.argv.slice(2));

BIN
node/node_modules/corepack/dist/lib/corepack.cjs generated vendored Normal file
View File

Binary file not shown.

3
node/node_modules/corepack/dist/npm.js generated vendored Normal file
View File

@ -0,0 +1,3 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('./lib/corepack.cjs').runMain(['npm', ...process.argv.slice(2)]);

3
node/node_modules/corepack/dist/npx.js generated vendored Normal file
View File

@ -0,0 +1,3 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('./lib/corepack.cjs').runMain(['npx', ...process.argv.slice(2)]);

3
node/node_modules/corepack/dist/pnpm.js generated vendored Normal file
View File

@ -0,0 +1,3 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('./lib/corepack.cjs').runMain(['pnpm', ...process.argv.slice(2)]);

3
node/node_modules/corepack/dist/pnpx.js generated vendored Normal file
View File

@ -0,0 +1,3 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('./lib/corepack.cjs').runMain(['pnpx', ...process.argv.slice(2)]);

3
node/node_modules/corepack/dist/yarn.js generated vendored Normal file
View File

@ -0,0 +1,3 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('./lib/corepack.cjs').runMain(['yarn', ...process.argv.slice(2)]);

3
node/node_modules/corepack/dist/yarnpkg.js generated vendored Normal file
View File

@ -0,0 +1,3 @@
#!/usr/bin/env node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='1'
require('./lib/corepack.cjs').runMain(['yarnpkg', ...process.argv.slice(2)]);

102
node/node_modules/corepack/package.json generated vendored Normal file
View File

@ -0,0 +1,102 @@
{
"name": "corepack",
"version": "0.29.4",
"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": "^18.17.1 || >=20.10.0"
},
"exports": {
"./package.json": "./package.json"
},
"license": "MIT",
"packageManager": "yarn@4.3.1+sha224.934d21773e22af4b69a7032a2d3b4cb38c1f7c019624777cc9916b23",
"devDependencies": {
"@types/debug": "^4.1.5",
"@types/node": "^20.4.6",
"@types/proxy-from-env": "^1",
"@types/semver": "^7.1.0",
"@types/which": "^3.0.0",
"@yarnpkg/eslint-config": "^2.0.0",
"@yarnpkg/fslib": "^3.0.0-rc.48",
"@zkochan/cmd-shim": "^6.0.0",
"better-sqlite3": "^10.0.0",
"clipanion": "patch:clipanion@npm%3A3.2.1#~/.yarn/patches/clipanion-npm-3.2.1-fc9187f56c.patch",
"debug": "^4.1.1",
"esbuild": "^0.21.0",
"eslint": "^8.57.0",
"proxy-from-env": "^1.1.0",
"semver": "^7.6.3",
"supports-color": "^9.0.0",
"tar": "^7.4.0",
"tsx": "^4.16.2",
"typescript": "^5.3.3",
"undici": "^6.19.2",
"v8-compile-cache": "^2.3.0",
"vitest": "^2.0.3",
"which": "^4.0.0"
},
"resolutions": {
"undici-types": "6.x"
},
"scripts": {
"build": "run clean && run build:bundle && tsx ./mkshims.ts",
"build:bundle": "esbuild ./sources/_lib.ts --bundle --platform=node --target=node18.17.0 --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
node/node_modules/corepack/shims/corepack generated vendored Normal file
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

7
node/node_modules/corepack/shims/corepack.cmd generated vendored Normal file
View File

@ -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
node/node_modules/corepack/shims/corepack.ps1 generated vendored Normal file
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

12
node/node_modules/corepack/shims/nodewin/corepack generated vendored Normal file
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

7
node/node_modules/corepack/shims/nodewin/corepack.cmd generated vendored Normal file
View File

@ -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" %*
)

28
node/node_modules/corepack/shims/nodewin/corepack.ps1 generated vendored Normal file
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/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
node/node_modules/corepack/shims/nodewin/npm generated vendored Normal file
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

7
node/node_modules/corepack/shims/nodewin/npm.cmd generated vendored Normal file
View File

@ -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" %*
)

28
node/node_modules/corepack/shims/nodewin/npm.ps1 generated vendored Normal file
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/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
node/node_modules/corepack/shims/nodewin/npx generated vendored Normal file
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

7
node/node_modules/corepack/shims/nodewin/npx.cmd generated vendored Normal file
View File

@ -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" %*
)

28
node/node_modules/corepack/shims/nodewin/npx.ps1 generated vendored Normal file
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/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
node/node_modules/corepack/shims/nodewin/pnpm generated vendored Normal file
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

7
node/node_modules/corepack/shims/nodewin/pnpm.cmd generated vendored Normal file
View File

@ -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" %*
)

28
node/node_modules/corepack/shims/nodewin/pnpm.ps1 generated vendored Normal file
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/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
node/node_modules/corepack/shims/nodewin/pnpx generated vendored Normal file
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

7
node/node_modules/corepack/shims/nodewin/pnpx.cmd generated vendored Normal file
View File

@ -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" %*
)

28
node/node_modules/corepack/shims/nodewin/pnpx.ps1 generated vendored Normal file
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/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
node/node_modules/corepack/shims/nodewin/yarn generated vendored Normal file
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

7
node/node_modules/corepack/shims/nodewin/yarn.cmd generated vendored Normal file
View File

@ -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" %*
)

28
node/node_modules/corepack/shims/nodewin/yarn.ps1 generated vendored Normal file
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/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

12
node/node_modules/corepack/shims/nodewin/yarnpkg generated vendored Normal file
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/yarnpkg.js" "$@"
else
exec node "$basedir/node_modules/corepack/dist/yarnpkg.js" "$@"
fi

7
node/node_modules/corepack/shims/nodewin/yarnpkg.cmd generated vendored Normal file
View File

@ -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" %*
)

28
node/node_modules/corepack/shims/nodewin/yarnpkg.ps1 generated vendored Normal file
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/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
node/node_modules/corepack/shims/npm generated vendored Normal file
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
node/node_modules/corepack/shims/npm.cmd generated vendored Normal file
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
node/node_modules/corepack/shims/npm.ps1 generated vendored Normal file
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
node/node_modules/corepack/shims/npx generated vendored Normal file
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
node/node_modules/corepack/shims/npx.cmd generated vendored Normal file
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
node/node_modules/corepack/shims/npx.ps1 generated vendored Normal file
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
node/node_modules/corepack/shims/pnpm generated vendored Normal file
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
node/node_modules/corepack/shims/pnpm.cmd generated vendored Normal file
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
node/node_modules/corepack/shims/pnpm.ps1 generated vendored Normal file
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
node/node_modules/corepack/shims/pnpx generated vendored Normal file
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
node/node_modules/corepack/shims/pnpx.cmd generated vendored Normal file
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
node/node_modules/corepack/shims/pnpx.ps1 generated vendored Normal file
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
node/node_modules/corepack/shims/yarn generated vendored Normal file
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
node/node_modules/corepack/shims/yarn.cmd generated vendored Normal file
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
node/node_modules/corepack/shims/yarn.ps1 generated vendored Normal file
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
node/node_modules/corepack/shims/yarnpkg generated vendored Normal file
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
node/node_modules/corepack/shims/yarnpkg.cmd generated vendored Normal file
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
node/node_modules/corepack/shims/yarnpkg.ps1 generated vendored Normal file
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

6
node/node_modules/.bin/npm → node/node_modules/npm-js-interface/node_modules/.bin/npm generated vendored
View File

@ -2,7 +2,11 @@
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*|*MINGW*|*MSYS*) basedir=`cygpath -w "$basedir"`;;
*CYGWIN*|*MINGW*|*MSYS*)
if command -v cygpath > /dev/null 2>&1; then
basedir=`cygpath -w "$basedir"`
fi
;;
esac
if [ -x "$basedir/node" ]; then

0
node/node_modules/.bin/npm.cmd → node/node_modules/npm-js-interface/node_modules/.bin/npm.cmd generated vendored
View File

0
node/node_modules/.bin/npm.ps1 → node/node_modules/npm-js-interface/node_modules/.bin/npm.ps1 generated vendored
View File

6
node/node_modules/.bin/npx → node/node_modules/npm-js-interface/node_modules/.bin/npx generated vendored
View File

@ -2,7 +2,11 @@
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*|*MINGW*|*MSYS*) basedir=`cygpath -w "$basedir"`;;
*CYGWIN*|*MINGW*|*MSYS*)
if command -v cygpath > /dev/null 2>&1; then
basedir=`cygpath -w "$basedir"`
fi
;;
esac
if [ -x "$basedir/node" ]; then

0
node/node_modules/.bin/npx.cmd → node/node_modules/npm-js-interface/node_modules/.bin/npx.cmd generated vendored
View File

0
node/node_modules/.bin/npx.ps1 → node/node_modules/npm-js-interface/node_modules/.bin/npx.ps1 generated vendored
View File

235
node/node_modules/npm-js-interface/node_modules/npm/LICENSE generated vendored Normal file
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.
--------

74
node/node_modules/npm-js-interface/node_modules/npm/README.md generated vendored Normal file
View File

@ -0,0 +1,74 @@
# npm - a JavaScript package manager
[![npm version](https://img.shields.io/npm/v/npm.svg)](https://npm.im/npm)
[![license](https://img.shields.io/npm/l/npm.svg)](https://npm.im/npm)
[![CI - cli](https://github.com/npm/cli/actions/workflows/ci.yml/badge.svg)](https://github.com/npm/cli/actions/workflows/ci.yml)
[![Benchmark Suite](https://github.com/npm/cli/actions/workflows/benchmark.yml/badge.svg)](https://github.com/npm/cli/actions/workflows/benchmark.yml)
### Requirements
One of the following versions of [Node.js](https://nodejs.org/en/download/) must be installed to run **`npm`**:
* `12.x.x` >= `12.13.0`
* `14.x.x` >= `14.15.0`
* `16.0.0` or higher
### 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`** &/or **`npm`**, consider using a "Node Version Manager" such as:
* [**`nvm`**](https://github.com/nvm-sh/nvm)
* [**`nvs`**](https://github.com/jasongin/nvs)
* [**`nave`**](https://github.com/isaacs/nave)
* [**`n`**](https://github.com/tj/n)
* [**`volta`**](https://github.com/volta-cli/volta)
* [**`nodenv`**](https://github.com/nodenv/nodenv)
* [**`asdf-nodejs`**](https://github.com/asdf-vm/asdf-nodejs)
* [**`nvm-windows`**](https://github.com/coreybutler/nvm-windows)
* [**`fnm`**](https://github.com/Schniz/fnm)
### 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
* [**Roadmap**](https://github.com/orgs/github/projects/4247/views/1?filterQuery=npm) - Track & follow along with our public roadmap
* [**Feedback**](https://github.com/npm/feedback) - 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
* [**Events Calendar**](https://calendar.google.com/calendar/u/0/embed?src=npmjs.com_oonluqt8oftrt0vmgrfbg6q6go@group.calendar.google.com) - Keep track of our Open RFC calls, releases, meetups, conferences & more
* [**Support**](https://www.npmjs.com/support) - Experiencing problems with the **npm** [website](https://npmjs.com) or [registry](https://registry.npmjs.org)? File a ticket [here](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 [here](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** in fact an acronym for "Node Package Manager"; It is a recursive bacronymic abbreviation for **"npm is not an acronym"** (if the project was 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 to ever have been considered an acronym, it would be as "node pm" or, potentially "new pm".

6
node/node_modules/npm-js-interface/node_modules/npm/bin/node-gyp-bin/node-gyp generated vendored Normal file
View File

@ -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

5
node/node_modules/npm-js-interface/node_modules/npm/bin/node-gyp-bin/node-gyp.cmd generated vendored Normal file
View File

@ -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%" %*
)

44
node/node_modules/npm-js-interface/node_modules/npm/bin/npm generated vendored Normal file
View File

@ -0,0 +1,44 @@
#!/usr/bin/env bash
(set -o igncr) 2>/dev/null && set -o igncr; # cygwin encoding fix
basedir=`dirname "$0"`
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
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)')"
NPM_CLI_JS="$CLI_BASEDIR/node_modules/npm/bin/npm-cli.js"
NPM_PREFIX=`"$NODE_EXE" "$NPM_CLI_JS" prefix -g`
if [ $? -ne 0 ]; then
# if this didn't work, then everything else below will fail
echo "Could not determine Node.js install directory" >&2
exit 1
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 [ `uname` = 'Linux' ] && type wslpath &>/dev/null ; 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" "$@"

BIN
node/node_modules/npm-js-interface/node_modules/npm/bin/npm-cli.js generated vendored Normal file
View File

Binary file not shown.

19
node/node_modules/npm-js-interface/node_modules/npm/bin/npm.cmd generated vendored Normal file
View File

@ -0,0 +1,19 @@
:: 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_CLI_JS=%~dp0\node_modules\npm\bin\npm-cli.js"
FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPM_CLI_JS%" prefix -g') 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%" %*

48
node/node_modules/npm-js-interface/node_modules/npm/bin/npx generated vendored Normal file
View File

@ -0,0 +1,48 @@
#!/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
NODE_EXE="$basedir/node.exe"
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE="$basedir/node"
fi
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE=node
fi
# these paths are passed to node.exe, so they need 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)')"
if [ $? -ne 0 ]; then
# if this didn't work, then everything else below will fail
echo "Could not determine Node.js install directory" >&2
exit 1
fi
NPM_CLI_JS="$CLI_BASEDIR/node_modules/npm/bin/npm-cli.js"
NPX_CLI_JS="$CLI_BASEDIR/node_modules/npm/bin/npx-cli.js"
NPM_PREFIX=`"$NODE_EXE" "$NPM_CLI_JS" prefix -g`
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 [ `uname` = 'Linux' ] && type wslpath &>/dev/null ; 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" "$@"

128
node/node_modules/npm-js-interface/node_modules/npm/bin/npx-cli.js generated vendored Normal file
View File

@ -0,0 +1,128 @@
#!/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('../lib/utils/config/index.js')
const npmSwitches = Object.entries(definitions)
.filter(([key, { 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)) {
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) {
console.error('See `npm help exec` for more information')
}
cli(process)

20
node/node_modules/npm-js-interface/node_modules/npm/bin/npx.cmd generated vendored Normal file
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_CLI_JS=%~dp0\node_modules\npm\bin\npm-cli.js"
SET "NPX_CLI_JS=%~dp0\node_modules\npm\bin\npx-cli.js"
FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPM_CLI_JS%" prefix -g') 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%" %*

106
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-access.md generated vendored Normal file
View File

@ -0,0 +1,106 @@
---
title: npm-access
section: 1
description: Set access level on published packages
---
### Synopsis
```bash
npm access public [<package>]
npm access restricted [<package>]
npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]
npm access 2fa-required [<package>]
npm access 2fa-not-required [<package>]
npm access ls-packages [<user>|<scope>|<scope:team>]
npm access ls-collaborators [<package> [<user>]]
npm access edit [<package>]
```
### 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.
* public / restricted (deprecated):
Set a package to be either publicly accessible or restricted.
* grant / revoke (deprecated):
Add or remove the ability of users and teams to have read-only or read-write
access to a package.
* 2fa-required / 2fa-not-required (deprecated):
Configure whether a package requires that anyone publishing it have two-factor
authentication enabled on their account.
* ls-packages (deprecated):
Show all of the packages a user or a team is able to access, along with the
access level, except for read-only public packages (it won't print the whole
registry listing)
* ls-collaborators (deprecated):
Show all of the access privileges for a package. Will only show permissions
for packages to which you have at least read access. If `<user>` is passed in,
the list is filtered only to teams _that_ user happens to belong to.
* edit (not implemented)
### 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 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 an otp token, 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
#### `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.
### 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)

93
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-adduser.md generated vendored Normal file
View File

@ -0,0 +1,93 @@
---
title: npm-adduser
section: 1
description: Add a registry user account
---
### Synopsis
```bash
npm adduser
aliases: login, add-user
```
Note: This command is unaware of workspaces.
### Description
Create or verify a user named `<username>` in the specified registry, and
save the credentials to the `.npmrc` file. If no registry is specified,
the default registry will be used (see [`config`](/using-npm/config)).
The username, password, and email are read in from prompts.
To reset your password, go to <https://www.npmjs.com/forgot>
To change your email address, go to <https://www.npmjs.com/email-edit>
You may use this command multiple times with the same user account to
authorize on a new machine. When authenticating on a new machine,
the username, password and email address must all match with
your existing record.
`npm login` is an alias to `adduser` and behaves exactly the same way.
### 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: "legacy"
* Type: "legacy", "web", "sso", "saml", "oauth", or "webauthn"
NOTE: auth-type values "sso", "saml", "oauth", and "webauthn" will be
removed in a future version.
What authentication strategy to use with `login`.
### 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)

421
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-audit.md generated vendored Normal file
View File

@ -0,0 +1,421 @@
---
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.
### 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 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 <a href="https://en.wikipedia.org/wiki/ISO_8601" target="_blank">ISO 8601 format</a>: `YYYY-MM-DDTHH:mm:ss.sssZ`
- `keydid`: 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 <a href="https://registry.npmjs.org/-/npm/v1/keys" target="_blank">example key's response from the public npm registry</a>.
### 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, 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` configuration setting.
### 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`.
#### `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.
#### `foreground-scripts`
* Default: false
* 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-script`
will still run their intended script if `ignore-scripts` is set, but they
will *not* run any pre- or post-scripts.
#### `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 that exist outside of the project root
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)

17
node/node_modules/npm/docs/content/commands/npm-bin.md → node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-bin.md generated vendored
View File

@ -6,19 +6,10 @@ description: Display npm bin folder
### Synopsis
<!-- AUTOGENERATED USAGE DESCRIPTIONS START -->
<!-- automatically generated, do not edit manually -->
<!-- see lib/commands/bin.js -->
```bash
npm bin
```
<!-- automatically generated, do not edit manually -->
<!-- see lib/commands/bin.js -->
<!-- AUTOGENERATED USAGE DESCRIPTIONS END -->
Note: This command is unaware of workspaces.
### Description
@ -27,9 +18,6 @@ Print the folder where npm will install executables.
### Configuration
<!-- AUTOGENERATED CONFIG DESCRIPTIONS START -->
<!-- automatically generated, do not edit manually -->
<!-- see lib/utils/config/definitions.js -->
#### `global`
* Default: false
@ -44,11 +32,6 @@ folder instead of the current working directory. See
* bin files are linked to `{prefix}/bin`
* man pages are linked to `{prefix}/share/man`
<!-- automatically generated, do not edit manually -->
<!-- see lib/utils/config/definitions.js -->
<!-- AUTOGENERATED CONFIG DESCRIPTIONS END -->
### See Also
* [npm prefix](/commands/npm-prefix)

104
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-bugs.md generated vendored Normal file
View File

@ -0,0 +1,104 @@
---
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 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: OS X: `"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)

93
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-cache.md generated vendored Normal file
View File

@ -0,0 +1,93 @@
---
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
```
Note: This command is unaware of workspaces.
### Description
Used to add, list, or clean the npm cache folder.
* 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 all data out of the cache folder. Note that this is typically
unnecessary, as npm's cache is self-healing and resistant to data
corruption issues.
* 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.
### 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 [`npm
cache`](/commands/npm-cache)
### 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)
* https://npm.im/cacache
* https://npm.im/pacote
* https://npm.im/@npmcli/arborist
* https://npm.im/make-fetch-happen

311
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-ci.md generated vendored Normal file
View File

@ -0,0 +1,311 @@
---
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
#### `save`
* Default: `true` unless when using `npm update` where it defaults to `false`
* Type: Boolean
Save installed packages to a `package.json` file as dependencies.
When used with the `npm rm` command, removes the dependency from
`package.json`.
Will also prevent writing to `package-lock.json` if set to `false`.
#### `save-exact`
* Default: false
* Type: Boolean
Dependencies saved to package.json will be configured with an exact version
rather than using npm's default semver range operator.
#### `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`
#### `global-style`
* Default: false
* Type: Boolean
Causes npm to install the package into your local `node_modules` folder with
the same layout it uses with the global `node_modules` folder. Only your
direct dependencies will show in `node_modules` and everything they depend
on will be flattened in their `node_modules` folders. This obviously will
eliminate some deduping. If used with `legacy-bundling`, `legacy-bundling`
will be preferred.
#### `legacy-bundling`
* Default: false
* Type: Boolean
Causes npm to install the package such that versions of npm prior to 1.4,
such as the one included with node 0.8, can install the package. This
eliminates all automatic deduping. If used with `global-style` this option
will be preferred.
#### `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.
#### `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 and 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.
This configuration does not affect `npm ci`.
#### `foreground-scripts`
* Default: false
* 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-script`
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.
#### `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 that exist outside of the project root
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)

41
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-completion.md generated vendored Normal file
View File

@ -0,0 +1,41 @@
---
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)

159
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-config.md generated vendored Normal file
View File

@ -0,0 +1,159 @@
---
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
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(7)](/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.
If value is omitted, then it sets it to an empty string.
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.
### 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 'notepad.exe' on
Windows, or 'vim' 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)
* [package.json](/configuring-npm/package-json)
* [npmrc](/configuring-npm/npmrc)
* [npm](/commands/npm)

272
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-dedupe.md generated vendored Normal file
View File

@ -0,0 +1,272 @@
---
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.0` 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
#### `global-style`
* Default: false
* Type: Boolean
Causes npm to install the package into your local `node_modules` folder with
the same layout it uses with the global `node_modules` folder. Only your
direct dependencies will show in `node_modules` and everything they depend
on will be flattened in their `node_modules` folders. This obviously will
eliminate some deduping. If used with `legacy-bundling`, `legacy-bundling`
will be preferred.
#### `legacy-bundling`
* Default: false
* Type: Boolean
Causes npm to install the package such that versions of npm prior to 1.4,
such as the one included with node 0.8, can install the package. This
eliminates all automatic deduping. If used with `global-style` this option
will be preferred.
#### `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 and 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.
This configuration does not affect `npm ci`.
#### `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.
#### `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-script`
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.
#### `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 that exist outside of the project root
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)

69
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-deprecate.md generated vendored Normal file
View File

@ -0,0 +1,69 @@
---
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.
### 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)

296
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-diff.md generated vendored Normal file
View File

@ -0,0 +1,296 @@
---
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.
Also the tag that is added to the package@version specified by the `npm tag`
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.
#### `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)

154
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-dist-tag.md generated vendored Normal file
View File

@ -0,0 +1,154 @@
---
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 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 at the OTP prompt.
* 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 at the OTP prompt.
* 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)

104
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-docs.md generated vendored Normal file
View File

@ -0,0 +1,104 @@
---
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
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: OS X: `"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)

118
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-doctor.md generated vendored Normal file
View File

@ -0,0 +1,118 @@
---
title: npm-doctor
section: 1
description: Check your npm environment
---
### Synopsis
```bash
npm doctor
```
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.
#### `npm ping`
By default, npm installs from the primary npm registry,
`registry.npmjs.org`. `npm doctor` hits a special ping 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.
#### `npm -v`
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.
#### `node -v`
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.
#### `npm config get 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.
#### `which git`
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)

44
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-edit.md generated vendored Normal file
View File

@ -0,0 +1,44 @@
---
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 'notepad.exe' on
Windows, or 'vim' 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)

361
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-exec.md generated vendored Normal file
View File

@ -0,0 +1,361 @@
---
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 they are installed to a folder in the npm cache, which
is added to the `PATH` environment variable in the executed process. A
prompt is printed (which can be suppressed by providing either `--yes` or
`--no`).
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.
### 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` or `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` configuration options,
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-script](/commands/npm-run-script)
* [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)

103
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-explain.md generated vendored Normal file
View File

@ -0,0 +1,103 @@
---
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)

47
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-explore.md generated vendored Normal file
View File

@ -0,0 +1,47 @@
---
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)

200
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-find-dupes.md generated vendored Normal file
View File

@ -0,0 +1,200 @@
---
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
#### `global-style`
* Default: false
* Type: Boolean
Causes npm to install the package into your local `node_modules` folder with
the same layout it uses with the global `node_modules` folder. Only your
direct dependencies will show in `node_modules` and everything they depend
on will be flattened in their `node_modules` folders. This obviously will
eliminate some deduping. If used with `legacy-bundling`, `legacy-bundling`
will be preferred.
#### `legacy-bundling`
* Default: false
* Type: Boolean
Causes npm to install the package such that versions of npm prior to 1.4,
such as the one included with node 0.8, can install the package. This
eliminates all automatic deduping. If used with `global-style` this option
will be preferred.
#### `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 and 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.
This configuration does not affect `npm ci`.
#### `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.
#### `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-script`
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 that exist outside of the project root
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)

135
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-fund.md generated vendored Normal file
View File

@ -0,0 +1,135 @@
---
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
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 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: OS X: `"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)

38
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-help-search.md generated vendored Normal file
View File

@ -0,0 +1,38 @@
---
title: npm-help-search
section: 1
description: Search npm help documentation
---
### Synopsis
```bash
npm help-search <text>
```
Note: This command is unaware of workspaces.
### Description
This command will search the npm markdown documentation files for the terms
provided, and then list the results, sorted by relevance.
If only one result is found, then it will show that help topic.
If the argument to `npm help` is not a known help topic, then it will call
`help-search`. It is rarely if ever necessary to call this command
directly.
### Configuration
#### `long`
* Default: false
* Type: Boolean
Show extended information in `ls`, `search`, and `help-search`.
### See Also
* [npm](/commands/npm)
* [npm help](/commands/npm-help)

44
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-help.md generated vendored Normal file
View File

@ -0,0 +1,44 @@
---
title: npm-help
section: 1
description: Get help on npm
---
### Synopsis
```bash
npm help <term> [<terms..>]
alias: hlep
```
Note: This command is unaware of workspaces.
### Description
If supplied a topic, then show the appropriate documentation page.
If the topic does not exist, or if multiple terms are provided, then npm
will run the `help-search` command to find a match. Note that, if
`help-search` finds a single subject, then it will run `help` on that
topic, so unique matches are equivalent to specifying a topic name.
### Configuration
#### `viewer`
* Default: "man" on Posix, "browser" on Windows
* Type: String
The program to use to view help content.
Set to `"browser"` to view html help content in the default web browser.
### See Also
* [npm](/commands/npm)
* [npm folders](/configuring-npm/folders)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)
* [npm help-search](/commands/npm-help-search)

108
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-hook.md generated vendored Normal file
View File

@ -0,0 +1,108 @@
---
title: npm-hook
section: 1
description: Manage registry hooks
---
### Synopsis
```bash
npm hook add <pkg> <url> <secret> [--type=<type>]
npm hook ls [pkg]
npm hook rm <id>
npm hook update <id> <url> <secret>
```
Note: This command is unaware of workspaces.
### Description
Allows you to manage [npm
hooks](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm),
including adding, removing, listing, and updating.
Hooks allow you to configure URL endpoints that will be notified whenever a
change happens to any of the supported entity types. Three different types
of entities can be watched by hooks: packages, owners, and scopes.
To create a package hook, simply reference the package name.
To create an owner hook, prefix the owner name with `~` (as in,
`~youruser`).
To create a scope hook, prefix the scope name with `@` (as in,
`@yourscope`).
The hook `id` used by `update` and `rm` are the IDs listed in `npm hook ls`
for that particular hook.
The shared secret will be sent along to the URL endpoint so you can verify
the request came from your own configured hook.
### Example
Add a hook to watch a package for changes:
```bash
$ npm hook add lodash https://example.com/ my-shared-secret
```
Add a hook to watch packages belonging to the user `substack`:
```bash
$ npm hook add ~substack https://example.com/ my-shared-secret
```
Add a hook to watch packages in the scope `@npm`
```bash
$ npm hook add @npm https://example.com/ my-shared-secret
```
List all your active hooks:
```bash
$ npm hook ls
```
List your active hooks for the `lodash` package:
```bash
$ npm hook ls lodash
```
Update an existing hook's url:
```bash
$ npm hook update id-deadbeef https://my-new-website.here/
```
Remove a hook:
```bash
$ npm hook rm id-deadbeef
```
### 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.
### See Also
* ["Introducing Hooks" blog post](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm)

292
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-init.md generated vendored Normal file
View File

@ -0,0 +1,292 @@
---
title: npm-init
section: 1
description: Create a package.json file
---
### Synopsis
```bash
npm init <package-spec> (same as `npx <package-spec>)
npm init <@scope> (same as `npx <@scope>/create`)
aliases: create, innit
```
### Description
`npm init <initializer>` can be used to set up a new or existing npm
package.
`initializer` in this case is an npm package named `create-<initializer>`,
which will be installed by [`npm-exec`](/commands/npm-exec), and then have its
main bin executed -- presumably creating or updating `package.json` and
running any other initialization-related operations.
The init command is transformed to a corresponding `npm exec` operation as
follows:
* `npm init foo` -> `npm exec create-foo`
* `npm init @usr/foo` -> `npm exec @usr/create-foo`
* `npm init @usr` -> `npm exec @usr/create`
* `npm init @usr@2.0.0` -> `npm exec @usr/create@2.0.0`
* `npm init @usr/foo@2.0.0` -> `npm exec @usr/create-foo@2.0.0`
If the initializer is omitted (by just calling `npm init`), init will fall
back to legacy init behavior. It will ask you a bunch of questions, and
then write a package.json for you. It will attempt to make reasonable
guesses based on existing fields, dependencies, and options selected. It is
strictly additive, so it will keep any fields and values that were already
set. You can also use `-y`/`--yes` to skip the questionnaire altogether. If
you pass `--scope`, it will create a scoped package.
*Note:* if a user already has the `create-<initializer>` package
globally installed, that will be what `npm init` uses. If you want npm
to use the latest version, or another specific version you must specify
it:
* `npm init foo@latest` # fetches and runs the latest `create-foo` from
the registry
* `npm init foo@1.2.3` # runs `create-foo@1.2.3` specifically
#### Forwarding additional options
Any additional options will be passed directly to the command, so `npm init
foo -- --hello` will map to `npm exec -- create-foo --hello`.
To better illustrate how options are forwarded, here's a more evolved
example showing options passed to both the **npm cli** and a create package,
both following commands are equivalent:
- `npm init foo -y --registry=<url> -- --hello -a`
- `npm exec -y --registry=<url> -- create-foo --hello -a`
### Examples
Create a new React-based project using
[`create-react-app`](https://npm.im/create-react-app):
```bash
$ npm init react-app ./my-react-app
```
Create a new `esm`-compatible package using
[`create-esm`](https://npm.im/create-esm):
```bash
$ mkdir my-esm-lib && cd my-esm-lib
$ npm init esm --yes
```
Generate a plain old package.json using legacy init:
```bash
$ mkdir my-npm-pkg && cd my-npm-pkg
$ git init
$ npm init
```
Generate it without having it ask any questions:
```bash
$ npm init -y
```
### Workspaces support
It's possible to create a new workspace within your project by using the
`workspace` config option. When using `npm init -w <dir>` the cli will
create the folders and boilerplate expected while also adding a reference
to your project `package.json` `"workspaces": []` property in order to make
sure that new generated **workspace** is properly set up as such.
Given a project with no workspaces, e.g:
```
.
+-- package.json
```
You may generate a new workspace using the legacy init:
```bash
$ npm init -w packages/a
```
That will generate a new folder and `package.json` file, while also updating
your top-level `package.json` to add the reference to this new workspace:
```
.
+-- package.json
`-- packages
`-- a
`-- package.json
```
The workspaces init also supports the `npm init <initializer> -w <dir>`
syntax, following the same set of rules explained earlier in the initial
**Description** section of this page. Similar to the previous example of
creating a new React-based project using
[`create-react-app`](https://npm.im/create-react-app), the following syntax
will make sure to create the new react app as a nested **workspace** within your
project and configure your `package.json` to recognize it as such:
```bash
npm init -w packages/my-react-app react-app .
```
This will make sure to generate your react app as expected, one important
consideration to have in mind is that `npm exec` is going to be run in the
context of the newly created folder for that workspace, and that's the reason
why in this example the initializer uses the initializer name followed with a
dot to represent the current directory in that context, e.g: `react-app .`:
```
.
+-- package.json
`-- packages
+-- a
| `-- package.json
`-- my-react-app
+-- README
+-- package.json
`-- ...
```
### Configuration
#### `yes`
* Default: null
* Type: null or Boolean
Automatically answer "yes" to any prompts that npm might print on the
command line.
#### `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!
#### `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
```
#### `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.
#### `workspaces-update`
* Default: true
* Type: Boolean
If set to true, the npm cli will run an update after operations that may
possibly change the workspaces installed to the `node_modules` folder.
#### `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)
* [init-package-json module](http://npm.im/init-package-json)
* [package.json](/configuring-npm/package-json)
* [npm version](/commands/npm-version)
* [npm scope](/using-npm/scope)
* [npm exec](/commands/npm-exec)
* [npm workspaces](/using-npm/workspaces)

258
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-install-ci-test.md generated vendored Normal file
View File

@ -0,0 +1,258 @@
---
title: npm-install-ci-test
section: 1
description: Install a project with a clean slate and run tests
---
### Synopsis
```bash
npm install-ci-test
alias: cit
```
### Description
This command runs `npm ci` followed immediately by `npm test`.
### Configuration
#### `save`
* Default: `true` unless when using `npm update` where it defaults to `false`
* Type: Boolean
Save installed packages to a `package.json` file as dependencies.
When used with the `npm rm` command, removes the dependency from
`package.json`.
Will also prevent writing to `package-lock.json` if set to `false`.
#### `save-exact`
* Default: false
* Type: Boolean
Dependencies saved to package.json will be configured with an exact version
rather than using npm's default semver range operator.
#### `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`
#### `global-style`
* Default: false
* Type: Boolean
Causes npm to install the package into your local `node_modules` folder with
the same layout it uses with the global `node_modules` folder. Only your
direct dependencies will show in `node_modules` and everything they depend
on will be flattened in their `node_modules` folders. This obviously will
eliminate some deduping. If used with `legacy-bundling`, `legacy-bundling`
will be preferred.
#### `legacy-bundling`
* Default: false
* Type: Boolean
Causes npm to install the package such that versions of npm prior to 1.4,
such as the one included with node 0.8, can install the package. This
eliminates all automatic deduping. If used with `global-style` this option
will be preferred.
#### `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.
#### `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 and 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.
This configuration does not affect `npm ci`.
#### `foreground-scripts`
* Default: false
* 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-script`
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.
#### `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 that exist outside of the project root
will be packed and installed as regular dependencies instead of creating a
symlink. This option has no effect on workspaces.
### See Also
* [npm install-test](/commands/npm-install-test)
* [npm ci](/commands/npm-ci)
* [npm test](/commands/npm-test)

259
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-install-test.md generated vendored Normal file
View File

@ -0,0 +1,259 @@
---
title: npm-install-test
section: 1
description: Install package(s) and run tests
---
### Synopsis
```bash
npm install-test [<package-spec> ...]
alias: it
```
### Description
This command runs an `npm install` followed immediately by an `npm test`. It
takes exactly the same arguments as `npm install`.
### Configuration
#### `save`
* Default: `true` unless when using `npm update` where it defaults to `false`
* Type: Boolean
Save installed packages to a `package.json` file as dependencies.
When used with the `npm rm` command, removes the dependency from
`package.json`.
Will also prevent writing to `package-lock.json` if set to `false`.
#### `save-exact`
* Default: false
* Type: Boolean
Dependencies saved to package.json will be configured with an exact version
rather than using npm's default semver range operator.
#### `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`
#### `global-style`
* Default: false
* Type: Boolean
Causes npm to install the package into your local `node_modules` folder with
the same layout it uses with the global `node_modules` folder. Only your
direct dependencies will show in `node_modules` and everything they depend
on will be flattened in their `node_modules` folders. This obviously will
eliminate some deduping. If used with `legacy-bundling`, `legacy-bundling`
will be preferred.
#### `legacy-bundling`
* Default: false
* Type: Boolean
Causes npm to install the package such that versions of npm prior to 1.4,
such as the one included with node 0.8, can install the package. This
eliminates all automatic deduping. If used with `global-style` this option
will be preferred.
#### `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.
#### `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 and 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.
This configuration does not affect `npm ci`.
#### `foreground-scripts`
* Default: false
* 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-script`
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.
#### `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 that exist outside of the project root
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)
* [npm install-ci-test](/commands/npm-install-ci-test)
* [npm test](/commands/npm-test)

695
node/node_modules/npm-js-interface/node_modules/npm/docs/content/commands/npm-install.md generated vendored Normal file
View File

@ -0,0 +1,695 @@
---
title: npm-install
section: 1
description: Install a package
---
### Synopsis
```bash
npm install [<package-spec> ...]
aliases: add, i, in, ins, inst, insta, instal, isnt, isnta, isntal, isntall
```
### Description
This command installs a package and any packages that it depends on. If the
package has a package-lock, or an npm shrinkwrap file, or a yarn lock file,
the installation of dependencies will be driven by that, respecting the
following order of precedence:
* `npm-shrinkwrap.json`
* `package-lock.json`
* `yarn.lock`
See [package-lock.json](/configuring-npm/package-lock-json) and
[`npm shrinkwrap`](/commands/npm-shrinkwrap).
A `package` is:
* a) a folder containing a program described by a
[`package.json`](/configuring-npm/package-json) file
* b) a gzipped tarball containing (a)
* c) a url that resolves to (b)
* d) a `<name>@<version>` that is published on the registry (see
[`registry`](/using-npm/registry)) with (c)
* e) a `<name>@<tag>` (see [`npm dist-tag`](/commands/npm-dist-tag)) that
points to (d)
* f) a `<name>` that has a "latest" tag satisfying (e)
* g) a `<git remote url>` that resolves to (a)
Even if you never publish your package, you can still get a lot of benefits
of using npm if you just want to write a node program (a), and perhaps if
you also want to be able to easily install it elsewhere after packing it up
into a tarball (b).
* `npm install` (in a package directory, no arguments):
Install the dependencies to the local `node_modules` folder.
In global mode (ie, with `-g` or `--global` appended to the command),
it installs the current package context (ie, the current working
directory) as a global package.
By default, `npm install` will install all modules listed as
dependencies in [`package.json`](/configuring-npm/package-json).
With the `--production` flag (or when the `NODE_ENV` environment
variable is set to `production`), npm will not install modules listed
in `devDependencies`. To install all modules listed in both
`dependencies` and `devDependencies` when `NODE_ENV` environment
variable is set to `production`, you can use `--production=false`.
> NOTE: The `--production` flag has no particular meaning when adding a
dependency to a project.
* `npm install <folder>`:
If `<folder>` sits inside the root of your project, its dependencies will be installed and may
be hoisted to the top-level `node_modules` as they would for other
types of dependencies. If `<folder>` sits outside the root of your project,
*npm will not install the package dependencies* in the directory `<folder>`,
but it will create a symlink to `<folder>`.
> NOTE: If you want to install the content of a directory like a package from the registry instead of creating a link, you would need to use the `--install-links` option.
Example:
```bash
npm install ../../other-package --install-links
npm install ./sub-package
```
* `npm install <tarball file>`:
Install a package that is sitting on the filesystem. Note: if you just
want to link a dev directory into your npm root, you can do this more
easily by using [`npm link`](/commands/npm-link).
Tarball requirements:
* The filename *must* use `.tar`, `.tar.gz`, or `.tgz` as the
extension.
* The package contents should reside in a subfolder inside the tarball
(usually it is called `package/`). npm strips one directory layer
when installing the package (an equivalent of `tar x
--strip-components=1` is run).
* The package must contain a `package.json` file with `name` and
`version` properties.
Example:
```bash
npm install ./package.tgz
```
* `npm install <tarball url>`:
Fetch the tarball url, and then install it. In order to distinguish between
this and other options, the argument must start with "http://" or "https://"
Example:
```bash
npm install https://github.com/indexzero/forever/tarball/v0.5.6
```
* `npm install [<@scope>/]<name>`:
Do a `<name>@<tag>` install, where `<tag>` is the "tag" config. (See
[`config`](/using-npm/config). The config's default value is `latest`.)
In most cases, this will install the version of the modules tagged as
`latest` on the npm registry.
Example:
```bash
npm install sax
```
`npm install` saves any specified packages into `dependencies` by default.
Additionally, you can control where and how they get saved with some
additional flags:
* `-P, --save-prod`: Package will appear in your `dependencies`. This
is the default unless `-D` or `-O` are present.
* `-D, --save-dev`: Package will appear in your `devDependencies`.
* `-O, --save-optional`: Package will appear in your
`optionalDependencies`.
* `--no-save`: Prevents saving to `dependencies`.
When using any of the above options to save dependencies to your
package.json, there are two additional, optional flags:
* `-E, --save-exact`: Saved dependencies will be configured with an
exact version rather than using npm's default semver range operator.
* `-B, --save-bundle`: Saved dependencies will also be added to your
`bundleDependencies` list.
Further, if you have an `npm-shrinkwrap.json` or `package-lock.json`
then it will be updated as well.
`<scope>` is optional. The package will be downloaded from the registry
associated with the specified scope. If no registry is associated with
the given scope the default registry is assumed. See
[`scope`](/using-npm/scope).
Note: if you do not include the @-symbol on your scope name, npm will
interpret this as a GitHub repository instead, see below. Scopes names
must also be followed by a slash.
Examples:
```bash
npm install sax
npm install githubname/reponame
npm install @myorg/privatepackage
npm install node-tap --save-dev
npm install dtrace-provider --save-optional
npm install readable-stream --save-exact
npm install ansi-regex --save-bundle
```
**Note**: If there is a file or folder named `<name>` in the current
working directory, then it will try to install that, and only try to
fetch the package by name if it is not valid.
* `npm install <alias>@npm:<name>`:
Install a package under a custom alias. Allows multiple versions of
a same-name package side-by-side, more convenient import names for
packages with otherwise long ones, and using git forks replacements
or forked npm packages as replacements. Aliasing works only on your
project and does not rename packages in transitive dependencies.
Aliases should follow the naming conventions stated in
[`validate-npm-package-name`](https://www.npmjs.com/package/validate-npm-package-name#naming-rules).
Examples:
```bash
npm install my-react@npm:react
npm install jquery2@npm:jquery@2
npm install jquery3@npm:jquery@3
npm install npa@npm:npm-package-arg
```
* `npm install [<@scope>/]<name>@<tag>`:
Install the version of the package that is referenced by the specified tag.
If the tag does not exist in the registry data for that package, then this
will fail.
Example:
```bash
npm install sax@latest
npm install @myorg/mypackage@latest
```
* `npm install [<@scope>/]<name>@<version>`:
Install the specified version of the package. This will fail if the
version has not been published to the registry.
Example:
```bash
npm install sax@0.1.1
npm install @myorg/privatepackage@1.5.0
```
* `npm install [<@scope>/]<name>@<version range>`:
Install a version of the package matching the specified version range.
This will follow the same rules for resolving dependencies described in
[`package.json`](/configuring-npm/package-json).
Note that most version ranges must be put in quotes so that your shell
will treat it as a single argument.
Example:
```bash
npm install sax@">=0.1.0 <0.2.0"
npm install @myorg/privatepackage@"16 - 17"
```
* `npm install <git remote url>`:
Installs the package from the hosted git provider, cloning it with
`git`. For a full git remote url, only that URL will be attempted.
```bash
<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
```
`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or
`git+file`.
If `#<commit-ish>` is provided, it will be used to clone exactly that
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>`
can be any valid semver range or exact version, and npm will look for
any tags or refs matching that range in the remote repository, much as
it would for a registry dependency. If neither `#<commit-ish>` or
`#semver:<semver>` is specified, then the default branch of the
repository is used.
If the repository makes use of submodules, those submodules will be
cloned as well.
If the package being installed contains a `prepare` script, its
`dependencies` and `devDependencies` will be installed, and the prepare
script will be run, before the package is packaged and installed.
The following git environment variables are recognized by npm and will
be added to the environment when running git:
* `GIT_ASKPASS`
* `GIT_EXEC_PATH`
* `GIT_PROXY_COMMAND`
* `GIT_SSH`
* `GIT_SSH_COMMAND`
* `GIT_SSL_CAINFO`
* `GIT_SSL_NO_VERIFY`
See the git man page for details.
Examples:
```bash
npm install git+ssh://git@github.com:npm/cli.git#v1.0.27
npm install git+ssh://git@github.com:npm/cli#pull/273
npm install git+ssh://git@github.com:npm/cli#semver:^5.0
npm install git+https://isaacs@github.com/npm/cli.git
npm install git://github.com/npm/cli.git#v1.0.27
GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://git@github.com:npm/cli.git
```
* `npm install <githubname>/<githubrepo>[#<commit-ish>]`:
* `npm install github:<githubname>/<githubrepo>[#<commit-ish>]`:
Install the package at `https://github.com/githubname/githubrepo` by
attempting to clone it using `git`.
If `#<commit-ish>` is provided, it will be used to clone exactly that
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>`
can be any valid semver range or exact version, and npm will look for
any tags or refs matching that range in the remote repository, much as
it would for a registry dependency. If neither `#<commit-ish>` or
`#semver:<semver>` is specified, then the default branch is used.
As with regular git dependencies, `dependencies` and `devDependencies`
will be installed if the package has a `prepare` script before the
package is done installing.
Examples:
```bash
npm install mygithubuser/myproject
npm install github:mygithubuser/myproject
```
* `npm install gist:[<githubname>/]<gistID>[#<commit-ish>|#semver:<semver>]`:
Install the package at `https://gist.github.com/gistID` by attempting to
clone it using `git`. The GitHub username associated with the gist is
optional and will not be saved in `package.json`.
As with regular git dependencies, `dependencies` and `devDependencies` will
be installed if the package has a `prepare` script before the package is
done installing.
Example:
```bash
npm install gist:101a11beef
```
* `npm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit-ish>]`:
Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo`
by attempting to clone it using `git`.
If `#<commit-ish>` is provided, it will be used to clone exactly that
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
be any valid semver range or exact version, and npm will look for any tags
or refs matching that range in the remote repository, much as it would for a
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
specified, then `master` is used.
As with regular git dependencies, `dependencies` and `devDependencies` will
be installed if the package has a `prepare` script before the package is
done installing.
Example:
```bash
npm install bitbucket:mybitbucketuser/myproject
```
* `npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]`:
Install the package at `https://gitlab.com/gitlabname/gitlabrepo`
by attempting to clone it using `git`.
If `#<commit-ish>` is provided, it will be used to clone exactly that
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
be any valid semver range or exact version, and npm will look for any tags
or refs matching that range in the remote repository, much as it would for a
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
specified, then `master` is used.
As with regular git dependencies, `dependencies` and `devDependencies` will
be installed if the package has a `prepare` script before the package is
done installing.
Example:
```bash
npm install gitlab:mygitlabuser/myproject
npm install gitlab:myusr/myproj#semver:^5.0
```
You may combine multiple arguments and even multiple types of arguments.
For example:
```bash
npm install sax@">=0.1.0 <0.2.0" bench supervisor
```
The `--tag` argument will apply to all of the specified install targets. If
a tag with the given name exists, the tagged version is preferred over
newer versions.
The `--dry-run` argument will report in the usual way what the install
would have done without actually installing anything.
The `--package-lock-only` argument will only update the
`package-lock.json`, instead of checking `node_modules` and downloading
dependencies.
The `-f` or `--force` argument will force npm to fetch remote resources
even if a local copy exists on disk.
```bash
npm install sax --force
```
### Configuration
See the [`config`](/using-npm/config) help doc. Many of the configuration
params have some effect on installation, since that's most of what npm
does.
These are some of the most common options related to installation.
#### `save`
* Default: `true` unless when using `npm update` where it defaults to `false`
* Type: Boolean
Save installed packages to a `package.json` file as dependencies.
When used with the `npm rm` command, removes the dependency from
`package.json`.
Will also prevent writing to `package-lock.json` if set to `false`.
#### `save-exact`
* Default: false
* Type: Boolean
Dependencies saved to package.json will be configured with an exact version
rather than using npm's default semver range operator.
#### `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`
#### `global-style`
* Default: false
* Type: Boolean
Causes npm to install the package into your local `node_modules` folder with
the same layout it uses with the global `node_modules` folder. Only your
direct dependencies will show in `node_modules` and everything they depend
on will be flattened in their `node_modules` folders. This obviously will
eliminate some deduping. If used with `legacy-bundling`, `legacy-bundling`
will be preferred.
#### `legacy-bundling`
* Default: false
* Type: Boolean
Causes npm to install the package such that versions of npm prior to 1.4,
such as the one included with node 0.8, can install the package. This
eliminates all automatic deduping. If used with `global-style` this option
will be preferred.
#### `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.
#### `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 and 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.
This configuration does not affect `npm ci`.
#### `foreground-scripts`
* Default: false
* 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-script`
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.
#### `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 that exist outside of the project root
will be packed and installed as regular dependencies instead of creating a
symlink. This option has no effect on workspaces.
### Algorithm
Given a `package{dep}` structure: `A{B,C}, B{C}, C{D}`,
the npm install algorithm produces:
```bash
A
+-- B
+-- C
+-- D
```
That is, the dependency from B to C is satisfied by the fact that A already
caused C to be installed at a higher level. D is still installed at the top
level because nothing conflicts with it.
For `A{B,C}, B{C,D@1}, C{D@2}`, this algorithm produces:
```bash
A
+-- B
+-- C
`-- D@2
+-- D@1
```
Because B's D@1 will be installed in the top-level, C now has to install
D@2 privately for itself. This algorithm is deterministic, but different
trees may be produced if two dependencies are requested for installation in
a different order.
See [folders](/configuring-npm/folders) for a more detailed description of
the specific folder structures that npm creates.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm update](/commands/npm-update)
* [npm audit](/commands/npm-audit)
* [npm fund](/commands/npm-fund)
* [npm link](/commands/npm-link)
* [npm rebuild](/commands/npm-rebuild)
* [npm scripts](/using-npm/scripts)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm registry](/using-npm/registry)
* [npm dist-tag](/commands/npm-dist-tag)
* [npm uninstall](/commands/npm-uninstall)
* [npm shrinkwrap](/commands/npm-shrinkwrap)
* [package.json](/configuring-npm/package-json)
* [workspaces](/using-npm/workspaces)

Some files were not shown because too many files have changed in this diff Show More