cutemeli/server
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

removed /etc and /opt

Browse Source
This commit is contained in:
cutemeli
2025-12-22 10:48:14 +00:00
parent 5ce7ca2c5d
commit 10d1afbb17
32559 changed files with 0 additions and 6756692 deletions
Download Patch File Download Diff File Expand all files Collapse all files

582
opt/plesk/node/24/lib/node_modules/corepack/CHANGELOG.md generated vendored
View File

@@ -1,582 +0,0 @@
# Changelog
## [0.34.5](https://github.com/nodejs/corepack/compare/v0.34.4...v0.34.5) (2025-11-24)
### Bug Fixes
* **pnpm:** fix bin path for v11 ([#776](https://github.com/nodejs/corepack/issues/776)) ([0c8048a](https://github.com/nodejs/corepack/commit/0c8048adc61651f6eb798448675d3ecc4a7e26a9))
* update package manager versions ([#773](https://github.com/nodejs/corepack/issues/773)) ([06c286b](https://github.com/nodejs/corepack/commit/06c286b5fc171e43090b5eed5cd501bc9580927f))
## [0.34.4](https://github.com/nodejs/corepack/compare/v0.34.3...v0.34.4) (2025-11-14)
### Bug Fixes
* bump pnpm version in `config.json` ([#768](https://github.com/nodejs/corepack/issues/768)) ([99a9a6e](https://github.com/nodejs/corepack/commit/99a9a6eb1b6e918ceb896b3d558bb5ed583bdc70))
* ignore devEngines version range when CLI provides a version ([#762](https://github.com/nodejs/corepack/issues/762)) ([ac518c4](https://github.com/nodejs/corepack/commit/ac518c4106f8d9ceb4e85e6c3614b1eba5d03fcb))
* use `lstatSync` in `generatePosixLink` ([#767](https://github.com/nodejs/corepack/issues/767)) ([a02bea0](https://github.com/nodejs/corepack/commit/a02bea078eb584ed7492ec561626987e35386bae))
## [0.34.3](https://github.com/nodejs/corepack/compare/v0.34.2...v0.34.3) (2025-11-07)
### Bug Fixes
* update package manager versions ([#765](https://github.com/nodejs/corepack/issues/765)) ([13a2e98](https://github.com/nodejs/corepack/commit/13a2e989ee37694a7ec1b1d60acdaa28f90642d1))
* Yarn switch install support and tests ([#761](https://github.com/nodejs/corepack/issues/761)) ([d04d483](https://github.com/nodejs/corepack/commit/d04d4839aeecaf4fca989c577f6c000dc90be933))
## [0.34.2](https://github.com/nodejs/corepack/compare/v0.34.1...v0.34.2) (2025-10-31)
### Bug Fixes
* bump package manager versions ([#754](https://github.com/nodejs/corepack/issues/754)) ([35e3869](https://github.com/nodejs/corepack/commit/35e3869f3f4d21bbfccdf78ea564ab0723d6f36f))
* fix potential race condition in `node-tar` ([#757](https://github.com/nodejs/corepack/pull/757)) ([78808a7](78808a72691655fe5140c02ae41d4baef88cd9fa))
## [0.34.1](https://github.com/nodejs/corepack/compare/v0.34.0...v0.34.1) (2025-10-17)
### Bug Fixes
* incorrect registry origin check ([#743](https://github.com/nodejs/corepack/issues/743)) ([cc840b2](https://github.com/nodejs/corepack/commit/cc840b2d232a29c225d2436d350640f0035ed28b))
* update package manager versions ([#728](https://github.com/nodejs/corepack/issues/728)) ([78ce029](https://github.com/nodejs/corepack/commit/78ce0297a9152bb5c68f724821a9a0095b408334))
## [0.34.0](https://github.com/nodejs/corepack/compare/v0.33.0...v0.34.0) (2025-07-19)
### ⚠ BREAKING CHANGES
* drop Node.js 18.x and 23.x support
### Features
* update package manager versions ([#719](https://github.com/nodejs/corepack/issues/719)) ([7707ea7](https://github.com/nodejs/corepack/commit/7707ea7350c129ad3aae8ca08e9e80fcf164dcb6))
### Miscellaneous Chores
* remove Node.js 18.x and 23.x usage, add 24.x ([#718](https://github.com/nodejs/corepack/issues/718)) ([783a42f](https://github.com/nodejs/corepack/commit/783a42fbe35371964e9dde75e2263b179f53bc0c))
## [0.33.0](https://github.com/nodejs/corepack/compare/v0.32.0...v0.33.0) (2025-06-02)
### Features
* Adds guard to avoid stepping on Yarn's feet ([#714](https://github.com/nodejs/corepack/issues/714)) ([5fc3691](https://github.com/nodejs/corepack/commit/5fc3691354eb5bdeca17a9495b234584353f0151))
* update package manager versions ([#671](https://github.com/nodejs/corepack/issues/671)) ([b45b3a3](https://github.com/nodejs/corepack/commit/b45b3a3244bacfbaf65188ae8c04209a1e98307d))
### Bug Fixes
* debug text typo ([#698](https://github.com/nodejs/corepack/issues/698)) ([0b94797](https://github.com/nodejs/corepack/commit/0b94797f96e30e46e466873fe7d437d0471cd92c))
## [0.32.0](https://github.com/nodejs/corepack/compare/v0.31.0...v0.32.0) (2025-02-28)
### Features
* add limited support for `devEngines` ([#643](https://github.com/nodejs/corepack/issues/643)) ([b456268](https://github.com/nodejs/corepack/commit/b4562688513f23e37e37b0d69a0daff33ca84c8d))
* add more informative error when fetching latest stable fails ([#644](https://github.com/nodejs/corepack/issues/644)) ([53b1fe7](https://github.com/nodejs/corepack/commit/53b1fe75c47c06bd72a8b8f8bb699a47c9ca32fb))
* add support for `.corepack.env` ([#642](https://github.com/nodejs/corepack/issues/642)) ([9b95b46](https://github.com/nodejs/corepack/commit/9b95b46f05e50fe1c60f05309c210ba8fe4e23c5))
* update package manager versions ([#617](https://github.com/nodejs/corepack/issues/617)) ([b83bb5e](https://github.com/nodejs/corepack/commit/b83bb5ec150980c998b9c7053dff307d912cb508))
### Bug Fixes
* do not resolve fallback descriptor when `packageManager` is defined ([#632](https://github.com/nodejs/corepack/issues/632)) ([12e77e5](https://github.com/nodejs/corepack/commit/12e77e506946d42a0de9ce8e68d75af8454d6776))
* **doc:** fix link to proxy library ([#636](https://github.com/nodejs/corepack/issues/636)) ([bae0839](https://github.com/nodejs/corepack/commit/bae08397943d4b99437389b4286546361091f4b3))
* replace explicit with specify as verb ([#665](https://github.com/nodejs/corepack/issues/665)) ([351d86c](https://github.com/nodejs/corepack/commit/351d86c20226a8c18bfe212be27401f2908b1595))
* **use:** do not throw on invalid `packageManager` ([#663](https://github.com/nodejs/corepack/issues/663)) ([4be72f6](https://github.com/nodejs/corepack/commit/4be72f6941afa0c9b2b7d26635016bb7b560df8a))
## [0.31.0](https://github.com/nodejs/corepack/compare/v0.30.0...v0.31.0) (2025-01-27)
### ⚠ BREAKING CHANGES
* drop support for Node.js 21.x ([#594](https://github.com/nodejs/corepack/issues/594))
### Features
* update package manager versions ([#595](https://github.com/nodejs/corepack/issues/595)) ([c7a9bde](https://github.com/nodejs/corepack/commit/c7a9bde16dcbbb7e6ef03fef740656cde7ade360))
### Bug Fixes
* only print message for `UsageError`s ([#602](https://github.com/nodejs/corepack/issues/602)) ([72a588c](https://github.com/nodejs/corepack/commit/72a588c2370c17e415b24fe389efdafb3c84e90b))
* update npm registry keys ([#614](https://github.com/nodejs/corepack/issues/614)) ([8c90caa](https://github.com/nodejs/corepack/commit/8c90caab7f1c5c9b89f1de113bc1dfc441bf25d2))
### Miscellaneous Chores
* drop support for Node.js 21.x ([#594](https://github.com/nodejs/corepack/issues/594)) ([8bebc0c](https://github.com/nodejs/corepack/commit/8bebc0c0a5cbcdeec41673dcbaf581e6e1c1be11))
## [0.30.0](https://github.com/nodejs/corepack/compare/v0.29.4...v0.30.0) (2024-11-23)
### Features
* update package manager versions ([#578](https://github.com/nodejs/corepack/issues/578)) ([a286c8f](https://github.com/nodejs/corepack/commit/a286c8f5537ea9ecf9b6ff53c7bc3e8da4e3c8bb))
### Performance Improvements
* prefer `module.enableCompileCache` over `v8-compile-cache` ([#574](https://github.com/nodejs/corepack/issues/574)) ([cba6905](https://github.com/nodejs/corepack/commit/cba690575bd606faeee54bd512ccb8797d49055f))
## [0.29.4](https://github.com/nodejs/corepack/compare/v0.29.3...v0.29.4) (2024-09-07)
### Features
* update package manager versions ([#543](https://github.com/nodejs/corepack/issues/543)) ([b819e40](https://github.com/nodejs/corepack/commit/b819e404dbb23c4ae3d5dbe55e21de74d714ee9c))
## [0.29.3](https://github.com/nodejs/corepack/compare/v0.29.2...v0.29.3) (2024-07-21)
### Bug Fixes
* fallback to `shasum` when `integrity` is not defined ([#542](https://github.com/nodejs/corepack/issues/542)) ([eb63873](https://github.com/nodejs/corepack/commit/eb63873c6c617a2f8ac7106e26ccfe8aa3ae1fb9))
* make `DEBUG=corepack` more useful ([#538](https://github.com/nodejs/corepack/issues/538)) ([6019d7b](https://github.com/nodejs/corepack/commit/6019d7b56e85bd8b7b58a1a487922c707e70e30e))
## [0.29.2](https://github.com/nodejs/corepack/compare/v0.29.1...v0.29.2) (2024-07-13)
### Bug Fixes
* trigger release after 0.29.1 failed to publish ([18e29ce](https://github.com/nodejs/corepack/commit/18e29ce3c465b64d48ccf3feef7cd1be94da70b0))
## [0.29.1](https://github.com/nodejs/corepack/compare/v0.29.0...v0.29.1) (2024-07-13)
### Bug Fixes
* trigger release after 0.29.0 failed to publish ([e6ba066](https://github.com/nodejs/corepack/commit/e6ba06657b0985c112f288932ca39c0562129566))
## [0.29.0](https://github.com/nodejs/corepack/compare/v0.28.2...v0.29.0) (2024-07-12)
### Features
* parallelize linking, unlinking and installing ([#524](https://github.com/nodejs/corepack/issues/524)) ([f0734e6](https://github.com/nodejs/corepack/commit/f0734e6e8023ff361dac179c0d8656740d550c27))
* update package manager versions ([#492](https://github.com/nodejs/corepack/issues/492)) ([3e3b046](https://github.com/nodejs/corepack/commit/3e3b04619cb4a91f207a72fb450f6fc4e2f01aec))
### Bug Fixes
* replace npm registry domain in tarball URL ([#502](https://github.com/nodejs/corepack/issues/502)) ([db6fae5](https://github.com/nodejs/corepack/commit/db6fae50cf44884d1e9a6f7e99402e7e807ba3ca))
* selectively import required semver functions ([#511](https://github.com/nodejs/corepack/issues/511)) ([e7ad533](https://github.com/nodejs/corepack/commit/e7ad533d43dc9495493f0d883c3cbbb94caa1d41))
## [0.28.2](https://github.com/nodejs/corepack/compare/v0.28.1...v0.28.2) (2024-05-31)
### Features
* update package manager versions ([#481](https://github.com/nodejs/corepack/issues/481)) ([e1abb83](https://github.com/nodejs/corepack/commit/e1abb832416a793b490b2b51b4082fe822fc932c))
## [0.28.1](https://github.com/nodejs/corepack/compare/v0.28.0...v0.28.1) (2024-05-10)
### Features
* add support for `COREPACK_INTEGRITY_KEYS=0` ([#470](https://github.com/nodejs/corepack/issues/470)) ([f15ebc2](https://github.com/nodejs/corepack/commit/f15ebc289ebcd6a86580f15ae3c4ef0e1be37c4b))
* update package manager versions ([#469](https://github.com/nodejs/corepack/issues/469)) ([985895b](https://github.com/nodejs/corepack/commit/985895bccb5ec68b3645c540d8500c572e1ccadb))
### Bug Fixes
* COREPACK_NPM_REGISTRY should allow for username/password auth ([#466](https://github.com/nodejs/corepack/issues/466)) ([6efa349](https://github.com/nodejs/corepack/commit/6efa34988229918debe6e881d45ba6715282f283))
## [0.28.0](https://github.com/nodejs/corepack/compare/v0.27.0...v0.28.0) (2024-04-20)
### ⚠ BREAKING CHANGES
* call `executePackageManagerRequest` directly ([#430](https://github.com/nodejs/corepack/issues/430))
### Bug Fixes
* call `executePackageManagerRequest` directly ([#430](https://github.com/nodejs/corepack/issues/430)) ([0f9b748](https://github.com/nodejs/corepack/commit/0f9b74864048d5dc150a63cc582966af0c5f363f))
## [0.27.0](https://github.com/nodejs/corepack/compare/v0.26.0...v0.27.0) (2024-04-19)
### ⚠ BREAKING CHANGES
* attempting to download a version from the npm registry (or a mirror) that was published using the now deprecated PGP signature without providing a hash will trigger an error. Users can disable the signature verification using a environment variable.
### Features
* separate read and write operations on lastKnownGood.json ([#446](https://github.com/nodejs/corepack/issues/446)) ([c449adc](https://github.com/nodejs/corepack/commit/c449adc81822a604ee8f00ae2b53fc411535f96d))
* update package manager versions ([#425](https://github.com/nodejs/corepack/issues/425)) ([1423190](https://github.com/nodejs/corepack/commit/142319056424b1e0da2bdbe801c52c5910023707))
* update package manager versions ([#462](https://github.com/nodejs/corepack/issues/462)) ([56816c2](https://github.com/nodejs/corepack/commit/56816c2b7ebc9926f07048b0ec4ff6025bb4e293))
* verify integrity signature when downloading from npm registry ([#432](https://github.com/nodejs/corepack/issues/432)) ([e561dd0](https://github.com/nodejs/corepack/commit/e561dd00bbacc5bc15a492fc36574fa0e37bff7b))
### Bug Fixes
* add path to `package.json` in error message ([#456](https://github.com/nodejs/corepack/issues/456)) ([32a93ea](https://github.com/nodejs/corepack/commit/32a93ea4f51eb7db7dc95a16c5719695edf4b53e))
* correctly set `Dispatcher` prototype for `ProxyAgent` ([#451](https://github.com/nodejs/corepack/issues/451)) ([73d9a1e](https://github.com/nodejs/corepack/commit/73d9a1e2d2f84906bf01952f1dca8adab576b7bf))
* download fewer metadata from npm registry ([#436](https://github.com/nodejs/corepack/issues/436)) ([082fabf](https://github.com/nodejs/corepack/commit/082fabf8b15658e69e4fb62bb854fe9aace78b70))
* hash check when downloading Yarn Berry from npm ([#439](https://github.com/nodejs/corepack/issues/439)) ([4672162](https://github.com/nodejs/corepack/commit/467216281e1719a739d0eeea370b335adfb37b8d))
* Incorrect authorization prefix for basic auth, and undocumented env var ([#454](https://github.com/nodejs/corepack/issues/454)) ([2d63536](https://github.com/nodejs/corepack/commit/2d63536413971d43f570deb035845aa0bd5202f0))
* re-add support for custom registries with auth ([#397](https://github.com/nodejs/corepack/issues/397)) ([d267753](https://github.com/nodejs/corepack/commit/d2677538cdb613fcab6d2a45bb07f349bdc65c2b))
## [0.26.0](https://github.com/nodejs/corepack/compare/v0.25.2...v0.26.0) (2024-03-08)
### Features
* Pins the package manager as it's used for the first time ([#413](https://github.com/nodejs/corepack/issues/413)) ([8b6c6d4](https://github.com/nodejs/corepack/commit/8b6c6d4b2b7a9d61ae6c33c07e12354bd5afc2ba))
* update package manager versions ([#415](https://github.com/nodejs/corepack/issues/415)) ([e8edba7](https://github.com/nodejs/corepack/commit/e8edba771bca6fb10c855c04eee8102ffa792d58))
### Bug Fixes
* group the download prompt together ([#391](https://github.com/nodejs/corepack/issues/391)) ([00506b2](https://github.com/nodejs/corepack/commit/00506b2a15dd87ec03240578077a35b7980e00c1))
* ignore `EROFS` errors ([#421](https://github.com/nodejs/corepack/issues/421)) ([b7ec137](https://github.com/nodejs/corepack/commit/b7ec137210efd35c3461321b6434e3e13a87d42f))
* improve support for `COREPACK_NPM_REGISTRY` with Yarn Berry ([#396](https://github.com/nodejs/corepack/issues/396)) ([47be27c](https://github.com/nodejs/corepack/commit/47be27c9db988e10f651d23b3f53bcf55318a894))
* Windows malicious file analysis waiting problem ([#398](https://github.com/nodejs/corepack/issues/398)) ([295a1cd](https://github.com/nodejs/corepack/commit/295a1cdb9cbbbce8434e8d82b96eb63e57c46c1a))
## [0.25.2](https://github.com/nodejs/corepack/compare/v0.25.1...v0.25.2) (2024-02-21)
### Features
* update package manager versions ([#362](https://github.com/nodejs/corepack/issues/362)) ([1423312](https://github.com/nodejs/corepack/commit/1423312a0eb7844dcdd43ae8a63cf12dcacedb2b))
### Bug Fixes
* do not hard fail if Corepack home folder cannot be created ([#382](https://github.com/nodejs/corepack/issues/382)) ([9834f57](https://github.com/nodejs/corepack/commit/9834f5790a99ce2c6c283321bb38b02e5561b7ca))
* do not show download prompt when downloading JSON ([#383](https://github.com/nodejs/corepack/issues/383)) ([bc137a0](https://github.com/nodejs/corepack/commit/bc137a0073c3343ce2d552b6e13bfd2a48f08351))
## [0.25.1](https://github.com/nodejs/corepack/compare/v0.25.0...v0.25.1) (2024-02-20)
### Bug Fixes
* use valid semver range for `engines.node` ([#378](https://github.com/nodejs/corepack/issues/378)) ([f2185fe](https://github.com/nodejs/corepack/commit/f2185fefa145cc75fca082acc169f8aaef637ca2))
## [0.25.0](https://github.com/nodejs/corepack/compare/v0.24.1...v0.25.0) (2024-02-20)
### ⚠ BREAKING CHANGES
* remove `--all` flag ([#351](https://github.com/nodejs/corepack/issues/351))
* remove Node.js 19.x from the range of supported versions ([#375](https://github.com/nodejs/corepack/issues/375))
* use `fetch` ([#365](https://github.com/nodejs/corepack/issues/365))
* remove old install folder migration ([#373](https://github.com/nodejs/corepack/issues/373))
* prompt user before downloading software ([#360](https://github.com/nodejs/corepack/issues/360))
### Features
* add `corepack cache` command ([#363](https://github.com/nodejs/corepack/issues/363)) ([f442366](https://github.com/nodejs/corepack/commit/f442366c1c00d0c3f388b757c3797504f9a6b62e))
* add support for URL in `"packageManager"` ([#359](https://github.com/nodejs/corepack/issues/359)) ([4a8ce6d](https://github.com/nodejs/corepack/commit/4a8ce6d42f081047a341f36067696346c9f3e1ea))
* bump Known Good Release when downloading new version ([#364](https://github.com/nodejs/corepack/issues/364)) ([a56c13b](https://github.com/nodejs/corepack/commit/a56c13bd0b1c11e50361b8b4b6f8a53571e3981a))
* prompt user before downloading software ([#360](https://github.com/nodejs/corepack/issues/360)) ([6b8d87f](https://github.com/nodejs/corepack/commit/6b8d87f2374f79855b24d659f2a2579d6b39f54f))
* remove `--all` flag ([#351](https://github.com/nodejs/corepack/issues/351)) ([d9c70b9](https://github.com/nodejs/corepack/commit/d9c70b91f698787d693406626a73dc95cb18bc1d))
* remove old install folder migration ([#373](https://github.com/nodejs/corepack/issues/373)) ([54e9510](https://github.com/nodejs/corepack/commit/54e9510cdaf6ed08c9dea1ed3999fa65116cb4c7))
* use `fetch` ([#365](https://github.com/nodejs/corepack/issues/365)) ([fe6a307](https://github.com/nodejs/corepack/commit/fe6a3072f64efa810b90e4ee52e0b3ff14c63184))
### Bug Fixes
* remove unsafe remove of install folder ([#372](https://github.com/nodejs/corepack/issues/372)) ([65880ca](https://github.com/nodejs/corepack/commit/65880cafed5f4195f8e7656ca9af4cbcbb7682d3))
### Miscellaneous Chores
* remove Node.js 19.x from the range of supported versions ([#375](https://github.com/nodejs/corepack/issues/375)) ([9a1cb38](https://github.com/nodejs/corepack/commit/9a1cb385bba9ade8e9fbf5517c2bdff60295f9ed))
## [0.24.1](https://github.com/nodejs/corepack/compare/v0.24.0...v0.24.1) (2024-01-13)
### Features
* update package manager versions ([#348](https://github.com/nodejs/corepack/issues/348)) ([cc3ada7](https://github.com/nodejs/corepack/commit/cc3ada73bccd0a5b0ff16834e518efa521c9eea4))
### Bug Fixes
* **use:** create `package.json` when calling `corepack use` on empty dir ([#350](https://github.com/nodejs/corepack/issues/350)) ([2950a8a](https://github.com/nodejs/corepack/commit/2950a8a30b64b4598abc354e45400e83d56e541b))
## [0.24.0](https://github.com/nodejs/corepack/compare/v0.23.0...v0.24.0) (2023-12-29)
### Features
* add support for HTTP redirect ([#341](https://github.com/nodejs/corepack/issues/341)) ([6df5063](https://github.com/nodejs/corepack/commit/6df5063b14868ff21499a051e5122fa7211be6ed))
* add support for rangeless commands ([#338](https://github.com/nodejs/corepack/issues/338)) ([9bee415](https://github.com/nodejs/corepack/commit/9bee4150815113d97f0bd77d62c8d999cfd68ad3))
* update package manager versions ([#330](https://github.com/nodejs/corepack/issues/330)) ([cfcc280](https://github.com/nodejs/corepack/commit/cfcc28047a788daeef2c0b15ee35a8b1a8149bb6))
* **yarn:** fallback to npm when `COREPACK_NPM_REGISTRY` is set ([#339](https://github.com/nodejs/corepack/issues/339)) ([0717c6a](https://github.com/nodejs/corepack/commit/0717c6af898e075f57c5694d699a3c51e79a024c))
### Bug Fixes
* clarify `EACCES` errors ([#343](https://github.com/nodejs/corepack/issues/343)) ([518bed8](https://github.com/nodejs/corepack/commit/518bed8b7d7c313163c79d31cb9bbc023dba6560))
## [0.23.0](https://github.com/nodejs/corepack/compare/v0.22.0...v0.23.0) (2023-11-05)
### Features
* update package manager versions ([#325](https://github.com/nodejs/corepack/issues/325)) ([450cd33](https://github.com/nodejs/corepack/commit/450cd332d00d3428f49ed09a4235bd12139931c9))
## [0.22.0](https://github.com/nodejs/corepack/compare/v0.21.0...v0.22.0) (2023-10-21)
### Features
* allow fallback to application/json for custom registries ([#314](https://github.com/nodejs/corepack/issues/314)) ([92f8e71](https://github.com/nodejs/corepack/commit/92f8e71f8c97c44f404ce9b7df8787a4292e6830))
* update package manager versions ([#318](https://github.com/nodejs/corepack/issues/318)) ([0bd2577](https://github.com/nodejs/corepack/commit/0bd2577bb4c6c3a5a33ecdb3b6ca2ff244c54f28))
## [0.21.0](https://github.com/nodejs/corepack/compare/v0.20.0...v0.21.0) (2023-10-08)
### ⚠ BREAKING CHANGES
* remove support for Node.js 16.x
### Features
* update package manager versions ([#297](https://github.com/nodejs/corepack/issues/297)) ([503e135](https://github.com/nodejs/corepack/commit/503e135878935cc881ebd94b48d5eca94ec4c27b))
### Miscellaneous Chores
* update supported Node.js versions ([#309](https://github.com/nodejs/corepack/issues/309)) ([787e24d](https://github.com/nodejs/corepack/commit/787e24df609513702eafcd8c6a5f03544d7d45cc))
## [0.20.0](https://github.com/nodejs/corepack/compare/v0.19.0...v0.20.0) (2023-08-29)
### Features
* refactor the CLI interface ([#291](https://github.com/nodejs/corepack/issues/291)) ([fe3e5cd](https://github.com/nodejs/corepack/commit/fe3e5cd86c45db0d87c7fdea87d57d59b0bdcb78))
* update package manager versions ([#292](https://github.com/nodejs/corepack/issues/292)) ([be9c286](https://github.com/nodejs/corepack/commit/be9c286846443ff03081e736fdf4a0ff031fbd38))
## [0.19.0](https://github.com/nodejs/corepack/compare/v0.18.1...v0.19.0) (2023-06-24)
### Features
* support ESM ([#270](https://github.com/nodejs/corepack/issues/270)) ([be2489c](https://github.com/nodejs/corepack/commit/be2489cd0aaabf26a019e1c089a3c8bcc329e94a))
* update package manager versions ([#280](https://github.com/nodejs/corepack/issues/280)) ([4188f2b](https://github.com/nodejs/corepack/commit/4188f2b4671228339fe16f9f566e7bac0c2c4f6d))
## [0.18.1](https://github.com/nodejs/corepack/compare/v0.18.0...v0.18.1) (2023-06-13)
### Features
* update package manager versions ([#272](https://github.com/nodejs/corepack/issues/272)) ([5345774](https://github.com/nodejs/corepack/commit/53457747a26a5de3debbd0d9282b338186bbd7c3))
### Bug Fixes
* disable `v8-compile-cache` when using `npm@>=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
opt/plesk/node/24/lib/node_modules/corepack/LICENSE.md generated vendored
View File

@@ -1,7 +0,0 @@
**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.

381
opt/plesk/node/24/lib/node_modules/corepack/README.md generated vendored
View File

@@ -1,381 +0,0 @@
# <img src="./icon.svg" height="25" /> corepack
[![Join us on OpenJS slack (channel #nodejs-corepack)](https://img.shields.io/badge/OpenJS%20Slack-%23nodejs--corepack-blue)](https://slack-invite.openjsf.org/)
Corepack is a zero-runtime-dependency Node.js script that acts as a bridge
between Node.js projects and the package managers they are intended to be used
with during development. In practical terms, **Corepack lets you use Yarn, npm,
and pnpm without having to install them**.
## How to Install
### Default Installs
Corepack is distributed with Node.js from version 14.19.0 up to (but not including) 25.0.0.
Run `corepack enable` to install the required Yarn and pnpm binaries on your path.
### Manual Installs
<details>
<summary>Install Corepack using npm</summary>
First uninstall your global Yarn and pnpm binaries (just leave npm). In general,
you'd do this by running the following command:
```shell
npm uninstall -g yarn pnpm
# That should be enough, but if you installed Yarn without going through npm it might
# be more tedious - for example, you might need to run `brew uninstall yarn` as well.
```
Then install Corepack:
```shell
npm install -g corepack
```
We do acknowledge the irony and overhead of using npm to install Corepack, which
is at least part of why the preferred option is to use the Corepack version that
is distributed along with Node.js itself.
</details>
<details><summary>Update Corepack using npm</summary>
To install the latest version of Corepack, use:
```shell
npm install -g corepack@latest
```
If Corepack was installed on your system using a Node.js Windows Installer
`.msi` package then you might need to remove it before attempting to install a
different version of Corepack using npm. You can select the Modify option of the
Node.js app settings to access the Windows Installer feature selection, and on
the "corepack manager" feature of the Node.js `.msi` package by selecting
"Entire feature will be unavailable". See
[Repair apps and programs in Windows](https://support.microsoft.com/en-us/windows/repair-apps-and-programs-in-windows-e90eefe4-d0a2-7c1b-dd59-949a9030f317)
for instructions on accessing the Windows apps page to modify settings.
</details>
<details><summary>Install Corepack from source</summary>
See [`CONTRIBUTING.md`](./CONTRIBUTING.md).
</details>
## Usage
### When Building Packages
Just use your package managers as you usually would. Run `yarn install` in Yarn
projects, `pnpm install` in pnpm projects, and `npm` in npm projects. Corepack
will catch these calls, and depending on the situation:
- **If the local project is configured for the package manager you're using**,
Corepack will download and cache the latest compatible version.
- **If the local project is configured for a different package manager**,
Corepack will request you to run the command again using the right package
manager - thus avoiding corruptions of your install artifacts.
- **If the local project isn't configured for any package manager**, Corepack
will assume that you know what you're doing, and will use whatever package
manager version has been pinned as "known good release". Check the relevant
section for more details.
### When Authoring Packages
Set your package's manager with the `packageManager` field in `package.json`:
```json
{
"packageManager": "yarn@3.2.3+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa"
}
```
Here, `yarn` is the name of the package manager, specified at version `3.2.3`,
along with the SHA-224 hash of this version for validation.
`packageManager@x.y.z` is required. The hash is optional but strongly
recommended as a security practice. Permitted values for the package manager are
`yarn`, `npm`, and `pnpm`.
You can also provide a URL to a `.js` file (which will be interpreted as a
CommonJS module) or a `.tgz` file (which will be interpreted as a package, and
the `"bin"` field of the `package.json` will be used to determine which file to
use in the archive).
```json
{
"packageManager": "yarn@https://registry.npmjs.org/@yarnpkg/cli-dist/-/cli-dist-3.2.3.tgz#sha224.16a0797d1710d1fb7ec40ab5c3801b68370a612a9b66ba117ad9924b"
}
```
#### `devEngines.packageManager`
When a `devEngines.packageManager` field is defined, and is an object containing
a `"name"` field (can also optionally contain `version` and `onFail` fields),
Corepack will use it to validate you're using a compatible package manager.
Depending on the value of `devEngines.packageManager.onFail`:
- if set to `ignore`, Corepack won't print any warning or error.
- if unset or set to `error`, Corepack will throw an error in case of a mismatch.
- if set to `warn` or some other value, Corepack will print a warning in case
of mismatch.
If the top-level `packageManager` field is missing, Corepack will use the
package manager defined in `devEngines.packageManager` – in which case you must
provide a specific version in `devEngines.packageManager.version`, ideally with
a hash, as explained in the previous section:
```json
{
"devEngines":{
"packageManager": {
"name": "yarn",
"version": "3.2.3+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa"
}
}
}
```
## Known Good Releases
When running Corepack within projects that don't list a supported package
manager, it will default to a set of Known Good Releases.
If there is no Known Good Release for the requested package manager, Corepack
looks up the npm registry for the latest available version and cache it for
future use.
The Known Good Releases can be updated system-wide using `corepack install -g`.
When Corepack downloads a new version of a given package manager on the same
major line as the Known Good Release, it auto-updates it by default.
## Offline Workflow
The utility commands detailed in the next section.
- Either you can use the network while building your container image, in which
case you'll simply run `corepack pack` to make sure that your image
includes the Last Known Good release for the specified package manager.
- Or you're publishing your project to a system where the network is
unavailable, in which case you'll preemptively generate a package manager
archive from your local computer (using `corepack pack -o`) before storing
it somewhere your container will be able to access (for example within your
repository). After that it'll just be a matter of running
`corepack install -g --cache-only <path/to/corepack.tgz>` to setup the cache.
## Utility Commands
### `corepack <binary name>[@<version>] [... args]`
This meta-command runs the specified package manager in the local folder. You
can use it to force an install to run with a given version, which can be useful
when looking for regressions.
Note that those commands still check whether the local project is configured for
the given package manager (ie you won't be able to run `corepack yarn install`
on a project where the `packageManager` field references `pnpm`).
### `corepack cache clean`
Clears the local `COREPACK_HOME` cache directory.
### `corepack cache clear`
Clears the local `COREPACK_HOME` cache directory.
### `corepack enable [... name]`
| Option | Description |
| --------------------- | --------------------------------------- |
| `--install-directory` | Add the shims to the specified location |
This command will detect where Corepack is installed and will create shims next
to it for each of the specified package managers (or all of them if the command
is called without parameters). Note that the npm shims will not be installed
unless explicitly requested, as npm is currently distributed with Node.js
through other means.
If the file system where the `corepack` binary is located is read-only, this
command will fail. A workaround is to add the binaries as alias in your
shell configuration file (e.g. in `~/.bash_aliases`):
```sh
alias yarn="corepack yarn"
alias yarnpkg="corepack yarnpkg"
alias pnpm="corepack pnpm"
alias pnpx="corepack pnpx"
alias npm="corepack npm"
alias npx="corepack npx"
```
On Windows PowerShell, you can add functions using the `$PROFILE` automatic
variable:
```powershell
echo "function yarn { corepack yarn `$args }" >> $PROFILE
echo "function yarnpkg { corepack yarnpkg `$args }" >> $PROFILE
echo "function pnpm { corepack pnpm `$args }" >> $PROFILE
echo "function pnpx { corepack pnpx `$args }" >> $PROFILE
echo "function npm { corepack npm `$args }" >> $PROFILE
echo "function npx { corepack npx `$args }" >> $PROFILE
```
### `corepack disable [... name]`
| Option | Description |
| --------------------- | ------------------------------------------ |
| `--install-directory` | Remove the shims to the specified location |
This command will detect where Node.js is installed and will remove the shims
from there.
### `corepack install`
Download and install the package manager configured in the local project.
This command doesn't change the global version used when running the package
manager from outside the project (use the \`-g,--global\` flag if you wish
to do this).
### `corepack install <-g,--global> [... name[@<version>]]`
Install the selected package managers and install them on the system.
Package managers thus installed will be configured as the new default when
calling their respective binaries outside of projects defining the
`packageManager` field.
### `corepack pack [... name[@<version>]]`
| Option | Description |
| --------------------- | ------------------------------------------ |
| `--json ` | Print the output folder rather than logs |
| `-o,--output ` | Path where to generate the archive |
Download the selected package managers and store them inside a tarball
suitable for use with `corepack install -g`.
### `corepack use <name[@<version>]>`
When run, this command will retrieve the latest release matching the provided
descriptor, assign it to the project's package.json file, and automatically
perform an install.
### `corepack up`
Retrieve the latest available version for the current major release line of
the package manager used in the local project, and update the project to use
it.
Unlike `corepack use` this command doesn't take a package manager name nor a
version range, as it will always select the latest available version from the
range specified in `devEngines.packageManager.version`, or fallback to the
same major line. Should you need to upgrade to a new major, use an explicit
`corepack use {name}@latest` call (or simply `corepack use {name}`).
## Environment Variables
- `COREPACK_DEFAULT_TO_LATEST` can be set to `0` in order to instruct Corepack
not to lookup on the remote registry for the latest version of the selected
package manager, and to not update the Last Known Good version when it
downloads a new version of the same major line.
- `COREPACK_ENABLE_AUTO_PIN` can be set to `1` to instruct Corepack to
update the `packageManager` field when it detects that the local package
doesn't list it. In general we recommend to always list a `packageManager`
field (which you can easily set through `corepack use [name]@[version]`), as
it ensures that your project installs are always deterministic.
- `COREPACK_ENABLE_DOWNLOAD_PROMPT` can be set to `0` to
prevent Corepack showing the URL when it needs to download software, or can be
set to `1` to have the URL shown. By default, when Corepack is called
explicitly (e.g. `corepack pnpm …`), it is set to `0`; when Corepack is called
implicitly (e.g. `pnpm …`), it is set to `1`.
The default value cannot be overridden in a `.corepack.env` file.
When standard input is a TTY and no CI environment is detected, Corepack will
ask for user input before starting the download.
- `COREPACK_ENABLE_UNSAFE_CUSTOM_URLS` can be set to `1` to allow use of
custom URLs to load a package manager known by Corepack (`yarn`, `npm`, and
`pnpm`).
- `COREPACK_ENABLE_NETWORK` can be set to `0` to prevent Corepack from accessing
the network (in which case you'll be responsible for hydrating the package
manager versions that will be required for the projects you'll run, using
`corepack install -g --cache-only`).
- `COREPACK_ENABLE_STRICT` can be set to `0` to prevent Corepack from throwing
error if the package manager does not correspond to the one defined for the
current project. This means that if a user is using the package manager
specified in the current project, it will use the version specified by the
project's `packageManager` field. But if the user is using other package
manager different from the one specified for the current project, it will use
the system-wide package manager version.
- `COREPACK_ENABLE_PROJECT_SPEC` can be set to `0` to prevent Corepack from
checking if the package manager corresponds to the one defined for the current
project. This means that it will always use the system-wide package manager
regardless of what is being specified in the project's `packageManager` field.
- `COREPACK_ENV_FILE` can be set to `0` to request Corepack to not attempt to
load `.corepack.env`; it can be set to a path to specify a different env file.
Only keys that start with `COREPACK_` and are not in the exception list
(`COREPACK_ENABLE_DOWNLOAD_PROMPT` and `COREPACK_ENV_FILE` are ignored)
will be taken into account.
For Node.js 18.x users, this setting has no effect as that version doesn't
support parsing of `.env` files.
- `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
[`proxy-from-env`](https://github.com/Rob--W/proxy-from-env).
- `COREPACK_INTEGRITY_KEYS` can be set to an empty string or `0` to
instruct Corepack to skip integrity checks, or to a JSON string containing
custom keys.
## Troubleshooting
The environment variable `DEBUG` can be set to `corepack` to enable additional debug logging.
### Networking
There are a wide variety of networking issues that can occur while running
`corepack` commands. Things to check:
- Make sure your network connection is active.
- Make sure the host for your request can be resolved by your DNS; try using
`curl [URL]` (ipv4) and `curl -6 [URL]` (ipv6) from your shell.
- Check your proxy settings (see [Environment Variables](#environment-variables)).
## Contributing
See [`CONTRIBUTING.md`](./CONTRIBUTING.md).
## License (MIT)
See [`LICENSE.md`](./LICENSE.md).

4
opt/plesk/node/24/lib/node_modules/corepack/dist/corepack.js generated vendored
View File

@@ -1,4 +0,0 @@
#!/opt/plesk/node/24/bin/node
process.env.COREPACK_ENABLE_DOWNLOAD_PROMPT??='0';
require('module').enableCompileCache?.();
require('./lib/corepack.cjs').runMain(process.argv.slice(2));

23713
opt/plesk/node/24/lib/node_modules/corepack/dist/lib/corepack.cjs generated vendored
View File

File diff suppressed because one or more lines are too long

4
opt/plesk/node/24/lib/node_modules/corepack/dist/npm.js generated vendored
View File

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

4
opt/plesk/node/24/lib/node_modules/corepack/dist/npx.js generated vendored
View File

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

4
opt/plesk/node/24/lib/node_modules/corepack/dist/pnpm.js generated vendored
View File

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

4
opt/plesk/node/24/lib/node_modules/corepack/dist/pnpx.js generated vendored
View File

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

4
opt/plesk/node/24/lib/node_modules/corepack/dist/yarn.js generated vendored
View File

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

4
opt/plesk/node/24/lib/node_modules/corepack/dist/yarnpkg.js generated vendored
View File

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

102
opt/plesk/node/24/lib/node_modules/corepack/package.json generated vendored
View File

@@ -1,102 +0,0 @@
{
"name": "corepack",
"version": "0.34.5",
"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": "^20.10.0 || ^22.11.0 || >=24.0.0"
},
"exports": {
"./package.json": "./package.json"
},
"license": "MIT",
"packageManager": "yarn@4.11.0+sha224.209a3e277c6bbc03df6e4206fbfcb0c1621c27ecf0688f79a0c619f0",
"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": "^3.0.0",
"@yarnpkg/fslib": "^3.0.0-rc.48",
"@zkochan/cmd-shim": "^6.0.0",
"better-sqlite3": "^11.7.2",
"clipanion": "patch:clipanion@npm%3A3.2.1#~/.yarn/patches/clipanion-npm-3.2.1-fc9187f56c.patch",
"debug": "^4.1.1",
"esbuild": "^0.25.0",
"eslint": "^9.22.0",
"proxy-from-env": "^1.1.0",
"semver": "^7.6.3",
"supports-color": "^10.0.0",
"tar": "^7.4.0",
"tsx": "^4.16.2",
"typescript": "^5.7.3",
"undici": "^6.21.2",
"v8-compile-cache": "^2.3.0",
"vitest": "^3.0.5",
"which": "^5.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
opt/plesk/node/24/lib/node_modules/corepack/shims/corepack generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/corepack.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\corepack.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\corepack.js" %*
)

28
opt/plesk/node/24/lib/node_modules/corepack/shims/corepack.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/corepack generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/corepack.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/corepack.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/npm generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/npm.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/npm.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/npx generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/npx.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/npx.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/pnpm generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/pnpm.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/pnpm.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/pnpx generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/pnpx.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/pnpx.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/yarn generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/yarn.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/yarn.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/yarnpkg generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/yarnpkg.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@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
opt/plesk/node/24/lib/node_modules/corepack/shims/nodewin/yarnpkg.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/npm generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/npm.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\npm.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\npm.js" %*
)

28
opt/plesk/node/24/lib/node_modules/corepack/shims/npm.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/npx generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/npx.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\npx.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\npx.js" %*
)

28
opt/plesk/node/24/lib/node_modules/corepack/shims/npx.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/pnpm generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/pnpm.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\pnpm.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\pnpm.js" %*
)

28
opt/plesk/node/24/lib/node_modules/corepack/shims/pnpm.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/pnpx generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/pnpx.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\pnpx.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\pnpx.js" %*
)

28
opt/plesk/node/24/lib/node_modules/corepack/shims/pnpx.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/yarn generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/yarn.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\yarn.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\yarn.js" %*
)

28
opt/plesk/node/24/lib/node_modules/corepack/shims/yarn.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/yarnpkg generated vendored
View File

@@ -1,12 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/corepack/shims/yarnpkg.cmd generated vendored
View File

@@ -1,7 +0,0 @@
@SETLOCAL
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\dist\yarnpkg.js" %*
) ELSE (
@SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\dist\yarnpkg.js" %*
)

28
opt/plesk/node/24/lib/node_modules/corepack/shims/yarnpkg.ps1 generated vendored
View File

@@ -1,28 +0,0 @@
#!/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

0
opt/plesk/node/24/lib/node_modules/npm/.npmrc generated vendored
View File

235
opt/plesk/node/24/lib/node_modules/npm/LICENSE generated vendored
View File

@@ -1,235 +0,0 @@
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.
--------

54
opt/plesk/node/24/lib/node_modules/npm/README.md generated vendored
View File

@@ -1,54 +0,0 @@
# npm - a JavaScript package manager
### Requirements
You should be running a currently supported version of [Node.js](https://nodejs.org/en/download/) to run **`npm`**. For a list of which versions of Node.js are currently supported, please see the [Node.js releases](https://nodejs.org/en/about/previous-releases) page.
### Installation
**`npm`** comes bundled with [**`node`**](https://nodejs.org/), & most third-party distributions, by default. Officially supported downloads/distributions can be found at: [nodejs.org/en/download](https://nodejs.org/en/download)
#### Direct Download
You can download & install **`npm`** directly from [**npmjs**.com](https://npmjs.com/) using our custom `install.sh` script:
```bash
curl -qL https://www.npmjs.com/install.sh | sh
```
#### Node Version Managers
If you're looking to manage multiple versions of **`Node.js`** &/or **`npm`**, consider using a [node version manager](https://github.com/search?q=node+version+manager+archived%3Afalse&type=repositories&ref=advsearch)
### Usage
```bash
npm <command>
```
### Links & Resources
* [**Documentation**](https://docs.npmjs.com/) - Official docs & how-tos for all things **npm**
* Note: you can also search docs locally with `npm help-search <query>`
* [**Bug Tracker**](https://github.com/npm/cli/issues) - Search or submit bugs against the CLI
* [**Roadmap**](https://github.com/orgs/github/projects/4247/views/1?filterQuery=npm) - Track & follow along with our public roadmap
* [**Community Feedback and Discussions**](https://github.com/orgs/community/discussions/categories/npm) - Contribute ideas & discussion around the npm registry, website & CLI
* [**RFCs**](https://github.com/npm/rfcs) - Contribute ideas & specifications for the API/design of the npm CLI
* [**Service Status**](https://status.npmjs.org/) - Monitor the current status & see incident reports for the website & registry
* [**Project Status**](https://npm.github.io/statusboard/) - See the health of all our maintained OSS projects in one view
* [**Support**](https://www.npmjs.com/support) - Experiencing problems with the **npm** [website](https://npmjs.com) or [registry](https://registry.npmjs.org)? [File a ticket](https://www.npmjs.com/support)
### Acknowledgments
* `npm` is configured to use the **npm Public Registry** at [https://registry.npmjs.org](https://registry.npmjs.org) by default; Usage of this registry is subject to **Terms of Use** available at [https://npmjs.com/policies/terms](https://npmjs.com/policies/terms)
* You can configure `npm` to use any other compatible registry you prefer. You can read more about [configuring third-party registries](https://docs.npmjs.com/cli/v7/using-npm/registry)
### FAQ on Branding
#### Is it "npm" or "NPM" or "Npm"?
**`npm`** should never be capitalized unless it is being displayed in a location that is customarily all-capitals (ex. titles on `man` pages).
#### Is "npm" an acronym for "Node Package Manager"?
Contrary to popular belief, **`npm`** **is not** 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
opt/plesk/node/24/lib/node_modules/npm/bin/node-gyp-bin/node-gyp generated vendored
View File

@@ -1,6 +0,0 @@
#!/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
opt/plesk/node/24/lib/node_modules/npm/bin/node-gyp-bin/node-gyp.cmd generated vendored
View File

@@ -1,5 +0,0 @@
if not defined npm_config_node_gyp (
node "%~dp0\..\..\node_modules\node-gyp\bin\node-gyp.js" %*
) else (
node "%npm_config_node_gyp%" %*
)

65
opt/plesk/node/24/lib/node_modules/npm/bin/npm generated vendored
View File

@@ -1,65 +0,0 @@
#!/usr/bin/env bash
# This is used by the Node.js installer, which expects the cygwin/mingw
# shell script to already be present in the npm dependency folder.
(set -o igncr) 2>/dev/null && set -o igncr; # cygwin encoding fix
basedir=`dirname "$0"`
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ `uname` = 'Linux' ] && type wslpath &>/dev/null ; then
IS_WSL="true"
fi
function no_node_dir {
# if this didn't work, then everything else below will fail
echo "Could not determine Node.js install directory" >&2
exit 1
}
NODE_EXE="$basedir/node.exe"
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE="$basedir/node"
fi
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE=node
fi
# this path is passed to node.exe, so it needs to match whatever
# kind of paths Node.js thinks it's using, typically win32 paths.
CLI_BASEDIR="$("$NODE_EXE" -p 'require("path").dirname(process.execPath)' 2> /dev/null)"
if [ $? -ne 0 ]; then
# this fails under WSL 1 so add an additional message. we also suppress stderr above
# because the actual error raised is not helpful. in WSL 1 node.exe cannot handle
# output redirection properly. See https://github.com/microsoft/WSL/issues/2370
if [ "$IS_WSL" == "true" ]; then
echo "WSL 1 is not supported. Please upgrade to WSL 2 or above." >&2
fi
no_node_dir
fi
NPM_PREFIX_JS="$CLI_BASEDIR/node_modules/npm/bin/npm-prefix.js"
NPM_CLI_JS="$CLI_BASEDIR/node_modules/npm/bin/npm-cli.js"
NPM_PREFIX=`"$NODE_EXE" "$NPM_PREFIX_JS"`
if [ $? -ne 0 ]; then
no_node_dir
fi
NPM_PREFIX_NPM_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npm-cli.js"
# a path that will fail -f test on any posix bash
NPM_WSL_PATH="/.."
# WSL can run Windows binaries, so we have to give it the win32 path
# however, WSL bash tests against posix paths, so we need to construct that
# to know if npm is installed globally.
if [ "$IS_WSL" == "true" ]; then
NPM_WSL_PATH=`wslpath "$NPM_PREFIX_NPM_CLI_JS"`
fi
if [ -f "$NPM_PREFIX_NPM_CLI_JS" ] || [ -f "$NPM_WSL_PATH" ]; then
NPM_CLI_JS="$NPM_PREFIX_NPM_CLI_JS"
fi
"$NODE_EXE" "$NPM_CLI_JS" "$@"

2
opt/plesk/node/24/lib/node_modules/npm/bin/npm-cli.js generated vendored
View File

@@ -1,2 +0,0 @@
#!/opt/plesk/node/24/bin/node
require('../lib/cli.js')(process)

30
opt/plesk/node/24/lib/node_modules/npm/bin/npm-prefix.js generated vendored
View File

@@ -1,30 +0,0 @@
#!/opt/plesk/node/24/bin/node
// This is a single-use bin to help windows discover the proper prefix for npm
// without having to load all of npm first
// It does not accept argv params
const path = require('node:path')
const Config = require('@npmcli/config')
const { definitions, flatten, shorthands } = require('@npmcli/config/lib/definitions')
const config = new Config({
npmPath: path.dirname(__dirname),
// argv is explicitly not looked at since prefix is not something that can be changed via argv
argv: [],
definitions,
flatten,
shorthands,
excludeNpmCwd: false,
})
async function main () {
try {
await config.load()
// eslint-disable-next-line no-console
console.log(config.globalPrefix)
} catch (err) {
// eslint-disable-next-line no-console
console.error(err)
process.exit(1)
}
}
main()

20
opt/plesk/node/24/lib/node_modules/npm/bin/npm.cmd generated vendored
View File

@@ -1,20 +0,0 @@
:: Created by npm, please don't edit manually.
@ECHO OFF
SETLOCAL
SET "NODE_EXE=%~dp0\node.exe"
IF NOT EXIST "%NODE_EXE%" (
SET "NODE_EXE=node"
)
SET "NPM_PREFIX_JS=%~dp0\node_modules\npm\bin\npm-prefix.js"
SET "NPM_CLI_JS=%~dp0\node_modules\npm\bin\npm-cli.js"
FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPM_PREFIX_JS%"') DO (
SET "NPM_PREFIX_NPM_CLI_JS=%%F\node_modules\npm\bin\npm-cli.js"
)
IF EXIST "%NPM_PREFIX_NPM_CLI_JS%" (
SET "NPM_CLI_JS=%NPM_PREFIX_NPM_CLI_JS%"
)
"%NODE_EXE%" "%NPM_CLI_JS%" %*

50
opt/plesk/node/24/lib/node_modules/npm/bin/npm.ps1 generated vendored
View File

@@ -1,50 +0,0 @@
#!/usr/bin/env pwsh
Set-StrictMode -Version 'Latest'
$NODE_EXE="$PSScriptRoot/node.exe"
if (-not (Test-Path $NODE_EXE)) {
$NODE_EXE="$PSScriptRoot/node"
}
if (-not (Test-Path $NODE_EXE)) {
$NODE_EXE="node"
}
$NPM_PREFIX_JS="$PSScriptRoot/node_modules/npm/bin/npm-prefix.js"
$NPM_CLI_JS="$PSScriptRoot/node_modules/npm/bin/npm-cli.js"
$NPM_PREFIX=(& $NODE_EXE $NPM_PREFIX_JS)
if ($LASTEXITCODE -ne 0) {
Write-Host "Could not determine Node.js install directory"
exit 1
}
$NPM_PREFIX_NPM_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npm-cli.js"
if (Test-Path $NPM_PREFIX_NPM_CLI_JS) {
$NPM_CLI_JS=$NPM_PREFIX_NPM_CLI_JS
}
if ($MyInvocation.ExpectingInput) { # takes pipeline input
$input | & $NODE_EXE $NPM_CLI_JS $args
} elseif (-not $MyInvocation.Line) { # used "-File" argument
& $NODE_EXE $NPM_CLI_JS $args
} else { # used "-Command" argument
if (($MyInvocation | Get-Member -Name 'Statement') -and $MyInvocation.Statement) {
$NPM_ORIGINAL_COMMAND = $MyInvocation.Statement
} else {
$NPM_ORIGINAL_COMMAND = (
[Management.Automation.InvocationInfo].GetProperty('ScriptPosition', [Reflection.BindingFlags] 'Instance, NonPublic')
).GetValue($MyInvocation).Text
}
$NODE_EXE = $NODE_EXE.Replace("``", "````")
$NPM_CLI_JS = $NPM_CLI_JS.Replace("``", "````")
$NPM_COMMAND_ARRAY = [Management.Automation.Language.Parser]::ParseInput($NPM_ORIGINAL_COMMAND, [ref] $null, [ref] $null).
EndBlock.Statements.PipelineElements.CommandElements.Extent.Text
$NPM_ARGS = ($NPM_COMMAND_ARRAY | Select-Object -Skip 1) -join ' '
Invoke-Expression "& `"$NODE_EXE`" `"$NPM_CLI_JS`" $NPM_ARGS"
}
exit $LASTEXITCODE

65
opt/plesk/node/24/lib/node_modules/npm/bin/npx generated vendored
View File

@@ -1,65 +0,0 @@
#!/usr/bin/env bash
# This is used by the Node.js installer, which expects the cygwin/mingw
# shell script to already be present in the npm dependency folder.
(set -o igncr) 2>/dev/null && set -o igncr; # cygwin encoding fix
basedir=`dirname "$0"`
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ `uname` = 'Linux' ] && type wslpath &>/dev/null ; then
IS_WSL="true"
fi
function no_node_dir {
# if this didn't work, then everything else below will fail
echo "Could not determine Node.js install directory" >&2
exit 1
}
NODE_EXE="$basedir/node.exe"
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE="$basedir/node"
fi
if ! [ -x "$NODE_EXE" ]; then
NODE_EXE=node
fi
# this path is passed to node.exe, so it needs to match whatever
# kind of paths Node.js thinks it's using, typically win32 paths.
CLI_BASEDIR="$("$NODE_EXE" -p 'require("path").dirname(process.execPath)' 2> /dev/null)"
if [ $? -ne 0 ]; then
# this fails under WSL 1 so add an additional message. we also suppress stderr above
# because the actual error raised is not helpful. in WSL 1 node.exe cannot handle
# output redirection properly. See https://github.com/microsoft/WSL/issues/2370
if [ "$IS_WSL" == "true" ]; then
echo "WSL 1 is not supported. Please upgrade to WSL 2 or above." >&2
fi
no_node_dir
fi
NPM_PREFIX_JS="$CLI_BASEDIR/node_modules/npm/bin/npm-prefix.js"
NPX_CLI_JS="$CLI_BASEDIR/node_modules/npm/bin/npx-cli.js"
NPM_PREFIX=`"$NODE_EXE" "$NPM_PREFIX_JS"`
if [ $? -ne 0 ]; then
no_node_dir
fi
NPM_PREFIX_NPX_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npx-cli.js"
# a path that will fail -f test on any posix bash
NPX_WSL_PATH="/.."
# WSL can run Windows binaries, so we have to give it the win32 path
# however, WSL bash tests against posix paths, so we need to construct that
# to know if npm is installed globally.
if [ "$IS_WSL" == "true" ]; then
NPX_WSL_PATH=`wslpath "$NPM_PREFIX_NPX_CLI_JS"`
fi
if [ -f "$NPM_PREFIX_NPX_CLI_JS" ] || [ -f "$NPX_WSL_PATH" ]; then
NPX_CLI_JS="$NPM_PREFIX_NPX_CLI_JS"
fi
"$NODE_EXE" "$NPX_CLI_JS" "$@"

130
opt/plesk/node/24/lib/node_modules/npm/bin/npx-cli.js generated vendored
View File

@@ -1,130 +0,0 @@
#!/opt/plesk/node/24/bin/node
const cli = require('../lib/cli.js')
// run the resulting command as `npm exec ...args`
process.argv[1] = require.resolve('./npm-cli.js')
process.argv.splice(2, 0, 'exec')
// TODO: remove the affordances for removed items in npm v9
const removedSwitches = new Set([
'always-spawn',
'ignore-existing',
'shell-auto-fallback',
])
const removedOpts = new Set([
'npm',
'node-arg',
'n',
])
const removed = new Set([
...removedSwitches,
...removedOpts,
])
const { definitions, shorthands } = require('@npmcli/config/lib/definitions')
const npmSwitches = Object.entries(definitions)
.filter(([, { type }]) => type === Boolean ||
(Array.isArray(type) && type.includes(Boolean)))
.map(([key]) => key)
// things that don't take a value
const switches = new Set([
...removedSwitches,
...npmSwitches,
'no-install',
'quiet',
'q',
'version',
'v',
'help',
'h',
])
// things that do take a value
const opts = new Set([
...removedOpts,
'package',
'p',
'cache',
'userconfig',
'call',
'c',
'shell',
'npm',
'node-arg',
'n',
])
// break out of loop when we find a positional argument or --
// If we find a positional arg, we shove -- in front of it, and
// let the normal npm cli handle the rest.
let i
let sawRemovedFlags = false
for (i = 3; i < process.argv.length; i++) {
const arg = process.argv[i]
if (arg === '--') {
break
} else if (/^-/.test(arg)) {
const [key, ...v] = arg.replace(/^-+/, '').split('=')
switch (key) {
case 'p':
process.argv[i] = ['--package', ...v].join('=')
break
case 'shell':
process.argv[i] = ['--script-shell', ...v].join('=')
break
case 'no-install':
process.argv[i] = '--yes=false'
break
default:
// resolve shorthands and run again
if (shorthands[key] && !removed.has(key)) {
const a = [...shorthands[key]]
if (v.length) {
a.push(v.join('='))
}
process.argv.splice(i, 1, ...a)
i--
continue
}
break
}
if (removed.has(key)) {
// eslint-disable-next-line no-console
console.error(`npx: the --${key} argument has been removed.`)
sawRemovedFlags = true
process.argv.splice(i, 1)
i--
}
if (v.length === 0 && !switches.has(key) &&
(opts.has(key) || !/^-/.test(process.argv[i + 1]))) {
// value will be next argument, skip over it.
if (removed.has(key)) {
// also remove the value for the cut key.
process.argv.splice(i + 1, 1)
} else {
i++
}
}
} else {
// found a positional arg, put -- in front of it, and we're done
process.argv.splice(i, 0, '--')
break
}
}
if (sawRemovedFlags) {
// eslint-disable-next-line no-console
console.error('See `npm help exec` for more information')
}
cli(process)

20
opt/plesk/node/24/lib/node_modules/npm/bin/npx.cmd generated vendored
View File

@@ -1,20 +0,0 @@
:: Created by npm, please don't edit manually.
@ECHO OFF
SETLOCAL
SET "NODE_EXE=%~dp0\node.exe"
IF NOT EXIST "%NODE_EXE%" (
SET "NODE_EXE=node"
)
SET "NPM_PREFIX_JS=%~dp0\node_modules\npm\bin\npm-prefix.js"
SET "NPX_CLI_JS=%~dp0\node_modules\npm\bin\npx-cli.js"
FOR /F "delims=" %%F IN ('CALL "%NODE_EXE%" "%NPM_PREFIX_JS%"') DO (
SET "NPM_PREFIX_NPX_CLI_JS=%%F\node_modules\npm\bin\npx-cli.js"
)
IF EXIST "%NPM_PREFIX_NPX_CLI_JS%" (
SET "NPX_CLI_JS=%NPM_PREFIX_NPX_CLI_JS%"
)
"%NODE_EXE%" "%NPX_CLI_JS%" %*

50
opt/plesk/node/24/lib/node_modules/npm/bin/npx.ps1 generated vendored
View File

@@ -1,50 +0,0 @@
#!/usr/bin/env pwsh
Set-StrictMode -Version 'Latest'
$NODE_EXE="$PSScriptRoot/node.exe"
if (-not (Test-Path $NODE_EXE)) {
$NODE_EXE="$PSScriptRoot/node"
}
if (-not (Test-Path $NODE_EXE)) {
$NODE_EXE="node"
}
$NPM_PREFIX_JS="$PSScriptRoot/node_modules/npm/bin/npm-prefix.js"
$NPX_CLI_JS="$PSScriptRoot/node_modules/npm/bin/npx-cli.js"
$NPM_PREFIX=(& $NODE_EXE $NPM_PREFIX_JS)
if ($LASTEXITCODE -ne 0) {
Write-Host "Could not determine Node.js install directory"
exit 1
}
$NPM_PREFIX_NPX_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npx-cli.js"
if (Test-Path $NPM_PREFIX_NPX_CLI_JS) {
$NPX_CLI_JS=$NPM_PREFIX_NPX_CLI_JS
}
if ($MyInvocation.ExpectingInput) { # takes pipeline input
$input | & $NODE_EXE $NPX_CLI_JS $args
} elseif (-not $MyInvocation.Line) { # used "-File" argument
& $NODE_EXE $NPX_CLI_JS $args
} else { # used "-Command" argument
if (($MyInvocation | Get-Member -Name 'Statement') -and $MyInvocation.Statement) {
$NPX_ORIGINAL_COMMAND = $MyInvocation.Statement
} else {
$NPX_ORIGINAL_COMMAND = (
[Management.Automation.InvocationInfo].GetProperty('ScriptPosition', [Reflection.BindingFlags] 'Instance, NonPublic')
).GetValue($MyInvocation).Text
}
$NODE_EXE = $NODE_EXE.Replace("``", "````")
$NPX_CLI_JS = $NPX_CLI_JS.Replace("``", "````")
$NPX_COMMAND_ARRAY = [Management.Automation.Language.Parser]::ParseInput($NPX_ORIGINAL_COMMAND, [ref] $null, [ref] $null).
EndBlock.Statements.PipelineElements.CommandElements.Extent.Text
$NPX_ARGS = ($NPX_COMMAND_ARRAY | Select-Object -Skip 1) -join ' '
Invoke-Expression "& `"$NODE_EXE`" `"$NPX_CLI_JS`" $NPX_ARGS"
}
exit $LASTEXITCODE

96
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-access.md generated vendored
View File

@@ -1,96 +0,0 @@
---
title: npm-access
section: 1
description: Set access level on published packages
---
### Synopsis
```bash
npm access list packages [<user>|<scope>|<scope:team>] [<package>]
npm access list collaborators [<package> [<user>]]
npm access get status [<package>]
npm access set status=public|private [<package>]
npm access set mfa=none|publish|automation [<package>]
npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]
```
Note: This command is unaware of workspaces.
### Description
Used to set access controls on private packages.
For all of the subcommands, `npm access` will perform actions on the packages in the current working directory if no package name is passed to the subcommand.
* grant / revoke:
Add or remove the ability of users and teams to have read-only or read-write access to a package.
### Details
`npm access` always operates directly on the current registry, configurable from the command line using `--registry=<registry url>`.
Unscoped packages are *always public*.
Scoped packages *default to restricted*, but you can either publish them as public using `npm publish --access=public`, or set their access as public using `npm access set status=public` after the initial publish.
You must have privileges to set the access of a package:
* You are an owner of an unscoped or scoped package.
* You are a member of the team that owns a scope.
* You have been given read-write privileges for a package, either as a member of a team or directly as an owner.
If you have two-factor authentication enabled then you'll be prompted to provide a second factor, or may use the `--otp=...` option to specify it on the command line.
If your account is not paid, then attempts to publish scoped packages will fail with an HTTP 402 status code (logically enough), unless you use
`--access=public`.
Management of teams and team memberships is done with the `npm team` command.
### Configuration
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse()
before saving them to your `package.json`.
Not supported by all npm commands.
#### `otp`
* Default: null
* Type: null or String
This is a one-time password from a two-factor authenticator. It's
needed when publishing or changing package permissions with `npm
access`.
If not set, and a registry response fails with a challenge for a
one-time password, npm will prompt on the command line for one.
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
### See Also
* [`libnpmaccess`](https://npm.im/libnpmaccess)
* [npm team](/commands/npm-team)
* [npm publish](/commands/npm-publish)
* [npm config](/commands/npm-config)
* [npm registry](/using-npm/registry)

87
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-adduser.md generated vendored
View File

@@ -1,87 +0,0 @@
---
title: npm-adduser
section: 1
description: Add a registry user account
---
### Synopsis
```bash
npm adduser
alias: add-user
```
Note: This command is unaware of workspaces.
### Description
Create a new user in the specified registry, and save the credentials to the `.npmrc` file.
If no registry is specified, the default registry will be used (see [`registry`](/using-npm/registry)).
When you run `npm adduser`, the CLI automatically generates a legacy token of `publish` type.
For more information, see [About legacy tokens](/about-access-tokens#about-legacy-tokens).
When using `legacy` for your `auth-type`, the username, password, and email are read in from prompts.
### Configuration
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
#### `scope`
* Default: the scope of the current project, if any, or ""
* Type: String
Associate an operation with a scope for a scoped registry.
Useful when logging in to or out of a private registry:
```
# log in, linking the scope to the custom registry
npm login --scope=@mycorp --registry=https://registry.mycorp.com
# log out, removing the link and the auth token
npm logout --scope=@mycorp
```
This will cause `@mycorp` to be mapped to the registry for future
installation of packages specified according to the pattern
`@mycorp/package`.
This will also cause `npm init` to create a scoped package.
```
# accept all defaults, and create a package named "@foo/whatever",
# instead of just named "whatever"
npm init --scope=@foo --yes
```
#### `auth-type`
* Default: "web"
* Type: "legacy" or "web"
What authentication strategy to use with `login`. Note that if an
`otp` config is given, this value will always be set to `legacy`.
### See Also
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm owner](/commands/npm-owner)
* [npm whoami](/commands/npm-whoami)
* [npm token](/commands/npm-token)
* [npm profile](/commands/npm-profile)

439
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-audit.md generated vendored
View File

@@ -1,439 +0,0 @@
---
title: npm-audit
section: 1
description: Run a security audit
---
### Synopsis
```bash
npm audit [fix|signatures]
```
### Description
The audit command submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities.
If any vulnerabilities are found, then the impact and appropriate remediation will be calculated.
If the `fix` argument is provided, then remediations will be applied to the package tree.
The command will exit with a 0 exit code if no vulnerabilities were found.
Note that some vulnerabilities cannot be fixed automatically and will require manual intervention or review.
Also note that since `npm audit fix` runs a full-fledged `npm install` under the hood, all configs that apply to the installer will also apply to `npm install` -- so things like `npm audit fix --package-lock-only` will work as expected.
By default, the audit command will exit with a non-zero code if any vulnerability is found.
It may be useful in CI environments to include the `--audit-level` parameter to specify the minimum vulnerability level that will cause the command to fail.
This option does not filter the report output, it simply changes the command's failure threshold.
### Package lock
By default npm requires a package-lock or shrinkwrap in order to run the audit.
You can bypass the package lock with `--no-package-lock` but be aware the results may be different with every run, since npm will re-build the dependency tree each time.
### Audit Signatures
To ensure the integrity of packages you download from the public npm registry, or any registry that supports signatures, you can verify the registry signatures of downloaded packages using the npm CLI.
Registry signatures can be verified using the following `audit` command:
```bash
$ npm audit signatures
```
The `audit signatures` command will also verify the provenance attestations of downloaded packages.
Because provenance attestations are such a new feature, security features may be added to (or changed in) the attestation format over time.
To ensure that you're always able to verify attestation signatures check that you're running the latest version of the npm CLI. Please note this often means updating npm beyond the version that ships with Node.js.
The npm CLI supports registry signatures and signing keys provided by any registry if the following conventions are followed:
1. Signatures are provided in the package's `packument` in each published version within the `dist` object:
```json
"dist":{
"..omitted..": "..omitted..",
"signatures": [{
"keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
"sig": "a312b9c3cb4a1b693e8ebac5ee1ca9cc01f2661c14391917dcb111517f72370809..."
}]
}
```
See this [example](https://registry.npmjs.org/light-cycle/1.4.3) of a signed package from the public npm registry.
The `sig` is generated using the following template: `${package.name}@${package.version}:${package.dist.integrity}` and the `keyid` has to match one of the public signing keys below.
2. Public signing keys are provided at `registry-host.tld/-/npm/v1/keys` in the following format:
```
{
"keys": [{
"expires": null,
"keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
"keytype": "ecdsa-sha2-nistp256",
"scheme": "ecdsa-sha2-nistp256",
"key": "{{B64_PUBLIC_KEY}}"
}]
}
```
Keys response:
- `expires`: null or a simplified extended [ISO 8601 format](https://en.wikipedia.org/wiki/ISO_8601): `YYYY-MM-DDTHH:mm:ss.sssZ`
- `keyid`: sha256 fingerprint of the public key
- `keytype`: only `ecdsa-sha2-nistp256` is currently supported by the npm CLI
- `scheme`: only `ecdsa-sha2-nistp256` is currently supported by the npm CLI
- `key`: base64 encoded public key
See this [example key's response from the public npm registry](https://registry.npmjs.org/-/npm/v1/keys).
### Audit Endpoints
There are two audit endpoints that npm may use to fetch vulnerability information: the `Bulk Advisory` endpoint and the `Quick Audit` endpoint.
#### Bulk Advisory Endpoint
As of version 7, npm uses the much faster `Bulk Advisory` endpoint to optimize the speed of calculating audit results.
npm will generate a JSON payload with the name and list of versions of each package in the tree, and POST it to the default configured registry at the path `/-/npm/v1/security/advisories/bulk`.
Any packages in the tree that do not have a `version` field in their package.json file will be ignored.
If any `--omit` options are specified (either via the [`--omit` config](/using-npm/config#omit), or one of the shorthands such as `--production`, `--only=dev`, and so on), then packages will be omitted from the submitted payload as appropriate.
If the registry responds with an error, or with an invalid response, then npm will attempt to load advisory data from the `Quick Audit` endpoint.
The expected result will contain a set of advisory objects for each dependency that matches the advisory range.
Each advisory object contains a `name`, `url`, `id`, `severity`, `vulnerable_versions`, and `title`.
npm then uses these advisory objects to calculate vulnerabilities and meta-vulnerabilities of the dependencies within the tree.
#### Quick Audit Endpoint
If the `Bulk Advisory` endpoint returns an error, or invalid data, npm will attempt to load advisory data from the `Quick Audit` endpoint, which is considerably slower in most cases.
The full package tree as found in `package-lock.json` is submitted, along with the following pieces of additional metadata:
* `npm_version`
* `node_version`
* `platform`
* `arch`
* `node_env`
All packages in the tree are submitted to the Quick Audit endpoint.
Omitted dependency types are skipped when generating the report.
#### Scrubbing
Out of an abundance of caution, npm versions 5 and 6 would "scrub" any packages from the submitted report if their name contained a `/` character, so as to avoid leaking the names of potentially private packages or git URLs.
However, in practice, this resulted in audits often failing to properly detect meta-vulnerabilities, because the tree would appear to be invalid due to missing dependencies, and prevented the detection of vulnerabilities in package trees that used git dependencies or private modules.
This scrubbing has been removed from npm as of version 7.
#### Calculating Meta-Vulnerabilities and Remediations
npm uses the [`@npmcli/metavuln-calculator`](http://npm.im/@npmcli/metavuln-calculator) module to turn a set of security advisories into a set of "vulnerability" objects.
A "meta-vulnerability" is a dependency that is vulnerable by virtue of dependence on vulnerable versions of a vulnerable package.
For example, if the package `foo` is vulnerable in the range `>=1.0.2 <2.0.0`, and the package `bar` depends on `foo@^1.1.0`, then that version of `bar` can only be installed by installing a vulnerable version of `foo`.
In this case, `bar` is a "metavulnerability".
Once metavulnerabilities for a given package are calculated, they are cached in the `~/.npm` folder and only re-evaluated if the advisory range changes, or a new version of the package is published (in which case, the new version is checked for metavulnerable status as well).
If the chain of metavulnerabilities extends all the way to the root project, and it cannot be updated without changing its dependency ranges, then `npm audit fix` will require the `--force` option to apply the remediation.
If remediations do not require changes to the dependency ranges, then all vulnerable packages will be updated to a version that does not have an advisory or metavulnerability posted against it.
### Exit Code
The `npm audit` command will exit with a 0 exit code if no vulnerabilities were found.
The `npm audit fix` command will exit with 0 exit code if no vulnerabilities are found _or_ if the remediation is able to successfully fix all vulnerabilities.
If vulnerabilities were found the exit code will depend on the [`audit-level` config](/using-npm/config#audit-level).
### Examples
Scan your project for vulnerabilities and automatically install any compatible updates to vulnerable dependencies:
```bash
$ npm audit fix
```
Run `audit fix` without modifying `node_modules`, but still updating the pkglock:
```bash
$ npm audit fix --package-lock-only
```
Skip updating `devDependencies`:
```bash
$ npm audit fix --only=prod
```
Have `audit fix` install SemVer-major updates to toplevel dependencies, not just SemVer-compatible ones:
```bash
$ npm audit fix --force
```
Do a dry run to get an idea of what `audit fix` will do, and _also_ output install information in JSON format:
```bash
$ npm audit fix --dry-run --json
```
Scan your project for vulnerabilities and just show the details, without fixing anything:
```bash
$ npm audit
```
Get the detailed audit report in JSON format:
```bash
$ npm audit --json
```
Fail an audit only if the results include a vulnerability with a level of moderate or higher:
```bash
$ npm audit --audit-level=moderate
```
### Configuration
#### `audit-level`
* Default: null
* Type: null, "info", "low", "moderate", "high", "critical", or "none"
The minimum level of vulnerability for `npm audit` to exit with a
non-zero exit code.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it
should only report what it would have done. This can be passed into
any of the commands that modify your local installation, eg,
`install`, `update`, `dedupe`, `uninstall`, as well as `pack` and
`publish`.
Note: This is NOT honored by other network related commands, eg
`dist-tags`, `owner`, etc.
#### `force`
* Default: false
* Type: Boolean
Removes various protections against unfortunate side effects, common
mistakes, unnecessary performance degradation, and malicious input.
* Allow clobbering non-npm files in global installs.
* Allow the `npm version` command to work on an unclean git repository.
* Allow deleting the cache folder with `npm cache clean`.
* Allow installing packages that have an `engines` declaration
requiring a different version of npm.
* Allow installing packages that have an `engines` declaration
requiring a different version of `node`, even if `--engine-strict` is
enabled.
* Allow `npm audit fix` to install modules outside your stated
dependency range (including SemVer-major changes).
* Allow unpublishing all versions of a published package.
* Allow conflicting peerDependencies to be installed in the root
project.
* Implicitly set `--yes` during `npm init`.
* Allow clobbering existing values in `npm pkg`
* Allow unpublishing of entire packages (not just a single version).
If you don't have a clear idea of what you want to do, it is strongly
recommended that you do not use this option!
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse()
before saving them to your `package.json`.
Not supported by all npm commands.
#### `package-lock-only`
* Default: false
* Type: Boolean
If set to true, the current operation will only use the
`package-lock.json`, ignoring `node_modules`.
For `update` this means only the `package-lock.json` will be updated,
instead of checking `node_modules` and downloading dependencies.
For `list` this means the output will be based on the tree described
by the `package-lock.json`, rather than the contents of
`node_modules`.
#### `package-lock`
* Default: true
* Type: Boolean
If set to false, then ignore `package-lock.json` files when
installing. This will also prevent _writing_ `package-lock.json` if
`save` is true.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists,
then it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV`
environment variable will be set to `'production'` for all lifecycle
scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple
times)
Option that allows for defining which types of dependencies to
install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted,
regardless of the order in which omit/include are specified on the
command-line.
#### `foreground-scripts`
* Default: `false` unless when using `npm pack` or `npm publish` where
it defaults to `true`
* Type: Boolean
Run all build scripts (ie, `preinstall`, `install`, and
`postinstall`) scripts for installed packages in the foreground
process, sharing standard input, output, and error with the main npm
process.
Note that this will generally make installs run slower, and be much
noisier, but can be useful for debugging.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script,
such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm
run` will still run their intended script if `ignore-scripts` is set,
but they will *not* run any pre- or post-scripts.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as
regular dependencies instead of creating a symlink. This option has
no effect on workspaces.
### See Also
* [npm install](/commands/npm-install)
* [config](/using-npm/config)

108
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-bugs.md generated vendored
View File

@@ -1,108 +0,0 @@
---
title: npm-bugs
section: 1
description: Report bugs for a package in a web browser
---
### Synopsis
```bash
npm bugs [<pkgname> [<pkgname> ...]]
alias: issues
```
### Description
This command tries to guess at the likely location of a package's bug tracker URL or the `mailto` URL of the support email, and then tries to open it using the [`--browser` config](/using-npm/config#browser) param.
If no package name is provided, it will search for a `package.json` in the current folder and use the `name` property.
### Configuration
#### `browser`
* Default: macOS: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: null, Boolean, or String
The browser that is called by npm commands to open websites.
Set to `false` to suppress browser behavior and instead print urls to
terminal.
Set to `true` to use default system URL opener.
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
### See Also
* [npm docs](/commands/npm-docs)
* [npm view](/commands/npm-view)
* [npm publish](/commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)

100
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-cache.md generated vendored
View File

@@ -1,100 +0,0 @@
---
title: npm-cache
section: 1
description: Manipulates packages cache
---
### Synopsis
```bash
npm cache add <package-spec>
npm cache clean [<key>]
npm cache ls [<name>@<version>]
npm cache verify
npm cache npx ls
npm cache npx rm [<key>...]
npm cache npx info <key>...
```
Note: This command is unaware of workspaces.
### Description
Used to add, list, or clean the `npm cache` folder.
Also used to view info about entries in the `npm exec` (aka `npx`) cache folder.
#### `npm cache`
* add:
Add the specified packages to the local cache.
This command is primarily intended to be used internally by npm, but it can provide a way to add data to the local installation cache explicitly.
* clean:
Delete a single entry or all entries out of the cache folder.
Note that this is typically unnecessary, as npm's cache is self-healing and resistant to data corruption issues.
* ls:
List given entries or all entries in the local cache.
* verify:
Verify the contents of the cache folder, garbage collecting any unneeded data, and verifying the integrity of the cache index and all cached data.
#### `npm cache npx`
* ls:
List all entries in the npx cache.
* rm:
Remove given entries or all entries from the npx cache.
* info:
Get detailed information about given entries in the npx cache.
### Details
npm stores cache data in an opaque directory within the configured `cache`, named `_cacache`.
This directory is a [`cacache`](http://npm.im/cacache)-based content-addressable cache that stores all http request data as well as other package-related data.
This directory is primarily accessed through `pacote`, the library responsible for all package fetching as of npm@5.
All data that passes through the cache is fully verified for integrity on both insertion and extraction.
Cache corruption will either trigger an error, or signal to `pacote` that the data must be refetched, which it will do automatically.
For this reason, it should never be necessary to clear the cache for any reason other than reclaiming disk space, thus why `clean` now requires `--force` to run.
There is currently no method exposed through npm to inspect or directly manage the contents of this cache.
In order to access it, `cacache` must be used directly.
npm will not remove data by itself: the cache will grow as new packages are installed.
### A note about the cache's design
The npm cache is strictly a cache: it should not be relied upon as a persistent and reliable data store for package data.
npm makes no guarantee that a previously-cached piece of data will be available later, and will automatically delete corrupted contents.
The primary guarantee that the cache makes is that, if it does return data, that data will be exactly the data that was inserted.
To run an offline verification of existing cache contents, use `npm cache verify`.
### Configuration
#### `cache`
* Default: Windows: `%LocalAppData%\npm-cache`, Posix: `~/.npm`
* Type: Path
The location of npm's cache directory.
### See Also
* [package spec](/using-npm/package-spec)
* [npm folders](/configuring-npm/folders)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm install](/commands/npm-install)
* [npm publish](/commands/npm-publish)
* [npm pack](/commands/npm-pack)
* [npm exec](/commands/npm-exec)
* https://npm.im/cacache
* https://npm.im/pacote
* https://npm.im/@npmcli/arborist
* https://npm.im/make-fetch-happen

321
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-ci.md generated vendored
View File

@@ -1,321 +0,0 @@
---
title: npm-ci
section: 1
description: Clean install a project
---
### Synopsis
```bash
npm ci
aliases: clean-install, ic, install-clean, isntall-clean
```
### Description
This command is similar to [`npm install`](/commands/npm-install), except it's meant to be used in automated environments such as test platforms, continuous integration, and deployment -- or any situation where you want to make sure you're doing a clean install of your dependencies.
The main differences between using `npm install` and `npm ci` are:
* The project **must** have an existing `package-lock.json` or
`npm-shrinkwrap.json`.
* If dependencies in the package lock do not match those in `package.json`,
`npm ci` will exit with an error, instead of updating the package lock.
* `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.
* If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
* It will never write to `package.json` or any of the package-locks:
installs are essentially frozen.
NOTE: If you create your `package-lock.json` file by running `npm install` with flags that can affect the shape of your dependency tree, such as
`--legacy-peer-deps` or `--install-links`, you _must_ provide the same flags to `npm ci` or you are likely to encounter errors.
An easy way to do this is to run, for example,
`npm config set legacy-peer-deps=true --location=project` and commit the
`.npmrc` file to your repo.
### Example
Make sure you have a package-lock and an up-to-date install:
```bash
$ cd ./my/npm/project
$ npm install
added 154 packages in 10s
$ ls | grep package-lock
```
Run `npm ci` in that project
```bash
$ npm ci
added 154 packages in 5s
```
Configure Travis CI to build using `npm ci` instead of `npm install`:
```bash
# .travis.yml
install:
- npm ci
# keep the npm cache around to speed up installs
cache:
directories:
- "$HOME/.npm"
```
### Configuration
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as
necessary within directory structure. nested: (formerly
--legacy-bundling) install in place, no hoisting. shallow (formerly
--global-style) only install direct deps at top-level. linked:
(experimental) install in node_modules/.store, link in place,
unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install
packages in the same manner that they are depended on. This may cause
very deep directory structures and duplicate package installs as
there is no de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but
hoist on deeper dependencies. Sets `--install-strategy=shallow`.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists,
then it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV`
environment variable will be set to `'production'` for all lifecycle
scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple
times)
Option that allows for defining which types of dependencies to
install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted,
regardless of the order in which omit/include are specified on the
command-line.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure,
even if npm could reasonably guess the appropriate resolution based
on non-peer dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency
graph will be resolved using the nearest non-peer dependency
specification, even if doing so will result in some packages
receiving a peer dependency outside the range set in their package's
`peerDependencies` object.
When such an override is performed, a warning is printed, explaining
the conflict and the packages involved. If `--strict-peer-deps` is
set, then this warning is treated as a failure.
#### `foreground-scripts`
* Default: `false` unless when using `npm pack` or `npm publish` where
it defaults to `true`
* Type: Boolean
Run all build scripts (ie, `preinstall`, `install`, and
`postinstall`) scripts for installed packages in the foreground
process, sharing standard input, output, and error with the main npm
process.
Note that this will generally make installs run slower, and be much
noisier, but can be useful for debugging.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script,
such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm
run` will still run their intended script if `ignore-scripts` is set,
but they will *not* run any pre- or post-scripts.
#### `audit`
* Default: true
* Type: Boolean
When "true" submit audit reports alongside the current npm command to
the default registry and all registries configured for scopes. See
the documentation for [`npm audit`](/commands/npm-audit) for details
on what is submitted.
#### `bin-links`
* Default: true
* Type: Boolean
Tells npm to create symlinks (or `.cmd` shims on Windows) for package
executables.
Set to false to have it not do this. This can be used to work around
the fact that some file systems don't support symlinks, even on
ostensibly Unix systems.
#### `fund`
* Default: true
* Type: Boolean
When "true" displays the message at the end of each `npm install`
acknowledging the number of dependencies looking for funding. See
[`npm fund`](/commands/npm-fund) for details.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it
should only report what it would have done. This can be passed into
any of the commands that modify your local installation, eg,
`install`, `update`, `dedupe`, `uninstall`, as well as `pack` and
`publish`.
Note: This is NOT honored by other network related commands, eg
`dist-tags`, `owner`, etc.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as
regular dependencies instead of creating a symlink. This option has
no effect on workspaces.
### See Also
* [npm install](/commands/npm-install)
* [package-lock.json](/configuring-npm/package-lock-json)

36
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-completion.md generated vendored
View File

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

178
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-config.md generated vendored
View File

@@ -1,178 +0,0 @@
---
title: npm-config
section: 1
description: Manage the npm configuration files
---
### Synopsis
```bash
npm config set <key>=<value> [<key>=<value> ...]
npm config get [<key> [<key> ...]]
npm config delete <key> [<key> ...]
npm config list [--json]
npm config edit
npm config fix
alias: c
```
Note: This command is unaware of workspaces.
### Description
npm gets its config settings from the command line, environment variables, `npmrc` files, and in some cases, the `package.json` file.
See [npmrc](/configuring-npm/npmrc) for more information about the npmrc files.
See [config](/using-npm/config) for a more thorough explanation of the mechanisms involved, and a full list of config options available.
The `npm config` command can be used to update and edit the contents of the user and global npmrc files.
### Sub-commands
Config supports the following sub-commands:
#### set
```bash
npm config set key=value [key=value...]
npm set key=value [key=value...]
```
Sets each of the config keys to the value provided.
Modifies the user configuration file unless [`location`](/commands/npm-config#location) is passed.
If value is omitted, the key will be removed from your config file entirely.
Note: for backwards compatibility, `npm config set key value` is supported as an alias for `npm config set key=value`.
#### get
```bash
npm config get [key ...]
npm get [key ...]
```
Echo the config value(s) to stdout.
If multiple keys are provided, then the values will be prefixed with the key names.
If no keys are provided, then this command behaves the same as `npm config list`.
#### list
```bash
npm config list
```
Show all the config settings.
Use `-l` to also show defaults.
Use `--json` to show the settings in json format.
#### delete
```bash
npm config delete key [key ...]
```
Deletes the specified keys from all configuration files.
#### edit
```bash
npm config edit
```
Opens the config file in an editor.
Use the `--global` flag to edit the global config.
#### fix
```bash
npm config fix
```
Attempts to repair invalid configuration items.
Usually this means attaching authentication config (i.e.
`_auth`, `_authToken`) to the configured `registry`.
### Configuration
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse()
before saving them to your `package.json`.
Not supported by all npm commands.
#### `global`
* Default: false
* Type: Boolean
Operates in "global" mode, so that packages are installed into the
`prefix` folder instead of the current working directory. See
[folders](/configuring-npm/folders) for more on the differences in
behavior.
* packages are installed into the `{prefix}/lib/node_modules` folder,
instead of the current working directory.
* bin files are linked to `{prefix}/bin`
* man pages are linked to `{prefix}/share/man`
#### `editor`
* Default: The EDITOR or VISUAL environment variables, or
'%SYSTEMROOT%\notepad.exe' on Windows, or 'vi' on Unix systems
* Type: String
The command to run for `npm edit` and `npm config edit`.
#### `location`
* Default: "user" unless `--global` is passed, which will also set this
value to "global"
* Type: "global", "user", or "project"
When passed to `npm config` this refers to which config file to use.
When set to "global" mode, packages are installed into the `prefix`
folder instead of the current working directory. See
[folders](/configuring-npm/folders) for more on the differences in
behavior.
* packages are installed into the `{prefix}/lib/node_modules` folder,
instead of the current working directory.
* bin files are linked to `{prefix}/bin`
* man pages are linked to `{prefix}/share/man`
#### `long`
* Default: false
* Type: Boolean
Show extended information in `ls`, `search`, and `help-search`.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm config](/commands/npm-config)
* [package.json](/configuring-npm/package-json)
* [npmrc](/configuring-npm/npmrc)
* [npm](/commands/npm)

318
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-dedupe.md generated vendored
View File

@@ -1,318 +0,0 @@
---
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
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as
necessary within directory structure. nested: (formerly
--legacy-bundling) install in place, no hoisting. shallow (formerly
--global-style) only install direct deps at top-level. linked:
(experimental) install in node_modules/.store, link in place,
unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install
packages in the same manner that they are depended on. This may cause
very deep directory structures and duplicate package installs as
there is no de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but
hoist on deeper dependencies. Sets `--install-strategy=shallow`.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure,
even if npm could reasonably guess the appropriate resolution based
on non-peer dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency
graph will be resolved using the nearest non-peer dependency
specification, even if doing so will result in some packages
receiving a peer dependency outside the range set in their package's
`peerDependencies` object.
When such an override is performed, a warning is printed, explaining
the conflict and the packages involved. If `--strict-peer-deps` is
set, then this warning is treated as a failure.
#### `package-lock`
* Default: true
* Type: Boolean
If set to false, then ignore `package-lock.json` files when
installing. This will also prevent _writing_ `package-lock.json` if
`save` is true.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists,
then it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV`
environment variable will be set to `'production'` for all lifecycle
scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple
times)
Option that allows for defining which types of dependencies to
install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted,
regardless of the order in which omit/include are specified on the
command-line.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script,
such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm
run` will still run their intended script if `ignore-scripts` is set,
but they will *not* run any pre- or post-scripts.
#### `audit`
* Default: true
* Type: Boolean
When "true" submit audit reports alongside the current npm command to
the default registry and all registries configured for scopes. See
the documentation for [`npm audit`](/commands/npm-audit) for details
on what is submitted.
#### `bin-links`
* Default: true
* Type: Boolean
Tells npm to create symlinks (or `.cmd` shims on Windows) for package
executables.
Set to false to have it not do this. This can be used to work around
the fact that some file systems don't support symlinks, even on
ostensibly Unix systems.
#### `fund`
* Default: true
* Type: Boolean
When "true" displays the message at the end of each `npm install`
acknowledging the number of dependencies looking for funding. See
[`npm fund`](/commands/npm-fund) for details.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it
should only report what it would have done. This can be passed into
any of the commands that modify your local installation, eg,
`install`, `update`, `dedupe`, `uninstall`, as well as `pack` and
`publish`.
Note: This is NOT honored by other network related commands, eg
`dist-tags`, `owner`, etc.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as
regular dependencies instead of creating a symlink. This option has
no effect on workspaces.
### See Also
* [npm find-dupes](/commands/npm-find-dupes)
* [npm ls](/commands/npm-ls)
* [npm update](/commands/npm-update)
* [npm install](/commands/npm-install)

87
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-deprecate.md generated vendored
View File

@@ -1,87 +0,0 @@
---
title: npm-deprecate
section: 1
description: Deprecate a version of a package
---
### Synopsis
```bash
npm deprecate <package-spec> <message>
```
Note: This command is unaware of workspaces.
### Description
This command will update the npm registry entry for a package, providing a deprecation warning to all who attempt to install it.
It works on [version ranges](https://semver.npmjs.com/) as well as specific versions, so you can do something like this:
```bash
npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
```
SemVer ranges passed to this command are interpreted such that they *do* include prerelease versions.
For example:
```bash
npm deprecate my-thing@1.x "1.x is no longer supported"
```
In this case, a version `my-thing@1.0.0-beta.0` will also be deprecated.
You must be the package owner to deprecate something.
See the `owner` and `adduser` help topics.
To un-deprecate a package, specify an empty string (`""`) for the `message` argument.
Note that you must use double quotes with no space between them to format an empty string.
### Configuration
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
#### `otp`
* Default: null
* Type: null or String
This is a one-time password from a two-factor authenticator. It's
needed when publishing or changing package permissions with `npm
access`.
If not set, and a registry response fails with a challenge for a
one-time password, npm will prompt on the command line for one.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it
should only report what it would have done. This can be passed into
any of the commands that modify your local installation, eg,
`install`, `update`, `dedupe`, `uninstall`, as well as `pack` and
`publish`.
Note: This is NOT honored by other network related commands, eg
`dist-tags`, `owner`, etc.
### See Also
* [package spec](/using-npm/package-spec)
* [npm publish](/commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm owner](/commands/npm-owner)
* [npm adduser](/commands/npm-adduser)

285
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-diff.md generated vendored
View File

@@ -1,285 +0,0 @@
---
title: npm-diff
section: 1
description: The registry diff command
---
### Synopsis
```bash
npm diff [...<paths>]
```
### Description
Similar to its `git diff` counterpart, this command will print diff patches of files for packages published to the npm registry.
* `npm diff --diff=<spec-a> --diff=<spec-b>`
Compares two package versions using their registry specifiers, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0`.
It's also possible to compare across forks of any package, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0`.
Any valid spec can be used, so that it's also possible to compare directories or git repositories, e.g: `npm diff --diff=pkg@latest --diff=./packages/pkg`
Here's an example comparing two different versions of a package named `abbrev` from the registry:
```bash
npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1
```
On success, output looks like:
```bash
diff --git a/package.json b/package.json
index v1.1.0..v1.1.1 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
{
"name": "abbrev",
- "version": "1.1.0",
+ "version": "1.1.1",
"description": "Like ruby's abbrev module, but in js",
"author": "Isaac Z. Schlueter <i@izs.me>",
"main": "abbrev.js",
```
Given the flexible nature of npm specs, you can also target local directories or git repos just like when using `npm install`:
```bash
npm diff --diff=https://github.com/npm/libnpmdiff --diff=./local-path
```
In the example above we can compare the contents from the package installed from the git repo at `github.com/npm/libnpmdiff` with the contents of the `./local-path` that contains a valid package, such as a modified copy of the original.
* `npm diff` (in a package directory, no arguments):
If the package is published to the registry, `npm diff` will fetch the tarball version tagged as `latest` (this value can be configured using the `tag` option) and proceed to compare the contents of files present in that tarball, with the current files in your local file system.
This workflow provides a handy way for package authors to see what package-tracked files have been changed in comparison with the latest published version of that package.
* `npm diff --diff=<pkg-name>` (in a package directory):
When using a single package name (with no version or tag specifier) as an argument, `npm diff` will work in a similar way to [`npm-outdated`](npm-outdated) and reach for the registry to figure out what current published version of the package named `<pkg-name>` will satisfy its dependent declared semver-range.
Once that specific version is known `npm diff` will print diff patches comparing the current version of `<pkg-name>` found in the local file system with that specific version returned by the registry.
Given a package named `abbrev` that is currently installed:
```bash
npm diff --diff=abbrev
```
That will request from the registry its most up to date version and will print a diff output comparing the currently installed version to this newer one if the version numbers are not the same.
* `npm diff --diff=<spec-a>` (in a package directory):
Similar to using only a single package name, it's also possible to declare a full registry specifier version if you wish to compare the local version of an installed package with the specific version/tag/semver-range provided in `<spec-a>`.
An example: assuming `pkg@1.0.0` is installed in the current `node_modules` folder, running:
```bash
npm diff --diff=pkg@2.0.0
```
It will effectively be an alias to
`npm diff --diff=pkg@1.0.0 --diff=pkg@2.0.0`.
* `npm diff --diff=<semver-a> [--diff=<semver-b>]` (in a package directory):
Using `npm diff` along with semver-valid version numbers is a shorthand to compare different versions of the current package.
It needs to be run from a package directory, such that for a package named `pkg` running `npm diff --diff=1.0.0 --diff=1.0.1` is the same as running `npm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1`.
If only a single argument `<version-a>` is provided, then the current local file system is going to be compared against that version.
Here's an example comparing two specific versions (published to the configured registry) of the current project directory:
```bash
npm diff --diff=1.0.0 --diff=1.1.0
```
Note that tag names are not valid `--diff` argument values, if you wish to compare to a published tag, you must use the `pkg@tagname` syntax.
#### Filtering files
It's possible to also specify positional arguments using file names or globs pattern matching in order to limit the result of diff patches to only a subset of files for a given package, e.g:
```bash
npm diff --diff=pkg@2 ./lib/ CHANGELOG.md
```
In the example above the diff output is only going to print contents of files located within the folder `./lib/` and changed lines of code within the `CHANGELOG.md` file.
### Configuration
#### `diff`
* Default:
* Type: String (can be set multiple times)
Define arguments to compare in `npm diff`.
#### `diff-name-only`
* Default: false
* Type: Boolean
Prints only filenames when using `npm diff`.
#### `diff-unified`
* Default: 3
* Type: Number
The number of lines of context to print in `npm diff`.
#### `diff-ignore-all-space`
* Default: false
* Type: Boolean
Ignore whitespace when comparing lines in `npm diff`.
#### `diff-no-prefix`
* Default: false
* Type: Boolean
Do not show any source or destination prefix in `npm diff` output.
Note: this causes `npm diff` to ignore the `--diff-src-prefix` and
`--diff-dst-prefix` configs.
#### `diff-src-prefix`
* Default: "a/"
* Type: String
Source prefix to be used in `npm diff` output.
#### `diff-dst-prefix`
* Default: "b/"
* Type: String
Destination prefix to be used in `npm diff` output.
#### `diff-text`
* Default: false
* Type: Boolean
Treat all files as text in `npm diff`.
#### `global`
* Default: false
* Type: Boolean
Operates in "global" mode, so that packages are installed into the
`prefix` folder instead of the current working directory. See
[folders](/configuring-npm/folders) for more on the differences in
behavior.
* packages are installed into the `{prefix}/lib/node_modules` folder,
instead of the current working directory.
* bin files are linked to `{prefix}/bin`
* man pages are linked to `{prefix}/share/man`
#### `tag`
* Default: "latest"
* Type: String
If you ask npm to install a package and don't tell it a specific
version, then it will install the specified tag.
It is the tag added to the package@version specified in the `npm
dist-tag add` command, if no explicit tag is given.
When used by the `npm diff` command, this is the tag used to fetch
the tarball that will be compared with the local files by default.
If used in the `npm publish` command, this is the tag that will be
added to the package submitted to the registry.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
## See Also
* [npm outdated](/commands/npm-outdated)
* [npm install](/commands/npm-install)
* [npm config](/commands/npm-config)
* [npm registry](/using-npm/registry)

140
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-dist-tag.md generated vendored
View File

@@ -1,140 +0,0 @@
---
title: npm-dist-tag
section: 1
description: Modify package distribution tags
---
### Synopsis
```bash
npm dist-tag add <package-spec (with version)> [<tag>]
npm dist-tag rm <package-spec> <tag>
npm dist-tag ls [<package-spec>]
alias: dist-tags
```
### Description
Add, remove, and enumerate distribution tags on a package:
* add: Tags the specified version of the package with the specified tag, or the [`--tag` config](/using-npm/config#tag) if not specified.
If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp <one-time password>`, or go through a second factor flow based on your `authtype`.
* rm: Clear a tag that is no longer in use from the package.
If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp <one-time password>`, or go through a second factor flow based on your `authtype`
* ls: Show all of the dist-tags for a package, defaulting to the package in the current prefix.
This is the default action if none is specified.
A tag can be used when installing packages as a reference to a version instead of using a specific version number:
```bash
npm install <name>@<tag>
```
When installing dependencies, a preferred tagged version may be specified:
```bash
npm install --tag <tag>
```
(This also applies to any other commands that resolve and install dependencies, such as `npm dedupe`, `npm update`, and `npm audit fix`.)
Publishing a package sets the `latest` tag to the published version unless the `--tag` option is used.
For example, `npm publish --tag=beta`.
By default, `npm install <pkg>` (without any `@<version>` or `@<tag>` specifier) installs the `latest` tag.
### Purpose
Tags can be used to provide an alias instead of version numbers.
For example, a project might choose to have multiple streams of development and use a different tag for each stream, e.g., `stable`, `beta`, `dev`,
`canary`.
By default, the `latest` tag is used by npm to identify the current version of a package, and `npm install <pkg>` (without any `@<version>` or `@<tag>` specifier) installs the `latest` tag.
Typically, projects only use the `latest` tag for stable release versions, and use other tags for unstable versions such as prereleases.
The `next` tag is used by some projects to identify the upcoming version.
Other than `latest`, no tag has any special significance to npm itself.
### Caveats
This command used to be known as `npm tag`, which only created new tags, and so had a different syntax.
Tags must share a namespace with version numbers, because they are specified in the same slot: `npm install <pkg>@<version>` vs `npm install <pkg>@<tag>`.
Tags that can be interpreted as valid semver ranges will be rejected.
For example, `v1.4` cannot be used as a tag, because it is interpreted by semver as `>=1.4.0 <1.5.0`.
See <https://github.com/npm/npm/issues/6082>.
The simplest way to avoid semver problems with tags is to use tags that do not begin with a number or the letter `v`.
### Configuration
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
### See Also
* [package spec](/using-npm/package-spec)
* [npm publish](/commands/npm-publish)
* [npm install](/commands/npm-install)
* [npm dedupe](/commands/npm-dedupe)
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

108
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-docs.md generated vendored
View File

@@ -1,108 +0,0 @@
---
title: npm-docs
section: 1
description: Open documentation for a package in a web browser
---
### Synopsis
```bash
npm docs [<pkgname> [<pkgname> ...]]
alias: home
```
### Description
This command tries to guess at the likely location of a package's documentation URL, and then tries to open it using the [`--browser` config](/using-npm/config#browser) param.
You can pass multiple package names at once.
If no package name is provided, it will search for a `package.json` in the current folder and use the `name` property.
### Configuration
#### `browser`
* Default: macOS: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: null, Boolean, or String
The browser that is called by npm commands to open websites.
Set to `false` to suppress browser behavior and instead print urls to
terminal.
Set to `true` to use default system URL opener.
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
### See Also
* [npm view](/commands/npm-view)
* [npm publish](/commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)

98
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-doctor.md generated vendored
View File

@@ -1,98 +0,0 @@
---
title: npm-doctor
section: 1
description: Check the health of your npm environment
---
### Synopsis
```bash
npm doctor [connection] [registry] [versions] [environment] [permissions] [cache]
```
Note: This command is unaware of workspaces.
### Description
`npm doctor` runs a set of checks to ensure that your npm installation has what it needs to manage your JavaScript packages.
npm is mostly a standalone tool, but it does have some basic requirements that must be met:
+ Node.js and git must be executable by npm.
+ The primary npm registry, `registry.npmjs.com`, or another service that uses the registry API, is available.
+ The directories that npm uses, `node_modules` (both locally and globally), exist and can be written by the current user.
+ The npm cache exists, and the package tarballs within it aren't corrupt.
Without all of these working properly, npm may not work properly.
Many issues are often attributable to things that are outside npm's code base, so `npm doctor` confirms that the npm installation is in a good state.
Also, in addition to this, there are also very many issue reports due to using old versions of npm.
Since npm is constantly improving, running `npm@latest` is better than an old version.
`npm doctor` verifies the following items in your environment, and if there are any recommended changes, it will display them.
By default npm runs all of these checks.
You can limit what checks are ran by specifying them as extra arguments.
#### `Connecting to the registry`
By default, npm installs from the primary npm registry,
`registry.npmjs.org`.
`npm doctor` hits a special connection testing endpoint within the registry.
This can also be checked with `npm ping`.
If this check fails, you may be using a proxy that needs to be configured, or may need to talk to your IT staff to get access over HTTPS to `registry.npmjs.org`.
This check is done against whichever registry you've configured (you can see what that is by running `npm config get registry`), and if you're using a private registry that doesn't support the `/whoami` endpoint supported by the primary registry, this check may fail.
#### `Checking npm version`
While Node.js may come bundled with a particular version of npm, it's the policy of the CLI team that we recommend all users run `npm@latest` if they can.
As the CLI is maintained by a small team of contributors, there are only resources for a single line of development, so npm's own long-term support releases typically only receive critical security and regression fixes.
The team believes that the latest tested version of npm is almost always likely to be the most functional and defect-free version of npm.
#### `Checking node version`
For most users, in most circumstances, the best version of Node will be the latest long-term support (LTS) release.
Those of you who want access to new ECMAscript features or bleeding-edge changes to Node's standard library may be running a newer version, and some may be required to run an older version of Node because of enterprise change control policies.
That's OK!
But in general, the npm team recommends that most users run Node.js LTS.
#### `Checking configured npm registry`
You may be installing from private package registries for your project or company.
That's great! Others may be following tutorials or StackOverflow questions in an effort to troubleshoot problems you may be having.
Sometimes, this may entail changing the registry you're pointing at.
This part of `npm doctor` just lets you, and maybe whoever's helping you with support, know that you're not using the default registry.
#### `Checking for git executable in PATH`
While it's documented in the README, it may not be obvious that npm needs Git installed to do many of the things that it does.
Also, in some cases – especially on Windows – you may have Git set up in such a way that it's not accessible via your `PATH` so that npm can find it.
This check ensures that Git is available.
#### Permissions checks
* Your cache must be readable and writable by the user running npm.
* Global package binaries must be writable by the user running npm.
* Your local `node_modules` path, if you're running `npm doctor` with a project directory, must be readable and writable by the user running npm.
#### Validate the checksums of cached packages
When an npm package is published, the publishing process generates a checksum that npm uses at install time to verify that the package didn't get corrupted in transit.
`npm doctor` uses these checksums to validate the package tarballs in your local cache (you can see where that cache is located with `npm config get cache`).
In the event that there are corrupt packages in your cache, you should probably run `npm cache clean -f` and reset the cache.
### Configuration
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
### See Also
* [npm bugs](/commands/npm-bugs)
* [npm help](/commands/npm-help)
* [npm ping](/commands/npm-ping)

41
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-edit.md generated vendored
View File

@@ -1,41 +0,0 @@
---
title: npm-edit
section: 1
description: Edit an installed package
---
### Synopsis
```bash
npm edit <pkg>[/<subpkg>...]
```
Note: This command is unaware of workspaces.
### Description
Selects a dependency in the current project and opens the package folder in the default editor (or whatever you've configured as the npm `editor` config -- see [`npm-config`](npm-config).)
After it has been edited, the package is rebuilt so as to pick up any changes in compiled packages.
For instance, you can do `npm install connect` to install connect into your package, and then `npm edit connect` to make a few changes to your locally installed copy.
### Configuration
#### `editor`
* Default: The EDITOR or VISUAL environment variables, or
'%SYSTEMROOT%\notepad.exe' on Windows, or 'vi' on Unix systems
* Type: String
The command to run for `npm edit` and `npm config edit`.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm explore](/commands/npm-explore)
* [npm install](/commands/npm-install)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

318
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-exec.md generated vendored
View File

@@ -1,318 +0,0 @@
---
title: npm-exec
section: 1
description: Run a command from a local or remote npm package
---
### Synopsis
```bash
npm exec -- <pkg>[@<version>] [args...]
npm exec --package=<pkg>[@<version>] -- <cmd> [args...]
npm exec -c '<cmd> [args...]'
npm exec --package=foo -c '<cmd> [args...]'
alias: x
```
### Description
This command allows you to run an arbitrary command from an npm package (either one installed locally, or fetched remotely), in a similar context as running it via `npm run`.
Run without positional arguments or `--call`, this allows you to interactively run commands in the same sort of shell environment that `package.json` scripts are run.
Interactive mode is not supported in CI environments when standard input is a TTY, to prevent hangs.
Whatever packages are specified by the `--package` option will be provided in the `PATH` of the executed command, along with any locally installed package executables.
The `--package` option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available.
If any requested packages are not present in the local project dependencies, then a prompt is printed, which can be suppressed by providing either `--yes` or `--no`.
When standard input is not a TTY or a CI environment is detected, `--yes` is assumed.
The requested packages are installed to a folder in the npm cache, which is added to the `PATH` environment variable in the executed process.
Package names provided without a specifier will be matched with whatever version exists in the local project.
Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency.
If no `-c` or `--call` option is provided, then the positional arguments are used to generate the command string.
If no `--package` options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic:
- If the package has a single entry in its `bin` field in `package.json`, or if all entries are aliases of the same command, then that command will be used.
- If the package has multiple `bin` entries, and one of them matches the unscoped portion of the `name` field, then that command will be used.
- If this does not result in exactly one option (either because there are no bin entries, or none of them match the `name` of the package), then `npm exec` exits with an error.
To run a binary _other than_ the named binary, specify one or more `--package` options, which will prevent npm from inferring the package from the first command argument.
### `npx` vs `npm exec`
When run via the `npx` binary, all flags and options *must* be set prior to any positional arguments.
When run via `npm exec`, a double-hyphen `--` flag can be used to suppress npm's parsing of switches and options that should be sent to the executed command.
For example:
```
$ npx foo@latest bar --package=@npmcli/foo
```
In this case, npm will resolve the `foo` package name, and run the following command:
```
$ foo bar --package=@npmcli/foo
```
Since the `--package` option comes _after_ the positional arguments, it is treated as an argument to the executed command.
In contrast, due to npm's argument parsing logic, running this command is different:
```
$ npm exec foo@latest bar --package=@npmcli/foo
```
In this case, npm will parse the `--package` option first, resolving the `@npmcli/foo` package.
Then, it will execute the following command in that context:
```
$ foo@latest bar
```
The double-hyphen character is recommended to explicitly tell npm to stop parsing command line options and switches.
The following command would thus be equivalent to the `npx` command above:
```
$ npm exec -- foo@latest bar --package=@npmcli/foo
```
### Configuration
#### `package`
* Default:
* Type: String (can be set multiple times)
The package or packages to install for [`npm
exec`](/commands/npm-exec)
#### `call`
* Default: ""
* Type: String
Optional companion option for `npm exec`, `npx` that allows for
specifying a custom command to be run along with the installed
packages.
```bash
npm exec --package yo --package generator-node --call "yo node"
```
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
### Examples
Run the version of `tap` in the local dependencies, with the provided arguments:
```
$ npm exec -- tap --bail test/foo.js
$ npx tap --bail test/foo.js
```
Run a command _other than_ the command whose name matches the package name by specifying a `--package` option:
```
$ npm exec --package=foo -- bar --bar-argument
# ~ or ~
$ npx --package=foo bar --bar-argument
```
Run an arbitrary shell script, in the context of the current project:
```
$ npm x -c 'eslint && say "hooray, lint passed"'
$ npx -c 'eslint && say "hooray, lint passed"'
```
### Workspaces support
You may use the [`workspace`](/using-npm/config#workspace) or [`workspaces`](/using-npm/config#workspaces) configs in order to run an arbitrary command from an npm package (either one installed locally, or fetched remotely) in the context of the specified workspaces.
If no positional argument or `--call` option is provided, it will open an interactive subshell in the context of each of these configured workspaces one at a time.
Given a project with configured workspaces, e.g:
```
.
+-- package.json
`-- packages
+-- a
| `-- package.json
+-- b
| `-- package.json
`-- c
`-- package.json
```
Assuming the workspace configuration is properly set up at the root level `package.json` file.
e.g:
```
{
"workspaces": [ "./packages/*" ]
}
```
You can execute an arbitrary command from a package in the context of each of the configured workspaces when using the [`workspaces` config options](/using-npm/config#workspace), in this example we're using **eslint** to lint any js file found within each workspace folder:
```
npm exec --ws -- eslint ./*.js
```
#### Filtering workspaces
It's also possible to execute a command in a single workspace using the `workspace` config along with a name or directory path:
```
npm exec --workspace=a -- eslint ./*.js
```
The `workspace` config can also be specified multiple times in order to run a specific script in the context of multiple workspaces.
When defining values for the `workspace` config in the command line, it also possible to use `-w` as a shorthand, e.g:
```
npm exec -w a -w b -- eslint ./*.js
```
This last command will run the `eslint` command in both `./packages/a` and
`./packages/b` folders.
### Compatibility with Older npx Versions
The `npx` binary was rewritten in npm v7.0.0, and the standalone `npx` package deprecated at that time.
`npx` uses the `npm exec` command instead of a separate argument parser and install process, with some affordances to maintain backwards compatibility with the arguments it accepted in previous versions.
This resulted in some shifts in its functionality:
- Any `npm` config value may be provided.
- To prevent security and user-experience problems from mistyping package
names, `npx` prompts before installing anything.
Suppress this prompt with the `-y` or `--yes` option.
- The `--no-install` option is deprecated, and will be converted to `--no`.
- Shell fallback functionality is removed, as it is not advisable.
- The `-p` argument is a shorthand for `--parseable` in npm, but shorthand for `--package` in npx.
This is maintained, but only for the `npx` executable.
- The `--ignore-existing` option is removed.
Locally installed bins are always present in the executed process `PATH`.
- The `--npm` option is removed.
`npx` will always use the `npm` it ships with.
- The `--node-arg` and `-n` options are removed.
- The `--always-spawn` option is redundant, and thus removed.
- The `--shell` option is replaced with `--script-shell`, but maintained in the `npx` executable for backwards compatibility.
### A note on caching
The npm cli utilizes its internal package cache when using the package name specified.
You can use the following to change how and when the cli uses this cache.
See [`npm cache`](/commands/npm-cache) for more on how the cache works.
#### prefer-online
Forces staleness checks for packages, making the cli look for updates immediately even if the package is already in the cache.
#### prefer-offline
Bypasses staleness checks for packages.
Missing data will still be requested from the server.
To force full offline mode, use `offline`.
#### offline
Forces full offline mode.
Any packages not locally cached will result in an error.
#### workspace
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result to selecting all of the nested workspaces)
This value is not exported to the environment for child processes.
#### workspaces
* Alias: `--ws`
* Type: Boolean
* Default: `false`
Run scripts in the context of all configured workspaces for the current project.
### See Also
* [npm run](/commands/npm-run)
* [npm scripts](/using-npm/scripts)
* [npm test](/commands/npm-test)
* [npm start](/commands/npm-start)
* [npm restart](/commands/npm-restart)
* [npm stop](/commands/npm-stop)
* [npm config](/commands/npm-config)
* [npm workspaces](/using-npm/workspaces)
* [npx](/commands/npx)

101
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-explain.md generated vendored
View File

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

46
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-explore.md generated vendored
View File

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

254
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-find-dupes.md generated vendored
View File

@@ -1,254 +0,0 @@
---
title: npm-find-dupes
section: 1
description: Find duplication in the package tree
---
### Synopsis
```bash
npm find-dupes
```
### Description
Runs `npm dedupe` in `--dry-run` mode, making npm only output the duplications, without actually changing the package tree.
### Configuration
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as
necessary within directory structure. nested: (formerly
--legacy-bundling) install in place, no hoisting. shallow (formerly
--global-style) only install direct deps at top-level. linked:
(experimental) install in node_modules/.store, link in place,
unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install
packages in the same manner that they are depended on. This may cause
very deep directory structures and duplicate package installs as
there is no de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but
hoist on deeper dependencies. Sets `--install-strategy=shallow`.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure,
even if npm could reasonably guess the appropriate resolution based
on non-peer dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency
graph will be resolved using the nearest non-peer dependency
specification, even if doing so will result in some packages
receiving a peer dependency outside the range set in their package's
`peerDependencies` object.
When such an override is performed, a warning is printed, explaining
the conflict and the packages involved. If `--strict-peer-deps` is
set, then this warning is treated as a failure.
#### `package-lock`
* Default: true
* Type: Boolean
If set to false, then ignore `package-lock.json` files when
installing. This will also prevent _writing_ `package-lock.json` if
`save` is true.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists,
then it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV`
environment variable will be set to `'production'` for all lifecycle
scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple
times)
Option that allows for defining which types of dependencies to
install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted,
regardless of the order in which omit/include are specified on the
command-line.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script,
such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm
run` will still run their intended script if `ignore-scripts` is set,
but they will *not* run any pre- or post-scripts.
#### `audit`
* Default: true
* Type: Boolean
When "true" submit audit reports alongside the current npm command to
the default registry and all registries configured for scopes. See
the documentation for [`npm audit`](/commands/npm-audit) for details
on what is submitted.
#### `bin-links`
* Default: true
* Type: Boolean
Tells npm to create symlinks (or `.cmd` shims on Windows) for package
executables.
Set to false to have it not do this. This can be used to work around
the fact that some file systems don't support symlinks, even on
ostensibly Unix systems.
#### `fund`
* Default: true
* Type: Boolean
When "true" displays the message at the end of each `npm install`
acknowledging the number of dependencies looking for funding. See
[`npm fund`](/commands/npm-fund) for details.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as
regular dependencies instead of creating a symlink. This option has
no effect on workspaces.
### See Also
* [npm dedupe](/commands/npm-dedupe)
* [npm ls](/commands/npm-ls)
* [npm update](/commands/npm-update)
* [npm install](/commands/npm-install)

138
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-fund.md generated vendored
View File

@@ -1,138 +0,0 @@
---
title: npm-fund
section: 1
description: Retrieve funding information
---
### Synopsis
```bash
npm fund [<package-spec>]
```
### Description
This command retrieves information on how to fund the dependencies of a given project.
If no package name is provided, it will list all dependencies that are looking for funding in a tree structure, listing the type of funding and the url to visit.
If a package name is provided then it tries to open its funding url using the [`--browser` config](/using-npm/config#browser) param; if there are multiple funding sources for the package, the user will be instructed to pass the
`--which` option to disambiguate.
The list will avoid duplicated entries and will stack all packages that share the same url as a single entry.
Thus, the list does not have the same shape of the output from `npm ls`.
#### Example
### Workspaces support
It's possible to filter the results to only include a single workspace and its dependencies using the [`workspace` config](/using-npm/config#workspace) option.
#### Example:
Here's an example running `npm fund` in a project with a configured workspace `a`:
```bash
$ npm fund
test-workspaces-fund@1.0.0
+-- https://example.com/a
| | `-- a@1.0.0
| `-- https://example.com/maintainer
| `-- foo@1.0.0
+-- https://example.com/npmcli-funding
| `-- @npmcli/test-funding
`-- https://example.com/org
`-- bar@2.0.0
```
And here is an example of the expected result when filtering only by a specific workspace `a` in the same project:
```bash
$ npm fund -w a
test-workspaces-fund@1.0.0
`-- https://example.com/a
| `-- a@1.0.0
`-- https://example.com/maintainer
`-- foo@2.0.0
```
### Configuration
#### `json`
* Default: false
* Type: Boolean
Whether or not to output JSON data, rather than the normal output.
* In `npm pkg set` it enables parsing set values with JSON.parse()
before saving them to your `package.json`.
Not supported by all npm commands.
#### `browser`
* Default: macOS: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: null, Boolean, or String
The browser that is called by npm commands to open websites.
Set to `false` to suppress browser behavior and instead print urls to
terminal.
Set to `true` to use default system URL opener.
#### `unicode`
* Default: false on windows, true on mac/unix systems with a unicode
locale, as defined by the `LC_ALL`, `LC_CTYPE`, or `LANG` environment
variables.
* Type: Boolean
When set to true, npm uses unicode characters in the tree output.
When false, it uses ascii characters instead of unicode glyphs.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `which`
* Default: null
* Type: null or Number
If there are multiple funding sources, which 1-indexed source URL to
open.
## See Also
* [package spec](/using-npm/package-spec)
* [npm install](/commands/npm-install)
* [npm docs](/commands/npm-docs)
* [npm ls](/commands/npm-ls)
* [npm config](/commands/npm-config)
* [npm workspaces](/using-npm/workspaces)

38
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-help-search.md generated vendored
View File

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

45
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-help.md generated vendored
View File

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

355
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-init.md generated vendored
View File

@@ -1,355 +0,0 @@
---
title: npm-init
section: 1
description: Create a package.json file
---
### Synopsis
```bash
npm init <package-spec> (same as `npx create-<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
```
Set the private flag to `true` in package.json:
```bash
$ npm init --init-private -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
#### `init-author-name`
* Default: ""
* Type: String
The value `npm init` should use by default for the package author's
name.
#### `init-author-url`
* Default: ""
* Type: "" or URL
The value `npm init` should use by default for the package author's
homepage.
#### `init-license`
* Default: "ISC"
* Type: String
The value `npm init` should use by default for the package license.
#### `init-module`
* Default: "~/.npm-init.js"
* Type: Path
A module that will be loaded by the `npm init` command. See the
documentation for the
[init-package-json](https://github.com/npm/init-package-json) module
for more information, or [npm init](/commands/npm-init).
#### `init-type`
* Default: "commonjs"
* Type: String
The value that `npm init` should use by default for the package.json
type field.
#### `init-version`
* Default: "1.0.0"
* Type: SemVer string
The value that `npm init` should use by default for the package
version number, if not already set in package.json.
#### `init-private`
* Default: false
* Type: Boolean
The value `npm init` should use by default for the package's private
flag.
#### `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)

275
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-install-ci-test.md generated vendored
View File

@@ -1,275 +0,0 @@
---
title: npm-install-ci-test
section: 1
description: Install a project with a clean slate and run tests
---
### Synopsis
```bash
npm install-ci-test
aliases: cit, clean-install-test, sit
```
### Description
This command runs `npm ci` followed immediately by `npm test`.
### Configuration
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as
necessary within directory structure. nested: (formerly
--legacy-bundling) install in place, no hoisting. shallow (formerly
--global-style) only install direct deps at top-level. linked:
(experimental) install in node_modules/.store, link in place,
unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install
packages in the same manner that they are depended on. This may cause
very deep directory structures and duplicate package installs as
there is no de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but
hoist on deeper dependencies. Sets `--install-strategy=shallow`.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists,
then it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV`
environment variable will be set to `'production'` for all lifecycle
scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple
times)
Option that allows for defining which types of dependencies to
install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted,
regardless of the order in which omit/include are specified on the
command-line.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure,
even if npm could reasonably guess the appropriate resolution based
on non-peer dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency
graph will be resolved using the nearest non-peer dependency
specification, even if doing so will result in some packages
receiving a peer dependency outside the range set in their package's
`peerDependencies` object.
When such an override is performed, a warning is printed, explaining
the conflict and the packages involved. If `--strict-peer-deps` is
set, then this warning is treated as a failure.
#### `foreground-scripts`
* Default: `false` unless when using `npm pack` or `npm publish` where
it defaults to `true`
* Type: Boolean
Run all build scripts (ie, `preinstall`, `install`, and
`postinstall`) scripts for installed packages in the foreground
process, sharing standard input, output, and error with the main npm
process.
Note that this will generally make installs run slower, and be much
noisier, but can be useful for debugging.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script,
such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm
run` will still run their intended script if `ignore-scripts` is set,
but they will *not* run any pre- or post-scripts.
#### `audit`
* Default: true
* Type: Boolean
When "true" submit audit reports alongside the current npm command to
the default registry and all registries configured for scopes. See
the documentation for [`npm audit`](/commands/npm-audit) for details
on what is submitted.
#### `bin-links`
* Default: true
* Type: Boolean
Tells npm to create symlinks (or `.cmd` shims on Windows) for package
executables.
Set to false to have it not do this. This can be used to work around
the fact that some file systems don't support symlinks, even on
ostensibly Unix systems.
#### `fund`
* Default: true
* Type: Boolean
When "true" displays the message at the end of each `npm install`
acknowledging the number of dependencies looking for funding. See
[`npm fund`](/commands/npm-fund) for details.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it
should only report what it would have done. This can be passed into
any of the commands that modify your local installation, eg,
`install`, `update`, `dedupe`, `uninstall`, as well as `pack` and
`publish`.
Note: This is NOT honored by other network related commands, eg
`dist-tags`, `owner`, etc.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as
regular dependencies instead of creating a symlink. This option has
no effect on workspaces.
### See Also
* [npm install-test](/commands/npm-install-test)
* [npm ci](/commands/npm-ci)
* [npm test](/commands/npm-test)

404
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-install-test.md generated vendored
View File

@@ -1,404 +0,0 @@
---
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`
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as
necessary within directory structure. nested: (formerly
--legacy-bundling) install in place, no hoisting. shallow (formerly
--global-style) only install direct deps at top-level. linked:
(experimental) install in node_modules/.store, link in place,
unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install
packages in the same manner that they are depended on. This may cause
very deep directory structures and duplicate package installs as
there is no de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but
hoist on deeper dependencies. Sets `--install-strategy=shallow`.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists,
then it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV`
environment variable will be set to `'production'` for all lifecycle
scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple
times)
Option that allows for defining which types of dependencies to
install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted,
regardless of the order in which omit/include are specified on the
command-line.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure,
even if npm could reasonably guess the appropriate resolution based
on non-peer dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency
graph will be resolved using the nearest non-peer dependency
specification, even if doing so will result in some packages
receiving a peer dependency outside the range set in their package's
`peerDependencies` object.
When such an override is performed, a warning is printed, explaining
the conflict and the packages involved. If `--strict-peer-deps` is
set, then this warning is treated as a failure.
#### `prefer-dedupe`
* Default: false
* Type: Boolean
Prefer to deduplicate packages if possible, rather than choosing a
newer version of a dependency.
#### `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.
#### `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`.
#### `foreground-scripts`
* Default: `false` unless when using `npm pack` or `npm publish` where
it defaults to `true`
* Type: Boolean
Run all build scripts (ie, `preinstall`, `install`, and
`postinstall`) scripts for installed packages in the foreground
process, sharing standard input, output, and error with the main npm
process.
Note that this will generally make installs run slower, and be much
noisier, but can be useful for debugging.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script,
such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm
run` will still run their intended script if `ignore-scripts` is set,
but they will *not* run any pre- or post-scripts.
#### `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.
#### `before`
* Default: null
* Type: null or Date
If passed to `npm install`, will rebuild the npm tree such that only
versions that were available **on or before** the given date are
installed. If there are no versions available for the current set of
dependencies, the command will error.
If the requested version is a `dist-tag` and the given tag does not
pass the `--before` filter, the most recent version less than or
equal to that tag will be used. For example, `foo@latest` might
install `foo@1.2` even though `latest` is `2.0`.
#### `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.
#### `cpu`
* Default: null
* Type: null or String
Override CPU architecture of native modules to install. Acceptable
values are same as `cpu` field of package.json, which comes from
`process.arch`.
#### `os`
* Default: null
* Type: null or String
Override OS of native modules to install. Acceptable values are same
as `os` field of package.json, which comes from `process.platform`.
#### `libc`
* Default: null
* Type: null or String
Override libc of native modules to install. Acceptable values are
same as `libc` field of package.json
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as
regular dependencies instead of creating a symlink. This option has
no effect on workspaces.
### See Also
* [npm install](/commands/npm-install)
* [npm install-ci-test](/commands/npm-install-ci-test)
* [npm test](/commands/npm-test)

762
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-install.md generated vendored
View File

@@ -1,762 +0,0 @@
---
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#tag).
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`.
* `--save-peer`: Package will appear in your `peerDependencies`.
* `-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
```
* `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`
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as
necessary within directory structure. nested: (formerly
--legacy-bundling) install in place, no hoisting. shallow (formerly
--global-style) only install direct deps at top-level. linked:
(experimental) install in node_modules/.store, link in place,
unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install
packages in the same manner that they are depended on. This may cause
very deep directory structures and duplicate package installs as
there is no de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but
hoist on deeper dependencies. Sets `--install-strategy=shallow`.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists,
then it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV`
environment variable will be set to `'production'` for all lifecycle
scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple
times)
Option that allows for defining which types of dependencies to
install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted,
regardless of the order in which omit/include are specified on the
command-line.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure,
even if npm could reasonably guess the appropriate resolution based
on non-peer dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency
graph will be resolved using the nearest non-peer dependency
specification, even if doing so will result in some packages
receiving a peer dependency outside the range set in their package's
`peerDependencies` object.
When such an override is performed, a warning is printed, explaining
the conflict and the packages involved. If `--strict-peer-deps` is
set, then this warning is treated as a failure.
#### `prefer-dedupe`
* Default: false
* Type: Boolean
Prefer to deduplicate packages if possible, rather than choosing a
newer version of a dependency.
#### `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.
#### `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`.
#### `foreground-scripts`
* Default: `false` unless when using `npm pack` or `npm publish` where
it defaults to `true`
* Type: Boolean
Run all build scripts (ie, `preinstall`, `install`, and
`postinstall`) scripts for installed packages in the foreground
process, sharing standard input, output, and error with the main npm
process.
Note that this will generally make installs run slower, and be much
noisier, but can be useful for debugging.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script,
such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm
run` will still run their intended script if `ignore-scripts` is set,
but they will *not* run any pre- or post-scripts.
#### `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.
#### `before`
* Default: null
* Type: null or Date
If passed to `npm install`, will rebuild the npm tree such that only
versions that were available **on or before** the given date are
installed. If there are no versions available for the current set of
dependencies, the command will error.
If the requested version is a `dist-tag` and the given tag does not
pass the `--before` filter, the most recent version less than or
equal to that tag will be used. For example, `foo@latest` might
install `foo@1.2` even though `latest` is `2.0`.
#### `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.
#### `cpu`
* Default: null
* Type: null or String
Override CPU architecture of native modules to install. Acceptable
values are same as `cpu` field of package.json, which comes from
`process.arch`.
#### `os`
* Default: null
* Type: null or String
Override OS of native modules to install. Acceptable values are same
as `os` field of package.json, which comes from `process.platform`.
#### `libc`
* Default: null
* Type: null or String
Override libc of native modules to install. Acceptable values are
same as `libc` field of package.json
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as
regular dependencies instead of creating a symlink. This option has
no effect on workspaces.
### 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)

387
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-link.md generated vendored
View File

@@ -1,387 +0,0 @@
---
title: npm-link
section: 1
description: Symlink a package folder
---
### Synopsis
```bash
npm link [<package-spec>]
alias: ln
```
### Description
This is handy for installing your own stuff, so that you can work on it and test iteratively without having to continually rebuild.
Package linking is a two-step process.
First, `npm link` in a package folder with no arguments will create a symlink in the global folder `{prefix}/lib/node_modules/<package>` that links to the package where the `npm link` command was executed.
It will also link any bins in the package to `{prefix}/bin/{name}`.
Note that `npm link` uses the global prefix (see `npm prefix -g` for its value).
Next, in some other location, `npm link package-name` will create a symbolic link from globally-installed `package-name` to `node_modules/` of the current folder.
Note that `package-name` is taken from `package.json`, _not_ from the directory name.
The package name can be optionally prefixed with a scope.
See [`scope`](/using-npm/scope).
The scope must be preceded by an @-symbol and followed by a slash.
When creating tarballs for `npm publish`, the linked packages are "snapshotted" to their current state by resolving the symbolic links, if they are included in `bundleDependencies`.
For example:
```bash
cd ~/projects/node-redis # go into the package directory
npm link # creates global link
cd ~/projects/node-bloggy # go into some other package directory.
npm link redis # link-install the package
```
Now, any changes to `~/projects/node-redis` will be reflected in
`~/projects/node-bloggy/node_modules/node-redis/`.
Note that the link should be to the package name, not the directory name for that package.
You may also shortcut the two steps in one.
For example, to do the above use-case in a shorter way:
```bash
cd ~/projects/node-bloggy # go into the dir of your main project
npm link ../node-redis # link the dir of your dependency
```
The second line is the equivalent of doing:
```bash
(cd ../node-redis; npm link)
npm link redis
```
That is, it first creates a global link, and then links the global installation target into your project's `node_modules` folder.
Note that in this case, you are referring to the directory name,
`node-redis`, rather than the package name `redis`.
If your linked package is scoped (see [`scope`](/using-npm/scope)) your link command must include that scope, e.g.
```bash
npm link @myorg/privatepackage
```
### Caveat
Note that package dependencies linked in this way are _not_ saved to `package.json` by default, on the assumption that the intention is to have a link stand in for a regular non-link dependency.
Otherwise, for example, if you depend on `redis@^3.0.1`, and ran `npm link redis`, it would replace the `^3.0.1` dependency with `file:../path/to/node-redis`, which you probably don't want! Additionally, other users or developers on your project would run into issues if they do not have their folders set up exactly the same as yours.
If you are adding a _new_ dependency as a link, you should add it to the relevant metadata by running `npm install <dep> --package-lock-only`.
If you _want_ to save the `file:` reference in your `package.json` and `package-lock.json` files, you can use `npm link <dep> --save` to do so.
### Workspace Usage
`npm link <pkg> --workspace <name>` will link the relevant package as a dependency of the specified workspace(s).
Note that It may actually be linked into the parent project's `node_modules` folder, if there are no conflicting dependencies.
`npm link --workspace <name>` will create a global link to the specified workspace(s).
### 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`
#### `install-strategy`
* Default: "hoisted"
* Type: "hoisted", "nested", "shallow", or "linked"
Sets the strategy for installing packages in node_modules. hoisted
(default): Install non-duplicated in top-level, and duplicated as
necessary within directory structure. nested: (formerly
--legacy-bundling) install in place, no hoisting. shallow (formerly
--global-style) only install direct deps at top-level. linked:
(experimental) install in node_modules/.store, link in place,
unhoisted.
#### `legacy-bundling`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=nested`
Instead of hoisting package installs in `node_modules`, install
packages in the same manner that they are depended on. This may cause
very deep directory structures and duplicate package installs as
there is no de-duplicating. Sets `--install-strategy=nested`.
#### `global-style`
* Default: false
* Type: Boolean
* DEPRECATED: This option has been deprecated in favor of
`--install-strategy=shallow`
Only install direct dependencies in the top level `node_modules`, but
hoist on deeper dependencies. Sets `--install-strategy=shallow`.
#### `strict-peer-deps`
* Default: false
* Type: Boolean
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
conflicting `peerDependencies` will be treated as an install failure,
even if npm could reasonably guess the appropriate resolution based
on non-peer dependency relationships.
By default, conflicting `peerDependencies` deep in the dependency
graph will be resolved using the nearest non-peer dependency
specification, even if doing so will result in some packages
receiving a peer dependency outside the range set in their package's
`peerDependencies` object.
When such an override is performed, a warning is printed, explaining
the conflict and the packages involved. If `--strict-peer-deps` is
set, then this warning is treated as a failure.
#### `package-lock`
* Default: true
* Type: Boolean
If set to false, then ignore `package-lock.json` files when
installing. This will also prevent _writing_ `package-lock.json` if
`save` is true.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists,
then it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV`
environment variable will be set to `'production'` for all lifecycle
scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple
times)
Option that allows for defining which types of dependencies to
install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted,
regardless of the order in which omit/include are specified on the
command-line.
#### `ignore-scripts`
* Default: false
* Type: Boolean
If true, npm does not run scripts specified in package.json files.
Note that commands explicitly intended to run a particular script,
such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm
run` will still run their intended script if `ignore-scripts` is set,
but they will *not* run any pre- or post-scripts.
#### `audit`
* Default: true
* Type: Boolean
When "true" submit audit reports alongside the current npm command to
the default registry and all registries configured for scopes. See
the documentation for [`npm audit`](/commands/npm-audit) for details
on what is submitted.
#### `bin-links`
* Default: true
* Type: Boolean
Tells npm to create symlinks (or `.cmd` shims on Windows) for package
executables.
Set to false to have it not do this. This can be used to work around
the fact that some file systems don't support symlinks, even on
ostensibly Unix systems.
#### `fund`
* Default: true
* Type: Boolean
When "true" displays the message at the end of each `npm install`
acknowledging the number of dependencies looking for funding. See
[`npm fund`](/commands/npm-fund) for details.
#### `dry-run`
* Default: false
* Type: Boolean
Indicates that you don't want npm to make any changes and that it
should only report what it would have done. This can be passed into
any of the commands that modify your local installation, eg,
`install`, `update`, `dedupe`, `uninstall`, as well as `pack` and
`publish`.
Note: This is NOT honored by other network related commands, eg
`dist-tags`, `owner`, etc.
#### `workspace`
* Default:
* Type: String (can be set multiple times)
Enable running a command in the context of the configured workspaces
of the current project while filtering by running only the workspaces
defined by this configuration option.
Valid values for the `workspace` config are either:
* Workspace names
* Path to a workspace directory
* Path to a parent workspace directory (will result in selecting all
workspaces within that folder)
When set for the `npm init` command, this may be set to the folder of
a workspace which does not yet exist, to create the folder and set it
up as a brand new workspace within the project.
This value is not exported to the environment for child processes.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as
regular dependencies instead of creating a symlink. This option has
no effect on workspaces.
### See Also
* [package spec](/using-npm/package-spec)
* [npm developers](/using-npm/developers)
* [package.json](/configuring-npm/package-json)
* [npm install](/commands/npm-install)
* [npm folders](/configuring-npm/folders)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

93
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-login.md generated vendored
View File

@@ -1,93 +0,0 @@
---
title: npm-login
section: 1
description: Login to a registry user account
---
### Synopsis
```bash
npm login
```
Note: This command is unaware of workspaces.
### Description
Verify a user in the specified registry, and save the credentials to the
`.npmrc` file.
If no registry is specified, the default registry will be used (see [`config`](/using-npm/config)).
When you run `npm login`, the CLI automatically generates a legacy token of `publish` type.
For more information, see [About legacy tokens](/about-access-tokens#about-legacy-tokens).
When using `legacy` for your `auth-type`, the username and password, 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.
### Configuration
#### `registry`
* Default: "https://registry.npmjs.org/"
* Type: URL
The base URL of the npm registry.
#### `scope`
* Default: the scope of the current project, if any, or ""
* Type: String
Associate an operation with a scope for a scoped registry.
Useful when logging in to or out of a private registry:
```
# log in, linking the scope to the custom registry
npm login --scope=@mycorp --registry=https://registry.mycorp.com
# log out, removing the link and the auth token
npm logout --scope=@mycorp
```
This will cause `@mycorp` to be mapped to the registry for future
installation of packages specified according to the pattern
`@mycorp/package`.
This will also cause `npm init` to create a scoped package.
```
# accept all defaults, and create a package named "@foo/whatever",
# instead of just named "whatever"
npm init --scope=@foo --yes
```
#### `auth-type`
* Default: "web"
* Type: "legacy" or "web"
What authentication strategy to use with `login`. Note that if an
`otp` config is given, this value will always be set to `legacy`.
### See Also
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm owner](/commands/npm-owner)
* [npm whoami](/commands/npm-whoami)
* [npm token](/commands/npm-token)
* [npm profile](/commands/npm-profile)

72
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-logout.md generated vendored
View File

@@ -1,72 +0,0 @@
---
title: npm-logout
section: 1
description: Log out of the registry
---
### Synopsis
```bash
npm logout
```
Note: This command is unaware of workspaces.
### Description
When logged into a registry that supports token-based authentication, tell the server to end this token's session.
This will invalidate the token everywhere you're using it, not just for the current environment.
When logged into a legacy registry that uses username and password authentication, this will clear the credentials in your user configuration.
In this case, it will _only_ affect the current environment.
If `--scope` is provided, this will find the credentials for the registry connected to that scope, if set.
### 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
```
### See Also
* [npm adduser](/commands/npm-adduser)
* [npm registry](/using-npm/registry)
* [npm config](/commands/npm-config)
* [npm whoami](/commands/npm-whoami)

270
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-ls.md generated vendored
View File

@@ -1,270 +0,0 @@
---
title: npm-ls
section: 1
description: List installed packages
---
### Synopsis
```bash
npm ls <package-spec>
alias: list
```
### Description
This command will print to stdout all the versions of packages that are installed, as well as their dependencies when `--all` is specified, in a tree structure.
Note: to get a "bottoms up" view of why a given package is included in the tree at all, use [`npm explain`](/commands/npm-explain).
Positional arguments are `name@version-range` identifiers, which will limit the results to only the paths to the packages named.
Note that nested packages will *also* show the paths to the specified packages.
For example, running `npm ls promzard` in npm's source tree will show:
```bash
npm@11.6.2 /path/to/npm
└─┬ init-package-json@0.0.4
└── promzard@0.1.5
```
It will print out extraneous, missing, and invalid packages.
If a project specifies git urls for dependencies these are shown in parentheses after the `name@version` to make it easier for users to recognize potential forks of a project.
The tree shown is the logical dependency tree, based on package dependencies, not the physical layout of your `node_modules` folder.
When run as `ll` or `la`, it shows extended information by default.
### Configuration
#### `all`
* Default: false
* Type: Boolean
When running `npm outdated` and `npm ls`, setting `--all` will show
all outdated or installed packages, rather than only those directly
depended upon by the current project.
#### `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.
#### `long`
* Default: false
* Type: Boolean
Show extended information in `ls`, `search`, and `help-search`.
#### `parseable`
* Default: false
* Type: Boolean
Output parseable results from commands that write to standard output.
For `npm search`, this will be tab-separated table format.
#### `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`
#### `depth`
* Default: `Infinity` if `--all` is set; otherwise, `0`
* Type: null or Number
The depth to go when recursing packages for `npm ls`.
If not set, `npm ls` will show only the immediate dependencies of the
root project. If `--all` is set, then npm will show all dependencies
by default.
#### `omit`
* Default: 'dev' if the `NODE_ENV` environment variable is set to
'production'; otherwise, empty.
* Type: "dev", "optional", or "peer" (can be set multiple times)
Dependency types to omit from the installation tree on disk.
Note that these dependencies _are_ still resolved and added to the
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
physically installed on disk.
If a package type appears in both the `--include` and `--omit` lists,
then it will be included.
If the resulting omit list includes `'dev'`, then the `NODE_ENV`
environment variable will be set to `'production'` for all lifecycle
scripts.
#### `include`
* Default:
* Type: "prod", "dev", "optional", or "peer" (can be set multiple
times)
Option that allows for defining which types of dependencies to
install.
This is the inverse of `--omit=<type>`.
Dependency types specified in `--include` will not be omitted,
regardless of the order in which omit/include are specified on the
command-line.
#### `link`
* Default: false
* Type: Boolean
Used with `npm ls`, limiting output to only those packages that are
linked.
#### `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`.
#### `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.
#### `workspaces`
* Default: null
* Type: null or Boolean
Set to true to run the command in the context of **all** configured
workspaces.
Explicitly setting this to false will cause commands like `install`
to ignore workspaces altogether. When not set explicitly:
- Commands that operate on the `node_modules` tree (install, update,
etc.) will link workspaces into the `node_modules` folder. - Commands
that do other things (test, exec, publish, etc.) will operate on the
root project, _unless_ one or more workspaces are specified in the
`workspace` config.
This value is not exported to the environment for child processes.
#### `include-workspace-root`
* Default: false
* Type: Boolean
Include the workspace root when workspaces are enabled for a command.
When false, specifying individual workspaces via the `workspace`
config, or all workspaces via the `workspaces` flag, will cause npm
to operate only on the specified workspaces, and not on the root
project.
This value is not exported to the environment for child processes.
#### `install-links`
* Default: false
* Type: Boolean
When set file: protocol dependencies will be packed and installed as
regular dependencies instead of creating a symlink. This option has
no effect on workspaces.
### See Also
* [package spec](/using-npm/package-spec)
* [npm explain](/commands/npm-explain)
* [npm config](/commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm folders](/configuring-npm/folders)
* [npm explain](/commands/npm-explain)
* [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)

114
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-org.md generated vendored
View File

@@ -1,114 +0,0 @@
---
title: npm-org
section: 1
description: Manage orgs
---
### Synopsis
```bash
npm org set orgname username [developer | admin | owner]
npm org rm orgname username
npm org ls orgname [<username>]
alias: ogr
```
Note: This command is unaware of workspaces.
### Example
Add a new developer to an org:
```bash
$ npm org set my-org @mx-smith
```
Add a new admin to an org (or change a developer to an admin):
```bash
$ npm org set my-org @mx-santos admin
```
Remove a user from an org:
```bash
$ npm org rm my-org mx-santos
```
List all users in an org:
```bash
$ npm org ls my-org
```
List all users in JSON format:
```bash
$ npm org ls my-org --json
```
See what role a user has in an org:
```bash
$ npm org ls my-org @mx-santos
```
### Description
You can use the `npm org` commands to manage and view users of an organization.
It supports adding and removing users, changing their roles, listing them, and finding specific ones and their roles.
### 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.
#### `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.
#### `parseable`
* Default: false
* Type: Boolean
Output parseable results from commands that write to standard output.
For `npm search`, this will be tab-separated table format.
### See Also
* [using orgs](/using-npm/orgs)
* [Documentation on npm Orgs](https://docs.npmjs.com/orgs/)

178
opt/plesk/node/24/lib/node_modules/npm/docs/content/commands/npm-outdated.md generated vendored
View File

@@ -1,178 +0,0 @@
---
title: npm-outdated
section: 1
description: Check for outdated packages
---
### Synopsis
```bash
npm outdated [<package-spec> ...]
```
### Description
This command will check the registry to see if any (or, specific) installed packages are currently outdated.
By default, only the direct dependencies of the root project and direct dependencies of your configured *workspaces* are shown.
Use `--all` to find all outdated meta-dependencies as well.
In the output:
* `wanted` is the maximum version of the package that satisfies the semver range specified in `package.json`.
If there's no available semver range (i.e. you're running `npm outdated --global`, or the package isn't included in `package.json`), then `wanted` shows the currently-installed version.
* `latest` is the version of the package tagged as latest in the registry.
Running `npm publish` with no special configuration will publish the package with a dist-tag of `latest`.
This may or may not be the maximum version of the package, or the most-recently published version of the package, depending on how the package's developer manages the latest [dist-tag](/commands/npm-dist-tag).
* `location` is where in the physical tree the package is located.
* `depended by` shows which package depends on the displayed dependency
* `package type` (when using `--long` / `-l`) tells you whether this package is a `dependency` or a dev/peer/optional dependency.
Packages not included in `package.json` are always marked `dependencies`.
* `homepage` (when using `--long` / `-l`) is the `homepage` value contained in the package's packument
* `depended by location` (when using `--long` / `-l`) shows location of the package that depends on the displayed dependency
* Red means there's a newer version matching your semver requirements, so you should update now.
* Yellow indicates that there's a newer version _above_ your semver requirements (usually new major, or new 0.x minor) so proceed with caution.
### An example
```bash
$ npm outdated
Package Current Wanted Latest Location Depended by
glob 5.0.15 5.0.15 6.0.1 node_modules/glob dependent-package-name
nothingness 0.0.3 git git node_modules/nothingness dependent-package-name
npm 3.5.1 3.5.2 3.5.1 node_modules/npm dependent-package-name
local-dev 0.0.3 linked linked local-dev dependent-package-name
once 1.3.2 1.3.3 1.3.3 node_modules/once dependent-package-name
```
With these `dependencies`:
```json
{
"glob": "^5.0.15",
"nothingness": "github:othiym23/nothingness#master",
"npm": "^3.5.1",
"once": "^1.3.1"
}
```
A few things to note:
* `glob` requires `^5`, which prevents npm from installing `glob@6`, which is outside the semver range.
* Git dependencies will always be reinstalled, because of how they're specified.
The installed committish might satisfy the dependency specifier (if it's something immutable, like a commit SHA), or it might not, so `npm outdated` and `npm update` have to fetch Git repos to check.
This is why currently doing a reinstall of a Git dependency always forces a new clone and install.
* `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because npm uses dist-tags to manage its `latest` and `next` release channels.
`npm update` will install the _newest_ version, but `npm install npm` (with no semver range) will install whatever's tagged as `latest`.
* `once` is just plain out of date.
Reinstalling `node_modules` from scratch or running `npm update` will bring it up to spec.
### Configuration
#### `all`
* Default: false
* Type: Boolean
When running `npm outdated` and `npm ls`, setting `--all` will show
all outdated or installed packages, rather than only those directly
depended upon by the current project.
#### `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.
#### `long`
* Default: false
* Type: Boolean
Show extended information in `ls`, `search`, and `help-search`.
#### `parseable`
* Default: false
* Type: Boolean
Output parseable results from commands that write to standard output.
For `npm search`, this will be tab-separated table format.
#### `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`
#### `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.
#### `before`
* Default: null
* Type: null or Date
If passed to `npm install`, will rebuild the npm tree such that only
versions that were available **on or before** the given date are
installed. If there are no versions available for the current set of
dependencies, the command will error.
If the requested version is a `dist-tag` and the given tag does not
pass the `--before` filter, the most recent version less than or
equal to that tag will be used. For example, `foo@latest` might
install `foo@1.2` even though `latest` is `2.0`.
### See Also
* [package spec](/using-npm/package-spec)
* [npm update](/commands/npm-update)
* [npm dist-tag](/commands/npm-dist-tag)
* [npm registry](/using-npm/registry)
* [npm folders](/configuring-npm/folders)
* [npm workspaces](/using-npm/workspaces)

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