From 0600b7e47e142e3b5ba5e30c9ae3034e54e56894 Mon Sep 17 00:00:00 2001 From: npm CLI robot Date: Wed, 8 Oct 2025 20:18:03 +0000 Subject: [PATCH] deps: upgrade npm to 11.6.2 --- deps/npm/README.md | 5 +- deps/npm/docs/content/commands/npm-access.md | 57 +- deps/npm/docs/content/commands/npm-adduser.md | 15 +- deps/npm/docs/content/commands/npm-audit.md | 267 +++--- deps/npm/docs/content/commands/npm-bugs.md | 39 +- deps/npm/docs/content/commands/npm-cache.md | 24 +- deps/npm/docs/content/commands/npm-ci.md | 177 ++-- .../docs/content/commands/npm-completion.md | 13 +- deps/npm/docs/content/commands/npm-config.md | 70 +- deps/npm/docs/content/commands/npm-dedupe.md | 180 ++-- .../docs/content/commands/npm-deprecate.md | 41 +- deps/npm/docs/content/commands/npm-diff.md | 138 +-- .../npm/docs/content/commands/npm-dist-tag.md | 88 +- deps/npm/docs/content/commands/npm-docs.md | 40 +- deps/npm/docs/content/commands/npm-doctor.md | 91 +- deps/npm/docs/content/commands/npm-edit.md | 11 +- deps/npm/docs/content/commands/npm-exec.md | 222 ++--- deps/npm/docs/content/commands/npm-explain.md | 28 +- deps/npm/docs/content/commands/npm-explore.md | 13 +- .../docs/content/commands/npm-find-dupes.md | 138 +-- deps/npm/docs/content/commands/npm-fund.md | 53 +- .../docs/content/commands/npm-help-search.md | 8 +- deps/npm/docs/content/commands/npm-help.md | 9 +- deps/npm/docs/content/commands/npm-init.md | 146 ++- .../content/commands/npm-install-ci-test.md | 158 ++-- .../docs/content/commands/npm-install-test.md | 225 ++--- deps/npm/docs/content/commands/npm-install.md | 471 ++++------ deps/npm/docs/content/commands/npm-link.md | 233 +++-- deps/npm/docs/content/commands/npm-login.md | 20 +- deps/npm/docs/content/commands/npm-logout.md | 11 +- deps/npm/docs/content/commands/npm-ls.md | 136 +-- deps/npm/docs/content/commands/npm-org.md | 22 +- .../npm/docs/content/commands/npm-outdated.md | 110 +-- deps/npm/docs/content/commands/npm-owner.md | 56 +- deps/npm/docs/content/commands/npm-pack.md | 66 +- deps/npm/docs/content/commands/npm-pkg.md | 123 +-- deps/npm/docs/content/commands/npm-prefix.md | 20 +- deps/npm/docs/content/commands/npm-profile.md | 52 +- deps/npm/docs/content/commands/npm-prune.md | 120 +-- deps/npm/docs/content/commands/npm-publish.md | 165 ++-- deps/npm/docs/content/commands/npm-query.md | 79 +- deps/npm/docs/content/commands/npm-rebuild.md | 81 +- deps/npm/docs/content/commands/npm-repo.md | 39 +- deps/npm/docs/content/commands/npm-restart.md | 22 +- deps/npm/docs/content/commands/npm-root.md | 15 +- deps/npm/docs/content/commands/npm-run.md | 150 ++- deps/npm/docs/content/commands/npm-sbom.md | 63 +- deps/npm/docs/content/commands/npm-search.md | 68 +- .../docs/content/commands/npm-shrinkwrap.md | 9 +- deps/npm/docs/content/commands/npm-star.md | 25 +- deps/npm/docs/content/commands/npm-stars.md | 6 +- deps/npm/docs/content/commands/npm-start.md | 26 +- deps/npm/docs/content/commands/npm-stop.md | 18 +- deps/npm/docs/content/commands/npm-team.md | 62 +- deps/npm/docs/content/commands/npm-test.md | 15 +- deps/npm/docs/content/commands/npm-token.md | 48 +- .../docs/content/commands/npm-undeprecate.md | 28 +- .../docs/content/commands/npm-uninstall.md | 76 +- .../docs/content/commands/npm-unpublish.md | 82 +- deps/npm/docs/content/commands/npm-unstar.md | 21 +- deps/npm/docs/content/commands/npm-update.md | 244 +++-- deps/npm/docs/content/commands/npm-version.md | 134 ++- deps/npm/docs/content/commands/npm-view.md | 82 +- deps/npm/docs/content/commands/npm-whoami.md | 7 +- deps/npm/docs/content/commands/npm.md | 129 +-- deps/npm/docs/content/commands/npx.md | 115 +-- .../docs/content/configuring-npm/folders.md | 150 ++- .../docs/content/configuring-npm/install.md | 54 +- .../configuring-npm/npm-shrinkwrap-json.md | 21 +- .../npm/docs/content/configuring-npm/npmrc.md | 67 +- .../content/configuring-npm/package-json.md | 577 +++++------- .../configuring-npm/package-lock-json.md | 254 ++--- deps/npm/docs/content/using-npm/config.md | 887 +++++++++--------- .../content/using-npm/dependency-selectors.md | 56 +- deps/npm/docs/content/using-npm/developers.md | 142 ++- deps/npm/docs/content/using-npm/logging.md | 31 +- deps/npm/docs/content/using-npm/orgs.md | 21 +- .../docs/content/using-npm/package-spec.md | 47 +- deps/npm/docs/content/using-npm/registry.md | 78 +- deps/npm/docs/content/using-npm/removal.md | 29 +- deps/npm/docs/content/using-npm/scope.md | 86 +- deps/npm/docs/content/using-npm/scripts.md | 177 ++-- deps/npm/docs/content/using-npm/workspaces.md | 84 +- deps/npm/docs/lib/index.js | 2 +- deps/npm/docs/output/commands/npm-access.html | 67 +- .../npm/docs/output/commands/npm-adduser.html | 19 +- deps/npm/docs/output/commands/npm-audit.html | 268 +++--- deps/npm/docs/output/commands/npm-bugs.html | 43 +- deps/npm/docs/output/commands/npm-cache.html | 25 +- deps/npm/docs/output/commands/npm-ci.html | 179 ++-- .../docs/output/commands/npm-completion.html | 17 +- deps/npm/docs/output/commands/npm-config.html | 71 +- deps/npm/docs/output/commands/npm-dedupe.html | 182 ++-- .../docs/output/commands/npm-deprecate.html | 44 +- deps/npm/docs/output/commands/npm-diff.html | 138 +-- .../docs/output/commands/npm-dist-tag.html | 92 +- deps/npm/docs/output/commands/npm-docs.html | 44 +- deps/npm/docs/output/commands/npm-doctor.html | 95 +- deps/npm/docs/output/commands/npm-edit.html | 15 +- deps/npm/docs/output/commands/npm-exec.html | 209 ++--- .../npm/docs/output/commands/npm-explain.html | 32 +- .../npm/docs/output/commands/npm-explore.html | 17 +- .../docs/output/commands/npm-find-dupes.html | 140 +-- deps/npm/docs/output/commands/npm-fund.html | 57 +- .../docs/output/commands/npm-help-search.html | 12 +- deps/npm/docs/output/commands/npm-help.html | 13 +- deps/npm/docs/output/commands/npm-init.html | 143 ++- .../output/commands/npm-install-ci-test.html | 160 ++-- .../output/commands/npm-install-test.html | 227 ++--- .../npm/docs/output/commands/npm-install.html | 472 ++++------ deps/npm/docs/output/commands/npm-link.html | 235 +++-- deps/npm/docs/output/commands/npm-login.html | 24 +- deps/npm/docs/output/commands/npm-logout.html | 15 +- deps/npm/docs/output/commands/npm-ls.html | 140 +-- deps/npm/docs/output/commands/npm-org.html | 25 +- .../docs/output/commands/npm-outdated.html | 112 +-- deps/npm/docs/output/commands/npm-owner.html | 59 +- deps/npm/docs/output/commands/npm-pack.html | 69 +- deps/npm/docs/output/commands/npm-ping.html | 4 +- deps/npm/docs/output/commands/npm-pkg.html | 127 +-- deps/npm/docs/output/commands/npm-prefix.html | 24 +- .../npm/docs/output/commands/npm-profile.html | 55 +- deps/npm/docs/output/commands/npm-prune.html | 123 +-- .../npm/docs/output/commands/npm-publish.html | 163 ++-- deps/npm/docs/output/commands/npm-query.html | 83 +- .../npm/docs/output/commands/npm-rebuild.html | 84 +- deps/npm/docs/output/commands/npm-repo.html | 43 +- .../npm/docs/output/commands/npm-restart.html | 23 +- deps/npm/docs/output/commands/npm-root.html | 19 +- deps/npm/docs/output/commands/npm-run.html | 152 ++- deps/npm/docs/output/commands/npm-sbom.html | 67 +- deps/npm/docs/output/commands/npm-search.html | 66 +- .../docs/output/commands/npm-shrinkwrap.html | 13 +- deps/npm/docs/output/commands/npm-star.html | 28 +- deps/npm/docs/output/commands/npm-stars.html | 10 +- deps/npm/docs/output/commands/npm-start.html | 28 +- deps/npm/docs/output/commands/npm-stop.html | 20 +- deps/npm/docs/output/commands/npm-team.html | 65 +- deps/npm/docs/output/commands/npm-test.html | 17 +- deps/npm/docs/output/commands/npm-token.html | 49 +- .../docs/output/commands/npm-undeprecate.html | 31 +- .../docs/output/commands/npm-uninstall.html | 80 +- .../docs/output/commands/npm-unpublish.html | 86 +- deps/npm/docs/output/commands/npm-unstar.html | 24 +- deps/npm/docs/output/commands/npm-update.html | 246 +++-- .../npm/docs/output/commands/npm-version.html | 137 ++- deps/npm/docs/output/commands/npm-view.html | 86 +- deps/npm/docs/output/commands/npm-whoami.html | 11 +- deps/npm/docs/output/commands/npm.html | 132 ++- deps/npm/docs/output/commands/npx.html | 109 +-- .../docs/output/configuring-npm/folders.html | 148 ++- .../docs/output/configuring-npm/install.html | 58 +- .../output/configuring-npm/npm-global.html | 148 ++- .../docs/output/configuring-npm/npm-json.html | 570 +++++------ .../configuring-npm/npm-shrinkwrap-json.html | 24 +- .../docs/output/configuring-npm/npmrc.html | 71 +- .../output/configuring-npm/package-json.html | 570 +++++------ .../configuring-npm/package-lock-json.html | 236 ++--- deps/npm/docs/output/using-npm/config.html | 877 ++++++++--------- .../using-npm/dependency-selectors.html | 60 +- .../npm/docs/output/using-npm/developers.html | 145 ++- deps/npm/docs/output/using-npm/logging.html | 35 +- deps/npm/docs/output/using-npm/orgs.html | 23 +- .../docs/output/using-npm/package-spec.html | 51 +- deps/npm/docs/output/using-npm/registry.html | 70 +- deps/npm/docs/output/using-npm/removal.html | 33 +- deps/npm/docs/output/using-npm/scope.html | 90 +- deps/npm/docs/output/using-npm/scripts.html | 177 ++-- .../npm/docs/output/using-npm/workspaces.html | 84 +- deps/npm/lib/base-cmd.js | 2 +- deps/npm/lib/cli/entry.js | 4 +- deps/npm/lib/cli/exit-handler.js | 8 +- deps/npm/lib/cli/update-notifier.js | 1 - deps/npm/lib/commands/audit.js | 2 +- deps/npm/lib/commands/completion.js | 2 +- deps/npm/lib/commands/config.js | 6 +- deps/npm/lib/commands/diff.js | 4 +- deps/npm/lib/commands/dist-tag.js | 2 +- deps/npm/lib/commands/exec.js | 2 +- deps/npm/lib/commands/help-search.js | 8 +- deps/npm/lib/commands/help.js | 2 +- deps/npm/lib/commands/outdated.js | 2 +- deps/npm/lib/commands/publish.js | 2 +- deps/npm/lib/npm.js | 2 +- deps/npm/lib/utils/display.js | 128 ++- deps/npm/lib/utils/format.js | 7 +- deps/npm/lib/utils/log-file.js | 2 +- deps/npm/lib/utils/open-url.js | 5 +- deps/npm/lib/utils/queryable.js | 6 +- deps/npm/lib/utils/sbom-cyclonedx.js | 6 +- deps/npm/lib/utils/sbom-spdx.js | 6 +- deps/npm/lib/utils/verify-signatures.js | 4 +- deps/npm/man/man1/npm-access.1 | 19 +- deps/npm/man/man1/npm-adduser.1 | 2 +- deps/npm/man/man1/npm-audit.1 | 15 +- deps/npm/man/man1/npm-bugs.1 | 2 +- deps/npm/man/man1/npm-cache.1 | 5 +- deps/npm/man/man1/npm-ci.1 | 7 +- deps/npm/man/man1/npm-completion.1 | 2 +- deps/npm/man/man1/npm-config.1 | 5 +- deps/npm/man/man1/npm-dedupe.1 | 7 +- deps/npm/man/man1/npm-deprecate.1 | 5 +- deps/npm/man/man1/npm-diff.1 | 6 +- deps/npm/man/man1/npm-dist-tag.1 | 2 +- deps/npm/man/man1/npm-docs.1 | 2 +- deps/npm/man/man1/npm-doctor.1 | 2 +- deps/npm/man/man1/npm-edit.1 | 2 +- deps/npm/man/man1/npm-exec.1 | 2 +- deps/npm/man/man1/npm-explain.1 | 2 +- deps/npm/man/man1/npm-explore.1 | 2 +- deps/npm/man/man1/npm-find-dupes.1 | 7 +- deps/npm/man/man1/npm-fund.1 | 2 +- deps/npm/man/man1/npm-help-search.1 | 2 +- deps/npm/man/man1/npm-help.1 | 2 +- deps/npm/man/man1/npm-init.1 | 5 +- deps/npm/man/man1/npm-install-ci-test.1 | 7 +- deps/npm/man/man1/npm-install-test.1 | 7 +- deps/npm/man/man1/npm-install.1 | 10 +- deps/npm/man/man1/npm-link.1 | 7 +- deps/npm/man/man1/npm-login.1 | 2 +- deps/npm/man/man1/npm-logout.1 | 2 +- deps/npm/man/man1/npm-ls.1 | 8 +- deps/npm/man/man1/npm-org.1 | 5 +- deps/npm/man/man1/npm-outdated.1 | 2 +- deps/npm/man/man1/npm-owner.1 | 5 +- deps/npm/man/man1/npm-pack.1 | 5 +- deps/npm/man/man1/npm-ping.1 | 2 +- deps/npm/man/man1/npm-pkg.1 | 2 +- deps/npm/man/man1/npm-prefix.1 | 2 +- deps/npm/man/man1/npm-profile.1 | 5 +- deps/npm/man/man1/npm-prune.1 | 7 +- deps/npm/man/man1/npm-publish.1 | 18 +- deps/npm/man/man1/npm-query.1 | 6 +- deps/npm/man/man1/npm-rebuild.1 | 5 +- deps/npm/man/man1/npm-repo.1 | 2 +- deps/npm/man/man1/npm-restart.1 | 11 +- deps/npm/man/man1/npm-root.1 | 2 +- deps/npm/man/man1/npm-run.1 | 8 +- deps/npm/man/man1/npm-sbom.1 | 4 +- deps/npm/man/man1/npm-search.1 | 2 +- deps/npm/man/man1/npm-shrinkwrap.1 | 2 +- deps/npm/man/man1/npm-star.1 | 5 +- deps/npm/man/man1/npm-stars.1 | 2 +- deps/npm/man/man1/npm-start.1 | 8 +- deps/npm/man/man1/npm-stop.1 | 8 +- deps/npm/man/man1/npm-team.1 | 5 +- deps/npm/man/man1/npm-test.1 | 8 +- deps/npm/man/man1/npm-token.1 | 7 +- deps/npm/man/man1/npm-undeprecate.1 | 5 +- deps/npm/man/man1/npm-uninstall.1 | 2 +- deps/npm/man/man1/npm-unpublish.1 | 2 +- deps/npm/man/man1/npm-unstar.1 | 5 +- deps/npm/man/man1/npm-update.1 | 7 +- deps/npm/man/man1/npm-version.1 | 8 +- deps/npm/man/man1/npm-view.1 | 2 +- deps/npm/man/man1/npm-whoami.1 | 2 +- deps/npm/man/man1/npm.1 | 6 +- deps/npm/man/man1/npx.1 | 2 +- deps/npm/man/man5/folders.5 | 2 +- deps/npm/man/man5/install.5 | 2 +- deps/npm/man/man5/npm-global.5 | 2 +- deps/npm/man/man5/npm-json.5 | 23 +- deps/npm/man/man5/npm-shrinkwrap-json.5 | 2 +- deps/npm/man/man5/npmrc.5 | 2 +- deps/npm/man/man5/package-json.5 | 23 +- deps/npm/man/man5/package-lock-json.5 | 2 +- deps/npm/man/man7/config.7 | 45 +- deps/npm/man/man7/dependency-selectors.7 | 4 +- deps/npm/man/man7/developers.7 | 4 +- deps/npm/man/man7/logging.7 | 2 +- deps/npm/man/man7/orgs.7 | 8 +- deps/npm/man/man7/package-spec.7 | 2 +- deps/npm/man/man7/registry.7 | 2 +- deps/npm/man/man7/removal.7 | 2 +- deps/npm/man/man7/scope.7 | 2 +- deps/npm/man/man7/scripts.7 | 13 +- deps/npm/man/man7/workspaces.7 | 2 +- .../node_modules/@npmcli/arborist/README.md | 2 +- .../@npmcli/arborist/bin/index.js | 2 +- .../arborist/lib/arborist/build-ideal-tree.js | 33 +- .../arborist/lib/arborist/isolated-reifier.js | 8 +- .../arborist/lib/arborist/load-actual.js | 2 +- .../arborist/lib/arborist/load-virtual.js | 3 +- .../@npmcli/arborist/lib/arborist/reify.js | 57 +- .../node_modules/@npmcli/arborist/lib/diff.js | 38 +- .../@npmcli/arborist/lib/gather-dep-set.js | 2 +- .../node_modules/@npmcli/arborist/lib/node.js | 12 +- .../@npmcli/arborist/lib/optional-set.js | 6 +- .../@npmcli/arborist/lib/packument-cache.js | 2 +- .../@npmcli/arborist/lib/place-dep.js | 6 +- .../arborist/lib/query-selector-all.js | 2 +- .../@npmcli/arborist/lib/shrinkwrap.js | 21 +- .../@npmcli/arborist/package.json | 2 +- .../npm/node_modules/@npmcli/config/README.md | 159 ++-- .../config/lib/definitions/definition.js | 4 +- .../config/lib/definitions/definitions.js | 18 +- .../node_modules/@npmcli/config/lib/index.js | 6 +- .../@npmcli/config/lib/set-envs.js | 2 +- .../node_modules/@npmcli/config/package.json | 2 +- .../@sigstore/sign/dist/util/oidc.js | 17 +- .../node_modules/@sigstore/sign/package.json | 4 +- deps/npm/node_modules/ci-info/index.js | 28 +- deps/npm/node_modules/ci-info/package.json | 2 +- deps/npm/node_modules/cidr-regex/package.json | 22 +- .../node_modules/hosted-git-info/lib/hosts.js | 2 - .../hosted-git-info/lib/parse-url.js | 13 +- .../node_modules/hosted-git-info/package.json | 6 +- deps/npm/node_modules/is-cidr/package.json | 22 +- deps/npm/node_modules/libnpmaccess/README.md | 2 +- .../node_modules/libnpmaccess/lib/index.js | 2 +- .../node_modules/libnpmaccess/package.json | 2 +- deps/npm/node_modules/libnpmdiff/README.md | 47 +- deps/npm/node_modules/libnpmdiff/package.json | 4 +- deps/npm/node_modules/libnpmexec/README.md | 2 +- .../libnpmexec/lib/get-bin-from-manifest.js | 2 +- deps/npm/node_modules/libnpmexec/package.json | 4 +- deps/npm/node_modules/libnpmfund/README.md | 4 +- deps/npm/node_modules/libnpmfund/package.json | 4 +- deps/npm/node_modules/libnpmpack/package.json | 4 +- .../node_modules/libnpmpublish/package.json | 2 +- deps/npm/node_modules/libnpmversion/README.md | 6 +- .../lru-cache/dist/commonjs/index.js | 6 +- .../lru-cache/dist/commonjs/index.min.js | 2 +- .../node_modules/lru-cache/dist/esm/index.js | 6 +- .../lru-cache/dist/esm/index.min.js | 2 +- deps/npm/node_modules/lru-cache/package.json | 2 +- .../normalize-package-data/LICENSE | 15 - .../lib/extract_description.js | 24 - .../normalize-package-data/lib/fixer.js | 472 ---------- .../lib/make_warning.js | 22 - .../normalize-package-data/lib/normalize.js | 48 - .../normalize-package-data/lib/safe_format.js | 11 - .../normalize-package-data/lib/typos.json | 25 - .../lib/warning_messages.json | 30 - .../normalize-package-data/package.json | 56 -- .../node_modules/npm-package-arg/lib/npa.js | 2 +- .../node_modules/npm-package-arg/package.json | 2 +- .../node_modules/npm-packlist/lib/index.js | 7 + .../node_modules/npm-packlist/package.json | 9 +- deps/npm/node_modules/semver/classes/range.js | 1 + .../npm/node_modules/semver/classes/semver.js | 24 +- .../semver/internal/identifiers.js | 4 + deps/npm/node_modules/semver/package.json | 6 +- deps/npm/package.json | 32 +- .../test/lib/commands/ls.js.test.cjs | 22 +- .../test/lib/commands/outdated.js.test.cjs | 2 +- .../test/lib/commands/publish.js.test.cjs | 2 +- .../test/lib/commands/sbom.js.test.cjs | 2 +- .../tap-snapshots/test/lib/docs.js.test.cjs | 26 +- .../test/lib/utils/error-message.js.test.cjs | 2 +- .../test/lib/utils/open-url.js.test.cjs | 2 +- deps/npm/test/lib/cli/exit-handler.js | 2 +- deps/npm/test/lib/cli/update-notifier.js | 6 +- deps/npm/test/lib/commands/config.js | 6 +- deps/npm/test/lib/commands/init.js | 6 +- deps/npm/test/lib/commands/login.js | 3 +- deps/npm/test/lib/commands/ls.js | 36 +- deps/npm/test/lib/commands/org.js | 12 +- deps/npm/test/lib/commands/outdated.js | 4 +- deps/npm/test/lib/commands/profile.js | 6 +- deps/npm/test/lib/commands/publish.js | 4 +- deps/npm/test/lib/commands/sbom.js | 2 +- deps/npm/test/lib/commands/team.js | 2 +- deps/npm/test/lib/load-all-commands.js | 6 +- deps/npm/test/lib/npm.js | 2 +- deps/npm/test/lib/utils/display.js | 2 +- deps/npm/test/lib/utils/error-message.js | 2 +- deps/npm/test/lib/utils/open-url.js | 2 +- deps/npm/test/lib/utils/queryable.js | 4 +- deps/npm/test/lib/utils/reify-output.js | 2 +- 370 files changed, 8540 insertions(+), 11114 deletions(-) delete mode 100644 deps/npm/node_modules/normalize-package-data/LICENSE delete mode 100644 deps/npm/node_modules/normalize-package-data/lib/extract_description.js delete mode 100644 deps/npm/node_modules/normalize-package-data/lib/fixer.js delete mode 100644 deps/npm/node_modules/normalize-package-data/lib/make_warning.js delete mode 100644 deps/npm/node_modules/normalize-package-data/lib/normalize.js delete mode 100644 deps/npm/node_modules/normalize-package-data/lib/safe_format.js delete mode 100644 deps/npm/node_modules/normalize-package-data/lib/typos.json delete mode 100644 deps/npm/node_modules/normalize-package-data/lib/warning_messages.json delete mode 100644 deps/npm/node_modules/normalize-package-data/package.json diff --git a/deps/npm/README.md b/deps/npm/README.md index 6271d5d33c0f01..efb9f9cd1c7f18 100644 --- a/deps/npm/README.md +++ b/deps/npm/README.md @@ -36,13 +36,12 @@ npm * [**RFCs**](https://github.com/npm/rfcs) - Contribute ideas & specifications for the API/design of the npm CLI * [**Service Status**](https://status.npmjs.org/) - Monitor the current status & see incident reports for the website & registry * [**Project Status**](https://npm.github.io/statusboard/) - See the health of all our maintained OSS projects in one view -* [**Events Calendar**](https://calendar.google.com/calendar/u/0/embed?src=npmjs.com_oonluqt8oftrt0vmgrfbg6q6go@group.calendar.google.com) - Keep track of our Open RFC calls, releases, meetups, conferences & more -* [**Support**](https://www.npmjs.com/support) - Experiencing problems with the **npm** [website](https://npmjs.com) or [registry](https://registry.npmjs.org)? File a ticket [here](https://www.npmjs.com/support) +* [**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 [here](https://docs.npmjs.com/cli/v7/using-npm/registry) +* 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 diff --git a/deps/npm/docs/content/commands/npm-access.md b/deps/npm/docs/content/commands/npm-access.md index e08030deba076d..1c6e168f230138 100644 --- a/deps/npm/docs/content/commands/npm-access.md +++ b/deps/npm/docs/content/commands/npm-access.md @@ -22,56 +22,28 @@ Note: This command is unaware of workspaces. 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. +For all of the subcommands, `npm access` will perform actions on the packages in the current working directory if no package name is passed to the subcommand. -* public / restricted (deprecated): - Set a package to be either publicly accessible or restricted. - -* grant / revoke (deprecated): - Add or remove the ability of users and teams to have read-only or read-write - access to a package. - -* 2fa-required / 2fa-not-required (deprecated): - Configure whether a package requires that anyone publishing it have two-factor - authentication enabled on their account. - -* ls-packages (deprecated): - Show all of the packages a user or a team is able to access, along with the - access level, except for read-only public packages (it won't print the whole - registry listing) - -* ls-collaborators (deprecated): - Show all of the access privileges for a package. Will only show permissions - for packages to which you have at least read access. If `` is passed in, - the list is filtered only to teams _that_ user happens to belong to. - -* edit (not implemented) +* 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=`. +`npm access` always operates directly on the current registry, configurable from the command line using `--registry=`. Unscoped packages are *always public*. -Scoped packages *default to restricted*, but you can either publish them as -public using `npm publish --access=public`, or set their access as public using -`npm access public` after the initial publish. +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. +* 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 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 +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. @@ -85,8 +57,8 @@ Management of teams and team memberships is done with the `npm team` command. 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`. +* 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. @@ -97,11 +69,12 @@ Not supported by all npm commands. * 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`. +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. +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. diff --git a/deps/npm/docs/content/commands/npm-adduser.md b/deps/npm/docs/content/commands/npm-adduser.md index a42ac6b863915e..78edb5d5702d7b 100644 --- a/deps/npm/docs/content/commands/npm-adduser.md +++ b/deps/npm/docs/content/commands/npm-adduser.md @@ -16,14 +16,13 @@ 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)). +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 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. +When using `legacy` for your `auth-type`, the username, password, and email are read in from prompts. ### Configuration @@ -72,8 +71,8 @@ npm init --scope=@foo --yes * 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`. +What authentication strategy to use with `login`. Note that if an +`otp` config is given, this value will always be set to `legacy`. diff --git a/deps/npm/docs/content/commands/npm-audit.md b/deps/npm/docs/content/commands/npm-audit.md index 17af3a686cb456..f38f933bee7962 100644 --- a/deps/npm/docs/content/commands/npm-audit.md +++ b/deps/npm/docs/content/commands/npm-audit.md @@ -12,32 +12,23 @@ 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 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. +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. +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. +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 @@ -49,12 +40,9 @@ Registry signatures can be verified using the following `audit` command: $ 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 `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: @@ -91,7 +79,7 @@ The `sig` is generated using the following template: `${package.name}@${package. Keys response: - `expires`: null or a simplified extended [ISO 8601 format](https://en.wikipedia.org/wiki/ISO_8601): `YYYY-MM-DDTHH:mm:ss.sssZ` -- `keydid`: sha256 fingerprint of the public key +- `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 @@ -100,42 +88,29 @@ See this [example key's response from the public npm registry](https://registry. ### Audit Endpoints -There are two audit endpoints that npm may use to fetch vulnerability -information: the `Bulk Advisory` endpoint and the `Quick Audit` endpoint. +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. +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`. +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. +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. +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`. +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. +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. +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: +The full package tree as found in `package-lock.json` is submitted, along with the following pieces of additional metadata: * `npm_version` * `node_version` @@ -148,64 +123,41 @@ 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. +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. +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. +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`. +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). +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. +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. +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). +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: +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: +Run `audit fix` without modifying `node_modules`, but still updating the pkglock: ```bash $ npm audit fix --package-lock-only @@ -217,22 +169,19 @@ Skip updating `devDependencies`: $ npm audit fix --only=prod ``` -Have `audit fix` install SemVer-major updates to toplevel dependencies, not -just SemVer-compatible ones: +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: +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: +Scan your project for vulnerabilities and just show the details, without fixing anything: ```bash $ npm audit @@ -257,8 +206,8 @@ $ npm audit --audit-level=moderate * 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. +The minimum level of vulnerability for `npm audit` to exit with a +non-zero exit code. @@ -267,13 +216,14 @@ exit code. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -288,14 +238,16 @@ 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 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. +* 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). @@ -312,8 +264,8 @@ recommended that you do not use this option! 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`. +* 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. @@ -324,14 +276,15 @@ Not supported by all npm commands. * Default: false * Type: Boolean -If set to true, the current operation will only use the `package-lock.json`, -ignoring `node_modules`. +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`. +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`. @@ -340,15 +293,16 @@ For `list` this means the output will be based on the tree described by the * 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. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -357,40 +311,45 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +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` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -401,10 +360,10 @@ but can be useful for debugging. 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. +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. @@ -413,9 +372,9 @@ run any pre- or post-scripts. * 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. +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: @@ -424,9 +383,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -438,13 +397,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -455,9 +415,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -466,9 +427,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-bugs.md b/deps/npm/docs/content/commands/npm-bugs.md index eef11c98b4c264..8789f21aa0143d 100644 --- a/deps/npm/docs/content/commands/npm-bugs.md +++ b/deps/npm/docs/content/commands/npm-bugs.md @@ -14,11 +14,8 @@ 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. +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 @@ -50,9 +47,9 @@ The base URL of the npm registry. * 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. +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: @@ -61,9 +58,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -75,13 +72,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -92,9 +90,10 @@ This value is not exported to the environment for child processes. 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. +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. diff --git a/deps/npm/docs/content/commands/npm-cache.md b/deps/npm/docs/content/commands/npm-cache.md index c61e2ac2555bf8..d1b114cfbeffee 100644 --- a/deps/npm/docs/content/commands/npm-cache.md +++ b/deps/npm/docs/content/commands/npm-cache.md @@ -26,10 +26,12 @@ 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. + 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. + 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. @@ -50,20 +52,26 @@ Also used to view info about entries in the `npm exec` (aka `npx`) cache folder. ### 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. +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. +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. +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. +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`. +To run an offline verification of existing cache contents, use `npm cache verify`. ### Configuration diff --git a/deps/npm/docs/content/commands/npm-ci.md b/deps/npm/docs/content/commands/npm-ci.md index e9e00271684181..115ea4a1b2a762 100644 --- a/deps/npm/docs/content/commands/npm-ci.md +++ b/deps/npm/docs/content/commands/npm-ci.md @@ -14,10 +14,7 @@ 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. +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: @@ -25,18 +22,14 @@ The main differences between using `npm install` and `npm ci` are: `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. +* `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, +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. @@ -78,11 +71,12 @@ cache: * 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. +(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. @@ -93,10 +87,10 @@ link in place, unhoisted. * 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`. +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`. @@ -107,15 +101,15 @@ de-duplicating. Sets `--install-strategy=nested`. * 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`. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -124,25 +118,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -152,33 +150,35 @@ the order in which omit/include are specified on the command-line. * 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. +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. +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. +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` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -189,10 +189,10 @@ but can be useful for debugging. 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. +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. @@ -201,10 +201,10 @@ run any pre- or post-scripts. * 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. +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. @@ -216,9 +216,9 @@ submitted. 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. +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. @@ -228,8 +228,8 @@ systems. * 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. +acknowledging the number of dependencies looking for funding. See +[`npm fund`](/commands/npm-fund) for details. @@ -238,13 +238,14 @@ fund`](/commands/npm-fund) for details. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -253,9 +254,9 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, * 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. +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: @@ -264,9 +265,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -278,13 +279,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -295,9 +297,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -306,9 +309,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-completion.md b/deps/npm/docs/content/commands/npm-completion.md index 8cbc71306c851a..f34c3713b2df9a 100644 --- a/deps/npm/docs/content/commands/npm-completion.md +++ b/deps/npm/docs/content/commands/npm-completion.md @@ -16,24 +16,19 @@ Note: This command is unaware of workspaces. 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: +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 +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. +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 diff --git a/deps/npm/docs/content/commands/npm-config.md b/deps/npm/docs/content/commands/npm-config.md index 603161b0687d67..78aa4c4d3fa3c1 100644 --- a/deps/npm/docs/content/commands/npm-config.md +++ b/deps/npm/docs/content/commands/npm-config.md @@ -21,17 +21,13 @@ 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. +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 [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. +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. +The `npm config` command can be used to update and edit the contents of the user and global npmrc files. ### Sub-commands @@ -44,13 +40,12 @@ 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. +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`. +Note: for backwards compatibility, `npm config set key value` is supported as an alias for `npm config set key=value`. #### get @@ -61,11 +56,9 @@ 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 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`. +If no keys are provided, then this command behaves the same as `npm config list`. #### list @@ -73,8 +66,9 @@ list`. npm config list ``` -Show all the config settings. Use `-l` to also show defaults. Use `--json` -to show the settings in json format. +Show all the config settings. +Use `-l` to also show defaults. +Use `--json` to show the settings in json format. #### delete @@ -90,8 +84,8 @@ Deletes the specified keys from all configuration files. npm config edit ``` -Opens the config file in an editor. Use the `--global` flag to edit the -global config. +Opens the config file in an editor. +Use the `--global` flag to edit the global config. #### fix @@ -99,9 +93,9 @@ global config. npm config fix ``` -Attempts to repair invalid configuration items. Usually this means -attaching authentication config (i.e. `_auth`, `_authToken`) to the -configured `registry`. +Attempts to repair invalid configuration items. +Usually this means attaching authentication config (i.e. +`_auth`, `_authToken`) to the configured `registry`. ### Configuration @@ -112,8 +106,8 @@ configured `registry`. 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`. +* 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. @@ -124,12 +118,13 @@ Not supported by all npm commands. * 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. +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. +* 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` @@ -147,18 +142,19 @@ 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" +* 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. +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. +* 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` diff --git a/deps/npm/docs/content/commands/npm-dedupe.md b/deps/npm/docs/content/commands/npm-dedupe.md index 1ff142ec4f806f..beace9335f0629 100644 --- a/deps/npm/docs/content/commands/npm-dedupe.md +++ b/deps/npm/docs/content/commands/npm-dedupe.md @@ -14,9 +14,7 @@ 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. +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: @@ -37,9 +35,7 @@ a `-- 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. +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: @@ -51,29 +47,21 @@ a `-- 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. +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. +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`. +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. +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. +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. +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 @@ -83,11 +71,12 @@ values in `package.json` you can run: `npm update --save` instead. * 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. +(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. @@ -98,10 +87,10 @@ link in place, unhoisted. * 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`. +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`. @@ -112,8 +101,8 @@ de-duplicating. Sets `--install-strategy=nested`. * 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`. +Only install direct dependencies in the top level `node_modules`, but +hoist on deeper dependencies. Sets `--install-strategy=shallow`. @@ -123,18 +112,19 @@ on deeper dependencies. Sets `--install-strategy=shallow`. * 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. +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. +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. +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. @@ -143,15 +133,16 @@ this warning is treated as a failure. * 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. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -160,25 +151,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -189,10 +184,10 @@ the order in which omit/include are specified on the command-line. 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. +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. @@ -201,10 +196,10 @@ run any pre- or post-scripts. * 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. +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. @@ -216,9 +211,9 @@ submitted. 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. +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. @@ -228,8 +223,8 @@ systems. * 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. +acknowledging the number of dependencies looking for funding. See +[`npm fund`](/commands/npm-fund) for details. @@ -238,13 +233,14 @@ fund`](/commands/npm-fund) for details. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -253,9 +249,9 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, * 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. +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: @@ -264,9 +260,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -278,13 +274,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -295,9 +292,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -306,9 +304,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-deprecate.md b/deps/npm/docs/content/commands/npm-deprecate.md index 80b039b25a0dbb..0724791ef484ab 100644 --- a/deps/npm/docs/content/commands/npm-deprecate.md +++ b/deps/npm/docs/content/commands/npm-deprecate.md @@ -14,18 +14,16 @@ 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. +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: +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: +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" @@ -33,12 +31,11 @@ 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. +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. +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 @@ -56,11 +53,12 @@ The base URL of the npm registry. * 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`. +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. +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. @@ -69,13 +67,14 @@ password, npm will prompt on the command line for one. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. diff --git a/deps/npm/docs/content/commands/npm-diff.md b/deps/npm/docs/content/commands/npm-diff.md index 5248410972785d..6337c04ba03700 100644 --- a/deps/npm/docs/content/commands/npm-diff.md +++ b/deps/npm/docs/content/commands/npm-diff.md @@ -12,22 +12,16 @@ npm diff [...] ### Description -Similar to its `git diff` counterpart, this command will print diff patches -of files for packages published to the npm registry. +Similar to its `git diff` counterpart, this command will print diff patches of files for packages published to the npm registry. * `npm diff --diff= --diff=` - 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`. + 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` + 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: + 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 @@ -50,39 +44,24 @@ of files for packages published to the npm registry. "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`: + 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. + 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. + 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. + 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=` (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 `` - will satisfy its dependent declared semver-range. Once that specific - version is known `npm diff` will print diff patches comparing the - current version of `` found in the local file system with - that specific version returned by the registry. + 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 `` will satisfy its dependent declared semver-range. + Once that specific version is known `npm diff` will print diff patches comparing the current version of `` found in the local file system with that specific version returned by the registry. Given a package named `abbrev` that is currently installed: @@ -90,19 +69,13 @@ of files for packages published to the npm registry. 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. + 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=` (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 ``. + 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 ``. - An example: assuming `pkg@1.0.0` is installed in the current `node_modules` - folder, running: + An example: assuming `pkg@1.0.0` is installed in the current `node_modules` folder, running: ```bash npm diff --diff=pkg@2.0.0 @@ -113,39 +86,29 @@ of files for packages published to the npm registry. * `npm diff --diff= [--diff=]` (in a package directory): - Using `npm diff` along with semver-valid version numbers is a shorthand - to compare different versions of the current package. + 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`. + 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 `` is provided, then the current local - file system is going to be compared against that version. + If only a single argument `` 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: + 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. +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: +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. +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 @@ -229,12 +192,13 @@ Treat all files as text in `npm diff`. * 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. +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. +* 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` @@ -245,17 +209,17 @@ folder instead of the current working directory. See * 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. +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. +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. +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. +If used in the `npm publish` command, this is the tag that will be +added to the package submitted to the registry. @@ -264,9 +228,9 @@ the package submitted to the registry. * 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. +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: @@ -275,9 +239,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -289,13 +253,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -306,9 +271,10 @@ This value is not exported to the environment for child processes. 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. +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 diff --git a/deps/npm/docs/content/commands/npm-dist-tag.md b/deps/npm/docs/content/commands/npm-dist-tag.md index 609da16b6d3ab1..c39e54b6b28e32 100644 --- a/deps/npm/docs/content/commands/npm-dist-tag.md +++ b/deps/npm/docs/content/commands/npm-dist-tag.md @@ -18,22 +18,16 @@ alias: dist-tags 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 `, or go through a second factor flow based on your `authtype`. +* 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 `, 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 `, - 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 `, 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. +* 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: +A tag can be used when installing packages as a reference to a version instead of using a specific version number: ```bash npm install @ @@ -45,28 +39,22 @@ When installing dependencies, a preferred tagged version may be specified: npm install --tag ``` -(This also applies to any other commands that resolve and install -dependencies, such as `npm dedupe`, `npm update`, and `npm audit fix`.) +(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`. +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 ` (without any `@` or `@` -specifier) installs the `latest` tag. +By default, `npm install ` (without any `@` or `@` 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`, +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 ` (without any `@` or `@` -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. +By default, the `latest` tag is used by npm to identify the current version of a package, and `npm install ` (without any `@` or `@` 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. @@ -74,19 +62,15 @@ 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. +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 @` vs -`npm install @`. +Tags must share a namespace with version numbers, because they are specified in the same slot: `npm install @` vs `npm install @`. -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 . +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 . -The simplest way to avoid semver problems with tags is to use tags that do -not begin with a number or the letter `v`. +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 @@ -95,9 +79,9 @@ not begin with a number or the letter `v`. * 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. +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: @@ -106,9 +90,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -120,13 +104,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -137,9 +122,10 @@ This value is not exported to the environment for child processes. 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. +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. diff --git a/deps/npm/docs/content/commands/npm-docs.md b/deps/npm/docs/content/commands/npm-docs.md index f41e6770df0af5..21bbcbd58c3d76 100644 --- a/deps/npm/docs/content/commands/npm-docs.md +++ b/deps/npm/docs/content/commands/npm-docs.md @@ -14,11 +14,9 @@ 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. +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 @@ -50,9 +48,9 @@ The base URL of the npm registry. * 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. +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: @@ -61,9 +59,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -75,13 +73,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -92,9 +91,10 @@ This value is not exported to the environment for child processes. 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. +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. diff --git a/deps/npm/docs/content/commands/npm-doctor.md b/deps/npm/docs/content/commands/npm-doctor.md index a96036a773b2a1..848f38a1c8b102 100644 --- a/deps/npm/docs/content/commands/npm-doctor.md +++ b/deps/npm/docs/content/commands/npm-doctor.md @@ -14,96 +14,71 @@ 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: +`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 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. +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. +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. +`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`. +`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. +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. +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! +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. +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. +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. +* 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. +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 diff --git a/deps/npm/docs/content/commands/npm-edit.md b/deps/npm/docs/content/commands/npm-edit.md index a26df11b5dd07e..dad77b0b7f3038 100644 --- a/deps/npm/docs/content/commands/npm-edit.md +++ b/deps/npm/docs/content/commands/npm-edit.md @@ -14,16 +14,11 @@ 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).) +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. +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. +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 diff --git a/deps/npm/docs/content/commands/npm-exec.md b/deps/npm/docs/content/commands/npm-exec.md index 7869befcdd1bf4..ac5b2a471a74b8 100644 --- a/deps/npm/docs/content/commands/npm-exec.md +++ b/deps/npm/docs/content/commands/npm-exec.md @@ -17,58 +17,34 @@ 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. +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. +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: @@ -76,34 +52,29 @@ For example: $ npx foo@latest bar --package=@npmcli/foo ``` -In this case, npm will resolve the `foo` package name, and run the -following command: +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. +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: +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: +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: +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 @@ -116,7 +87,8 @@ $ npm exec -- foo@latest bar --package=@npmcli/foo * Default: * Type: String (can be set multiple times) -The package or packages to install for [`npm exec`](/commands/npm-exec) +The package or packages to install for [`npm +exec`](/commands/npm-exec) @@ -125,8 +97,9 @@ The package or packages to install for [`npm exec`](/commands/npm-exec) * 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. +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" @@ -139,9 +112,9 @@ npm exec --package yo --package generator-node --call "yo node" * 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. +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: @@ -150,9 +123,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -164,13 +137,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -181,24 +155,23 @@ This value is not exported to the environment for child processes. 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. +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: +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: +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 @@ -215,13 +188,8 @@ $ 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. +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: @@ -237,8 +205,8 @@ Given a project with configured workspaces, e.g: `-- package.json ``` -Assuming the workspace configuration is properly set up at the root level -`package.json` file. e.g: +Assuming the workspace configuration is properly set up at the root level `package.json` file. +e.g: ``` { @@ -246,10 +214,7 @@ Assuming the workspace configuration is properly set up at the root level } ``` -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: +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 @@ -257,17 +222,14 @@ 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: +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: +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 @@ -278,69 +240,60 @@ This last command will run the `eslint` command in both `./packages/a` and ### 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. +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. + 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 `-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. +- 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. +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. +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`. +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. +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. +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) +* 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. @@ -350,8 +303,7 @@ This value is not exported to the environment for child processes. * Type: Boolean * Default: `false` -Run scripts in the context of all configured workspaces for the current -project. +Run scripts in the context of all configured workspaces for the current project. ### See Also diff --git a/deps/npm/docs/content/commands/npm-explain.md b/deps/npm/docs/content/commands/npm-explain.md index b0f0ebcb680831..c5a89ca793906d 100644 --- a/deps/npm/docs/content/commands/npm-explain.md +++ b/deps/npm/docs/content/commands/npm-explain.md @@ -14,11 +14,9 @@ alias: why ### Description -This command will print the chain of dependencies causing a given package -to be installed in the current project. +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. +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` @@ -38,10 +36,8 @@ node_modules/tacks/node_modules/glob 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. +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 @@ -62,8 +58,8 @@ node_modules/nyc/node_modules/find-up 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`. +* 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. @@ -74,9 +70,9 @@ Not supported by all npm commands. * 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. +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: @@ -85,9 +81,9 @@ Valid values for the `workspace` config are either: * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-explore.md b/deps/npm/docs/content/commands/npm-explore.md index e25e760d08d70a..be37de759c83f2 100644 --- a/deps/npm/docs/content/commands/npm-explore.md +++ b/deps/npm/docs/content/commands/npm-explore.md @@ -16,25 +16,22 @@ Note: This command is unaware of workspaces. 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. +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: +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 ` if you make any changes. +Note that the package is *not* automatically rebuilt afterwards, so be sure to use `npm rebuild ` if you make any changes. ### Configuration #### `shell` -* Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" on - Windows +* Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" + on Windows * Type: String The shell to run for the `npm explore` command. diff --git a/deps/npm/docs/content/commands/npm-find-dupes.md b/deps/npm/docs/content/commands/npm-find-dupes.md index bf1a474033cc6d..25cf8a32b1b714 100644 --- a/deps/npm/docs/content/commands/npm-find-dupes.md +++ b/deps/npm/docs/content/commands/npm-find-dupes.md @@ -12,8 +12,7 @@ npm find-dupes ### Description -Runs `npm dedupe` in `--dry-run` mode, making npm only output the -duplications, without actually changing the package tree. +Runs `npm dedupe` in `--dry-run` mode, making npm only output the duplications, without actually changing the package tree. ### Configuration @@ -23,11 +22,12 @@ duplications, without actually changing the package tree. * 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. +(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. @@ -38,10 +38,10 @@ link in place, unhoisted. * 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`. +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`. @@ -52,8 +52,8 @@ de-duplicating. Sets `--install-strategy=nested`. * 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`. +Only install direct dependencies in the top level `node_modules`, but +hoist on deeper dependencies. Sets `--install-strategy=shallow`. @@ -63,18 +63,19 @@ on deeper dependencies. Sets `--install-strategy=shallow`. * 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. +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. +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. +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. @@ -83,15 +84,16 @@ this warning is treated as a failure. * 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. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -100,25 +102,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -129,10 +135,10 @@ the order in which omit/include are specified on the command-line. 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. +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. @@ -141,10 +147,10 @@ run any pre- or post-scripts. * 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. +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. @@ -156,9 +162,9 @@ submitted. 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. +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. @@ -168,8 +174,8 @@ systems. * 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. +acknowledging the number of dependencies looking for funding. See +[`npm fund`](/commands/npm-fund) for details. @@ -178,9 +184,9 @@ fund`](/commands/npm-fund) for details. * 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. +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: @@ -189,9 +195,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -203,13 +209,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -220,9 +227,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -231,9 +239,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-fund.md b/deps/npm/docs/content/commands/npm-fund.md index a2c7bce3e9214f..235d626c050231 100644 --- a/deps/npm/docs/content/commands/npm-fund.md +++ b/deps/npm/docs/content/commands/npm-fund.md @@ -12,31 +12,23 @@ npm fund [] ### 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 +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`. +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. +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`: +Here's an example running `npm fund` in a project with a configured workspace `a`: ```bash $ npm fund @@ -51,8 +43,7 @@ test-workspaces-fund@1.0.0 `-- 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: +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 @@ -72,8 +63,8 @@ test-workspaces-fund@1.0.0 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`. +* 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. @@ -95,12 +86,13 @@ 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. +* 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. +When set to true, npm uses unicode characters in the tree output. +When false, it uses ascii characters instead of unicode glyphs. @@ -109,9 +101,9 @@ false, it uses ascii characters instead of unicode glyphs. * 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. +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: @@ -120,9 +112,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -131,7 +123,8 @@ This value is not exported to the environment for child processes. * Default: null * Type: null or Number -If there are multiple funding sources, which 1-indexed source URL to open. +If there are multiple funding sources, which 1-indexed source URL to +open. diff --git a/deps/npm/docs/content/commands/npm-help-search.md b/deps/npm/docs/content/commands/npm-help-search.md index 5bc4602ef9811f..caf761750c5551 100644 --- a/deps/npm/docs/content/commands/npm-help-search.md +++ b/deps/npm/docs/content/commands/npm-help-search.md @@ -14,14 +14,12 @@ 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. +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. +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 diff --git a/deps/npm/docs/content/commands/npm-help.md b/deps/npm/docs/content/commands/npm-help.md index bc2c8762eefdae..6e935670c6d666 100644 --- a/deps/npm/docs/content/commands/npm-help.md +++ b/deps/npm/docs/content/commands/npm-help.md @@ -18,10 +18,8 @@ Note: This command is unaware of workspaces. 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. +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 @@ -32,7 +30,8 @@ topic, so unique matches are equivalent to specifying a topic name. The program to use to view help content. -Set to `"browser"` to view html help content in the default web browser. +Set to `"browser"` to view html help content in the default web +browser. diff --git a/deps/npm/docs/content/commands/npm-init.md b/deps/npm/docs/content/commands/npm-init.md index 9e0e6e0f42b913..3049eeead613d2 100644 --- a/deps/npm/docs/content/commands/npm-init.md +++ b/deps/npm/docs/content/commands/npm-init.md @@ -15,16 +15,12 @@ aliases: create, innit ### Description -`npm init ` can be used to set up a new or existing npm -package. +`npm init ` can be used to set up a new or existing npm package. `initializer` in this case is an npm package named `create-`, -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. +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: +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` @@ -32,46 +28,37 @@ follows: * `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-` 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 +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-` 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`. +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: +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= -- --hello -a` - `npm exec -y --registry= -- create-foo --hello -a` ### Examples -Create a new React-based project using -[`create-react-app`](https://npm.im/create-react-app): +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): +Create a new `esm`-compatible package using [`create-esm`](https://npm.im/create-esm): ```bash $ mkdir my-esm-lib && cd my-esm-lib @@ -99,11 +86,8 @@ $ 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 ` 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. +It's possible to create a new workspace within your project by using the `workspace` config option. +When using `npm init -w ` 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: @@ -118,8 +102,7 @@ You may generate a new workspace using the legacy init: $ 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: +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: ``` . @@ -129,23 +112,15 @@ your top-level `package.json` to add the reference to this new workspace: `-- package.json ``` -The workspaces init also supports the `npm init -w ` -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: +The workspaces init also supports the `npm init -w ` 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 .`: +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 .`: ``` . @@ -166,7 +141,8 @@ dot to represent the current directory in that context, e.g: `react-app .`: * Default: "" * Type: String -The value `npm init` should use by default for the package author's name. +The value `npm init` should use by default for the package author's +name. @@ -196,8 +172,8 @@ The value `npm init` should use by default for the package license. 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-package-json](https://github.com/npm/init-package-json) module +for more information, or [npm init](/commands/npm-init). @@ -206,8 +182,8 @@ more information, or [npm init](/commands/npm-init). * Default: "commonjs" * Type: String -The value that `npm init` should use by default for the package.json type -field. +The value that `npm init` should use by default for the package.json +type field. @@ -216,8 +192,8 @@ field. * 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. +The value that `npm init` should use by default for the package +version number, if not already set in package.json. @@ -226,7 +202,8 @@ number, if not already set in package.json. * Default: false * Type: Boolean -The value `npm init` should use by default for the package's private flag. +The value `npm init` should use by default for the package's private +flag. @@ -251,14 +228,16 @@ 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 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. +* 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). @@ -304,9 +283,9 @@ npm init --scope=@foo --yes * 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. +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: @@ -315,9 +294,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -329,13 +308,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -344,8 +324,9 @@ This value is not exported to the environment for child processes. * 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. +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. @@ -356,9 +337,10 @@ possibly change the workspaces installed to the `node_modules` folder. 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. +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. diff --git a/deps/npm/docs/content/commands/npm-install-ci-test.md b/deps/npm/docs/content/commands/npm-install-ci-test.md index 8b2f03e418a839..0ec8030a3197c4 100644 --- a/deps/npm/docs/content/commands/npm-install-ci-test.md +++ b/deps/npm/docs/content/commands/npm-install-ci-test.md @@ -24,11 +24,12 @@ This command runs `npm ci` followed immediately by `npm test`. * 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. +(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. @@ -39,10 +40,10 @@ link in place, unhoisted. * 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`. +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`. @@ -53,15 +54,15 @@ de-duplicating. Sets `--install-strategy=nested`. * 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`. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -70,25 +71,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -98,33 +103,35 @@ the order in which omit/include are specified on the command-line. * 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. +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. +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. +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` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -135,10 +142,10 @@ but can be useful for debugging. 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. +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. @@ -147,10 +154,10 @@ run any pre- or post-scripts. * 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. +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. @@ -162,9 +169,9 @@ submitted. 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. +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. @@ -174,8 +181,8 @@ systems. * 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. +acknowledging the number of dependencies looking for funding. See +[`npm fund`](/commands/npm-fund) for details. @@ -184,13 +191,14 @@ fund`](/commands/npm-fund) for details. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -199,9 +207,9 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, * 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. +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: @@ -210,9 +218,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -224,13 +232,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -241,9 +250,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -252,9 +262,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-install-test.md b/deps/npm/docs/content/commands/npm-install-test.md index ee206cdf3ad9f7..275405ff5c1ce8 100644 --- a/deps/npm/docs/content/commands/npm-install-test.md +++ b/deps/npm/docs/content/commands/npm-install-test.md @@ -14,14 +14,15 @@ alias: it ### Description -This command runs an `npm install` followed immediately by an `npm test`. It -takes exactly the same arguments as `npm install`. +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` +* Default: `true` unless when using `npm update` where it defaults to + `false` * Type: Boolean Save installed packages to a `package.json` file as dependencies. @@ -38,8 +39,8 @@ Will also prevent writing to `package-lock.json` if set to `false`. * 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. +Dependencies saved to package.json will be configured with an exact +version rather than using npm's default semver range operator. @@ -48,12 +49,13 @@ rather than using npm's default semver range operator. * 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. +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. +* 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` @@ -65,11 +67,12 @@ folder instead of the current working directory. See * 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. +(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. @@ -80,10 +83,10 @@ link in place, unhoisted. * 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`. +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`. @@ -94,15 +97,15 @@ de-duplicating. Sets `--install-strategy=nested`. * 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`. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -111,25 +114,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -139,18 +146,19 @@ the order in which omit/include are specified on the command-line. * 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. +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. +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. +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. @@ -159,8 +167,8 @@ this warning is treated as a failure. * Default: false * Type: Boolean -Prefer to deduplicate packages if possible, rather than choosing a newer -version of a dependency. +Prefer to deduplicate packages if possible, rather than choosing a +newer version of a dependency. @@ -169,8 +177,9 @@ version of a dependency. * 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. +If set to false, then ignore `package-lock.json` files when +installing. This will also prevent _writing_ `package-lock.json` if +`save` is true. @@ -179,29 +188,31 @@ will also prevent _writing_ `package-lock.json` if `save` is true. * Default: false * Type: Boolean -If set to true, the current operation will only use the `package-lock.json`, -ignoring `node_modules`. +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`. +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` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -212,10 +223,10 @@ but can be useful for debugging. 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. +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. @@ -224,10 +235,10 @@ run any pre- or post-scripts. * 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. +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. @@ -237,14 +248,14 @@ submitted. * 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. +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`. +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`. @@ -256,9 +267,9 @@ will be used. For example, `foo@latest` might install `foo@1.2` even though 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. +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. @@ -268,8 +279,8 @@ systems. * 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. +acknowledging the number of dependencies looking for funding. See +[`npm fund`](/commands/npm-fund) for details. @@ -278,13 +289,14 @@ fund`](/commands/npm-fund) for details. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -293,8 +305,9 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, * 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`. +Override CPU architecture of native modules to install. Acceptable +values are same as `cpu` field of package.json, which comes from +`process.arch`. @@ -303,8 +316,8 @@ are same as `cpu` field of package.json, which comes from `process.arch`. * 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`. +Override OS of native modules to install. Acceptable values are same +as `os` field of package.json, which comes from `process.platform`. @@ -313,8 +326,8 @@ field of package.json, which comes from `process.platform`. * Default: null * Type: null or String -Override libc of native modules to install. Acceptable values are same as -`libc` field of package.json +Override libc of native modules to install. Acceptable values are +same as `libc` field of package.json @@ -323,9 +336,9 @@ Override libc of native modules to install. Acceptable values are same as * 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. +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: @@ -334,9 +347,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -348,13 +361,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -365,9 +379,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -376,9 +391,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-install.md b/deps/npm/docs/content/commands/npm-install.md index 0068d1f2d25092..edb71938893eda 100644 --- a/deps/npm/docs/content/commands/npm-install.md +++ b/deps/npm/docs/content/commands/npm-install.md @@ -14,64 +14,45 @@ 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: +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). +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 +* 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 `@` that is published on the registry (see - [`registry`](/using-npm/registry)) with (c) -* e) a `@` (see [`npm dist-tag`](/commands/npm-dist-tag)) that - points to (d) +* d) a `@` that is published on the registry (see [`registry`](/using-npm/registry)) with (c) +* e) a `@` (see [`npm dist-tag`](/commands/npm-dist-tag)) that points to (d) * f) a `` that has a "latest" tag satisfying (e) * g) a `` 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). +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. + 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). + 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`. + 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. + > NOTE: The `--production` flag has no particular meaning when adding a dependency to a project. * `npm install `: - If `` 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 `` sits outside the root of your project, - *npm will not install the package dependencies* in the directory ``, - but it will create a symlink to ``. + If `` 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 `` sits outside the root of your project, *npm will not install the package dependencies* in the directory ``, but it will create a symlink to ``. > 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. @@ -84,19 +65,14 @@ into a tarball (b). * `npm install `: - 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). + 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. + * 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: @@ -106,8 +82,8 @@ into a tarball (b). * `npm install `: - 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://" + 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: @@ -117,11 +93,11 @@ into a tarball (b). * `npm install [<@scope>/]`: - Do a `@` install, where `` is the "tag" config. (See - [`config`](/using-npm/config#tag). The config's default value is `latest`.) + Do a `@` install, where `` 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. + In most cases, this will install the version of the modules tagged as `latest` on the npm registry. Example: @@ -130,11 +106,10 @@ into a tarball (b). ``` `npm install` saves any specified packages into `dependencies` by default. - Additionally, you can control where and how they get saved with some - additional flags: + 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. + * `-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`. @@ -145,26 +120,21 @@ into a tarball (b). * `--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: + 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. + * `-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. + * `-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. + Further, if you have an `npm-shrinkwrap.json` or `package-lock.json` then it will be updated as well. - `` 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). + `` 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. + 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: @@ -180,13 +150,10 @@ into a tarball (b). * `npm install @npm:`: - 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). + 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: @@ -200,8 +167,7 @@ into a tarball (b). * `npm install [<@scope>/]@`: 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. + If the tag does not exist in the registry data for that package, then this will fail. Example: @@ -212,8 +178,8 @@ into a tarball (b). * `npm install [<@scope>/]@`: - Install the specified version of the package. This will fail if the - version has not been published to the registry. + Install the specified version of the package. + This will fail if the version has not been published to the registry. Example: @@ -225,11 +191,9 @@ into a tarball (b). * `npm install [<@scope>/]@`: 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). + 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. + Note that most version ranges must be put in quotes so that your shell will treat it as a single argument. Example: @@ -240,8 +204,8 @@ into a tarball (b). * `npm install `: - Installs the package from the hosted git provider, cloning it with - `git`. For a full git remote url, only that URL will be attempted. + 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 ://[[:]@][:][:][/][# | #semver:] @@ -250,23 +214,15 @@ into a tarball (b). `` is one of `git`, `git+ssh`, `git+http`, `git+https`, or `git+file`. - If `#` is provided, it will be used to clone exactly that - commit. If the commit-ish has the format `#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 `#` or - `#semver:` is specified, then the default branch of the - repository is used. + If `#` is provided, it will be used to clone exactly that commit. + If the commit-ish has the format `#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 `#` or `#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 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. + 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: + The following git environment variables are recognized by npm and will be added to the environment when running git: * `GIT_ASKPASS` * `GIT_EXEC_PATH` @@ -292,19 +248,13 @@ into a tarball (b). * `npm install /[#]`: * `npm install github:/[#]`: - Install the package at `https://github.com/githubname/githubrepo` by - attempting to clone it using `git`. + Install the package at `https://github.com/githubname/githubrepo` by attempting to clone it using `git`. - If `#` is provided, it will be used to clone exactly that - commit. If the commit-ish has the format `#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 `#` or - `#semver:` is specified, then the default branch is used. + If `#` is provided, it will be used to clone exactly that commit. + If the commit-ish has the format `#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 `#` or `#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. + 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: @@ -315,13 +265,10 @@ into a tarball (b). * `npm install gist:[/][#|#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`. + 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. + 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: @@ -331,19 +278,13 @@ into a tarball (b). * `npm install bitbucket:/[#]`: - Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo` - by attempting to clone it using `git`. + Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo` by attempting to clone it using `git`. - If `#` is provided, it will be used to clone exactly that - commit. If the commit-ish has the format `#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 `#` or `#semver:` is - specified, then `master` is used. + If `#` is provided, it will be used to clone exactly that commit. + If the commit-ish has the format `#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 `#` or `#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. + 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: @@ -353,19 +294,13 @@ into a tarball (b). * `npm install gitlab:/[#]`: - Install the package at `https://gitlab.com/gitlabname/gitlabrepo` - by attempting to clone it using `git`. + Install the package at `https://gitlab.com/gitlabname/gitlabrepo` by attempting to clone it using `git`. - If `#` is provided, it will be used to clone exactly that - commit. If the commit-ish has the format `#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 `#` or `#semver:` is - specified, then `master` is used. + If `#` is provided, it will be used to clone exactly that commit. + If the commit-ish has the format `#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 `#` or `#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. + 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: @@ -381,19 +316,14 @@ For example: 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 `--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 `--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 `--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. +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 @@ -401,15 +331,15 @@ 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. +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` +* Default: `true` unless when using `npm update` where it defaults to + `false` * Type: Boolean Save installed packages to a `package.json` file as dependencies. @@ -426,8 +356,8 @@ Will also prevent writing to `package-lock.json` if set to `false`. * 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. +Dependencies saved to package.json will be configured with an exact +version rather than using npm's default semver range operator. @@ -436,12 +366,13 @@ rather than using npm's default semver range operator. * 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. +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. +* 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` @@ -453,11 +384,12 @@ folder instead of the current working directory. See * 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. +(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. @@ -468,10 +400,10 @@ link in place, unhoisted. * 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`. +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`. @@ -482,15 +414,15 @@ de-duplicating. Sets `--install-strategy=nested`. * 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`. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -499,25 +431,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -527,18 +463,19 @@ the order in which omit/include are specified on the command-line. * 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. +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. +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. +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. @@ -547,8 +484,8 @@ this warning is treated as a failure. * Default: false * Type: Boolean -Prefer to deduplicate packages if possible, rather than choosing a newer -version of a dependency. +Prefer to deduplicate packages if possible, rather than choosing a +newer version of a dependency. @@ -557,8 +494,9 @@ version of a dependency. * 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. +If set to false, then ignore `package-lock.json` files when +installing. This will also prevent _writing_ `package-lock.json` if +`save` is true. @@ -567,29 +505,31 @@ will also prevent _writing_ `package-lock.json` if `save` is true. * Default: false * Type: Boolean -If set to true, the current operation will only use the `package-lock.json`, -ignoring `node_modules`. +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`. +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` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -600,10 +540,10 @@ but can be useful for debugging. 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. +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. @@ -612,10 +552,10 @@ run any pre- or post-scripts. * 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. +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. @@ -625,14 +565,14 @@ submitted. * 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. +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`. +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`. @@ -644,9 +584,9 @@ will be used. For example, `foo@latest` might install `foo@1.2` even though 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. +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. @@ -656,8 +596,8 @@ systems. * 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. +acknowledging the number of dependencies looking for funding. See +[`npm fund`](/commands/npm-fund) for details. @@ -666,13 +606,14 @@ fund`](/commands/npm-fund) for details. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -681,8 +622,9 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, * 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`. +Override CPU architecture of native modules to install. Acceptable +values are same as `cpu` field of package.json, which comes from +`process.arch`. @@ -691,8 +633,8 @@ are same as `cpu` field of package.json, which comes from `process.arch`. * 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`. +Override OS of native modules to install. Acceptable values are same +as `os` field of package.json, which comes from `process.platform`. @@ -701,8 +643,8 @@ field of package.json, which comes from `process.platform`. * Default: null * Type: null or String -Override libc of native modules to install. Acceptable values are same as -`libc` field of package.json +Override libc of native modules to install. Acceptable values are +same as `libc` field of package.json @@ -711,9 +653,9 @@ Override libc of native modules to install. Acceptable values are same as * 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. +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: @@ -722,9 +664,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -736,13 +678,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -753,9 +696,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -764,16 +708,15 @@ This value is not exported to the environment for child processes. * 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. +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: +Given a `package{dep}` structure: `A{B,C}, B{C}, C{D}`, the npm install algorithm produces: ```bash A @@ -782,9 +725,8 @@ A +-- 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. +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: @@ -796,13 +738,10 @@ A +-- 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. +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 [folders](/configuring-npm/folders) for a more detailed description of the specific folder structures that npm creates. ### See Also diff --git a/deps/npm/docs/content/commands/npm-link.md b/deps/npm/docs/content/commands/npm-link.md index b7677f06937bea..527c646c09adac 100644 --- a/deps/npm/docs/content/commands/npm-link.md +++ b/deps/npm/docs/content/commands/npm-link.md @@ -14,31 +14,23 @@ 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. +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/` 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). +First, `npm link` in a package folder with no arguments will create a symlink in the global folder `{prefix}/lib/node_modules/` 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. +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. +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. +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`. +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: @@ -50,11 +42,11 @@ 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. +`~/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: +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 @@ -68,14 +60,12 @@ The second line is the equivalent of doing: 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. +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. +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 @@ -83,36 +73,26 @@ 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. +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 --package-lock-only`. +If you are adding a _new_ dependency as a link, you should add it to the relevant metadata by running `npm install --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 --save` to do so. +If you _want_ to save the `file:` reference in your `package.json` and `package-lock.json` files, you can use `npm link --save` to do so. ### Workspace Usage -`npm link --workspace ` 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 ` 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 ` will create a global link to the specified -workspace(s). +`npm link --workspace ` will create a global link to the specified workspace(s). ### Configuration #### `save` -* Default: `true` unless when using `npm update` where it defaults to `false` +* Default: `true` unless when using `npm update` where it defaults to + `false` * Type: Boolean Save installed packages to a `package.json` file as dependencies. @@ -129,8 +109,8 @@ Will also prevent writing to `package-lock.json` if set to `false`. * 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. +Dependencies saved to package.json will be configured with an exact +version rather than using npm's default semver range operator. @@ -139,12 +119,13 @@ rather than using npm's default semver range operator. * 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. +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. +* 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` @@ -156,11 +137,12 @@ folder instead of the current working directory. See * 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. +(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. @@ -171,10 +153,10 @@ link in place, unhoisted. * 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`. +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`. @@ -185,8 +167,8 @@ de-duplicating. Sets `--install-strategy=nested`. * 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`. +Only install direct dependencies in the top level `node_modules`, but +hoist on deeper dependencies. Sets `--install-strategy=shallow`. @@ -196,18 +178,19 @@ on deeper dependencies. Sets `--install-strategy=shallow`. * 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. +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. +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. +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. @@ -216,15 +199,16 @@ this warning is treated as a failure. * 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. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -233,25 +217,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -262,10 +250,10 @@ the order in which omit/include are specified on the command-line. 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. +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. @@ -274,10 +262,10 @@ run any pre- or post-scripts. * 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. +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. @@ -289,9 +277,9 @@ submitted. 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. +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. @@ -301,8 +289,8 @@ systems. * 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. +acknowledging the number of dependencies looking for funding. See +[`npm fund`](/commands/npm-fund) for details. @@ -311,13 +299,14 @@ fund`](/commands/npm-fund) for details. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -326,9 +315,9 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, * 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. +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: @@ -337,9 +326,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -351,13 +340,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -368,9 +358,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -379,9 +370,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-login.md b/deps/npm/docs/content/commands/npm-login.md index d9499f712cbc87..7738dc2c15c62d 100644 --- a/deps/npm/docs/content/commands/npm-login.md +++ b/deps/npm/docs/content/commands/npm-login.md @@ -15,22 +15,20 @@ 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)). +`.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 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. +When using `legacy` for your `auth-type`, the username and password, are read in from prompts. To reset your password, go to To change your email address, go to -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. +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 @@ -79,8 +77,8 @@ npm init --scope=@foo --yes * 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`. +What authentication strategy to use with `login`. Note that if an +`otp` config is given, this value will always be set to `legacy`. diff --git a/deps/npm/docs/content/commands/npm-logout.md b/deps/npm/docs/content/commands/npm-logout.md index 2d5aa3e5827f74..0008259ce78d9a 100644 --- a/deps/npm/docs/content/commands/npm-logout.md +++ b/deps/npm/docs/content/commands/npm-logout.md @@ -14,16 +14,13 @@ 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 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. +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. +If `--scope` is provided, this will find the credentials for the registry connected to that scope, if set. ### Configuration diff --git a/deps/npm/docs/content/commands/npm-ls.md b/deps/npm/docs/content/commands/npm-ls.md index 2b5808f513e031..1d57122b828b41 100644 --- a/deps/npm/docs/content/commands/npm-ls.md +++ b/deps/npm/docs/content/commands/npm-ls.md @@ -14,32 +14,25 @@ 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. +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). +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: +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.1 /path/to/npm +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. +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. +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. @@ -50,9 +43,9 @@ When run as `ll` or `la`, it shows extended information by default. * 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. +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. @@ -63,8 +56,8 @@ upon by the current project. 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`. +* 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. @@ -84,8 +77,8 @@ Show extended information in `ls`, `search`, and `help-search`. * Default: false * Type: Boolean -Output parseable results from commands that write to standard output. For -`npm search`, this will be tab-separated table format. +Output parseable results from commands that write to standard output. +For `npm search`, this will be tab-separated table format. @@ -94,12 +87,13 @@ Output parseable results from commands that write to standard output. For * 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. +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. +* 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` @@ -107,20 +101,21 @@ folder instead of the current working directory. See #### `depth` -* Default: `Infinity` if `--all` is set, otherwise `0` +* 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. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -129,25 +124,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -156,7 +155,8 @@ the order in which omit/include are specified on the command-line. * Default: false * Type: Boolean -Used with `npm ls`, limiting output to only those packages that are linked. +Used with `npm ls`, limiting output to only those packages that are +linked. @@ -165,25 +165,27 @@ Used with `npm ls`, limiting output to only those packages that are linked. * Default: false * Type: Boolean -If set to true, the current operation will only use the `package-lock.json`, -ignoring `node_modules`. +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`. +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. +* 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. +When set to true, npm uses unicode characters in the tree output. +When false, it uses ascii characters instead of unicode glyphs. @@ -192,9 +194,9 @@ false, it uses ascii characters instead of unicode glyphs. * 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. +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: @@ -203,9 +205,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -217,13 +219,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -234,9 +237,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -245,9 +249,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-org.md b/deps/npm/docs/content/commands/npm-org.md index f06524731df51d..54ad8822660e3d 100644 --- a/deps/npm/docs/content/commands/npm-org.md +++ b/deps/npm/docs/content/commands/npm-org.md @@ -56,9 +56,8 @@ $ 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. +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 @@ -76,11 +75,12 @@ The base URL of the npm registry. * 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`. +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. +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. @@ -91,8 +91,8 @@ password, npm will prompt on the command line for one. 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`. +* 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. @@ -103,8 +103,8 @@ Not supported by all npm commands. * Default: false * Type: Boolean -Output parseable results from commands that write to standard output. For -`npm search`, this will be tab-separated table format. +Output parseable results from commands that write to standard output. +For `npm search`, this will be tab-separated table format. diff --git a/deps/npm/docs/content/commands/npm-outdated.md b/deps/npm/docs/content/commands/npm-outdated.md index 62a8f44b25c321..89e9a6ae849c28 100644 --- a/deps/npm/docs/content/commands/npm-outdated.md +++ b/deps/npm/docs/content/commands/npm-outdated.md @@ -12,39 +12,26 @@ npm outdated [ ...] ### Description -This command will check the registry to see if any (or, specific) installed -packages are currently outdated. +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. +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. +* `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). + 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 +* `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. +* 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 @@ -70,20 +57,14 @@ With these `dependencies`: 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. +* `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 @@ -92,9 +73,9 @@ A few things to note: * 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. +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. @@ -105,8 +86,8 @@ upon by the current project. 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`. +* 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. @@ -126,8 +107,8 @@ Show extended information in `ls`, `search`, and `help-search`. * Default: false * Type: Boolean -Output parseable results from commands that write to standard output. For -`npm search`, this will be tab-separated table format. +Output parseable results from commands that write to standard output. +For `npm search`, this will be tab-separated table format. @@ -136,12 +117,13 @@ Output parseable results from commands that write to standard output. For * 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. +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. +* 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` @@ -152,9 +134,9 @@ folder instead of the current working directory. See * 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. +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: @@ -163,9 +145,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -175,14 +157,14 @@ This value is not exported to the environment for child processes. * 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`. +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`. diff --git a/deps/npm/docs/content/commands/npm-owner.md b/deps/npm/docs/content/commands/npm-owner.md index cd172adc3dee8d..f3f8feb7c3d3f6 100644 --- a/deps/npm/docs/content/commands/npm-owner.md +++ b/deps/npm/docs/content/commands/npm-owner.md @@ -18,20 +18,18 @@ alias: author Manage ownership of published packages. -* ls: List all the users who have access to modify a package and push new - versions. Handy when you need to know who to bug for help. -* add: Add a new user as a maintainer of a package. This user is enabled - to modify metadata, publish new versions, and add other owners. -* rm: Remove a user from the package owner list. This immediately revokes - their privileges. +* ls: List all the users who have access to modify a package and push new versions. +Handy when you need to know who to bug for help. +* add: Add a new user as a maintainer of a package. +This user is enabled to modify metadata, publish new versions, and add other owners. +* rm: Remove a user from the package owner list. +This immediately revokes their privileges. -Note that there is only one level of access. Either you can modify a package, -or you can't. Future versions may contain more fine-grained access levels, but -that is not implemented at this time. +Note that there is only one level of access. +Either you can modify a package, or you can't. +Future versions may contain more fine-grained access levels, but that is not implemented at this time. -If you have two-factor authentication enabled with `auth-and-writes` (see -[`npm-profile`](/commands/npm-profile)) then you'll need to go through a second factor -flow when changing ownership or include an otp on the command line with `--otp`. +If you have two-factor authentication enabled with `auth-and-writes` (see [`npm-profile`](/commands/npm-profile)) then you'll need to go through a second factor flow when changing ownership or include an otp on the command line with `--otp`. ### Configuration @@ -49,11 +47,12 @@ The base URL of the npm registry. * 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`. +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. +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. @@ -62,9 +61,9 @@ password, npm will prompt on the command line for one. * 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. +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: @@ -73,9 +72,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -87,13 +86,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. diff --git a/deps/npm/docs/content/commands/npm-pack.md b/deps/npm/docs/content/commands/npm-pack.md index 6488180543a20d..97356cd340d766 100644 --- a/deps/npm/docs/content/commands/npm-pack.md +++ b/deps/npm/docs/content/commands/npm-pack.md @@ -17,13 +17,14 @@ npm pack * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -34,8 +35,8 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, 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`. +* 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. @@ -55,9 +56,9 @@ Directory in which `npm pack` will save tarballs. * 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. +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: @@ -66,9 +67,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -80,13 +81,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -97,9 +99,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -110,23 +113,18 @@ This value is not exported to the environment for child processes. 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. +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. ### Description -For anything that's installable (that is, a package folder, tarball, -tarball url, git url, name@tag, name@version, name, or scoped name), this -command will fetch it to the cache, copy the tarball to the current working -directory as `-.tgz`, and then write the filenames out to -stdout. +For anything that's installable (that is, a package folder, tarball, tarball url, git url, name@tag, name@version, name, or scoped name), this command will fetch it to the cache, copy the tarball to the current working directory as `-.tgz`, and then write the filenames out to stdout. -If the same package is specified multiple times, then the file will be -overwritten the second time. +If the same package is specified multiple times, then the file will be overwritten the second time. If no arguments are supplied, then npm packs the current package folder. diff --git a/deps/npm/docs/content/commands/npm-pkg.md b/deps/npm/docs/content/commands/npm-pkg.md index f668c562affd31..7615343cbf9606 100644 --- a/deps/npm/docs/content/commands/npm-pkg.md +++ b/deps/npm/docs/content/commands/npm-pkg.md @@ -18,13 +18,9 @@ npm pkg fix ### Description A command that automates the management of `package.json` files. -`npm pkg` provide 3 different sub commands that allow you to modify or retrieve -values for given object keys in your `package.json`. +`npm pkg` provide 3 different sub commands that allow you to modify or retrieve values for given object keys in your `package.json`. -The syntax to retrieve and set fields is a dot separated representation of -the nested object properties to be found within your `package.json`, it's the -same notation used in [`npm view`](/commands/npm-view) to retrieve information -from the registry manifest, below you can find more examples on how to use it. +The syntax to retrieve and set fields is a dot separated representation of the nested object properties to be found within your `package.json`, it's the same notation used in [`npm view`](/commands/npm-view) to retrieve information from the registry manifest, below you can find more examples on how to use it. Returned values are always in **json** format. @@ -32,8 +28,7 @@ Returned values are always in **json** format. Retrieves a value `key`, defined in your `package.json` file. - For example, in order to retrieve the name of the current package, you - can run: + For example, in order to retrieve the name of the current package, you can run: ```bash npm pkg get name @@ -45,32 +40,29 @@ Returned values are always in **json** format. npm pkg get name version ``` - You can view child fields by separating them with a period. To retrieve - the value of a test `script` value, you would run the following command: + You can view child fields by separating them with a period. + To retrieve the value of a test `script` value, you would run the following command: ```bash npm pkg get scripts.test ``` - For fields that are arrays, requesting a non-numeric field will return - all of the values from the objects in the list. For example, to get all - the contributor emails for a package, you would run: + For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list. + For example, to get all the contributor emails for a package, you would run: ```bash npm pkg get contributors.email ``` - You may also use numeric indices in square braces to specifically select - an item in an array field. To just get the email address of the first - contributor in the list, you can run: + You may also use numeric indices in square braces to specifically select an item in an array field. + To just get the email address of the first contributor in the list, you can run: ```bash npm pkg get contributors[0].email ``` - For complex fields you can also name a property in square brackets - to specifically select a child field. This is especially helpful - with the exports object: + For complex fields you can also name a property in square brackets to specifically select a child field. + This is especially helpful with the exports object: ```bash npm pkg get "exports[.].require" @@ -78,19 +70,12 @@ Returned values are always in **json** format. * `npm pkg set =` - Sets a `value` in your `package.json` based on the `field` value. When - saving to your `package.json` file the same set of rules used during - `npm install` and other cli commands that touches the `package.json` file - are used, making sure to respect the existing indentation and possibly - applying some validation prior to saving values to the file. + Sets a `value` in your `package.json` based on the `field` value. + When saving to your `package.json` file the same set of rules used during `npm install` and other cli commands that touches the `package.json` file are used, making sure to respect the existing indentation and possibly applying some validation prior to saving values to the file. - The same syntax used to retrieve values from your package can also be used - to define new properties or overriding existing ones, below are some - examples of how the dot separated syntax can be used to edit your - `package.json` file. + The same syntax used to retrieve values from your package can also be used to define new properties or overriding existing ones, below are some examples of how the dot separated syntax can be used to edit your `package.json` file. - Defining a new bin named `mynewcommand` in your `package.json` that points - to a file `cli.js`: + Defining a new bin named `mynewcommand` in your `package.json` that points to a file `cli.js`: ```bash npm pkg set bin.mynewcommand=cli.js @@ -102,23 +87,19 @@ Returned values are always in **json** format. npm pkg set description='Awesome package' engines.node='>=10' ``` - It's also possible to add to array values, for example to add a new - contributor entry: + It's also possible to add to array values, for example to add a new contributor entry: ```bash npm pkg set contributors[0].name='Foo' contributors[0].email='foo@bar.ca' ``` - You may also append items to the end of an array using the special - empty bracket notation: + You may also append items to the end of an array using the special empty bracket notation: ```bash npm pkg set contributors[].name='Foo' contributors[].name='Bar' ``` - It's also possible to parse values as json prior to saving them to your - `package.json` file, for example in order to set a `"private": true` - property: + It's also possible to parse values as json prior to saving them to your `package.json` file, for example in order to set a `"private": true` property: ```bash npm pkg set private=true --json @@ -134,9 +115,8 @@ Returned values are always in **json** format. Deletes a `key` from your `package.json` - The same syntax used to set values from your package can also be used - to remove existing ones. For example, in order to remove a script named - build: + The same syntax used to set values from your package can also be used to remove existing ones. + For example, in order to remove a script named build: ```bash npm pkg delete scripts.build @@ -144,28 +124,20 @@ Returned values are always in **json** format. * `npm pkg fix` - Auto corrects common errors in your `package.json`. npm already - does this during `publish`, which leads to subtle (mostly harmless) - differences between the contents of your `package.json` file and the - manifest that npm uses during installation. + Auto corrects common errors in your `package.json`. + npm already does this during `publish`, which leads to subtle (mostly harmless) differences between the contents of your `package.json` file and the manifest that npm uses during installation. ### Workspaces support -You can set/get/delete items across your configured workspaces by using the -[`workspace`](/using-npm/config#workspace) or -[`workspaces`](/using-npm/config#workspaces) config options. +You can set/get/delete items across your configured workspaces by using the [`workspace`](/using-npm/config#workspace) or [`workspaces`](/using-npm/config#workspaces) config options. -For example, setting a `funding` value across all configured workspaces -of a project: +For example, setting a `funding` value across all configured workspaces of a project: ```bash npm pkg set funding=https://example.com --ws ``` -When using `npm pkg get` to retrieve info from your configured workspaces, the -returned result will be in a json format in which top level keys are the -names of each workspace, the values of these keys will be the result values -returned from each of the configured workspaces, e.g: +When using `npm pkg get` to retrieve info from your configured workspaces, the returned result will be in a json format in which top level keys are the names of each workspace, the values of these keys will be the result values returned from each of the configured workspaces, e.g: ``` npm pkg get name version --ws @@ -194,14 +166,16 @@ 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 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. +* 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). @@ -218,8 +192,8 @@ recommended that you do not use this option! 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`. +* 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. @@ -230,9 +204,9 @@ Not supported by all npm commands. * 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. +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: @@ -241,9 +215,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -255,13 +229,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. ## See Also diff --git a/deps/npm/docs/content/commands/npm-prefix.md b/deps/npm/docs/content/commands/npm-prefix.md index ad584643a1ecec..ba483428daecec 100644 --- a/deps/npm/docs/content/commands/npm-prefix.md +++ b/deps/npm/docs/content/commands/npm-prefix.md @@ -14,12 +14,11 @@ Note: This command is unaware of workspaces. ### Description -Print the local prefix to standard output. This is the closest parent directory -to contain a `package.json` file or `node_modules` directory, unless `-g` is -also specified. +Print the local prefix to standard output. +This is the closest parent directory to contain a `package.json` file or `node_modules` directory, unless `-g` is also specified. -If `-g` is specified, this will be the value of the global prefix. See -[`npm config`](/commands/npm-config) for more detail. +If `-g` is specified, this will be the value of the global prefix. +See [`npm config`](/commands/npm-config) for more detail. ### Example @@ -40,12 +39,13 @@ npm prefix -g * 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. +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. +* 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` diff --git a/deps/npm/docs/content/commands/npm-profile.md b/deps/npm/docs/content/commands/npm-profile.md index 2468d6c87faf60..aa344822d0c53c 100644 --- a/deps/npm/docs/content/commands/npm-profile.md +++ b/deps/npm/docs/content/commands/npm-profile.md @@ -17,12 +17,11 @@ Note: This command is unaware of workspaces. ### Description -Change your profile information on the registry. Note that this command -depends on the registry implementation, so third-party registries may not -support this interface. +Change your profile information on the registry. +Note that this command depends on the registry implementation, so third-party registries may not support this interface. -* `npm profile get []`: Display all of the properties of your - profile, or one or more specific properties. It looks like: +* `npm profile get []`: Display all of the properties of your profile, or one or more specific properties. +It looks like: ``` name: example @@ -37,23 +36,19 @@ created: 2015-02-26T01:38:35.892Z updated: 2017-10-02T21:29:45.922Z ``` -* `npm profile set `: Set the value of a profile - property. You can set the following properties this way: email, fullname, - homepage, freenode, twitter, github +* `npm profile set `: Set the value of a profile property. +You can set the following properties this way: email, fullname, homepage, freenode, twitter, github -* `npm profile set password`: Change your password. This is interactive, - you'll be prompted for your current password and a new password. You'll - also be prompted for an OTP if you have two-factor authentication - enabled. +* `npm profile set password`: Change your password. +This is interactive, you'll be prompted for your current password and a new password. +You'll also be prompted for an OTP if you have two-factor authentication enabled. -* `npm profile enable-2fa [auth-and-writes|auth-only]`: Enables two-factor - authentication. Defaults to `auth-and-writes` mode. Modes are: - * `auth-only`: Require an OTP when logging in or making changes to your - account's authentication. The OTP will be required on both the website - and the command line. - * `auth-and-writes`: Requires an OTP at all the times `auth-only` does, - and also requires one when publishing a module, setting the `latest` - dist-tag, or changing access via `npm access` and `npm owner`. +* `npm profile enable-2fa [auth-and-writes|auth-only]`: Enables two-factor authentication. +Defaults to `auth-and-writes` mode. +Modes are: + * `auth-only`: Require an OTP when logging in or making changes to your account's authentication. +The OTP will be required on both the website and the command line. + * `auth-and-writes`: Requires an OTP at all the times `auth-only` does, and also requires one when publishing a module, setting the `latest` dist-tag, or changing access via `npm access` and `npm owner`. * `npm profile disable-2fa`: Disables two-factor authentication. @@ -79,8 +74,8 @@ The base URL of the npm registry. 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`. +* 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. @@ -91,8 +86,8 @@ Not supported by all npm commands. * Default: false * Type: Boolean -Output parseable results from commands that write to standard output. For -`npm search`, this will be tab-separated table format. +Output parseable results from commands that write to standard output. +For `npm search`, this will be tab-separated table format. @@ -101,11 +96,12 @@ Output parseable results from commands that write to standard output. For * 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`. +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. +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. diff --git a/deps/npm/docs/content/commands/npm-prune.md b/deps/npm/docs/content/commands/npm-prune.md index 0b0922fe8d0980..8a889831bf0988 100644 --- a/deps/npm/docs/content/commands/npm-prune.md +++ b/deps/npm/docs/content/commands/npm-prune.md @@ -12,32 +12,26 @@ npm prune [[<@scope>/]...] ### Description -This command removes "extraneous" packages. If a package name is provided, -then only packages matching one of the supplied names are removed. +This command removes "extraneous" packages. +If a package name is provided, then only packages matching one of the supplied names are removed. -Extraneous packages are those present in the `node_modules` folder that are -not listed as any package's dependency list. +Extraneous packages are those present in the `node_modules` folder that are not listed as any package's dependency list. -If the `--omit=dev` flag is specified or the `NODE_ENV` environment -variable is set to `production`, this command will remove the packages -specified in your `devDependencies`. +If the `--omit=dev` flag is specified or the `NODE_ENV` environment variable is set to `production`, this command will remove the packages specified in your `devDependencies`. If the `--dry-run` flag is used then no changes will actually be made. -If the `--json` flag is used, then the changes `npm prune` made (or would -have made with `--dry-run`) are printed as a JSON object. +If the `--json` flag is used, then the changes `npm prune` made (or would have made with `--dry-run`) are printed as a JSON object. -In normal operation, extraneous modules are pruned automatically, so you'll -only need this command with the `--production` flag. However, in the real -world, operation is not always "normal". When crashes or mistakes happen, -this command can help clean up any resulting garbage. +In normal operation, extraneous modules are pruned automatically, so you'll only need this command with the `--production` flag. +However, in the real world, operation is not always "normal". When crashes or mistakes happen, this command can help clean up any resulting garbage. ### Configuration #### `omit` * Default: 'dev' if the `NODE_ENV` environment variable is set to - 'production', otherwise empty. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -46,25 +40,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -73,13 +71,14 @@ the order in which omit/include are specified on the command-line. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -90,8 +89,8 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, 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`. +* 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. @@ -99,16 +98,17 @@ Not supported by all npm commands. #### `foreground-scripts` -* Default: `false` unless when using `npm pack` or `npm publish` where it - defaults to `true` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -119,10 +119,10 @@ but can be useful for debugging. 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. +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. @@ -131,9 +131,9 @@ run any pre- or post-scripts. * 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. +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: @@ -142,9 +142,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -156,13 +156,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -173,9 +174,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -184,9 +186,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-publish.md b/deps/npm/docs/content/commands/npm-publish.md index 266038c306359c..0210f353a908fc 100644 --- a/deps/npm/docs/content/commands/npm-publish.md +++ b/deps/npm/docs/content/commands/npm-publish.md @@ -14,79 +14,55 @@ npm publish Publishes a package to the registry so that it can be installed by name. -By default npm will publish to the public registry. This can be -overridden by specifying a different default registry or using a -[`scope`](/using-npm/scope) in the name, combined with a -scope-configured registry (see -[`package.json`](/configuring-npm/package-json)). +By default npm will publish to the public registry. +This can be overridden by specifying a different default registry or using a [`scope`](/using-npm/scope) in the name, combined with a scope-configured registry (see [`package.json`](/configuring-npm/package-json)). -A `package` is interpreted the same way as other commands (like -`npm install`) and can be: +A `package` is interpreted the same way as other commands (like `npm install`) and can be: -* a) a folder containing a program described by a - [`package.json`](/configuring-npm/package-json) file +* 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 `@` that is published on the registry (see - [`registry`](/using-npm/registry)) with (c) -* e) a `@` (see [`npm dist-tag`](/commands/npm-dist-tag)) that - points to (d) +* d) a `@` that is published on the registry (see [`registry`](/using-npm/registry)) with (c) +* e) a `@` (see [`npm dist-tag`](/commands/npm-dist-tag)) that points to (d) * f) a `` that has a "latest" tag satisfying (e) * g) a `` that resolves to (a) -The publish will fail if the package name and version combination already -exists in the specified registry. +The publish will fail if the package name and version combination already exists in the specified registry. -Once a package is published with a given name and version, that specific -name and version combination can never be used again, even if it is removed -with [`npm unpublish`](/commands/npm-unpublish). +Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with [`npm unpublish`](/commands/npm-unpublish). -As of `npm@5`, both a sha1sum and an integrity field with a sha512sum of the -tarball will be submitted to the registry during publication. Subsequent -installs will use the strongest supported algorithm to verify downloads. +As of `npm@5`, both a sha1sum and an integrity field with a sha512sum of the tarball will be submitted to the registry during publication. +Subsequent installs will use the strongest supported algorithm to verify downloads. -Similar to `--dry-run` see [`npm pack`](/commands/npm-pack), which figures -out the files to be included and packs them into a tarball to be uploaded -to the registry. +Similar to `--dry-run` see [`npm pack`](/commands/npm-pack), which figures out the files to be included and packs them into a tarball to be uploaded to the registry. ### Files included in package -To see what will be included in your package, run `npm pack --dry-run`. All -files are included by default, with the following exceptions: +To see what will be included in your package, run `npm pack --dry-run`. +All files are included by default, with the following exceptions: -- Certain files that are relevant to package installation and distribution - are always included. For example, `package.json`, `README.md`, +- Certain files that are relevant to package installation and distribution are always included. +For example, `package.json`, `README.md`, `LICENSE`, and so on. -- If there is a "files" list in - [`package.json`](/configuring-npm/package-json), then only the files - specified will be included. (If directories are specified, then they - will be walked recursively and their contents included, subject to the - same ignore rules.) +- If there is a "files" list in [`package.json`](/configuring-npm/package-json), then only the files specified will be included. + (If directories are specified, then they will be walked recursively and their contents included, subject to the same ignore rules.) -- If there is a `.gitignore` or `.npmignore` file, then ignored files in - that and all child directories will be excluded from the package. If - _both_ files exist, then the `.gitignore` is ignored, and only the +- If there is a `.gitignore` or `.npmignore` file, then ignored files in that and all child directories will be excluded from the package. + If _both_ files exist, then the `.gitignore` is ignored, and only the `.npmignore` is used. - `.npmignore` files follow the [same pattern - rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring) - as `.gitignore` files + `.npmignore` files follow the [same pattern rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring) as `.gitignore` files -- If the file matches certain patterns, then it will _never_ be included, - unless explicitly added to the `"files"` list in `package.json`, or - un-ignored with a `!` rule in a `.npmignore` or `.gitignore` file. +- If the file matches certain patterns, then it will _never_ be included, unless explicitly added to the `"files"` list in `package.json`, or un-ignored with a `!` rule in a `.npmignore` or `.gitignore` file. - Symbolic links are never included in npm packages. -See [`developers`](/using-npm/developers) for full details on what's -included in the published package, as well as details on how the package is -built. +See [`developers`](/using-npm/developers) for full details on what's included in the published package, as well as details on how the package is built. -See [`package.json`](/configuring-npm/package-json) for more info on -what can and can't be ignored. +See [`package.json`](/configuring-npm/package-json) for more info on what can and can't be ignored. ### Configuration @@ -95,35 +71,35 @@ what can and can't be ignored. * 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. +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. +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. +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. +If used in the `npm publish` command, this is the tag that will be +added to the package submitted to the registry. #### `access` -* Default: 'public' for new packages, existing packages it will not change the - current level +* Default: 'public' for new packages, existing packages it will not + change the current level * Type: null, "restricted", or "public" If you do not want your scoped package to be publicly viewable (and installable) set `--access=restricted`. -Unscoped packages can not be set to `restricted`. +Unscoped packages cannot be set to `restricted`. -Note: This defaults to not changing the current access level for existing -packages. Specifying a value of `restricted` or `public` during publish will -change the access for an existing package the same way that `npm access set -status` would. +Note: This defaults to not changing the current access level for +existing packages. Specifying a value of `restricted` or `public` +during publish will change the access for an existing package the +same way that `npm access set status` would. @@ -132,13 +108,14 @@ status` would. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -147,11 +124,12 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, * 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`. +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. +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. @@ -160,9 +138,9 @@ password, npm will prompt on the command line for one. * 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. +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: @@ -171,9 +149,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -185,13 +163,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -202,9 +181,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -213,19 +193,20 @@ This value is not exported to the environment for child processes. * Default: false * Type: Boolean -When publishing from a supported cloud CI/CD system, the package will be -publicly linked to where it was built and published from. +When publishing from a supported cloud CI/CD system, the package will +be publicly linked to where it was built and published from. -This config can not be used with: `provenance-file` +This config cannot be used with: `provenance-file` #### `provenance-file` * Default: null * Type: Path -When publishing, the provenance bundle at the given path will be used. +When publishing, the provenance bundle at the given path will be +used. -This config can not be used with: `provenance` +This config cannot be used with: `provenance` ### See Also diff --git a/deps/npm/docs/content/commands/npm-query.md b/deps/npm/docs/content/commands/npm-query.md index f435ce67e9d912..1b78734c317f7b 100644 --- a/deps/npm/docs/content/commands/npm-query.md +++ b/deps/npm/docs/content/commands/npm-query.md @@ -12,8 +12,7 @@ npm query ### Description -The `npm query` command allows for usage of css selectors in order to retrieve -an array of dependency objects. +The `npm query` command allows for usage of css selectors in order to retrieve an array of dependency objects. ### Piping npm query to other commands @@ -138,21 +137,16 @@ npm query ":type(git)" | jq 'map(.name)' | xargs -I {} npm why {} ### Expecting a certain number of results -One common use of `npm query` is to make sure there is only one version of -a certain dependency in your tree. This is especially common for -ecosystems like that rely on `typescript` where having state split -across two different but identically-named packages causes bugs. You -can use the `--expect-results` or `--expect-result-count` in your setup -to ensure that npm will exit with an exit code if your tree doesn't look -like you want it to. +One common use of `npm query` is to make sure there is only one version of a certain dependency in your tree. +This is especially common for ecosystems like that rely on `typescript` where having state split across two different but identically-named packages causes bugs. +You can use the `--expect-results` or `--expect-result-count` in your setup to ensure that npm will exit with an exit code if your tree doesn't look like you want it to. ```sh $ npm query '#react' --expect-result-count=1 ``` -Perhaps you want to quickly check if there are any production -dependencies that could be updated: +Perhaps you want to quickly check if there are any production dependencies that could be updated: ```sh $ npm query ':root>:outdated(in-range).prod' --no-expect-results @@ -160,7 +154,8 @@ $ npm query ':root>:outdated(in-range).prod' --no-expect-results ### Package lock only mode -If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. This means that information from the package.json files of your dependencies will not be included in the result set (e.g. description, homepage, engines). +If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. +This means that information from the package.json files of your dependencies will not be included in the result set (e.g. description, homepage, engines). ### Configuration @@ -169,12 +164,13 @@ If package-lock-only is enabled, only the information in the package lock (or sh * 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. +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. +* 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` @@ -185,9 +181,9 @@ folder instead of the current working directory. See * 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. +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: @@ -196,9 +192,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -210,13 +206,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -227,9 +224,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -238,14 +236,15 @@ This value is not exported to the environment for child processes. * Default: false * Type: Boolean -If set to true, the current operation will only use the `package-lock.json`, -ignoring `node_modules`. +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`. +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`. @@ -254,10 +253,10 @@ For `list` this means the output will be based on the tree described by the * Default: null * Type: null or Boolean -Tells npm whether or not to expect results from the command. Can be either -true (expect some results) or false (expect no results). +Tells npm whether or not to expect results from the command. Can be +either true (expect some results) or false (expect no results). -This config can not be used with: `expect-result-count` +This config cannot be used with: `expect-result-count` #### `expect-result-count` @@ -266,7 +265,7 @@ This config can not be used with: `expect-result-count` Tells to expect a specific number of results from the command. -This config can not be used with: `expect-results` +This config cannot be used with: `expect-results` ## See Also * [dependency selectors](/using-npm/dependency-selectors) diff --git a/deps/npm/docs/content/commands/npm-rebuild.md b/deps/npm/docs/content/commands/npm-rebuild.md index ff88f613f415ff..529a583b719748 100644 --- a/deps/npm/docs/content/commands/npm-rebuild.md +++ b/deps/npm/docs/content/commands/npm-rebuild.md @@ -36,7 +36,8 @@ If there is a `binding.gyp` file in the root of your package, then npm will use } ``` -This default behavior is suppressed if the `package.json` has its own `install` or `preinstall` scripts. It is also suppressed if the package specifies `"gypfile": false` +This default behavior is suppressed if the `package.json` has its own `install` or `preinstall` scripts. +It is also suppressed if the package specifies `"gypfile": false` ### Configuration @@ -45,12 +46,13 @@ This default behavior is suppressed if the `package.json` has its own `install` * 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. +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. +* 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` @@ -64,24 +66,25 @@ folder instead of the current working directory. See 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. +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. #### `foreground-scripts` -* Default: `false` unless when using `npm pack` or `npm publish` where it - defaults to `true` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -92,10 +95,10 @@ but can be useful for debugging. 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. +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. @@ -104,9 +107,9 @@ run any pre- or post-scripts. * 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. +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: @@ -115,9 +118,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -129,13 +132,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -146,9 +150,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -157,9 +162,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-repo.md b/deps/npm/docs/content/commands/npm-repo.md index 79a3ced2aa38c1..10e14c0204db06 100644 --- a/deps/npm/docs/content/commands/npm-repo.md +++ b/deps/npm/docs/content/commands/npm-repo.md @@ -12,11 +12,8 @@ npm repo [ [ ...]] ### Description -This command tries to guess at the likely location of a package's -repository URL, 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 -`repository` property. +This command tries to guess at the likely location of a package's repository URL, 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 `repository` property. ### Configuration @@ -48,9 +45,9 @@ The base URL of the npm registry. * 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. +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: @@ -59,9 +56,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -73,13 +70,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -90,9 +88,10 @@ This value is not exported to the environment for child processes. 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. +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. diff --git a/deps/npm/docs/content/commands/npm-restart.md b/deps/npm/docs/content/commands/npm-restart.md index 7c0957f2852c13..1c240de24953dd 100644 --- a/deps/npm/docs/content/commands/npm-restart.md +++ b/deps/npm/docs/content/commands/npm-restart.md @@ -12,18 +12,16 @@ npm restart [-- ] ### Description -This restarts a project. It is equivalent to running `npm run -restart`. +This restarts a project. +It is equivalent to running `npm run restart`. -If the current project has a `"restart"` script specified in -`package.json`, then the following scripts will be run: +If the current project has a `"restart"` script specified in `package.json`, then the following scripts will be run: 1. prerestart 2. restart 3. postrestart -If it does _not_ have a `"restart"` script specified, but it does have -`stop` and/or `start` scripts, then the following scripts will be run: +If it does _not_ have a `"restart"` script specified, but it does have `stop` and/or `start` scripts, then the following scripts will be run: 1. prerestart 2. prestop @@ -43,10 +41,10 @@ If it does _not_ have a `"restart"` script specified, but it does have 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. +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. @@ -55,8 +53,8 @@ run any pre- or post-scripts. * Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows * Type: null or String -The shell to use for scripts run with the `npm exec`, `npm run` and `npm -init ` commands. +The shell to use for scripts run with the `npm exec`, `npm run` and +`npm init ` commands. diff --git a/deps/npm/docs/content/commands/npm-root.md b/deps/npm/docs/content/commands/npm-root.md index 75d70c2afb6265..8648eace72d45a 100644 --- a/deps/npm/docs/content/commands/npm-root.md +++ b/deps/npm/docs/content/commands/npm-root.md @@ -16,8 +16,8 @@ Note: This command is unaware of workspaces. Print the effective `node_modules` folder to standard out. -Useful for using npm in shell scripts that do things with the -`node_modules` folder. For example: +Useful for using npm in shell scripts that do things with the `node_modules` folder. +For example: ```bash #!/bin/bash @@ -32,12 +32,13 @@ echo "Global packages installed in: ${global_node_modules}" * 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. +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. +* 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` diff --git a/deps/npm/docs/content/commands/npm-run.md b/deps/npm/docs/content/commands/npm-run.md index 90a0c633ff9d8a..2066bf36817ebd 100644 --- a/deps/npm/docs/content/commands/npm-run.md +++ b/deps/npm/docs/content/commands/npm-run.md @@ -14,16 +14,15 @@ aliases: run-script, rum, urn ### Description -This runs an arbitrary command from a package's `"scripts"` object. If no +This runs an arbitrary command from a package's `"scripts"` object. +If no `"command"` is provided, it will list the available scripts. -`run[-script]` is used by the test, start, restart, and stop commands, but -can be called directly, as well. When the scripts in the package are -printed out, they're separated into lifecycle (test, start, restart) and -directly-run scripts. +`run[-script]` is used by the test, start, restart, and stop commands, but can be called directly, as well. +When the scripts in the package are printed out, they're separated into lifecycle (test, start, restart) and directly-run scripts. -Any positional arguments are passed to the specified script. Use `--` to -pass `-`-prefixed flags and options which would otherwise be parsed by npm. +Any positional arguments are passed to the specified script. +Use `--` to pass `-`-prefixed flags and options which would otherwise be parsed by npm. For example: @@ -31,19 +30,14 @@ For example: npm run test -- --grep="pattern" ``` -The arguments will only be passed to the script specified after `npm run` -and not to any `pre` or `post` script. +The arguments will only be passed to the script specified after `npm run` and not to any `pre` or `post` script. -The `env` script is a special built-in command that can be used to list -environment variables that will be available to the script at runtime. If an -"env" command is defined in your package, it will take precedence over the -built-in. +The `env` script is a special built-in command that can be used to list environment variables that will be available to the script at runtime. +If an "env" command is defined in your package, it will take precedence over the built-in. -In addition to the shell's pre-existing `PATH`, `npm run` adds -`node_modules/.bin` to the `PATH` provided to scripts. Any binaries -provided by locally-installed dependencies can be used without the -`node_modules/.bin` prefix. For example, if there is a `devDependency` on -`tap` in your package, you should write: +In addition to the shell's pre-existing `PATH`, `npm run` adds `node_modules/.bin` to the `PATH` provided to scripts. +Any binaries provided by locally-installed dependencies can be used without the `node_modules/.bin` prefix. +For example, if there is a `devDependency` on `tap` in your package, you should write: ```bash "scripts": {"test": "tap test/*.js"} @@ -55,33 +49,22 @@ instead of "scripts": {"test": "node_modules/.bin/tap test/*.js"} ``` -The actual shell your script is run within is platform dependent. By default, -on Unix-like systems it is the `/bin/sh` command, on Windows it is -`cmd.exe`. +The actual shell your script is run within is platform dependent. +By default, on Unix-like systems it is the `/bin/sh` command, on Windows it is `cmd.exe`. The actual shell referred to by `/bin/sh` also depends on the system. -You can customize the shell with the -[`script-shell` config](/using-npm/config#script-shell). +You can customize the shell with the [`script-shell` config](/using-npm/config#script-shell). -Scripts are run from the root of the package folder, regardless of what the -current working directory is when `npm run` is called. If you want your -script to use different behavior based on what subdirectory you're in, you -can use the `INIT_CWD` environment variable, which holds the full path you -were in when you ran `npm run`. +Scripts are run from the root of the package folder, regardless of what the current working directory is when `npm run` is called. +If you want your script to use different behavior based on what subdirectory you're in, you can use the `INIT_CWD` environment variable, which holds the full path you were in when you ran `npm run`. -`npm run` sets the `NODE` environment variable to the `node` executable -with which `npm` is executed. +`npm run` sets the `NODE` environment variable to the `node` executable with which `npm` is executed. -If you try to run a script without having a `node_modules` directory and it -fails, you will be given a warning to run `npm install`, just in case you've -forgotten. +If you try to run a script without having a `node_modules` directory and it fails, you will be given a warning to run `npm install`, just in case you've forgotten. ### 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 a package's `"scripts"` object in the context of the -specified workspaces. If no `"command"` is provided, it will list the available -scripts for each of these configured workspaces. +You may use the [`workspace`](/using-npm/config#workspace) or [`workspaces`](/using-npm/config#workspaces) configs in order to run an arbitrary command from a package's `"scripts"` object in the context of the specified workspaces. +If no `"command"` is provided, it will list the available scripts for each of these configured workspaces. Given a project with configured workspaces, e.g: @@ -97,8 +80,8 @@ Given a project with configured workspaces, e.g: `-- package.json ``` -Assuming the workspace configuration is properly set up at the root level -`package.json` file. e.g: +Assuming the workspace configuration is properly set up at the root level `package.json` file. +e.g: ``` { @@ -106,9 +89,7 @@ Assuming the workspace configuration is properly set up at the root level } ``` -And that each of the configured workspaces has a configured `test` script, -we can run tests in all of them using the -[`workspaces` config](/using-npm/config#workspaces): +And that each of the configured workspaces has a configured `test` script, we can run tests in all of them using the [`workspaces` config](/using-npm/config#workspaces): ``` npm test --workspaces @@ -116,24 +97,20 @@ npm test --workspaces #### Filtering workspaces -It's also possible to run a script in a single workspace using the `workspace` -config along with a name or directory path: +It's also possible to run a script in a single workspace using the `workspace` config along with a name or directory path: ``` npm test --workspace=a ``` -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: +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 test -w a -w b ``` -This last command will run `test` in both `./packages/a` and `./packages/b` -packages. +This last command will run `test` in both `./packages/a` and `./packages/b` packages. ### Configuration @@ -142,9 +119,9 @@ packages. * 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. +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: @@ -153,9 +130,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -167,13 +144,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -184,9 +162,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -195,12 +174,12 @@ This value is not exported to the environment for child processes. * Default: false * Type: Boolean -If true, npm will not exit with an error code when `run` is invoked for a -script that isn't defined in the `scripts` section of `package.json`. This -option can be used when it's desirable to optionally run a script when it's -present and fail if the script fails. This is useful, for example, when -running scripts that may only apply for some builds in an otherwise generic -CI setup. +If true, npm will not exit with an error code when `run` is invoked +for a script that isn't defined in the `scripts` section of +`package.json`. This option can be used when it's desirable to +optionally run a script when it's present and fail if the script +fails. This is useful, for example, when running scripts that may +only apply for some builds in an otherwise generic CI setup. This value is not exported to the environment for child processes. @@ -211,25 +190,26 @@ This value is not exported to the environment for child processes. 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. +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. #### `foreground-scripts` -* Default: `false` unless when using `npm pack` or `npm publish` where it - defaults to `true` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -238,8 +218,8 @@ but can be useful for debugging. * Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows * Type: null or String -The shell to use for scripts run with the `npm exec`, `npm run` and `npm -init ` commands. +The shell to use for scripts run with the `npm exec`, `npm run` and +`npm init ` commands. diff --git a/deps/npm/docs/content/commands/npm-sbom.md b/deps/npm/docs/content/commands/npm-sbom.md index 6e8033b96aedc7..fd9d183005790c 100644 --- a/deps/npm/docs/content/commands/npm-sbom.md +++ b/deps/npm/docs/content/commands/npm-sbom.md @@ -12,9 +12,8 @@ npm sbom ### Description -The `npm sbom` command generates a Software Bill of Materials (SBOM) listing the -dependencies for the current project. SBOMs can be generated in either -[SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/) format. +The `npm sbom` command generates a Software Bill of Materials (SBOM) listing the dependencies for the current project. +SBOMs can be generated in either [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/) format. ### Example CycloneDX SBOM @@ -208,17 +207,16 @@ dependencies for the current project. SBOMs can be generated in either ### Package lock only mode -If package-lock-only is enabled, only the information in the package -lock (or shrinkwrap) is loaded. This means that information from the -package.json files of your dependencies will not be included in the -result set (e.g. description, homepage, engines). +If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. +This means that information from the package.json files of your dependencies will not be included in the result set (e.g. +description, homepage, engines). ### Configuration #### `omit` * Default: 'dev' if the `NODE_ENV` environment variable is set to - 'production', otherwise empty. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -227,11 +225,12 @@ 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 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. +If the resulting omit list includes `'dev'`, then the `NODE_ENV` +environment variable will be set to `'production'` for all lifecycle +scripts. @@ -240,14 +239,15 @@ variable will be set to `'production'` for all lifecycle scripts. * Default: false * Type: Boolean -If set to true, the current operation will only use the `package-lock.json`, -ignoring `node_modules`. +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`. +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`. @@ -265,9 +265,9 @@ SBOM format to use when generating SBOMs. * Default: "library" * Type: "library", "application", or "framework" -The type of package described by the generated SBOM. For SPDX, this is the -value for the `primaryPackagePurpose` field. For CycloneDX, this is the -value for the `type` field. +The type of package described by the generated SBOM. For SPDX, this +is the value for the `primaryPackagePurpose` field. For CycloneDX, +this is the value for the `type` field. @@ -276,9 +276,9 @@ value for the `type` field. * 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. +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: @@ -287,9 +287,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -301,13 +301,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. ## See Also diff --git a/deps/npm/docs/content/commands/npm-search.md b/deps/npm/docs/content/commands/npm-search.md index 4e4bbf58aec39e..4803ef57dfc975 100644 --- a/deps/npm/docs/content/commands/npm-search.md +++ b/deps/npm/docs/content/commands/npm-search.md @@ -16,26 +16,20 @@ Note: This command is unaware of workspaces. ### Description -Search the registry for packages matching the search terms. `npm search` -performs a linear, incremental, lexically-ordered search through package -metadata for all files in the registry. If your terminal has color -support, it will further highlight the matches in the results. This can -be disabled with the config item `color` - -Additionally, using the `--searchopts` and `--searchexclude` options -paired with more search terms will include and exclude further patterns. -The main difference between `--searchopts` and the standard search terms -is that the former does not highlight results in the output and you can -use them more fine-grained filtering. Additionally, you can add both of -these to your config to change default search filtering behavior. - -Search also allows targeting of maintainers in search results, by prefixing -their npm username with `=`. - -If a term starts with `/`, then it's interpreted as a regular expression -and supports standard JavaScript RegExp syntax. In this case search will -ignore a trailing `/` . (Note you must escape or quote many regular -expression characters in most shells.) +Search the registry for packages matching the search terms. +`npm search` +performs a linear, incremental, lexically-ordered search through package metadata for all files in the registry. +If your terminal has color support, it will further highlight the matches in the results. +This can be disabled with the config item `color` + +Additionally, using the `--searchopts` and `--searchexclude` options paired with more search terms will include and exclude further patterns. +The main difference between `--searchopts` and the standard search terms is that the former does not highlight results in the output and you can use them more fine-grained filtering. +Additionally, you can add both of these to your config to change default search filtering behavior. + +Search also allows targeting of maintainers in search results, by prefixing their npm username with `=`. + +If a term starts with `/`, then it's interpreted as a regular expression and supports standard JavaScript RegExp syntax. +In this case search will ignore a trailing `/` . (Note you must escape or quote many regular expression characters in most shells.) ### Configuration @@ -46,8 +40,8 @@ expression characters in most shells.) 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`. +* 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. @@ -55,11 +49,12 @@ Not supported by all npm commands. #### `color` -* Default: true unless the NO_COLOR environ is set to something other than '0' +* Default: true unless the NO_COLOR environ is set to something other + than '0' * Type: "always" or Boolean -If false, never shows colors. If `"always"` then always shows colors. If -true, then only prints color codes for tty file descriptors. +If false, never shows colors. If `"always"` then always shows colors. +If true, then only prints color codes for tty file descriptors. @@ -68,8 +63,8 @@ true, then only prints color codes for tty file descriptors. * Default: false * Type: Boolean -Output parseable results from commands that write to standard output. For -`npm search`, this will be tab-separated table format. +Output parseable results from commands that write to standard output. +For `npm search`, this will be tab-separated table format. @@ -87,8 +82,8 @@ Show the description in `npm search` * Default: 20 * Type: Number -Number of items to limit search results to. Will not apply at all to legacy -searches. +Number of items to limit search results to. Will not apply at all to +legacy searches. @@ -124,8 +119,8 @@ The base URL of the npm registry. * Default: false * Type: Boolean -If true, staleness checks for cached data will be forced, making the CLI -look for updates immediately even for fresh package data. +If true, staleness checks for cached data will be forced, making the +CLI look for updates immediately even for fresh package data. @@ -134,9 +129,9 @@ look for updates immediately even for fresh package data. * Default: false * Type: Boolean -If true, staleness checks for cached data will be bypassed, but missing data -will be requested from the server. To force full offline mode, use -`--offline`. +If true, staleness checks for cached data will be bypassed, but +missing data will be requested from the server. To force full offline +mode, use `--offline`. @@ -145,8 +140,9 @@ will be requested from the server. To force full offline mode, use * Default: false * Type: Boolean -Force offline mode: no network requests will be done during install. To -allow the CLI to fill in missing cache data, see `--prefer-offline`. +Force offline mode: no network requests will be done during install. +To allow the CLI to fill in missing cache data, see +`--prefer-offline`. diff --git a/deps/npm/docs/content/commands/npm-shrinkwrap.md b/deps/npm/docs/content/commands/npm-shrinkwrap.md index de05c32d9c5c86..813affd9f56071 100644 --- a/deps/npm/docs/content/commands/npm-shrinkwrap.md +++ b/deps/npm/docs/content/commands/npm-shrinkwrap.md @@ -14,12 +14,9 @@ Note: This command is unaware of workspaces. ### Description -This command repurposes `package-lock.json` into a publishable -`npm-shrinkwrap.json` or simply creates a new one. The file created and -updated by this command will then take precedence over any other existing -or future `package-lock.json` files. For a detailed explanation of the -design and purpose of package locks in npm, see -[package-lock-json](/configuring-npm/package-lock-json). +This command repurposes `package-lock.json` into a publishable `npm-shrinkwrap.json` or simply creates a new one. +The file created and updated by this command will then take precedence over any other existing or future `package-lock.json` files. +For a detailed explanation of the design and purpose of package locks in npm, see [package-lock-json](/configuring-npm/package-lock-json). ### See Also diff --git a/deps/npm/docs/content/commands/npm-star.md b/deps/npm/docs/content/commands/npm-star.md index 59e1fbec52cc97..163bce4a73af3a 100644 --- a/deps/npm/docs/content/commands/npm-star.md +++ b/deps/npm/docs/content/commands/npm-star.md @@ -14,10 +14,11 @@ Note: This command is unaware of workspaces. ### Description -"Starring" a package means that you have some interest in it. It's -a vaguely positive way to show that you care. +"Starring" a package means that you have some interest in it. +It's a vaguely positive way to show that you care. -It's a boolean thing. Starring repeatedly has no additional effect. +It's a boolean thing. +Starring repeatedly has no additional effect. ### More @@ -46,12 +47,13 @@ The base URL of the npm registry. #### `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. +* 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. +When set to true, npm uses unicode characters in the tree output. +When false, it uses ascii characters instead of unicode glyphs. @@ -60,11 +62,12 @@ false, it uses ascii characters instead of unicode glyphs. * 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`. +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. +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. diff --git a/deps/npm/docs/content/commands/npm-stars.md b/deps/npm/docs/content/commands/npm-stars.md index 642ccfa14f1956..f49883a7a2c193 100644 --- a/deps/npm/docs/content/commands/npm-stars.md +++ b/deps/npm/docs/content/commands/npm-stars.md @@ -14,11 +14,9 @@ Note: This command is unaware of workspaces. ### Description -If you have starred a lot of neat things and want to find them again -quickly this command lets you do just that. +If you have starred a lot of neat things and want to find them again quickly this command lets you do just that. -You may also want to see your friend's favorite packages, in this case -you will most certainly enjoy this command. +You may also want to see your friend's favorite packages, in this case you will most certainly enjoy this command. ### Configuration diff --git a/deps/npm/docs/content/commands/npm-start.md b/deps/npm/docs/content/commands/npm-start.md index dc1ab617c66e51..19afcc689e8093 100644 --- a/deps/npm/docs/content/commands/npm-start.md +++ b/deps/npm/docs/content/commands/npm-start.md @@ -12,18 +12,14 @@ npm start [-- ] ### Description -This runs a predefined command specified in the `"start"` property of -a package's `"scripts"` object. +This runs a predefined command specified in the `"start"` property of a package's `"scripts"` object. -If the `"scripts"` object does not define a `"start"` property, npm -will run `node server.js`. +If the `"scripts"` object does not define a `"start"` property, npm will run `node server.js`. -Note that this is different from the default node behavior of running -the file specified in a package's `"main"` attribute when evoking with -`node .` +Note that this is different from the default node behavior of running the file specified in a package's `"main"` attribute when evoking with `node .` -As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can -use custom arguments when executing scripts. Refer to [`npm run`](/commands/npm-run) for more details. +As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can use custom arguments when executing scripts. +Refer to [`npm run`](/commands/npm-run) for more details. ### Example @@ -54,10 +50,10 @@ npm start 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. +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. @@ -66,8 +62,8 @@ run any pre- or post-scripts. * Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows * Type: null or String -The shell to use for scripts run with the `npm exec`, `npm run` and `npm -init ` commands. +The shell to use for scripts run with the `npm exec`, `npm run` and +`npm init ` commands. diff --git a/deps/npm/docs/content/commands/npm-stop.md b/deps/npm/docs/content/commands/npm-stop.md index ee8974c18a4b09..d342a81bda2108 100644 --- a/deps/npm/docs/content/commands/npm-stop.md +++ b/deps/npm/docs/content/commands/npm-stop.md @@ -12,11 +12,9 @@ npm stop [-- ] ### Description -This runs a predefined command specified in the "stop" property of a -package's "scripts" object. +This runs a predefined command specified in the "stop" property of a package's "scripts" object. -Unlike with [npm start](/commands/npm-start), there is no default script -that will run if the `"stop"` property is not defined. +Unlike with [npm start](/commands/npm-start), there is no default script that will run if the `"stop"` property is not defined. ### Example @@ -47,10 +45,10 @@ npm stop 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. +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. @@ -59,8 +57,8 @@ run any pre- or post-scripts. * Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows * Type: null or String -The shell to use for scripts run with the `npm exec`, `npm run` and `npm -init ` commands. +The shell to use for scripts run with the `npm exec`, `npm run` and +`npm init ` commands. diff --git a/deps/npm/docs/content/commands/npm-team.md b/deps/npm/docs/content/commands/npm-team.md index 7895df7c961522..4d660b0d3a583b 100644 --- a/deps/npm/docs/content/commands/npm-team.md +++ b/deps/npm/docs/content/commands/npm-team.md @@ -18,22 +18,18 @@ Note: This command is unaware of workspaces. ### Description -Used to manage teams in organizations, and change team memberships. Does not -handle permissions for packages. +Used to manage teams in organizations, and change team memberships. +Does not handle permissions for packages. -Teams must always be fully qualified with the organization/scope they belong to -when operating on them, separated by a colon (`:`). That is, if you have a -`newteam` team in an `org` organization, you must always refer to that team -as `@org:newteam` in these commands. +Teams must always be fully qualified with the organization/scope they belong to when operating on them, separated by a colon (`:`). +That is, if you have a `newteam` team in an `org` organization, you must always refer to that team as `@org:newteam` in these commands. -If you have two-factor authentication enabled in `auth-and-writes` mode, then -you can provide a code from your authenticator with `[--otp ]`. -If you don't include this then you will be taken through a second factor flow based -on your `authtype`. +If you have two-factor authentication enabled in `auth-and-writes` mode, then you can provide a code from your authenticator with `[--otp ]`. +If you don't include this then you will be taken through a second factor flow based on your `authtype`. * create / destroy: - Create a new team, or destroy an existing one. Note: You cannot remove the - `developers` team, [learn more.](https://docs.npmjs.com/about-developers-team) + Create a new team, or destroy an existing one. + Note: You cannot remove the `developers` team, [learn more.](https://docs.npmjs.com/about-developers-team) Here's how to create a new team `newteam` under the `org` org: @@ -41,8 +37,7 @@ on your `authtype`. npm team create @org:newteam ``` - You should see a confirming message such as: `+@org:newteam` once the new - team has been created. + You should see a confirming message such as: `+@org:newteam` once the new team has been created. * add: Add a user to an existing team. @@ -58,8 +53,7 @@ on your `authtype`. * rm: Using `npm team rm` you can also remove users from a team they belong to. - Here's an example removing user `username` from `newteam` team - in `org` organization: + Here's an example removing user `username` from `newteam` team in `org` organization: ```bash npm team rm @org:newteam username @@ -69,9 +63,8 @@ on your `authtype`. `username removed from @org:newteam` * ls: - If performed on an organization name, will return a list of existing teams - under that organization. If performed on a team, it will instead return a list - of all users belonging to that particular team. + If performed on an organization name, will return a list of existing teams under that organization. + If performed on a team, it will instead return a list of all users belonging to that particular team. Here's an example of how to list all teams from an org named `org`: @@ -87,18 +80,14 @@ on your `authtype`. ### Details -`npm team` always operates directly on the current registry, configurable from -the command line using `--registry=`. +`npm team` always operates directly on the current registry, configurable from the command line using `--registry=`. -You must be a *team admin* to create teams and manage team membership, under -the given organization. Listing teams and team memberships may be done by -any member of the organization. +You must be a *team admin* to create teams and manage team membership, under the given organization. +Listing teams and team memberships may be done by any member of the organization. -Organization creation and management of team admins and *organization* members -is done through the website, not the npm CLI. +Organization creation and management of team admins and *organization* members is done through the website, not the npm CLI. -To use teams to manage permissions on packages belonging to your organization, -use the `npm access` command to grant or revoke the appropriate permissions. +To use teams to manage permissions on packages belonging to your organization, use the `npm access` command to grant or revoke the appropriate permissions. ### Configuration @@ -116,11 +105,12 @@ The base URL of the npm registry. * 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`. +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. +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. @@ -129,8 +119,8 @@ password, npm will prompt on the command line for one. * Default: false * Type: Boolean -Output parseable results from commands that write to standard output. For -`npm search`, this will be tab-separated table format. +Output parseable results from commands that write to standard output. +For `npm search`, this will be tab-separated table format. @@ -141,8 +131,8 @@ Output parseable results from commands that write to standard output. For 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`. +* 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. diff --git a/deps/npm/docs/content/commands/npm-test.md b/deps/npm/docs/content/commands/npm-test.md index f72a817f8ede84..60d94eb2398063 100644 --- a/deps/npm/docs/content/commands/npm-test.md +++ b/deps/npm/docs/content/commands/npm-test.md @@ -14,8 +14,7 @@ aliases: tst, t ### Description -This runs a predefined command specified in the `"test"` property of -a package's `"scripts"` object. +This runs a predefined command specified in the `"test"` property of a package's `"scripts"` object. ### Example @@ -44,10 +43,10 @@ npm test 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. +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. @@ -56,8 +55,8 @@ run any pre- or post-scripts. * Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows * Type: null or String -The shell to use for scripts run with the `npm exec`, `npm run` and `npm -init ` commands. +The shell to use for scripts run with the `npm exec`, `npm run` and +`npm init ` commands. diff --git a/deps/npm/docs/content/commands/npm-token.md b/deps/npm/docs/content/commands/npm-token.md index 771da7d9857534..43c0fdc6c7309f 100644 --- a/deps/npm/docs/content/commands/npm-token.md +++ b/deps/npm/docs/content/commands/npm-token.md @@ -19,8 +19,8 @@ Note: This command is unaware of workspaces. This lets you list, create and revoke authentication tokens. * `npm token list`: - Shows a table of all active authentication tokens. You can request - this as JSON with `--json` or tab-separated values with `--parseable`. + Shows a table of all active authentication tokens. + You can request this as JSON with `--json` or tab-separated values with `--parseable`. ``` Read only token npm_1f… with id 7f3134 created 2017-10-21 @@ -33,29 +33,22 @@ Publish token npm_… with id e0cf92 created 2017-10-02 ``` * `npm token create [--read-only] [--cidr=]`: - Create a new authentication token. It can be `--read-only`, or accept - a list of - [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) - ranges with which to limit use of this token. This will prompt you for - your password, and, if you have two-factor authentication enabled, an - otp. - - Currently, the cli can not generate automation tokens. Please refer to - the [docs - website](https://docs.npmjs.com/creating-and-viewing-access-tokens) - for more information on generating automation tokens. + Create a new authentication token. + It can be `--read-only`, or accept a list of [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) ranges with which to limit use of this token. + This will prompt you for your password, and, if you have two-factor authentication enabled, an otp. + + Currently, the cli cannot generate automation tokens. + Please refer to the [docs website](https://docs.npmjs.com/creating-and-viewing-access-tokens) for more information on generating automation tokens. ``` Created publish token a73c9572-f1b9-8983-983d-ba3ac3cc913d ``` * `npm token revoke `: - Immediately removes an authentication token from the registry. You - will no longer be able to use it. This can accept both complete - tokens (such as those you get back from `npm token create`, and those - found in your `.npmrc`), and ids as seen in the parseable or json - output of `npm token list`. This will NOT accept the truncated token - found in the normal `npm token list` output. + Immediately removes an authentication token from the registry. + You will no longer be able to use it. + This can accept both complete tokens (such as those you get back from `npm token create`, and those found in your `.npmrc`), and ids as seen in the parseable or json output of `npm token list`. + This will NOT accept the truncated token found in the normal `npm token list` output. ### Configuration @@ -64,8 +57,8 @@ Created publish token a73c9572-f1b9-8983-983d-ba3ac3cc913d * Default: false * Type: Boolean -This is used to mark a token as unable to publish when configuring limited -access tokens with the `npm token create` command. +This is used to mark a token as unable to publish when configuring +limited access tokens with the `npm token create` command. @@ -74,8 +67,8 @@ access tokens with the `npm token create` command. * Default: null * Type: null or String (can be set multiple times) -This is a list of CIDR address to be used when configuring limited access -tokens with the `npm token create` command. +This is a list of CIDR address to be used when configuring limited +access tokens with the `npm token create` command. @@ -93,11 +86,12 @@ The base URL of the npm registry. * 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`. +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. +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. diff --git a/deps/npm/docs/content/commands/npm-undeprecate.md b/deps/npm/docs/content/commands/npm-undeprecate.md index f9abfd794c7eee..3034aca212f3db 100644 --- a/deps/npm/docs/content/commands/npm-undeprecate.md +++ b/deps/npm/docs/content/commands/npm-undeprecate.md @@ -14,11 +14,9 @@ Note: This command is unaware of workspaces. ### Description -This command will update the npm registry entry for a package, removing any -deprecation warnings that currently exist. +This command will update the npm registry entry for a package, removing any deprecation warnings that currently exist. -It works in the same way as [npm deprecate](/commands/npm-deprecate), except -that this command removes deprecation warnings instead of adding them. +It works in the same way as [npm deprecate](/commands/npm-deprecate), except that this command removes deprecation warnings instead of adding them. ### Configuration @@ -36,11 +34,12 @@ The base URL of the npm registry. * 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`. +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. +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. @@ -49,13 +48,14 @@ password, npm will prompt on the command line for one. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. ### See Also diff --git a/deps/npm/docs/content/commands/npm-uninstall.md b/deps/npm/docs/content/commands/npm-uninstall.md index de90df9c0c3bc5..1d8bb6418e07cf 100644 --- a/deps/npm/docs/content/commands/npm-uninstall.md +++ b/deps/npm/docs/content/commands/npm-uninstall.md @@ -14,26 +14,19 @@ aliases: unlink, remove, rm, r, un ### Description -This uninstalls a package, completely removing everything npm installed -on its behalf. +This uninstalls a package, completely removing everything npm installed on its behalf. It also removes the package from the `dependencies`, `devDependencies`, -`optionalDependencies`, and `peerDependencies` objects in your -`package.json`. +`optionalDependencies`, and `peerDependencies` objects in your `package.json`. -Further, if you have an `npm-shrinkwrap.json` or `package-lock.json`, npm -will update those files as well. +Further, if you have an `npm-shrinkwrap.json` or `package-lock.json`, npm will update those files as well. -`--no-save` will tell npm not to remove the package from your -`package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files. +`--no-save` will tell npm not to remove the package from your `package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files. -`--save` or `-S` will tell npm to remove the package from your -`package.json`, `npm-shrinkwrap.json`, and `package-lock.json` files. -This is the default, but you may need to use this if you have for -instance `save=false` in your `npmrc` file +`--save` or `-S` will tell npm to remove the package from your `package.json`, `npm-shrinkwrap.json`, and `package-lock.json` files. +This is the default, but you may need to use this if you have for instance `save=false` in your `npmrc` file -In global mode (ie, with `-g` or `--global` appended to the command), -it uninstalls the current package context as a global package. +In global mode (ie, with `-g` or `--global` appended to the command), it uninstalls the current package context as a global package. `--no-save` is ignored in this case. Scope is optional and follows the usual rules for [`scope`](/using-npm/scope). @@ -44,8 +37,7 @@ Scope is optional and follows the usual rules for [`scope`](/using-npm/scope). npm uninstall sax ``` -`sax` will no longer be in your `package.json`, `npm-shrinkwrap.json`, or -`package-lock.json` files. +`sax` will no longer be in your `package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files. ```bash npm uninstall lodash --no-save @@ -58,7 +50,8 @@ npm uninstall lodash --no-save #### `save` -* Default: `true` unless when using `npm update` where it defaults to `false` +* Default: `true` unless when using `npm update` where it defaults to + `false` * Type: Boolean Save installed packages to a `package.json` file as dependencies. @@ -75,12 +68,13 @@ Will also prevent writing to `package-lock.json` if set to `false`. * 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. +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. +* 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` @@ -91,9 +85,9 @@ folder instead of the current working directory. See * 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. +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: @@ -102,9 +96,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -116,13 +110,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -133,9 +128,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -144,9 +140,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-unpublish.md b/deps/npm/docs/content/commands/npm-unpublish.md index 2421e102325363..db68ae7d40bc03 100644 --- a/deps/npm/docs/content/commands/npm-unpublish.md +++ b/deps/npm/docs/content/commands/npm-unpublish.md @@ -10,35 +10,25 @@ description: Remove a package from the registry npm unpublish [] ``` -To learn more about how the npm registry treats unpublish, see our -[unpublish policies](https://docs.npmjs.com/policies/unpublish). +To learn more about how the npm registry treats unpublish, see our [unpublish policies](https://docs.npmjs.com/policies/unpublish). ### Warning -Consider using the [`deprecate`](/commands/npm-deprecate) command instead, -if your intent is to encourage users to upgrade, or if you no longer -want to maintain a package. +Consider using the [`deprecate`](/commands/npm-deprecate) command instead, if your intent is to encourage users to upgrade, or if you no longer want to maintain a package. ### Description -This removes a package version from the registry, deleting its entry and -removing the tarball. +This removes a package version from the registry, deleting its entry and removing the tarball. -The npm registry will return an error if you are not [logged -in](/commands/npm-adduser). +The npm registry will return an error if you are not [logged in](/commands/npm-adduser). -If you do not specify a package name at all, the name and version to be -unpublished will be pulled from the project in the current directory. +If you do not specify a package name at all, the name and version to be unpublished will be pulled from the project in the current directory. -If you specify a package name but do not specify a version or if you -remove all of a package's versions then the registry will remove the -root package entry entirely. +If you specify a package name but do not specify a version or if you remove all of a package's versions then the registry will remove the root package entry entirely. -Even if you unpublish a package version, that specific name and version -combination can never be reused. In order to publish the package again, -you must use a new version number. If you unpublish the entire package, -you may not publish any new versions of that package until 24 hours have -passed. +Even if you unpublish a package version, that specific name and version combination can never be reused. +In order to publish the package again, you must use a new version number. +If you unpublish the entire package, you may not publish any new versions of that package until 24 hours have passed. ### Configuration @@ -47,13 +37,14 @@ passed. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -68,14 +59,16 @@ 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 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. +* 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). @@ -90,9 +83,9 @@ recommended that you do not use this option! * 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. +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: @@ -101,9 +94,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -115,13 +108,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. diff --git a/deps/npm/docs/content/commands/npm-unstar.md b/deps/npm/docs/content/commands/npm-unstar.md index 92ae740befa391..8c560bc5da06dc 100644 --- a/deps/npm/docs/content/commands/npm-unstar.md +++ b/deps/npm/docs/content/commands/npm-unstar.md @@ -14,8 +14,7 @@ Note: This command is unaware of workspaces. ### Description -"Unstarring" a package is the opposite of [`npm star`](/commands/npm-star), -it removes an item from your list of favorite packages. +"Unstarring" a package is the opposite of [`npm star`](/commands/npm-star), it removes an item from your list of favorite packages. ### More @@ -42,12 +41,13 @@ The base URL of the npm registry. #### `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. +* 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. +When set to true, npm uses unicode characters in the tree output. +When false, it uses ascii characters instead of unicode glyphs. @@ -56,11 +56,12 @@ false, it uses ascii characters instead of unicode glyphs. * 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`. +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. +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. diff --git a/deps/npm/docs/content/commands/npm-update.md b/deps/npm/docs/content/commands/npm-update.md index ff108a8f7f0431..c20da891716ba5 100644 --- a/deps/npm/docs/content/commands/npm-update.md +++ b/deps/npm/docs/content/commands/npm-update.md @@ -14,30 +14,21 @@ aliases: up, upgrade, udpate ### Description -This command will update all the packages listed to the latest version -(specified by the [`tag` config](/using-npm/config#tag)), respecting the semver -constraints of both your package and its dependencies (if they also require the -same package). +This command will update all the packages listed to the latest version (specified by the [`tag` config](/using-npm/config#tag)), respecting the semver constraints of both your package and its dependencies (if they also require the same package). It will also install missing packages. -If the `-g` flag is specified, this command will update globally installed -packages. +If the `-g` flag is specified, this command will update globally installed packages. -If no package name is specified, all packages in the specified location (global -or local) will be updated. +If no package name is specified, all packages in the specified location (global or local) will be updated. -Note that by default `npm update` will not update the semver values of direct -dependencies in your project `package.json`. If you want to also update -values in `package.json` you can run: `npm update --save` (or add the -`save=true` option to a [configuration file](/configuring-npm/npmrc) -to make that the default behavior). +Note that by default `npm update` will not update the semver values of direct dependencies in your project `package.json`. +If you want to also update values in `package.json` you can run: `npm update --save` (or add the `save=true` option to a [configuration file](/configuring-npm/npmrc) to make that the default behavior). ### Example -For the examples below, assume that the current package is `app` and it depends -on dependencies, `dep1` (`dep2`, .. etc.). The published versions of `dep1` -are: +For the examples below, assume that the current package is `app` and it depends on dependencies, `dep1` (`dep2`, .. etc.). +The published versions of `dep1` are: ```json { @@ -79,9 +70,9 @@ However, if `app`'s `package.json` contains: } ``` -In this case, running `npm update` will install `dep1@1.1.2`. Even though the -`latest` tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is -equivalent to `>=1.1.1 <1.2.0`. So the highest-sorting version that satisfies +In this case, running `npm update` will install `dep1@1.1.2`. +Even though the `latest` tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is equivalent to `>=1.1.1 <1.2.0`. +So the highest-sorting version that satisfies `~1.1.1` is used, which is `1.1.2`. #### Caret Dependencies below 1.0.0 @@ -104,8 +95,7 @@ If the dependence were on `^0.4.0`: } ``` -Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting -version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`) +Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`) #### Subdependencies @@ -133,32 +123,26 @@ and `dep2` itself depends on this limited range of `dep1` } ``` -Then `npm update` will install `dep1@1.1.2` because that is the highest -version that `dep2` allows. npm will prioritize having a single version -of `dep1` in your tree rather than two when that single version can -satisfy the semver requirements of multiple dependencies in your tree. -In this case if you really did need your package to use a newer version -you would need to use `npm install`. +Then `npm update` will install `dep1@1.1.2` because that is the highest version that `dep2` allows. + npm will prioritize having a single version of `dep1` in your tree rather than two when that single version can satisfy the semver requirements of multiple dependencies in your tree. +In this case if you really did need your package to use a newer version you would need to use `npm install`. #### Updating Globally-Installed Packages -`npm update -g` will apply the `update` action to each globally installed -package that is `outdated` -- that is, has a version that is different from -`wanted`. +`npm update -g` will apply the `update` action to each globally installed package that is `outdated` -- that is, has a version that is different from `wanted`. -Note: Globally installed packages are treated as if they are installed with a -caret semver range specified. So if you require to update to `latest` you may -need to run `npm install -g [...]` +Note: Globally installed packages are treated as if they are installed with a caret semver range specified. +So if you require to update to `latest` you may need to run `npm install -g [...]` -NOTE: If a package has been upgraded to a version newer than `latest`, it will -be _downgraded_. +NOTE: If a package has been upgraded to a version newer than `latest`, it will be _downgraded_. ### Configuration #### `save` -* Default: `true` unless when using `npm update` where it defaults to `false` +* Default: `true` unless when using `npm update` where it defaults to + `false` * Type: Boolean Save installed packages to a `package.json` file as dependencies. @@ -175,12 +159,13 @@ Will also prevent writing to `package-lock.json` if set to `false`. * 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. +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. +* 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` @@ -192,11 +177,12 @@ folder instead of the current working directory. See * 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. +(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. @@ -207,10 +193,10 @@ link in place, unhoisted. * 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`. +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`. @@ -221,15 +207,15 @@ de-duplicating. Sets `--install-strategy=nested`. * 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`. +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. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -238,25 +224,29 @@ 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 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. +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) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -266,18 +256,19 @@ the order in which omit/include are specified on the command-line. * 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. +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. +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. +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. @@ -286,23 +277,25 @@ this warning is treated as a failure. * 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. +If set to false, then ignore `package-lock.json` files when +installing. This will also prevent _writing_ `package-lock.json` if +`save` is true. #### `foreground-scripts` -* Default: `false` unless when using `npm pack` or `npm publish` where it - defaults to `true` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -313,10 +306,10 @@ but can be useful for debugging. 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. +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. @@ -325,10 +318,10 @@ run any pre- or post-scripts. * 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. +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. @@ -338,14 +331,14 @@ submitted. * 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. +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`. +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`. @@ -357,9 +350,9 @@ will be used. For example, `foo@latest` might install `foo@1.2` even though 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. +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. @@ -369,8 +362,8 @@ systems. * 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. +acknowledging the number of dependencies looking for funding. See +[`npm fund`](/commands/npm-fund) for details. @@ -379,13 +372,14 @@ fund`](/commands/npm-fund) for details. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -394,9 +388,9 @@ Note: This is NOT honored by other network related commands, eg `dist-tags`, * 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. +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: @@ -405,9 +399,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -419,13 +413,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -436,9 +431,10 @@ This value is not exported to the environment for child processes. 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. +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. @@ -447,9 +443,9 @@ This value is not exported to the environment for child processes. * 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. +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. diff --git a/deps/npm/docs/content/commands/npm-version.md b/deps/npm/docs/content/commands/npm-version.md index c543f90d2cf2e9..aeaa764e0df5f9 100644 --- a/deps/npm/docs/content/commands/npm-version.md +++ b/deps/npm/docs/content/commands/npm-version.md @@ -19,8 +19,8 @@ alias: verison * Default: false * Type: Boolean -Prevents throwing an error when `npm version` is used to set the new version -to the same value as the current version. +Prevents throwing an error when `npm version` is used to set the new +version to the same value as the current version. @@ -38,8 +38,8 @@ Run git commit hooks when using the `npm version` command. * Default: true * Type: Boolean -Tag the commit when using the `npm version` command. Setting this to false -results in no commit being made at all. +Tag the commit when using the `npm version` command. Setting this to +false results in no commit being made at all. @@ -50,8 +50,8 @@ results in no commit being made at all. 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`. +* 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. @@ -62,8 +62,8 @@ Not supported by all npm commands. * Default: "" * Type: String -The "prerelease identifier" to use as a prefix for the "prerelease" part of -a semver. Like the `rc` in `1.2.0-rc.8`. +The "prerelease identifier" to use as a prefix for the "prerelease" +part of a semver. Like the `rc` in `1.2.0-rc.8`. @@ -72,11 +72,11 @@ a semver. Like the `rc` in `1.2.0-rc.8`. * Default: false * Type: Boolean -If set to true, then the `npm version` command will tag the version using -`-s` to add a signature. +If set to true, then the `npm version` command will tag the version +using `-s` to add a signature. -Note that git requires you to have set up GPG keys in your git configs for -this to work properly. +Note that git requires you to have set up GPG keys in your git +configs for this to work properly. @@ -85,9 +85,9 @@ this to work properly. * 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. +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: @@ -96,9 +96,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -110,13 +110,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -125,8 +126,9 @@ This value is not exported to the environment for child processes. * 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. +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. @@ -137,77 +139,66 @@ possibly change the workspaces installed to the `node_modules` folder. 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. +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. ### Description -Run this in a package directory to bump the version and write the new data -back to `package.json`, `package-lock.json`, and, if present, +Run this in a package directory to bump the version and write the new data back to `package.json`, `package-lock.json`, and, if present, `npm-shrinkwrap.json`. -The `newversion` argument should be a valid semver string, a valid second -argument to [semver.inc](https://github.com/npm/node-semver#functions) (one -of `patch`, `minor`, `major`, `prepatch`, `preminor`, `premajor`, -`prerelease`), or `from-git`. In the second case, the existing version will -be incremented by 1 in the specified field. `from-git` will try to read -the latest git tag, and use that as the new npm version. +The `newversion` argument should be a valid semver string, a valid second argument to [semver.inc](https://github.com/npm/node-semver#functions) (one of `patch`, `minor`, `major`, `prepatch`, `preminor`, `premajor`, `prerelease`), or `from-git`. +In the second case, the existing version will be incremented by 1 in the specified field. +`from-git` will try to read the latest git tag, and use that as the new npm version. -If run in a git repo, it will also create a version commit and tag. This -behavior is controlled by `git-tag-version` (see below), and can be -disabled on the command line by running `npm --no-git-tag-version version`. -It will fail if the working directory is not clean, unless the `-f` or -`--force` flag is set. +If run in a git repo, it will also create a version commit and tag. +This behavior is controlled by `git-tag-version` (see below), and can be disabled on the command line by running `npm --no-git-tag-version version`. +It will fail if the working directory is not clean, unless the `-f` or `--force` flag is set. -If supplied with `-m` or [`--message` config](/using-npm/config#message) option, -npm will use it as a commit message when creating a version commit. If the -`message` config contains `%s` then that will be replaced with the resulting -version number. For example: +If supplied with `-m` or [`--message` config](/using-npm/config#message) option, npm will use it as a commit message when creating a version commit. +If the `message` config contains `%s` then that will be replaced with the resulting version number. +For example: ```bash npm version patch -m "Upgrade to %s for reasons" ``` -If the [`sign-git-tag` config](/using-npm/config#sign-git-tag) is set, then the -tag will be signed using the `-s` flag to git. Note that you must have a default -GPG key set up in your git config for this to work properly. For example: +If the [`sign-git-tag` config](/using-npm/config#sign-git-tag) is set, then the tag will be signed using the `-s` flag to git. +Note that you must have a default GPG key set up in your git config for this to work properly. +For example: ```bash $ npm config set sign-git-tag true $ npm version patch -You need a passphrase to unlock the secret key for -user: "isaacs (http://blog.izs.me/) " +You need a passphrase to unlock the secret key for user: "isaacs (http://blog.izs.me/) " 2048-bit RSA key, ID 6C481CF6, created 2010-08-31 Enter passphrase: ``` -If `preversion`, `version`, or `postversion` are in the `scripts` property -of the package.json, they will be executed as part of running `npm -version`. +If `preversion`, `version`, or `postversion` are in the `scripts` property of the package.json, they will be executed as part of running `npm version`. The exact order of execution is as follows: -1. Check to make sure the git working directory is clean before we get - started. Your scripts may add files to the commit in future steps. +1. Check to make sure the git working directory is clean before we get started. + Your scripts may add files to the commit in future steps. This step is skipped if the `--force` flag is set. -2. Run the `preversion` script. These scripts have access to the old - `version` in package.json. A typical use would be running your full - test suite before deploying. Any files you want added to the commit - should be explicitly added using `git add`. -3. Bump `version` in `package.json` as requested (`patch`, `minor`, - `major`, etc). -4. Run the `version` script. These scripts have access to the new `version` - in package.json (so they can incorporate it into file headers in - generated files for example). Again, scripts should explicitly add - generated files to the commit using `git add`. +2. Run the `preversion` script. + These scripts have access to the old `version` in package.json. + A typical use would be running your full test suite before deploying. + Any files you want added to the commit should be explicitly added using `git add`. +3. Bump `version` in `package.json` as requested (`patch`, `minor`, `major`, etc). +4. Run the `version` script. + These scripts have access to the new `version` in package.json (so they can incorporate it into file headers in generated files for example). + Again, scripts should explicitly add generated files to the commit using `git add`. 5. Commit and tag. -6. Run the `postversion` script. Use it to clean up the file system or - automatically push the commit and/or tag. +6. Run the `postversion` script. + Use it to clean up the file system or automatically push the commit and/or tag. Take the following example: @@ -221,10 +212,9 @@ Take the following example: } ``` -This runs all your tests and proceeds only if they pass. Then runs your -`build` script, and adds everything in the `dist` directory to the commit. -After the commit, it pushes the new commit and tag up to the server, and -deletes the `build/temp` directory. +This runs all your tests and proceeds only if they pass. +Then runs your `build` script, and adds everything in the `dist` directory to the commit. +After the commit, it pushes the new commit and tag up to the server, and deletes the `build/temp` directory. ### See Also diff --git a/deps/npm/docs/content/commands/npm-view.md b/deps/npm/docs/content/commands/npm-view.md index 63bfe41398d1f3..9b803b01d12223 100644 --- a/deps/npm/docs/content/commands/npm-view.md +++ b/deps/npm/docs/content/commands/npm-view.md @@ -33,7 +33,8 @@ npm view ronn@0.3.5 dependencies ``` By default, `npm view` shows data about the current project context (by looking for a `package.json`). -To show field data for the current project use a file path (i.e. `.`): +To show field data for the current project use a file path (i.e. +`.`): ```bash npm view . dependencies @@ -46,25 +47,22 @@ To view the git repository URL for the latest version of `npm`, you would run th npm view npm repository.url ``` -This makes it easy to view information about a dependency with a bit of -shell scripting. For example, to view all the data about the version of -`opts` that `ronn` depends on, you could write the following: +This makes it easy to view information about a dependency with a bit of shell scripting. +For example, to view all the data about the version of `opts` that `ronn` depends on, you could write the following: ```bash npm view opts@$(npm view ronn dependencies.opts) ``` -For fields that are arrays, requesting a non-numeric field will return -all of the values from the objects in the list. For example, to get all -the contributor email addresses for the `express` package, you would run: +For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list. +For example, to get all the contributor email addresses for the `express` package, you would run: ```bash npm view express contributors.email ``` -You may also use numeric indices in square braces to specifically select -an item in an array field. To just get the email address of the first -contributor in the list, you can run: +You may also use numeric indices in square braces to specifically select an item in an array field. +To just get the email address of the first contributor in the list, you can run: ```bash npm view express contributors[0].email @@ -77,31 +75,28 @@ npm view express time'[4.8.0]' ``` Multiple fields may be specified, and will be printed one after another. -For example, to get all the contributor names and email addresses, you -can do this: +For example, to get all the contributor names and email addresses, you can do this: ```bash npm view express contributors.name contributors.email ``` -"Person" fields are shown as a string if they would be shown as an -object. So, for example, this will show the list of `npm` contributors in -the shortened string format. (See [`package.json`](/configuring-npm/package-json) for more on this.) +"Person" fields are shown as a string if they would be shown as an object. +So, for example, this will show the list of `npm` contributors in the shortened string format. + (See [`package.json`](/configuring-npm/package-json) for more on this.) ```bash npm view npm contributors ``` -If a version range is provided, then data will be printed for every -matching version of the package. This will show which version of `jsdom` -was required by each matching version of `yui3`: +If a version range is provided, then data will be printed for every matching version of the package. +This will show which version of `jsdom` was required by each matching version of `yui3`: ```bash npm view yui3@'>0.5.4' dependencies.jsdom ``` -To show the `connect` package version history, you can do -this: +To show the `connect` package version history, you can do this: ```bash npm view connect versions @@ -116,8 +111,8 @@ npm view connect versions 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`. +* 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. @@ -128,9 +123,9 @@ Not supported by all npm commands. * 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. +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: @@ -139,9 +134,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -153,13 +148,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -170,25 +166,23 @@ This value is not exported to the environment for child processes. 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. +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. ### Output -If only a single string field for a single version is output, then it -will not be colorized or quoted, to enable piping the output to -another command. If the field is an object, it will be output as a JavaScript object literal. +If only a single string field for a single version is output, then it will not be colorized or quoted, to enable piping the output to another command. +If the field is an object, it will be output as a JavaScript object literal. If the `--json` flag is given, the outputted fields will be JSON. -If the version range matches multiple versions then each printed value -will be prefixed with the version it applies to. +If the version range matches multiple versions then each printed value will be prefixed with the version it applies to. -If multiple fields are requested, then each of them is prefixed with -the field name. +If multiple fields are requested, then each of them is prefixed with the field name. ### See Also diff --git a/deps/npm/docs/content/commands/npm-whoami.md b/deps/npm/docs/content/commands/npm-whoami.md index a1458f0202355c..fb09864050ff6c 100644 --- a/deps/npm/docs/content/commands/npm-whoami.md +++ b/deps/npm/docs/content/commands/npm-whoami.md @@ -16,12 +16,9 @@ Note: This command is unaware of workspaces. Display the npm username of the currently logged-in user. -If logged into a registry that provides token-based authentication, then -connect to the `/-/whoami` registry endpoint to find the username -associated with the token, and print to standard output. +If logged into a registry that provides token-based authentication, then connect to the `/-/whoami` registry endpoint to find the username associated with the token, and print to standard output. -If logged into a registry that uses Basic Auth, then simply print the -`username` portion of the authentication string. +If logged into a registry that uses Basic Auth, then simply print the `username` portion of the authentication string. ### Configuration diff --git a/deps/npm/docs/content/commands/npm.md b/deps/npm/docs/content/commands/npm.md index e104d9ffc397cf..c53944048cf8a7 100644 --- a/deps/npm/docs/content/commands/npm.md +++ b/deps/npm/docs/content/commands/npm.md @@ -14,138 +14,111 @@ Note: This command is unaware of workspaces. ### Version -11.6.1 +11.6.2 ### Description -npm is the package manager for the Node JavaScript platform. It puts -modules in place so that node can find them, and manages dependency -conflicts intelligently. +npm is the package manager for the Node JavaScript platform. +It puts modules in place so that node can find them, and manages dependency conflicts intelligently. -It is extremely configurable to support a variety of use cases. Most -commonly, you use it to publish, discover, install, and develop node -programs. +It is extremely configurable to support a variety of use cases. +Most commonly, you use it to publish, discover, install, and develop node programs. Run `npm help` to get a list of available commands. ### Important -npm comes preconfigured to use npm's public registry at -https://registry.npmjs.org by default. Use of the npm public registry is -subject to terms of use available at -https://docs.npmjs.com/policies/terms. +npm comes preconfigured to use npm's public registry at https://registry.npmjs.org by default. +Use of the npm public registry is subject to terms of use available at https://docs.npmjs.com/policies/terms. -You can configure npm to use any compatible registry you like, and even -run your own registry. Use of someone else's registry is governed by -their terms of use. +You can configure npm to use any compatible registry you like, and even run your own registry. +Use of someone else's registry is governed by their terms of use. ### Introduction You probably got npm because you want to install stuff. -The very first thing you will most likely want to run in any node -program is `npm install` to install its dependencies. +The very first thing you will most likely want to run in any node program is `npm install` to install its dependencies. -You can also run `npm install blerg` to install the latest version of -"blerg". Check out [`npm install`](/commands/npm-install) for more -info. It can do a lot of stuff. +You can also run `npm install blerg` to install the latest version of "blerg". Check out [`npm install`](/commands/npm-install) for more info. +It can do a lot of stuff. -Use the `npm search` command to show everything that's available in the -public registry. Use `npm ls` to show everything you've installed. +Use the `npm search` command to show everything that's available in the public registry. +Use `npm ls` to show everything you've installed. ### Dependencies -If a package lists a dependency using a git URL, npm will install that -dependency using the [`git`](https://github.com/git-guides/install-git) -command and will generate an error if it is not installed. +If a package lists a dependency using a git URL, npm will install that dependency using the [`git`](https://github.com/git-guides/install-git) command and will generate an error if it is not installed. -If one of the packages npm tries to install is a native node module and -requires compiling of C++ Code, npm will use -[node-gyp](https://github.com/nodejs/node-gyp) for that task. -For a Unix system, [node-gyp](https://github.com/nodejs/node-gyp) -needs Python, make and a buildchain like GCC. On Windows, -Python and Microsoft Visual Studio C++ are needed. For more information -visit [the node-gyp repository](https://github.com/nodejs/node-gyp) and -the [node-gyp Wiki](https://github.com/nodejs/node-gyp/wiki). +If one of the packages npm tries to install is a native node module and requires compiling of C++ Code, npm will use [node-gyp](https://github.com/nodejs/node-gyp) for that task. +For a Unix system, [node-gyp](https://github.com/nodejs/node-gyp) needs Python, make and a buildchain like GCC. On Windows, Python and Microsoft Visual Studio C++ are needed. +For more information visit [the node-gyp repository](https://github.com/nodejs/node-gyp) and the [node-gyp Wiki](https://github.com/nodejs/node-gyp/wiki). ### Directories -See [`folders`](/configuring-npm/folders) to learn about where npm puts -stuff. +See [`folders`](/configuring-npm/folders) to learn about where npm puts stuff. In particular, npm has two modes of operation: * local mode: - npm installs packages into the current project directory, which - defaults to the current working directory. Packages install to - `./node_modules`, and bins to `./node_modules/.bin`. + npm installs packages into the current project directory, which defaults to the current working directory. + Packages install to `./node_modules`, and bins to `./node_modules/.bin`. * global mode: - npm installs packages into the install prefix at - `$npm_config_prefix/lib/node_modules` and bins to - `$npm_config_prefix/bin`. + npm installs packages into the install prefix at `$npm_config_prefix/lib/node_modules` and bins to `$npm_config_prefix/bin`. -Local mode is the default. Use `-g` or `--global` on any command to -run in global mode instead. +Local mode is the default. +Use `-g` or `--global` on any command to run in global mode instead. ### Developer Usage -If you're using npm to develop and publish your code, check out the -following help topics: +If you're using npm to develop and publish your code, check out the following help topics: * json: - Make a package.json file. See - [`package.json`](/configuring-npm/package-json). + Make a package.json file. + See [`package.json`](/configuring-npm/package-json). * link: - Links your current working code into Node's path, so that you don't - have to reinstall every time you make a change. Use [`npm - link`](/commands/npm-link) to do this. + Links your current working code into Node's path, so that you don't have to reinstall every time you make a change. + Use [`npm link`](/commands/npm-link) to do this. * install: - It's a good idea to install things if you don't need the symbolic - link. Especially, installing other peoples code from the registry is - done via [`npm install`](/commands/npm-install) + It's a good idea to install things if you don't need the symbolic link. + Especially, installing other peoples code from the registry is done via [`npm install`](/commands/npm-install) * adduser: - Create an account or log in. When you do this, npm will store - credentials in the user config file. + Create an account or log in. + When you do this, npm will store credentials in the user config file. * publish: - Use the [`npm publish`](/commands/npm-publish) command to upload your - code to the registry. + Use the [`npm publish`](/commands/npm-publish) command to upload your code to the registry. #### Configuration -npm is extremely configurable. It reads its configuration options from -5 places. +npm is extremely configurable. +It reads its configuration options from 5 places. * Command line switches: - Set a config with `--key val`. All keys take a value, even if they - are booleans (the config parser doesn't know what the options are at - the time of parsing). If you do not provide a value (`--key`) then - the option is set to boolean `true`. + Set a config with `--key val`. + All keys take a value, even if they are booleans (the config parser doesn't know what the options are at the time of parsing). + If you do not provide a value (`--key`) then the option is set to boolean `true`. * Environment Variables: - Set any config by prefixing the name in an environment variable with - `npm_config_`. For example, `export npm_config_key=val`. + Set any config by prefixing the name in an environment variable with `npm_config_`. + For example, `export npm_config_key=val`. * User Configs: - The file at `$HOME/.npmrc` is an ini-formatted list of configs. If - present, it is parsed. If the `userconfig` option is set in the cli - or env, that file will be used instead. + The file at `$HOME/.npmrc` is an ini-formatted list of configs. + If present, it is parsed. + If the `userconfig` option is set in the cli or env, that file will be used instead. * Global Configs: - The file found at `./etc/npmrc` (relative to the global prefix will be - parsed if it is found. See [`npm prefix`](/commands/npm-prefix) for - more info on the global prefix. If the `globalconfig` option is set - in the cli, env, or user config, then that file is parsed instead. + The file found at `./etc/npmrc` (relative to the global prefix will be parsed if it is found. + See [`npm prefix`](/commands/npm-prefix) for more info on the global prefix. + If the `globalconfig` option is set in the cli, env, or user config, then that file is parsed instead. * Defaults: - npm's default configuration options are defined in - `lib/utils/config/definitions.js`. These must not be changed. + npm's default configuration options are defined in `lib/utils/config/definitions.js`. + These must not be changed. -See [`config`](/using-npm/config) for much much more information. +See [`config`](/using-npm/config) for much, much, more information. ### Contributions Patches welcome! -If you would like to help, but don't know what to work on, read the -[contributing -guidelines](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md) and -check the issues list. +If you would like to help, but don't know what to work on, read the [contributing guidelines](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md) and check the issues list. ### Bugs diff --git a/deps/npm/docs/content/commands/npx.md b/deps/npm/docs/content/commands/npx.md index 02a208503d2625..83fcf326fbceb3 100644 --- a/deps/npm/docs/content/commands/npx.md +++ b/deps/npm/docs/content/commands/npx.md @@ -15,52 +15,32 @@ npx --package=foo -c ' [args...]' ### 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`. - -Whatever packages are specified by the `--package` option will be -provided in the `PATH` of the executed command, along with any locally -installed package executables. The `--package` option may be -specified multiple times, to execute the supplied command in an environment -where all specified packages are available. - -If any requested packages are not present in the local project -dependencies, then they are installed to a folder in the npm cache, which -is added to the `PATH` environment variable in the executed process. A -prompt is printed (which can be suppressed by providing either `--yes` or -`--no`). - -Package names provided without a specifier will be matched with whatever -version exists in the local project. Package names with a specifier will -only be considered a match if they have the exact same name and version as -the local dependency. - -If no `-c` or `--call` option is provided, then the positional arguments -are used to generate the command string. If no `--package` options -are provided, then npm will attempt to determine the executable name from -the package specifier provided as the first positional argument according -to the following heuristic: - -- If the package has a single entry in its `bin` field in `package.json`, - or if all entries are aliases of the same command, then that command - will be used. -- If the package has multiple `bin` entries, and one of them matches the - unscoped portion of the `name` field, then that command will be used. -- If this does not result in exactly one option (either because there are - no bin entries, or none of them match the `name` of the package), then +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`. + +Whatever packages are specified by the `--package` option will be provided in the `PATH` of the executed command, along with any locally installed package executables. +The `--package` option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available. + +If any requested packages are not present in the local project dependencies, then they are installed to a folder in the npm cache, which is added to the `PATH` environment variable in the executed process. +A prompt is printed (which can be suppressed by providing either `--yes` or `--no`). + +Package names provided without a specifier will be matched with whatever version exists in the local project. +Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency. + +If no `-c` or `--call` option is provided, then the positional arguments are used to generate the command string. +If no `--package` options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic: + +- If the package has a single entry in its `bin` field in `package.json`, or if all entries are aliases of the same command, then that command will be used. +- If the package has multiple `bin` entries, and one of them matches the unscoped portion of the `name` field, then that command will be used. +- If this does not result in exactly one option (either because there are no bin entries, or none of them match the `name` of the package), then `npm exec` exits with an error. To run a binary _other than_ the named binary, specify one or more -`--package` options, which will prevent npm from inferring the package from -the first command argument. +`--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. +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: @@ -68,34 +48,30 @@ For example: $ npx foo@latest bar --package=@npmcli/foo ``` -In this case, npm will resolve the `foo` package name, and run the -following command: +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. +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: +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: +`@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: +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 @@ -103,16 +79,14 @@ $ npm exec -- foo@latest bar --package=@npmcli/foo ### Examples -Run the version of `tap` in the local dependencies, with the provided -arguments: +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: +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 @@ -129,32 +103,27 @@ $ npx -c 'eslint && say "hooray, lint passed"' ### 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. +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. +- 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 have been removed. Use [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions) instead: e.g., +- 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 have been removed. +Use [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions) instead: e.g., `NODE_OPTIONS="--trace-warnings --trace-exit" npx foo --random=true` - 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. +- The `--shell` option is replaced with `--script-shell`, but maintained in the `npx` executable for backwards compatibility. ### See Also diff --git a/deps/npm/docs/content/configuring-npm/folders.md b/deps/npm/docs/content/configuring-npm/folders.md index 88e4e185584a07..56459c86930ba8 100644 --- a/deps/npm/docs/content/configuring-npm/folders.md +++ b/deps/npm/docs/content/configuring-npm/folders.md @@ -6,60 +6,49 @@ description: Folder Structures Used by npm ### Description -npm puts various things on your computer. That's its job. +npm puts various things on your computer. +That's its job. This document will tell you what it puts where. #### tl;dr -* Local install (default): puts stuff in `./node_modules` of the current - package root. -* Global install (with `-g`): puts stuff in /usr/local or wherever node - is installed. +* Local install (default): puts stuff in `./node_modules` of the current package root. +* Global install (with `-g`): puts stuff in /usr/local or wherever node is installed. * Install it **locally** if you're going to `require()` it. * Install it **globally** if you're going to run it on the command line. * If you need both, then install it in both places, or use `npm link`. #### prefix Configuration -The [`prefix` config](/using-npm/config#prefix) defaults to the location where -node is installed. On most systems, this is `/usr/local`. On Windows, it's -`%AppData%\npm`. On Unix systems, it's one level up, since node is typically -installed at `{prefix}/bin/node` rather than `{prefix}/node.exe`. +The [`prefix` config](/using-npm/config#prefix) defaults to the location where node is installed. +On most systems, this is `/usr/local`. +On Windows, it's `%AppData%\npm`. +On Unix systems, it's one level up, since node is typically installed at `{prefix}/bin/node` rather than `{prefix}/node.exe`. When the `global` flag is set, npm installs things into this prefix. -When it is not set, it uses the root of the current package, or the -current working directory if not in a package already. +When it is not set, it uses the root of the current package, or the current working directory if not in a package already. #### Node Modules Packages are dropped into the `node_modules` folder under the `prefix`. -When installing locally, this means that you can -`require("packagename")` to load its main module, or -`require("packagename/lib/path/to/sub/module")` to load other modules. +When installing locally, this means that you can `require("packagename")` to load its main module, or `require("packagename/lib/path/to/sub/module")` to load other modules. Global installs on Unix systems go to `{prefix}/lib/node_modules`. -Global installs on Windows go to `{prefix}/node_modules` (that is, no -`lib` folder.) +Global installs on Windows go to `{prefix}/node_modules` (that is, no `lib` folder.) -Scoped packages are installed the same way, except they are grouped together -in a sub-folder of the relevant `node_modules` folder with the name of that -scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place -the package in `{prefix}/node_modules/@myorg/package`. See -[`scope`](/using-npm/scope) for more details. +Scoped packages are installed the same way, except they are grouped together in a sub-folder of the relevant `node_modules` folder with the name of that scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place the package in `{prefix}/node_modules/@myorg/package`. +See [`scope`](/using-npm/scope) for more details. If you wish to `require()` a package, then install it locally. #### Executables -When in global mode, executables are linked into `{prefix}/bin` on Unix, -or directly into `{prefix}` on Windows. Ensure that path is in your -terminal's `PATH` environment to run them. +When in global mode, executables are linked into `{prefix}/bin` on Unix, or directly into `{prefix}` on Windows. +Ensure that path is in your terminal's `PATH` environment to run them. -When in local mode, executables are linked into -`./node_modules/.bin` so that they can be made available to scripts run -through npm. (For example, so that a test runner will be in the path -when you run `npm test`.) +When in local mode, executables are linked into `./node_modules/.bin` so that they can be made available to scripts run through npm. +(For example, so that a test runner will be in the path when you run `npm test`.) #### Man Pages @@ -71,67 +60,48 @@ Man pages are not installed on Windows systems. #### Cache -See [`npm cache`](/commands/npm-cache). Cache files are stored in `~/.npm` on Posix, or -`%LocalAppData%/npm-cache` on Windows. +See [`npm cache`](/commands/npm-cache). +Cache files are stored in `~/.npm` on Posix, or `%LocalAppData%/npm-cache` on Windows. This is controlled by the [`cache` config](/using-npm/config#cache) param. ### More Information -When installing locally, npm first tries to find an appropriate -`prefix` folder. This is so that `npm install foo@1.2.3` will install -to the sensible root of your package, even if you happen to have `cd`ed -into some other folder. +When installing locally, npm first tries to find an appropriate `prefix` folder. +This is so that `npm install foo@1.2.3` will install to the sensible root of your package, even if you happen to have `cd`ed into some other folder. -Starting at the $PWD, npm will walk up the folder tree checking for a -folder that contains either a `package.json` file, or a `node_modules` -folder. If such a thing is found, then that is treated as the effective -"current directory" for the purpose of running npm commands. (This -behavior is inspired by and similar to git's .git-folder seeking -logic when running git commands in a working dir.) +Starting at the $PWD, npm will walk up the folder tree checking for a folder that contains either a `package.json` file, or a `node_modules` folder. +If such a thing is found, then that is treated as the effective "current directory" for the purpose of running npm commands. +(This behavior is inspired by and similar to git's .git-folder seeking logic when running git commands in a working dir.) If no package root is found, then the current folder is used. -When you run `npm install foo@1.2.3`, then the package is loaded into -the cache, and then unpacked into `./node_modules/foo`. Then, any of -foo's dependencies are similarly unpacked into -`./node_modules/foo/node_modules/...`. +When you run `npm install foo@1.2.3`, then the package is loaded into the cache, and then unpacked into `./node_modules/foo`. +Then, any of foo's dependencies are similarly unpacked into `./node_modules/foo/node_modules/...`. -Any bin files are symlinked to `./node_modules/.bin/`, so that they may -be found by npm scripts when necessary. +Any bin files are symlinked to `./node_modules/.bin/`, so that they may be found by npm scripts when necessary. #### Global Installation -If the [`global` config](/using-npm/config#global) is set to true, then npm will -install packages "globally". +If the [`global` config](/using-npm/config#global) is set to true, then npm will install packages "globally". -For global installation, packages are installed roughly the same way, -but using the folders described above. +For global installation, packages are installed roughly the same way, but using the folders described above. #### Cycles, Conflicts, and Folder Parsimony -Cycles are handled using the property of node's module system that it -walks up the directories looking for `node_modules` folders. So, at every -stage, if a package is already installed in an ancestor `node_modules` -folder, then it is not installed at the current location. - -Consider the case above, where `foo -> bar -> baz`. Imagine if, in -addition to that, baz depended on bar, so you'd have: -`foo -> bar -> baz -> bar -> baz ...`. However, since the folder -structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to -put another copy of bar into `.../baz/node_modules`, since when baz calls -`require("bar")`, it will get the copy that is installed in -`foo/node_modules/bar`. - -This shortcut is only used if the exact same -version would be installed in multiple nested `node_modules` folders. It -is still possible to have `a/node_modules/b/node_modules/a` if the two -"a" packages are different versions. However, without repeating the -exact same package multiple times, an infinite regress will always be -prevented. - -Another optimization can be made by installing dependencies at the -highest level possible, below the localized "target" folder (hoisting). +Cycles are handled using the property of node's module system that it walks up the directories looking for `node_modules` folders. +So, at every stage, if a package is already installed in an ancestor `node_modules` folder, then it is not installed at the current location. + +Consider the case above, where `foo -> bar -> baz`. +Imagine if, in addition to that, baz depended on bar, so you'd have: +`foo -> bar -> baz -> bar -> baz ...`. +However, since the folder structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to put another copy of bar into `.../baz/node_modules`, since when baz calls `require("bar")`, it will get the copy that is installed in `foo/node_modules/bar`. + +This shortcut is only used if the exact same version would be installed in multiple nested `node_modules` folders. +It is still possible to have `a/node_modules/b/node_modules/a` if the two "a" packages are different versions. +However, without repeating the exact same package multiple times, an infinite regress will always be prevented. + +Another optimization can be made by installing dependencies at the highest level possible, below the localized "target" folder (hoisting). Since version 3, npm hoists dependencies by default. #### Example @@ -152,8 +122,7 @@ foo `-- bar ``` -In this case, we might expect a folder structure like this -(with all dependencies hoisted to the highest level possible): +In this case, we might expect a folder structure like this (with all dependencies hoisted to the highest level possible): ```bash foo @@ -167,36 +136,29 @@ foo +-- quux (3.2.0) <---[E] ``` -Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are -installed in foo's `node_modules` folder. +Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are installed in foo's `node_modules` folder. -Even though the latest copy of blerg is 1.3.7, foo has a specific -dependency on version 1.2.5. So, that gets installed at [A]. Since the -parent installation of blerg satisfies bar's dependency on `blerg@1.x`, -it does not install another copy under [B]. +Even though the latest copy of blerg is 1.3.7, foo has a specific dependency on version 1.2.5. +So, that gets installed at [A]. +Since the parent installation of blerg satisfies bar's dependency on `blerg@1.x`, it does not install another copy under [B]. -Bar [B] also has dependencies on baz and asdf. Because it depends on `baz@2.x`, it cannot -re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D], -and must install its own copy [C]. In order to minimize duplication, npm hoists -dependencies to the top level by default, so asdf is installed under [A]. +Bar [B] also has dependencies on baz and asdf. +Because it depends on `baz@2.x`, it cannot re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D], and must install its own copy [C]. +In order to minimize duplication, npm hoists dependencies to the top level by default, so asdf is installed under [A]. Underneath bar, the `baz -> quux -> bar` dependency creates a cycle. -However, because bar is already in quux's ancestry [B], it does not -unpack another copy of bar into that folder. Likewise, quux's [E] -folder tree is empty, because its dependency on bar is satisfied -by the parent folder copy installed at [B]. +However, because bar is already in quux's ancestry [B], it does not unpack another copy of bar into that folder. +Likewise, quux's [E] folder tree is empty, because its dependency on bar is satisfied by the parent folder copy installed at [B]. For a graphical breakdown of what is installed where, use `npm ls`. #### Publishing -Upon publishing, npm will look in the `node_modules` folder. If any of -the items there are not in the `bundleDependencies` array, then they will -not be included in the package tarball. +Upon publishing, npm will look in the `node_modules` folder. +If any of the items there are not in the `bundleDependencies` array, then they will not be included in the package tarball. -This allows a package maintainer to install all of their dependencies -(and dev dependencies) locally, but only re-publish those items that -cannot be found elsewhere. See [`package.json`](/configuring-npm/package-json) for more information. +This allows a package maintainer to install all of their dependencies (and dev dependencies) locally, but only re-publish those items that cannot be found elsewhere. +See [`package.json`](/configuring-npm/package-json) for more information. ### See also diff --git a/deps/npm/docs/content/configuring-npm/install.md b/deps/npm/docs/content/configuring-npm/install.md index cee846745f218a..1d7e7b80e6c223 100644 --- a/deps/npm/docs/content/configuring-npm/install.md +++ b/deps/npm/docs/content/configuring-npm/install.md @@ -6,27 +6,19 @@ description: Download and install node and npm ### Description -To publish and install packages to and from the public npm registry, you -must install Node.js and the npm command line interface using either a Node -version manager or a Node installer. **We strongly recommend using a Node -version manager to install Node.js and npm.** We do not recommend using a -Node installer, since the Node installation process installs npm in a -directory with local permissions and can cause permissions errors when you -run npm packages globally. +To publish and install packages to and from the public npm registry, you must install Node.js and the npm command line interface using either a Node version manager or a Node installer. +**We strongly recommend using a Node version manager to install Node.js and npm.** We do not recommend using a +Node installer, since the Node installation process installs npm in a directory with local permissions and can cause permissions errors when you run npm packages globally. ### Overview -- [Checking your version of npm and - Node.js](#checking-your-version-of-npm-and-nodejs) -- [Using a Node version manager to install Node.js and - npm](#using-a-node-version-manager-to-install-nodejs-and-npm) -- [Using a Node installer to install Node.js and - npm](#using-a-node-installer-to-install-nodejs-and-npm) +- [Checking your version of npm and Node.js](#checking-your-version-of-npm-and-nodejs) +- [Using a Node version manager to install Node.js and npm](#using-a-node-version-manager-to-install-nodejs-and-npm) +- [Using a Node installer to install Node.js and npm](#using-a-node-installer-to-install-nodejs-and-npm) ### Checking your version of npm and Node.js -To see if you already have Node.js and npm installed and check the -installed version, run the following commands: +To see if you already have Node.js and npm installed and check the installed version, run the following commands: ``` node -v @@ -35,37 +27,27 @@ npm -v ### Using a Node version manager to install Node.js and npm -Node version managers allow you to install and switch between multiple -versions of Node.js and npm on your system so you can test your -applications on multiple versions of npm to ensure they work for users on -different versions. You can -[search for them on GitHub](https://github.com/search?q=node+version+manager+archived%3Afalse&type=repositories&ref=advsearch). +Node version managers allow you to install and switch between multiple versions of Node.js and npm on your system so you can test your applications on multiple versions of npm to ensure they work for users on different versions. +You can [search for them on GitHub](https://github.com/search?q=node+version+manager+archived%3Afalse&type=repositories&ref=advsearch). ### Using a Node installer to install Node.js and npm -If you are unable to use a Node version manager, you can use a Node -installer to install both Node.js and npm on your system. +If you are unable to use a Node version manager, you can use a Node installer to install both Node.js and npm on your system. * [Node.js installer](https://nodejs.org/en/download/) -* [NodeSource installer](https://github.com/nodesource/distributions). If - you use Linux, we recommend that you use a NodeSource installer. +* [NodeSource installer](https://github.com/nodesource/distributions). +If you use Linux, we recommend that you use a NodeSource installer. #### macOS or Windows Node installers -If you're using macOS or Windows, use one of the installers from the -[Node.js download page](https://nodejs.org/en/download/). Be sure to -install the version labeled **LTS**. Other versions have not yet been -tested with npm. +If you're using macOS or Windows, use one of the installers from the [Node.js download page](https://nodejs.org/en/download/). +Be sure to install the version labeled **LTS**. Other versions have not yet been tested with npm. #### Linux or other operating systems Node installers -If you're using Linux or another operating system, use one of the following -installers: +If you're using Linux or another operating system, use one of the following installers: -- [NodeSource installer](https://github.com/nodesource/distributions) - (recommended) -- One of the installers on the [Node.js download - page](https://nodejs.org/en/download/) +- [NodeSource installer](https://github.com/nodesource/distributions) (recommended) +- One of the installers on the [Node.js download page](https://nodejs.org/en/download/) -Or see [this page](https://nodejs.org/en/download/package-manager/) to -install npm for Linux in the way many Linux developers prefer. +Or see [this page](https://nodejs.org/en/download/package-manager/) to install npm for Linux in the way many Linux developers prefer. diff --git a/deps/npm/docs/content/configuring-npm/npm-shrinkwrap-json.md b/deps/npm/docs/content/configuring-npm/npm-shrinkwrap-json.md index ab0a2410793809..4ea5e4dc20b1d0 100644 --- a/deps/npm/docs/content/configuring-npm/npm-shrinkwrap-json.md +++ b/deps/npm/docs/content/configuring-npm/npm-shrinkwrap-json.md @@ -6,25 +6,16 @@ description: A publishable lockfile ### Description -`npm-shrinkwrap.json` is a file created by [`npm -shrinkwrap`](/commands/npm-shrinkwrap). It is identical to -`package-lock.json`, with one major caveat: Unlike `package-lock.json`, +`npm-shrinkwrap.json` is a file created by [`npm shrinkwrap`](/commands/npm-shrinkwrap). +It is identical to `package-lock.json`, with one major caveat: Unlike `package-lock.json`, `npm-shrinkwrap.json` may be included when publishing a package. -The recommended use-case for `npm-shrinkwrap.json` is applications deployed -through the publishing process on the registry: for example, daemons and -command-line tools intended as global installs or `devDependencies`. It's -strongly discouraged for library authors to publish this file, since that -would prevent end users from having control over transitive dependency -updates. +The recommended use-case for `npm-shrinkwrap.json` is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs or `devDependencies`. +It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates. -If both `package-lock.json` and `npm-shrinkwrap.json` are present in a -package root, `npm-shrinkwrap.json` will be preferred over the -`package-lock.json` file. +If both `package-lock.json` and `npm-shrinkwrap.json` are present in a package root, `npm-shrinkwrap.json` will be preferred over the `package-lock.json` file. -For full details and description of the `npm-shrinkwrap.json` file format, -refer to the manual page for -[package-lock.json](/configuring-npm/package-lock-json). +For full details and description of the `npm-shrinkwrap.json` file format, refer to the manual page for [package-lock.json](/configuring-npm/package-lock-json). ### See also diff --git a/deps/npm/docs/content/configuring-npm/npmrc.md b/deps/npm/docs/content/configuring-npm/npmrc.md index eb1306e4c10033..41d7c5e462c518 100644 --- a/deps/npm/docs/content/configuring-npm/npmrc.md +++ b/deps/npm/docs/content/configuring-npm/npmrc.md @@ -6,14 +6,11 @@ description: The npm config files ### Description -npm gets its config settings from the command line, environment variables, -and `npmrc` files. +npm gets its config settings from the command line, environment variables, and `npmrc` files. -The `npm config` command can be used to update and edit the contents of the -user and global npmrc files. +The `npm config` command can be used to update and edit the contents of the user and global npmrc files. -For a list of available configuration options, see -[config](/using-npm/config). +For a list of available configuration options, see [config](/using-npm/config). ### Files @@ -25,21 +22,21 @@ The four relevant files are: * npm builtin config file (`/path/to/npm/npmrc`) All npm config files are an ini-formatted list of `key = value` parameters. -Environment variables can be replaced using `${VARIABLE_NAME}`. By default -if the variable is not defined, it is left unreplaced. By adding `?` after -variable name they can be forced to evaluate to an empty string instead. For -example: +Environment variables can be replaced using `${VARIABLE_NAME}`. +By default if the variable is not defined, it is left unreplaced. +By adding `?` after variable name they can be forced to evaluate to an empty string instead. +For example: ```bash cache = ${HOME}/.npm-packages node-options = "${NODE_OPTIONS?} --use-system-ca" ``` -Each of these files is loaded, and config options are resolved in priority -order. For example, a setting in the userconfig file would override the -setting in the globalconfig file. +Each of these files is loaded, and config options are resolved in priority order. +For example, a setting in the userconfig file would override the setting in the globalconfig file. -Array values are specified by adding "[]" after the key name. For example: +Array values are specified by adding "[]" after the key name. +For example: ```bash key[] = "first value" @@ -49,7 +46,8 @@ key[] = "second value" #### Comments Lines in `.npmrc` files are interpreted as comments when they begin with a -`;` or `#` character. `.npmrc` files are parsed by +`;` or `#` character. +`.npmrc` files are parsed by [npm/ini](https://github.com/npm/ini), which specifies this comment syntax. For example: @@ -62,43 +60,35 @@ For example: #### Per-project config file -When working locally in a project, a `.npmrc` file in the root of the -project (ie, a sibling of `node_modules` and `package.json`) will set -config values specific to this project. +When working locally in a project, a `.npmrc` file in the root of the project (ie, a sibling of `node_modules` and `package.json`) will set config values specific to this project. -Note that this only applies to the root of the project that you're running -npm in. It has no effect when your module is published. For example, you -can't publish a module that forces itself to install globally, or in a -different location. +Note that this only applies to the root of the project that you're running npm in. +It has no effect when your module is published. +For example, you can't publish a module that forces itself to install globally, or in a different location. -Additionally, this file is not read in global mode, such as when running -`npm install -g`. +Additionally, this file is not read in global mode, such as when running `npm install -g`. #### Per-user config file -`$HOME/.npmrc` (or the `userconfig` param, if set in the environment or on -the command line) +`$HOME/.npmrc` (or the `userconfig` param, if set in the environment or on the command line) #### Global config file -`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above): This file -is an ini-file formatted list of `key = value` parameters. Environment -variables can be replaced as above. +`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above): This file is an ini-file formatted list of `key = value` parameters. +Environment variables can be replaced as above. #### Built-in config file `path/to/npm/itself/npmrc` -This is an unchangeable "builtin" configuration file that npm keeps -consistent across updates. Set fields in here using the `./configure` -script that comes with npm. This is primarily for distribution maintainers -to override default configs in a standard and consistent manner. +This is an unchangeable "builtin" configuration file that npm keeps consistent across updates. +Set fields in here using the `./configure` script that comes with npm. +This is primarily for distribution maintainers to override default configs in a standard and consistent manner. ### Auth related configuration -The settings `_auth`, `_authToken`, `username`, `_password`, `certfile`, -and `keyfile` must all be scoped to a specific registry. This ensures that -`npm` will never send credentials to the wrong host. +The settings `_auth`, `_authToken`, `username`, `_password`, `certfile`, and `keyfile` must all be scoped to a specific registry. +This ensures that `npm` will never send credentials to the wrong host. The full list is: - `_auth` (base64 authentication string) @@ -111,9 +101,8 @@ The full list is: - `keyfile` (path to key file) In order to scope these values, they must be prefixed by a URI fragment. -If the credential is meant for any request to a registry on a single host, -the scope may look like `//registry.npmjs.org/:`. If it must be scoped to a -specific path on the host that path may also be provided, such as +If the credential is meant for any request to a registry on a single host, the scope may look like `//registry.npmjs.org/:`. +If it must be scoped to a specific path on the host that path may also be provided, such as `//my-custom-registry.org/unique/path:`. ``` diff --git a/deps/npm/docs/content/configuring-npm/package-json.md b/deps/npm/docs/content/configuring-npm/package-json.md index 568070b38dfce0..f06babf2911299 100644 --- a/deps/npm/docs/content/configuring-npm/package-json.md +++ b/deps/npm/docs/content/configuring-npm/package-json.md @@ -6,72 +6,64 @@ description: Specifics of npm's package.json handling ### Description -This document is all you need to know about what's required in your -package.json file. It must be actual JSON, not just a JavaScript object -literal. +This document is all you need to know about what's required in your package.json file. +It must be actual JSON, not just a JavaScript object literal. -A lot of the behavior described in this document is affected by the config -settings described in [`config`](/using-npm/config). +A lot of the behavior described in this document is affected by the config settings described in [`config`](/using-npm/config). ### name -If you plan to publish your package, the *most* important things in your -package.json are the name and version fields as they will be required. The -name and version together form an identifier that is assumed to be -completely unique. Changes to the package should come along with changes -to the version. If you don't plan to publish your package, the name and -version fields are optional. +If you plan to publish your package, the *most* important things in your package.json are the name and version fields as they will be required. +The name and version together form an identifier that is assumed to be completely unique. +Changes to the package should come along with changes to the version. +If you don't plan to publish your package, the name and version fields are optional. The name is what your thing is called. Some rules: -* The name must be less than or equal to 214 characters. This includes the - scope for scoped packages. -* The names of scoped packages can begin with a dot or an underscore. This - is not permitted without a scope. +* The name must be less than or equal to 214 characters. + This includes the scope for scoped packages. +* The names of scoped packages can begin with a dot or an underscore. + This is not permitted without a scope. * New packages must not have uppercase letters in the name. -* The name ends up being part of a URL, an argument on the command line, - and a folder name. Therefore, the name can't contain any non-URL-safe - characters. +* The name ends up being part of a URL, an argument on the command line, and a folder name. + Therefore, the name can't contain any non-URL-safe characters. Some tips: * Don't use the same name as a core Node module. -* Don't put "js" or "node" in the name. It's assumed that it's js, since - you're writing a package.json file, and you can specify the engine using - the "[engines](#engines)" field. (See below.) -* The name will probably be passed as an argument to require(), so it - should be something short, but also reasonably descriptive. -* You may want to check the npm registry to see if there's something by - that name already, before you get too attached to it. +* Don't put "js" or "node" in the name. + It's assumed that it's js, since you're writing a package.json file, and you can specify the engine using the "[engines](#engines)" field. + (See below.) +* The name will probably be passed as an argument to require(), so it should be something short, but also reasonably descriptive. +* You may want to check the npm registry to see if there's something by that name already, before you get too attached to it. -A name can be optionally prefixed by a scope, e.g. `@npm/example`. See -[`scope`](/using-npm/scope) for more detail. +A name can be optionally prefixed by a scope, e.g. `@npm/example`. +See [`scope`](/using-npm/scope) for more detail. ### version -If you plan to publish your package, the *most* important things in your -package.json are the name and version fields as they will be required. The -name and version together form an identifier that is assumed to be -completely unique. Changes to the package should come along with changes -to the version. If you don't plan to publish your package, the name and -version fields are optional. +If you plan to publish your package, the *most* important things in your package.json are the name and version fields as they will be required. +The name and version together form an identifier that is assumed to be completely unique. +Changes to the package should come along with changes to the version. +If you don't plan to publish your package, the name and version fields are optional. -Version must be parseable by -[node-semver](https://github.com/npm/node-semver), which is bundled with -npm as a dependency. (`npm install semver` to use it yourself.) +Version must be parseable by [node-semver](https://github.com/npm/node-semver), which is bundled with npm as a dependency. +(`npm install semver` to use it yourself.) ### description -Put a description in it. It's a string. This helps people discover your -package, as it's listed in `npm search`. +Put a description in it. +It's a string. +This helps people discover your package, as it's listed in `npm search`. ### keywords -Put keywords in it. It's an array of strings. This helps people discover -your package as it's listed in `npm search`. +Put keywords in it. +It's an array of strings. +This helps people discover your package as it's listed in `npm search`. ### homepage @@ -85,9 +77,8 @@ Example: ### bugs -The URL to your project's issue tracker and / or the email address to which -issues should be reported. These are helpful for people who encounter -issues with your package. +The URL to your project's issue tracker and / or the email address to which issues should be reported. +These are helpful for people who encounter issues with your package. It should look like this: @@ -100,19 +91,16 @@ It should look like this: } ``` -You can specify either one or both values. If you want to provide only a -URL, you can specify the value for "bugs" as a simple string instead of an -object. +You can specify either one or both values. +If you want to provide only a URL, you can specify the value for "bugs" as a simple string instead of an object. If a URL is provided, it will be used by the `npm bugs` command. ### license -You should specify a license for your package so that people know how they -are permitted to use it, and any restrictions you're placing on it. +You should specify a license for your package so that people know how they are permitted to use it, and any restrictions you're placing on it. -If you're using a common license such as BSD-2-Clause or MIT, add a current -SPDX license identifier for the license you're using, like this: +If you're using a common license such as BSD-2-Clause or MIT, add a current SPDX license identifier for the license you're using, like this: ```json { @@ -120,21 +108,17 @@ SPDX license identifier for the license you're using, like this: } ``` -You can check [the full list of SPDX license -IDs](https://spdx.org/licenses/). Ideally, you should pick one that is -[OSI](https://opensource.org/licenses/) approved. +You can check [the full list of SPDX license IDs](https://spdx.org/licenses/). +Ideally, you should pick one that is [OSI](https://opensource.org/licenses/) approved. -If your package is licensed under multiple common licenses, use an [SPDX -license expression syntax version 2.0 -string](https://spdx.dev/specifications/), like this: +If your package is licensed under multiple common licenses, use an [SPDX license expression syntax version 2.0 string](https://spdx.dev/specifications/), like this: ```json { "license" : "(ISC OR GPL-3.0)" } ``` -If you are using a license that hasn't been assigned an SPDX identifier, or if -you are using a custom license, use a string value like this one: +If you are using a license that hasn't been assigned an SPDX identifier, or if you are using a custom license, use a string value like this one: ```json { @@ -143,8 +127,7 @@ you are using a custom license, use a string value like this one: ``` Then include a file named `` at the top level of the package. -Some old packages used license objects or a "licenses" property containing -an array of license objects: +Some old packages used license objects or a "licenses" property containing an array of license objects: ```json // Not valid metadata @@ -170,7 +153,8 @@ an array of license objects: } ``` -Those styles are now deprecated. Instead, use SPDX expressions, like this: +Those styles are now deprecated. +Instead, use SPDX expressions, like this: ```json { @@ -184,8 +168,7 @@ Those styles are now deprecated. Instead, use SPDX expressions, like this: } ``` -Finally, if you do not wish to grant others the right to use a private or -unpublished package under any terms: +Finally, if you do not wish to grant others the right to use a private or unpublished package under any terms: ```json { @@ -197,9 +180,9 @@ Consider also setting `"private": true` to prevent accidental publication. ### people fields: author, contributors -The "author" is one person. "contributors" is an array of people. A -"person" is an object with a "name" field and optionally "url" and "email", -like this: +The "author" is one person. +"contributors" is an array of people. +A "person" is an object with a "name" field and optionally "url" and "email", like this: ```json { @@ -209,8 +192,7 @@ like this: } ``` -Or you can shorten that all into a single string, and npm will parse it for -you: +Or you can shorten that all into a single string, and npm will parse it for you: ```json { @@ -224,9 +206,7 @@ npm also sets a top-level "maintainers" field with your npm user info. ### funding -You can specify an object containing a URL that provides up-to-date -information about ways to help fund development of your package, a -string URL, or an array of objects and string URLs: +You can specify an object containing a URL that provides up-to-date information about ways to help fund development of your package, a string URL, or an array of objects and string URLs: ```json { @@ -268,30 +248,22 @@ string URL, or an array of objects and string URLs: } ``` -Users can use the `npm fund` subcommand to list the `funding` URLs of all -dependencies of their project, direct and indirect. A shortcut to visit -each funding URL is also available when providing the project name such as: -`npm fund ` (when there are multiple URLs, the first one will -be visited) +Users can use the `npm fund` subcommand to list the `funding` URLs of all dependencies of their project, direct and indirect. +A shortcut to visit each funding URL is also available when providing the project name such as: +`npm fund ` (when there are multiple URLs, the first one will be visited) ### files -The optional `files` field is an array of file patterns that describes the -entries to be included when your package is installed as a dependency. File -patterns follow a similar syntax to `.gitignore`, but reversed: including a -file, directory, or glob pattern (`*`, `**/*`, and such) will make it so -that file is included in the tarball when it's packed. Omitting the field -will make it default to `["*"]`, which means it will include all files. +The optional `files` field is an array of file patterns that describes the entries to be included when your package is installed as a dependency. +File patterns follow a similar syntax to `.gitignore`, but reversed: including a file, directory, or glob pattern (`*`, `**/*`, and such) will make it so that file is included in the tarball when it's packed. +Omitting the field will make it default to `["*"]`, which means it will include all files. -Some special files and directories are also included or excluded regardless -of whether they exist in the `files` array (see below). +Some special files and directories are also included or excluded regardless of whether they exist in the `files` array (see below). -You can also provide a `.npmignore` file in the root of your package or in -subdirectories, which will keep files from being included. At the root of -your package it will not override the "files" field, but in subdirectories -it will. The `.npmignore` file works just like a `.gitignore`. If there is -a `.gitignore` file, and `.npmignore` is missing, `.gitignore`'s contents -will be used instead. +You can also provide a `.npmignore` file in the root of your package or in subdirectories, which will keep files from being included. +At the root of your package it will not override the "files" field, but in subdirectories it will. +The `.npmignore` file works just like a `.gitignore`. +If there is a `.gitignore` file, and `.npmignore` is missing, `.gitignore`'s contents will be used instead. Certain files are always included, regardless of settings: @@ -319,15 +291,13 @@ Some files are always ignored by default: * `config.gypi` * `node_modules` * `npm-debug.log` -* `package-lock.json` (use - [`npm-shrinkwrap.json`](/configuring-npm/npm-shrinkwrap-json) - if you wish it to be published) +* `package-lock.json` (use [`npm-shrinkwrap.json`](/configuring-npm/npm-shrinkwrap-json) if you wish it to be published) * `pnpm-lock.yaml` * `yarn.lock` * `bun.lockb` -Most of these ignored files can be included specifically if included in -the `files` globs. Exceptions to this are: +Most of these ignored files can be included specifically if included in the `files` globs. +Exceptions to this are: * `.git` * `.npmrc` @@ -337,48 +307,37 @@ the `files` globs. Exceptions to this are: * `yarn.lock` * `bun.lockb` -These can not be included. +These cannot be included. ### exports -The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package. For more details see the [node.js documentation on package entry points](https://nodejs.org/api/packages.html#package-entry-points) +The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package. +For more details see the [node.js documentation on package entry points](https://nodejs.org/api/packages.html#package-entry-points) ### main -The main field is a module ID that is the primary entry point to your -program. That is, if your package is named `foo`, and a user installs it, -and then does `require("foo")`, then your main module's exports object will -be returned. +The main field is a module ID that is the primary entry point to your program. +That is, if your package is named `foo`, and a user installs it, and then does `require("foo")`, then your main module's exports object will be returned. This should be a module relative to the root of your package folder. -For most modules, it makes the most sense to have a main script and often -not much else. +For most modules, it makes the most sense to have a main script and often not much else. If `main` is not set, it defaults to `index.js` in the package's root folder. ### browser -If your module is meant to be used client-side the browser field should be -used instead of the main field. This is helpful to hint users that it might -rely on primitives that aren't available in Node.js modules. (e.g. -`window`) +If your module is meant to be used client-side the browser field should be used instead of the main field. +This is helpful to hint users that it might rely on primitives that aren't available in Node.js modules. +(e.g. `window`) ### bin -A lot of packages have one or more executable files that they'd like to -install into the PATH. npm makes this pretty easy (in fact, it uses this -feature to install the "npm" executable.) +A lot of packages have one or more executable files that they'd like to install into the PATH. npm makes this pretty easy (in fact, it uses this feature to install the "npm" executable.) -To use this, supply a `bin` field in your package.json which is a map of -command name to local file name. When this package is installed globally, -that file will be either linked inside the global bins directory or -a cmd (Windows Command File) will be created which executes the specified -file in the `bin` field, so it is available to run by `name` or `name.cmd` (on -Windows PowerShell). When this package is installed as a dependency in another -package, the file will be linked where it will be available to that package -either directly by `npm exec` or by name in other scripts when invoking them -via `npm run`. +To use this, supply a `bin` field in your package.json which is a map of command name to local file name. +When this package is installed globally, that file will be either linked inside the global bins directory or a cmd (Windows Command File) will be created which executes the specified file in the `bin` field, so it is available to run by `name` or `name.cmd` (on Windows PowerShell). +When this package is installed as a dependency in another package, the file will be linked where it will be available to that package either directly by `npm exec` or by name in other scripts when invoking them via `npm run`. For example, myapp could have this: @@ -391,13 +350,10 @@ For example, myapp could have this: } ``` -So, when you install myapp, in case of unix-like OS it'll create a symlink -from the `cli.js` script to `/usr/local/bin/myapp` and in case of windows it -will create a cmd file usually at `C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd` -which runs the `cli.js` script. +So, when you install myapp, in case of unix-like OS it'll create a symlink from the `cli.js` script to `/usr/local/bin/myapp` and in case of windows it will create a cmd file usually at `C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd` which runs the `cli.js` script. -If you have a single executable, and its name should be the name of the -package, then you can just supply it as a string. For example: +If you have a single executable, and its name should be the name of the package, then you can just supply it as a string. +For example: ```json { @@ -419,23 +375,18 @@ would be the same as this: } ``` -Please make sure that your file(s) referenced in `bin` starts with -`#!/usr/bin/env node`, otherwise the scripts are started without the node -executable! +Please make sure that your file(s) referenced in `bin` starts with `#!/usr/bin/env node`; otherwise, the scripts are started without the node executable! Note that you can also set the executable files using [directories.bin](#directoriesbin). -See [folders](/configuring-npm/folders#executables) for more info on -executables. +See [folders](/configuring-npm/folders#executables) for more info on executables. ### man -Specify either a single file or an array of filenames to put in place for -the `man` program to find. +Specify either a single file or an array of filenames to put in place for the `man` program to find. -If only a single file is provided, then it's installed such that it is the -result from `man `, regardless of its actual filename. For -example: +If only a single file is provided, then it's installed such that it is the result from `man `, regardless of its actual filename. +For example: ```json { @@ -447,8 +398,7 @@ example: } ``` -would link the `./man/doc.1` file in such that it is the target for `man -foo` +would link the `./man/doc.1` file in such that it is the target for `man foo` If the filename doesn't start with the package name, then it's prefixed. So, this: @@ -468,9 +418,8 @@ So, this: will create files to do `man foo` and `man foo-bar`. -Man files must end with a number, and optionally a `.gz` suffix if they are -compressed. The number dictates which man section the file is installed -into. +Man files must end with a number, and optionally a `.gz` suffix if they are compressed. +The number dictates which man section the file is installed into. ```json { @@ -489,34 +438,28 @@ will create entries for `man foo` and `man 2 foo` ### directories -The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec -details a few ways that you can indicate the structure of your package -using a `directories` object. If you look at [npm's -package.json](https://registry.npmjs.org/npm/latest), you'll see that it -has directories for doc, lib, and man. +The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec details a few ways that you can indicate the structure of your package using a `directories` object. +If you look at [npm's package.json](https://registry.npmjs.org/npm/latest), you'll see that it has directories for doc, lib, and man. In the future, this information may be used in other creative ways. #### directories.bin -If you specify a `bin` directory in `directories.bin`, all the files in -that folder will be added. +If you specify a `bin` directory in `directories.bin`, all the files in that folder will be added. -Because of the way the `bin` directive works, specifying both a `bin` path -and setting `directories.bin` is an error. If you want to specify -individual files, use `bin`, and for all the files in an existing `bin` -directory, use `directories.bin`. +Because of the way the `bin` directive works, specifying both a `bin` path and setting `directories.bin` is an error. +If you want to specify individual files, use `bin`, and for all the files in an existing `bin` directory, use `directories.bin`. #### directories.man -A folder that is full of man pages. Sugar to generate a "man" array by -walking the folder. +A folder that is full of man pages. +Sugar to generate a "man" array by walking the folder. ### repository -Specify the place where your code lives. This is helpful for people who -want to contribute. If the git repo is on GitHub, then the `npm repo` -command will be able to find you. +Specify the place where your code lives. +This is helpful for people who want to contribute. +If the git repo is on GitHub, then the `npm repo` command will be able to find you. Do it like this: @@ -529,13 +472,11 @@ Do it like this: } ``` -The URL should be a publicly available (perhaps read-only) URL that can be -handed directly to a VCS program without any modification. It should not -be a URL to an html project page that you put in your browser. It's for -computers. +The URL should be a publicly available (perhaps read-only) URL that can be handed directly to a VCS program without any modification. +It should not be a URL to an html project page that you put in your browser. +It's for computers. -For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the -same shortcut syntax you use for `npm install`: +For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same shortcut syntax you use for `npm install`: ```json { @@ -551,9 +492,7 @@ same shortcut syntax you use for `npm install`: } ``` -If the `package.json` for your package is not in the root directory (for -example if it is part of a monorepo), you can specify the directory in -which it lives: +If the `package.json` for your package is not in the root directory (for example if it is part of a monorepo), you can specify the directory in which it lives: ```json { @@ -567,18 +506,15 @@ which it lives: ### scripts -The "scripts" property is a dictionary containing script commands that are -run at various times in the lifecycle of your package. The key is the -lifecycle event, and the value is the command to run at that point. +The "scripts" property is a dictionary containing script commands that are run at various times in the lifecycle of your package. +The key is the lifecycle event, and the value is the command to run at that point. -See [`scripts`](/using-npm/scripts) to find out more about writing package -scripts. +See [`scripts`](/using-npm/scripts) to find out more about writing package scripts. ### config -A "config" object can be used to set configuration parameters used in -package scripts that persist across upgrades. For instance, if a package -had the following: +A "config" object can be used to set configuration parameters used in package scripts that persist across upgrades. +For instance, if a package had the following: ```json { @@ -589,18 +525,16 @@ had the following: } ``` -It could also have a "start" script that referenced the -`npm_package_config_port` environment variable. +It could also have a "start" script that referenced the `npm_package_config_port` environment variable. ### dependencies -Dependencies are specified in a simple object that maps a package name to a -version range. The version range is a string which has one or more -space-separated descriptors. Dependencies can also be identified with a -tarball or git URL. +Dependencies are specified in a simple object that maps a package name to a version range. +The version range is a string which has one or more space-separated descriptors. +Dependencies can also be identified with a tarball or git URL. -**Please do not put test harnesses or transpilers or other "development" -time tools in your `dependencies` object.** See `devDependencies`, below. +**Please do not put test harnesses or transpilers or other "development" time tools in your `dependencies` object.** +See `devDependencies`, below. See [semver](https://github.com/npm/node-semver#versions) for more details about specifying version ranges. @@ -609,8 +543,7 @@ See [semver](https://github.com/npm/node-semver#versions) for more details about * `>=version` etc * `://[[:]@][:][:][/][# | #semver:] ``` -`` is one of `git`, `git+ssh`, `git+http`, `git+https`, or -`git+file`. +`` is one of `git`, `git+ssh`, `git+http`, `git+https`, or `git+file`. -If `#` is provided, it will be used to clone exactly that -commit. If the commit-ish has the format `#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 `#` or `#semver:` is -specified, then the default branch is used. +If `#` is provided, it will be used to clone exactly that commit. +If the commit-ish has the format `#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 `#` or `#semver:` is specified, then the default branch is used. Examples: @@ -681,14 +608,10 @@ git+https://isaacs@github.com/npm/cli.git git://github.com/npm/cli.git#v1.0.27 ``` -When installing from a `git` repository, the presence of certain fields in the -`package.json` will cause npm to believe it needs to perform a build. To do so -your repository will be cloned into a temporary directory, all of its deps -installed, relevant scripts run, and the resulting directory packed and -installed. +When installing from a `git` repository, the presence of certain fields in the `package.json` will cause npm to believe it needs to perform a build. +To do so your repository will be cloned into a temporary directory, all of its deps installed, relevant scripts run, and the resulting directory packed and installed. -This flow will occur if your git dependency uses `workspaces`, or if any of the -following scripts are present: +This flow will occur if your git dependency uses `workspaces`, or if any of the following scripts are present: * `build` * `prepare` @@ -697,15 +620,13 @@ following scripts are present: * `install` * `postinstall` -If your git repository includes pre-built artifacts, you will likely want to -make sure that none of the above scripts are defined, or your dependency -will be rebuilt for every installation. +If your git repository includes pre-built artifacts, you will likely want to make sure that none of the above scripts are defined, or your dependency will be rebuilt for every installation. #### GitHub URLs As of version 1.1.65, you can refer to GitHub URLs as just "foo": -"user/foo-project". Just as with git URLs, a `commit-ish` suffix can be -included. For example: +"user/foo-project". Just as with git URLs, a `commit-ish` suffix can be included. +For example: ```json { @@ -721,9 +642,8 @@ included. For example: #### Local Paths -As of version 2.0.0 you can provide a path to a local directory that -contains a package. Local paths can be saved using `npm install -S` or `npm -install --save`, using any of these forms: +As of version 2.0.0 you can provide a path to a local directory that contains a package. +Local paths can be saved using `npm install -S` or `npm install --save`, using any of these forms: ```bash ../foo/bar @@ -732,8 +652,8 @@ install --save`, using any of these forms: /foo/bar ``` -in which case they will be normalized to a relative path and added to your -`package.json`. For example: +in which case they will be normalized to a relative path and added to your `package.json`. +For example: ```json { @@ -744,30 +664,21 @@ in which case they will be normalized to a relative path and added to your } ``` -This feature is helpful for local offline development and creating tests -that require npm installing where you don't want to hit an external server, -but should not be used when publishing your package to the public registry. +This feature is helpful for local offline development and creating tests that require npm installing where you don't want to hit an external server, but should not be used when publishing your package to the public registry. -*note*: Packages linked by local path will not have their own -dependencies installed when `npm install` is run. You must -run `npm install` from inside the local path itself. +*note*: Packages linked by local path will not have their own dependencies installed when `npm install` is run. +You must run `npm install` from inside the local path itself. ### devDependencies -If someone is planning on downloading and using your module in their -program, then they probably don't want or need to download and build the -external test or documentation framework that you use. +If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use. -In this case, it's best to map these additional items in a -`devDependencies` object. +In this case, it's best to map these additional items in a `devDependencies` object. -These things will be installed when doing `npm link` or `npm install` from -the root of a package, and can be managed like any other npm configuration -param. See [`config`](/using-npm/config) for more on the topic. +These things will be installed when doing `npm link` or `npm install` from the root of a package, and can be managed like any other npm configuration param. +See [`config`](/using-npm/config) for more on the topic. -For build steps that are not platform-specific, such as compiling -CoffeeScript or other languages to JavaScript, use the `prepare` script to -do this, and make the required package a devDependency. +For build steps that are not platform-specific, such as compiling CoffeeScript or other languages to JavaScript, use the `prepare` script to do this, and make the required package a devDependency. For example: @@ -786,18 +697,13 @@ For example: } ``` -The `prepare` script will be run before publishing, so that users can -consume the functionality without requiring them to compile it themselves. -In dev mode (ie, locally running `npm install`), it'll run this script as -well, so that you can test it easily. +The `prepare` script will be run before publishing, so that users can consume the functionality without requiring them to compile it themselves. +In dev mode (ie, locally running `npm install`), it'll run this script as well, so that you can test it easily. ### peerDependencies -In some cases, you want to express the compatibility of your package with a -host tool or library, while not necessarily doing a `require` of this host. -This is usually referred to as a *plugin*. Notably, your module may be -exposing a specific interface, expected and specified by the host -documentation. +In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a `require` of this host. +This is usually referred to as a *plugin*. Notably, your module may be exposing a specific interface, expected and specified by the host documentation. For example: @@ -811,39 +717,30 @@ For example: } ``` -This ensures your package `@npm/tea-latte` can be installed *along* with the -second major version of the host package `@npm/tea` only. `npm install -tea-latte` could possibly yield the following dependency graph: +This ensures your package `@npm/tea-latte` can be installed *along* with the second major version of the host package `@npm/tea` only. +`npm install tea-latte` could possibly yield the following dependency graph: ```bash ├── @npm/tea-latte@1.3.5 └── @npm/tea@2.2.0 ``` -In npm versions 3 through 6, `peerDependencies` were not automatically -installed, and would raise a warning if an invalid version of the peer -dependency was found in the tree. As of npm v7, peerDependencies _are_ -installed by default. +In npm versions 3 through 6, `peerDependencies` were not automatically installed, and would raise a warning if an invalid version of the peer dependency was found in the tree. +As of npm v7, peerDependencies _are_ installed by default. -Trying to install another plugin with a conflicting requirement may cause -an error if the tree cannot be resolved correctly. For this reason, make -sure your plugin requirement is as broad as possible, and not to lock it -down to specific patch versions. +Trying to install another plugin with a conflicting requirement may cause an error if the tree cannot be resolved correctly. +For this reason, make sure your plugin requirement is as broad as possible, and not to lock it down to specific patch versions. -Assuming the host complies with [semver](https://semver.org/), only changes -in the host package's major version will break your plugin. Thus, if you've -worked with every 1.x version of the host package, use `"^1.0"` or `"1.x"` -to express this. If you depend on features introduced in 1.5.2, use -`"^1.5.2"`. +Assuming the host complies with [semver](https://semver.org/), only changes in the host package's major version will break your plugin. +Thus, if you've worked with every 1.x version of the host package, use `"^1.0"` or `"1.x"` to express this. +If you depend on features introduced in 1.5.2, use `"^1.5.2"`. ### peerDependenciesMeta -The `peerDependenciesMeta` field serves to provide npm more information on how -your peer dependencies are to be used. Specifically, it allows peer -dependencies to be marked as optional. Npm will not automatically install -optional peer dependencies. This allows you to -integrate and interact with a variety of host packages without requiring -all of them to be installed. +The `peerDependenciesMeta` field serves to provide npm more information on how your peer dependencies are to be used. +Specifically, it allows peer dependencies to be marked as optional. +Npm will not automatically install optional peer dependencies. +This allows you to integrate and interact with a variety of host packages without requiring all of them to be installed. For example: @@ -865,13 +762,9 @@ For example: ### bundleDependencies -This defines an array of package names that will be bundled when publishing -the package. +This defines an array of package names that will be bundled when publishing the package. -In cases where you need to preserve npm packages locally or have them -available through a single file download, you can bundle the packages in a -tarball file by specifying the package names in the `bundleDependencies` -array and executing `npm pack`. +In cases where you need to preserve npm packages locally or have them available through a single file download, you can bundle the packages in a tarball file by specifying the package names in the `bundleDependencies` array and executing `npm pack`. For example: @@ -889,28 +782,23 @@ If we define a package.json like this: ``` we can obtain `@npm/awesome-web-framework-1.0.0.tgz` file by running `npm pack`. -This file contains the dependencies `@npm/renderized` and `@npm/super-streams` which -can be installed in a new project by executing `npm install -awesome-web-framework-1.0.0.tgz`. Note that the package names do not -include any versions, as that information is specified in `dependencies`. +This file contains the dependencies `@npm/renderized` and `@npm/super-streams` which can be installed in a new project by executing `npm install awesome-web-framework-1.0.0.tgz`. +Note that the package names do not include any versions, as that information is specified in `dependencies`. If this is spelled `"bundledDependencies"`, then that is also honored. -Alternatively, `"bundleDependencies"` can be defined as a boolean value. A -value of `true` will bundle all dependencies, a value of `false` will bundle -none. +Alternatively, `"bundleDependencies"` can be defined as a boolean value. +A value of `true` will bundle all dependencies, a value of `false` will bundle none. ### optionalDependencies -If a dependency can be used, but you would like npm to proceed if it cannot -be found or fails to install, then you may put it in the -`optionalDependencies` object. This is a map of package name to version or -URL, just like the `dependencies` object. The difference is that build -failures do not cause installation to fail. Running `npm install ---omit=optional` will prevent these dependencies from being installed. +If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the `optionalDependencies` object. +This is a map of package name to version or URL, just like the `dependencies` object. +The difference is that build failures do not cause installation to fail. +Running `npm install --omit=optional` will prevent these dependencies from being installed. -It is still your program's responsibility to handle the lack of the -dependency. For example, something like this: +It is still your program's responsibility to handle the lack of the dependency. +For example, something like this: ```js try { @@ -930,29 +818,20 @@ if (foo) { } ``` -Entries in `optionalDependencies` will override entries of the same name in -`dependencies`, so it's usually best to only put in one place. +Entries in `optionalDependencies` will override entries of the same name in `dependencies`, so it's usually best to only put in one place. ### overrides -If you need to make specific changes to dependencies of your dependencies, for -example replacing the version of a dependency with a known security issue, -replacing an existing dependency with a fork, or making sure that the same -version of a package is used everywhere, then you may add an override. +If you need to make specific changes to dependencies of your dependencies, for example replacing the version of a dependency with a known security issue, replacing an existing dependency with a fork, or making sure that the same version of a package is used everywhere, then you may add an override. -Overrides provide a way to replace a package in your dependency tree with -another version, or another package entirely. These changes can be scoped as -specific or as vague as desired. +Overrides provide a way to replace a package in your dependency tree with another version, or another package entirely. +These changes can be scoped as specific or as vague as desired. Overrides are only considered in the root `package.json` file for a project. -Overrides in installed dependencies (including -[workspaces](/using-npm/workspaces)) are not considered in dependency tree -resolution. Published packages may dictate their resolutions by pinning -dependencies or using an -[`npm-shrinkwrap.json`](/configuring-npm/npm-shrinkwrap-json) file. +Overrides in installed dependencies (including [workspaces](/using-npm/workspaces)) are not considered in dependency tree resolution. +Published packages may dictate their resolutions by pinning dependencies or using an [`npm-shrinkwrap.json`](/configuring-npm/npm-shrinkwrap-json) file. -To make sure the package `@npm/foo` is always installed as version `1.0.0` no matter -what version your dependencies rely on: +To make sure the package `@npm/foo` is always installed as version `1.0.0` no matter what version your dependencies rely on: ```json { @@ -962,10 +841,8 @@ what version your dependencies rely on: } ``` -The above is a short hand notation, the full object form can be used to allow -overriding a package itself as well as a child of the package. This will cause -`@npm/foo` to always be `1.0.0` while also making `@npm/bar` at any depth beyond `@npm/foo` -also `1.0.0`: +The above is a short hand notation, the full object form can be used to allow overriding a package itself as well as a child of the package. +This will cause `@npm/foo` to always be `1.0.0` while also making `@npm/bar` at any depth beyond `@npm/foo` also `1.0.0`: ```json { @@ -978,8 +855,7 @@ also `1.0.0`: } ``` -To only override `@npm/foo` to be `1.0.0` when it's a child (or grandchild, or great -grandchild, etc) of the package `@npm/bar`: +To only override `@npm/foo` to be `1.0.0` when it's a child (or grandchild, or great grandchild, etc) of the package `@npm/bar`: ```json { @@ -991,8 +867,8 @@ grandchild, etc) of the package `@npm/bar`: } ``` -Keys can be nested to any arbitrary length. To override `@npm/foo` only when it's a -child of `@npm/bar` and only when `@npm/bar` is a child of `@npm/baz`: +Keys can be nested to any arbitrary length. +To override `@npm/foo` only when it's a child of `@npm/bar` and only when `@npm/bar` is a child of `@npm/baz`: ```json { @@ -1019,11 +895,8 @@ To override `@npm/foo` to `1.0.0`, but only when it's a child of `@npm/bar@2.0.0 } ``` -You may not set an override for a package that you directly depend on unless -both the dependency and the override itself share the exact same spec. To make -this limitation easier to deal with, overrides may also be defined as a -reference to a spec for a direct dependency by prefixing the name of the -package you wish the version to match with a `$`. +You may not set an override for a package that you directly depend on unless both the dependency and the override itself share the exact same spec. +To make this limitation easier to deal with, overrides may also be defined as a reference to a spec for a direct dependency by prefixing the name of the package you wish the version to match with a `$`. ```json { @@ -1055,11 +928,10 @@ You can specify the version of node that your stuff works on: } ``` -And, like with dependencies, if you don't specify the version (or if you -specify "\*" as the version), then any version of node will do. +And, like with dependencies, if you don't specify the version (or if you specify "\*" as the version), then any version of node will do. -You can also use the "engines" field to specify which versions of npm are -capable of properly installing your program. For example: +You can also use the "engines" field to specify which versions of npm are capable of properly installing your program. +For example: ```json { @@ -1069,15 +941,11 @@ capable of properly installing your program. For example: } ``` -Unless the user has set the -[`engine-strict` config](/using-npm/config#engine-strict) flag, this field is -advisory only and will only produce warnings when your package is installed as a -dependency. +Unless the user has set the [`engine-strict` config](/using-npm/config#engine-strict) flag, this field is advisory only and will only produce warnings when your package is installed as a dependency. ### os -You can specify which operating systems your -module will run on: +You can specify which operating systems your module will run on: ```json { @@ -1088,8 +956,7 @@ module will run on: } ``` -You can also block instead of allowing operating systems, just prepend the -blocked os with a '!': +You can also block instead of allowing operating systems, just prepend the blocked os with a '!': ```json { @@ -1101,13 +968,11 @@ blocked os with a '!': The host operating system is determined by `process.platform` -It is allowed to both block and allow an item, although there isn't any -good reason to do this. +It is allowed to both block and allow an item, although there isn't any good reason to do this. ### cpu -If your code only runs on certain cpu architectures, -you can specify which ones. +If your code only runs on certain cpu architectures, you can specify which ones. ```json { @@ -1133,8 +998,8 @@ The host architecture is determined by `process.arch` ### libc -If your code only runs or builds in certain versions of libc, you can -specify which ones. This field only applies if `os` is `linux`. +If your code only runs or builds in certain versions of libc, you can specify which ones. +This field only applies if `os` is `linux`. ```json { @@ -1149,10 +1014,18 @@ The `devEngines` field aids engineers working on a codebase to all be using the You can specify a `devEngines` property in your `package.json` which will run before `install`, `ci`, and `run` commands. -> Note: `engines` and `devEngines` differ in object shape. They also function very differently. `engines` is designed to alert the user when a dependency uses a differening npm or node version that the project it's being used in, whereas `devEngines` is used to alert people interacting with the source code of a project. -The supported keys under the `devEngines` property are `cpu`, `os`, `libc`, `runtime`, and `packageManager`. Each property can be an object or an array of objects. Objects must contain `name`, and optionally can specify `version`, and `onFail`. `onFail` can be `warn`, `error`, or `ignore`, and if left undefined is of the same value as `error`. `npm` will assume that you're running with `node`. -Here's an example of a project that will fail if the environment is not `node` and `npm`. If you set `runtime.name` or `packageManager.name` to any other string, it will fail within the npm CLI. +> Note: `engines` and `devEngines` differ in object shape. +They also function very differently. +`engines` is designed to alert the user when a dependency uses a different npm or node version than the project it's being used in, whereas `devEngines` is used to alert people interacting with the source code of a project. + +The supported keys under the `devEngines` property are `cpu`, `os`, `libc`, `runtime`, and `packageManager`. +Each property can be an object or an array of objects. +Objects must contain `name`, and optionally can specify `version`, and `onFail`. +`onFail` can be `warn`, `error`, or `ignore`, and if left undefined is of the same value as `error`. +`npm` will assume that you're running with `node`. +Here's an example of a project that will fail if the environment is not `node` and `npm`. +If you set `runtime.name` or `packageManager.name` to any other string, it will fail within the npm CLI. ```json { @@ -1171,39 +1044,25 @@ Here's an example of a project that will fail if the environment is not `node` a ### private -If you set `"private": true` in your package.json, then npm will refuse to -publish it. +If you set `"private": true` in your package.json, then npm will refuse to publish it. This is a way to prevent accidental publication of private repositories. -If you would like to ensure that a given package is only ever published to -a specific registry (for example, an internal registry), then use the -`publishConfig` dictionary described below to override the `registry` -config param at publish-time. +If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the `publishConfig` dictionary described below to override the `registry` config param at publish-time. ### publishConfig -This is a set of config values that will be used at publish-time. It's -especially handy if you want to set the tag, registry or access, so that -you can ensure that a given package is not tagged with "latest", published -to the global public registry or that a scoped module is private by -default. +This is a set of config values that will be used at publish-time. +It's especially handy if you want to set the tag, registry or access, so that you can ensure that a given package is not tagged with "latest", published to the global public registry or that a scoped module is private by default. -See [`config`](/using-npm/config) to see the list of config options that -can be overridden. +See [`config`](/using-npm/config) to see the list of config options that can be overridden. ### workspaces -The optional `workspaces` field is an array of file patterns that describes -locations within the local file system that the install client should look -up to find each [workspace](/using-npm/workspaces) that needs to be -symlinked to the top level `node_modules` folder. +The optional `workspaces` field is an array of file patterns that describes locations within the local file system that the install client should look up to find each [workspace](/using-npm/workspaces) that needs to be symlinked to the top level `node_modules` folder. -It can describe either the direct paths of the folders to be used as -workspaces or it can define globs that will resolve to these same folders. +It can describe either the direct paths of the folders to be used as workspaces or it can define globs that will resolve to these same folders. -In the following example, all folders located inside the folder -`./packages` will be treated as workspaces as long as they have valid -`package.json` files inside them: +In the following example, all folders located inside the folder `./packages` will be treated as workspaces as long as they have valid `package.json` files inside them: ```json { @@ -1222,20 +1081,16 @@ npm will default some values based on package contents. * `"scripts": {"start": "node server.js"}` - If there is a `server.js` file in the root of your package, then npm will - default the `start` command to `node server.js`. + If there is a `server.js` file in the root of your package, then npm will default the `start` command to `node server.js`. * `"scripts":{"install": "node-gyp rebuild"}` - If there is a `binding.gyp` file in the root of your package and you have - not defined an `install` or `preinstall` script, npm will default the - `install` command to compile using node-gyp. + If there is a `binding.gyp` file in the root of your package and you have not defined an `install` or `preinstall` script, npm will default the `install` command to compile using node-gyp. * `"contributors": [...]` - If there is an `AUTHORS` file in the root of your package, npm will treat - each line as a `Name (url)` format, where email and url are - optional. Lines which start with a `#` or are blank, will be ignored. + If there is an `AUTHORS` file in the root of your package, npm will treat each line as a `Name (url)` format, where email and url are optional. + Lines which start with a `#` or are blank, will be ignored. ### SEE ALSO diff --git a/deps/npm/docs/content/configuring-npm/package-lock-json.md b/deps/npm/docs/content/configuring-npm/package-lock-json.md index f3b012175fa0ec..579dd49807812f 100644 --- a/deps/npm/docs/content/configuring-npm/package-lock-json.md +++ b/deps/npm/docs/content/configuring-npm/package-lock-json.md @@ -6,228 +6,164 @@ description: A manifestation of the manifest ### Description -`package-lock.json` is automatically generated for any operations where npm -modifies either the `node_modules` tree, or `package.json`. It describes the -exact tree that was generated, such that subsequent installs are able to -generate identical trees, regardless of intermediate dependency updates. +`package-lock.json` is automatically generated for any operations where npm modifies either the `node_modules` tree, or `package.json`. +It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates. -This file is intended to be committed into source repositories, and serves -various purposes: +This file is intended to be committed into source repositories, and serves various purposes: -* Describe a single representation of a dependency tree such that - teammates, deployments, and continuous integration are guaranteed to - install exactly the same dependencies. +* Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies. -* Provide a facility for users to "time-travel" to previous states of - `node_modules` without having to commit the directory itself. +* Provide a facility for users to "time-travel" to previous states of `node_modules` without having to commit the directory itself. -* Facilitate greater visibility of tree changes through readable source - control diffs. +* Facilitate greater visibility of tree changes through readable source control diffs. -* Optimize the installation process by allowing npm to skip repeated - metadata resolutions for previously-installed packages. +* Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages. -* As of npm v7, lockfiles include enough information to gain a complete - picture of the package tree, reducing the need to read `package.json` - files, and allowing for significant performance improvements. +* As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read `package.json` files, and allowing for significant performance improvements. When `npm` creates or updates `package-lock.json`, it will infer line endings and indentation from `package.json` so that the formatting of both files matches. ### `package-lock.json` vs `npm-shrinkwrap.json` -Both of these files have the same format, and perform similar functions in -the root of a project. +Both of these files have the same format, and perform similar functions in the root of a project. -The difference is that `package-lock.json` cannot be published, and it will -be ignored if found in any place other than the root project. +The difference is that `package-lock.json` cannot be published, and it will be ignored if found in any place other than the root project. -In contrast, [npm-shrinkwrap.json](/configuring-npm/npm-shrinkwrap-json) allows -publication, and defines the dependency tree from the point encountered. -This is not recommended unless deploying a CLI tool or otherwise using the -publication process for producing production packages. +In contrast, [npm-shrinkwrap.json](/configuring-npm/npm-shrinkwrap-json) allows publication, and defines the dependency tree from the point encountered. +This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages. -If both `package-lock.json` and `npm-shrinkwrap.json` are present in the -root of a project, `npm-shrinkwrap.json` will take precedence and -`package-lock.json` will be ignored. +If both `package-lock.json` and `npm-shrinkwrap.json` are present in the root of a project, `npm-shrinkwrap.json` will take precedence and `package-lock.json` will be ignored. ### Hidden Lockfiles -In order to avoid processing the `node_modules` folder repeatedly, npm as -of v7 uses a "hidden" lockfile present in -`node_modules/.package-lock.json`. This contains information about the -tree, and is used in lieu of reading the entire `node_modules` hierarchy -provided that the following conditions are met: +In order to avoid processing the `node_modules` folder repeatedly, npm as of v7 uses a "hidden" lockfile present in `node_modules/.package-lock.json`. +This contains information about the tree, and is used in lieu of reading the entire `node_modules` hierarchy provided that the following conditions are met: - All package folders it references exist in the `node_modules` hierarchy. -- No package folders exist in the `node_modules` hierarchy that are not - listed in the lockfile. -- The modified time of the file is at least as recent as all of the package - folders it references. - -That is, the hidden lockfile will only be relevant if it was created as -part of the most recent update to the package tree. If another CLI mutates -the tree in any way, this will be detected, and the hidden lockfile will be -ignored. - -Note that it _is_ possible to manually change the _contents_ of a package -in such a way that the modified time of the package folder is unaffected. -For example, if you add a file to `node_modules/foo/lib/bar.js`, then the -modified time on `node_modules/foo` will not reflect this change. If you -are manually editing files in `node_modules`, it is generally best to -delete the file at `node_modules/.package-lock.json`. - -As the hidden lockfile is ignored by older npm versions, it does not -contain the backwards compatibility affordances present in "normal" -lockfiles. That is, it is `lockfileVersion: 3`, rather than -`lockfileVersion: 2`. +- No package folders exist in the `node_modules` hierarchy that are not listed in the lockfile. +- The modified time of the file is at least as recent as all of the package folders it references. + +That is, the hidden lockfile will only be relevant if it was created as part of the most recent update to the package tree. +If another CLI mutates the tree in any way, this will be detected, and the hidden lockfile will be ignored. + +Note that it _is_ possible to manually change the _contents_ of a package in such a way that the modified time of the package folder is unaffected. +For example, if you add a file to `node_modules/foo/lib/bar.js`, then the modified time on `node_modules/foo` will not reflect this change. +If you are manually editing files in `node_modules`, it is generally best to delete the file at `node_modules/.package-lock.json`. + +As the hidden lockfile is ignored by older npm versions, it does not contain the backwards compatibility affordances present in "normal" lockfiles. +That is, it is `lockfileVersion: 3`, rather than `lockfileVersion: 2`. ### Handling Old Lockfiles -When npm detects a lockfile from npm v6 or before during the package -installation process, it is automatically updated to fetch missing -information from either the `node_modules` tree or (in the case of empty -`node_modules` trees or very old lockfile formats) the npm registry. +When npm detects a lockfile from npm v6 or before during the package installation process, it is automatically updated to fetch missing information from either the `node_modules` tree or (in the case of empty `node_modules` trees or very old lockfile formats) the npm registry. ### File Format #### `name` -The name of the package this is a package-lock for. This will match what's -in `package.json`. +The name of the package this is a package-lock for. +This will match what's in `package.json`. #### `version` -The version of the package this is a package-lock for. This will match -what's in `package.json`. +The version of the package this is a package-lock for. +This will match what's in `package.json`. #### `lockfileVersion` -An integer version, starting at `1` with the version number of this -document whose semantics were used when generating this -`package-lock.json`. +An integer version, starting at `1` with the version number of this document whose semantics were used when generating this `package-lock.json`. -Note that the file format changed significantly in npm v7 to track -information that would have otherwise required looking in `node_modules` or -the npm registry. Lockfiles generated by npm v7 will contain -`lockfileVersion: 2`. +Note that the file format changed significantly in npm v7 to track information that would have otherwise required looking in `node_modules` or the npm registry. +Lockfiles generated by npm v7 will contain `lockfileVersion: 2`. -* No version provided: an "ancient" shrinkwrap file from a version of npm - prior to npm v5. +* No version provided: an "ancient" shrinkwrap file from a version of npm prior to npm v5. * `1`: The lockfile version used by npm v5 and v6. -* `2`: The lockfile version used by npm v7 and v8. Backwards compatible to v1 - lockfiles. -* `3`: The lockfile version used by npm v9 and above. Backwards compatible to npm v7. +* `2`: The lockfile version used by npm v7 and v8. Backwards compatible to v1 lockfiles. +* `3`: The lockfile version used by npm v9 and above. + Backwards compatible to npm v7. -npm will always attempt to get whatever data it can out of a lockfile, even -if it is not a version that it was designed to support. +npm will always attempt to get whatever data it can out of a lockfile, even if it is not a version that it was designed to support. #### `packages` -This is an object that maps package locations to an object containing the -information about that package. +This is an object that maps package locations to an object containing the information about that package. -The root project is typically listed with a key of `""`, and all other -packages are listed with their relative paths from the root project folder. +The root project is typically listed with a key of `""`, and all other packages are listed with their relative paths from the root project folder. Package descriptors have the following fields: * version: The version found in `package.json` -* resolved: The place where the package was actually resolved from. In - the case of packages fetched from the registry, this will be a url to a - tarball. In the case of git dependencies, this will be the full git url - with commit sha. In the case of link dependencies, this will be the - location of the link target. `registry.npmjs.org` is a magic value meaning - "the currently configured registry". +* resolved: The place where the package was actually resolved from. + In the case of packages fetched from the registry, this will be a url to a tarball. + In the case of git dependencies, this will be the full git url with commit sha. + In the case of link dependencies, this will be the location of the link target. + `registry.npmjs.org` is a magic value meaning "the currently configured registry". -* integrity: A `sha512` or `sha1` [Standard Subresource - Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) - string for the artifact that was unpacked in this location. +* integrity: A `sha512` or `sha1` [Standard Subresource Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) string for the artifact that was unpacked in this location. -* link: A flag to indicate that this is a symbolic link. If this is - present, no other fields are specified, since the link target will also - be included in the lockfile. +* link: A flag to indicate that this is a symbolic link. + If this is present, no other fields are specified, since the link target will also be included in the lockfile. * dev, optional, devOptional: If the package is strictly part of the - `devDependencies` tree, then `dev` will be true. If it is strictly part - of the `optionalDependencies` tree, then `optional` will be set. If it - is both a `dev` dependency _and_ an `optional` dependency of a non-dev - dependency, then `devOptional` will be set. (An `optional` dependency of - a `dev` dependency will have both `dev` and `optional` set.) + `devDependencies` tree, then `dev` will be true. + If it is strictly part of the `optionalDependencies` tree, then `optional` will be set. + If it is both a `dev` dependency _and_ an `optional` dependency of a non-dev dependency, then `devOptional` will be set. + (An `optional` dependency of a `dev` dependency will have both `dev` and `optional` set.) * inBundle: A flag to indicate that the package is a bundled dependency. -* hasInstallScript: A flag to indicate that the package has a `preinstall`, - `install`, or `postinstall` script. +* hasInstallScript: A flag to indicate that the package has a `preinstall`, `install`, or `postinstall` script. -* hasShrinkwrap: A flag to indicate that the package has an - `npm-shrinkwrap.json` file. +* hasShrinkwrap: A flag to indicate that the package has an `npm-shrinkwrap.json` file. -* bin, license, engines, dependencies, optionalDependencies: fields from - `package.json` +* bin, license, engines, dependencies, optionalDependencies: fields from `package.json` #### dependencies Legacy data for supporting versions of npm that use `lockfileVersion: 1`. -This is a mapping of package names to dependency objects. Because the -object structure is strictly hierarchical, symbolic link dependencies are -somewhat challenging to represent in some cases. +This is a mapping of package names to dependency objects. +Because the object structure is strictly hierarchical, symbolic link dependencies are somewhat challenging to represent in some cases. -npm v7 ignores this section entirely if a `packages` section is present, -but does keep it up to date in order to support switching between npm v6 -and npm v7. +npm v7 ignores this section entirely if a `packages` section is present, but does keep it up to date in order to support switching between npm v6 and npm v7. Dependency objects have the following fields: -* version: a specifier that varies depending on the nature of the package, - and is usable in fetching a new copy of it. - - * bundled dependencies: Regardless of source, this is a version number - that is purely for informational purposes. - * registry sources: This is a version number. (eg, `1.2.3`) - * git sources: This is a git specifier with resolved committish. (eg, - `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`) - * http tarball sources: This is the URL of the tarball. (eg, - `https://example.com/example-1.3.0.tgz`) - * local tarball sources: This is the file URL of the tarball. (eg - `file:///opt/storage/example-1.3.0.tgz`) - * local link sources: This is the file URL of the link. (eg - `file:libs/our-module`) - -* integrity: A `sha512` or `sha1` [Standard Subresource - Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) - string for the artifact that was unpacked in this location. For git - dependencies, this is the commit sha. - -* resolved: For registry sources this is path of the tarball relative to - the registry URL. If the tarball URL isn't on the same server as the - registry URL then this is a complete URL. `registry.npmjs.org` is a magic - value meaning "the currently configured registry". - -* bundled: If true, this is the bundled dependency and will be installed - by the parent module. When installing, this module will be extracted - from the parent module during the extract phase, not installed as a - separate dependency. - -* dev: If true then this dependency is either a development dependency ONLY - of the top level module or a transitive dependency of one. This is false - for dependencies that are both a development dependency of the top level - and a transitive dependency of a non-development dependency of the top - level. - -* optional: If true then this dependency is either an optional dependency - ONLY of the top level module or a transitive dependency of one. This is - false for dependencies that are both an optional dependency of the top - level and a transitive dependency of a non-optional dependency of the top - level. - -* requires: This is a mapping of module name to version. This is a list of - everything this module requires, regardless of where it will be - installed. The version should match via normal matching rules a - dependency either in our `dependencies` or in a level higher than us. - -* dependencies: The dependencies of this dependency, exactly as at the top - level. +* version: a specifier that varies depending on the nature of the package, and is usable in fetching a new copy of it. + + * bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes. + * registry sources: This is a version number. + (eg, `1.2.3`) + * git sources: This is a git specifier with resolved committish. + (eg, `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`) + * http tarball sources: This is the URL of the tarball. + (eg, `https://example.com/example-1.3.0.tgz`) + * local tarball sources: This is the file URL of the tarball. + (eg `file:///opt/storage/example-1.3.0.tgz`) + * local link sources: This is the file URL of the link. + (eg `file:libs/our-module`) + +* integrity: A `sha512` or `sha1` [Standard Subresource Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) string for the artifact that was unpacked in this location. + For git dependencies, this is the commit sha. + +* resolved: For registry sources this is path of the tarball relative to the registry URL. + If the tarball URL isn't on the same server as the registry URL then this is a complete URL. + `registry.npmjs.org` is a magic value meaning "the currently configured registry". + +* bundled: If true, this is the bundled dependency and will be installed by the parent module. + When installing, this module will be extracted from the parent module during the extract phase, not installed as a separate dependency. + +* dev: If true then this dependency is either a development dependency ONLY of the top level module or a transitive dependency of one. + This is false for dependencies that are both a development dependency of the top level and a transitive dependency of a non-development dependency of the top level. + +* optional: If true then this dependency is either an optional dependency ONLY of the top level module or a transitive dependency of one. + This is false for dependencies that are both an optional dependency of the top level and a transitive dependency of a non-optional dependency of the top level. + +* requires: This is a mapping of module name to version. + This is a list of everything this module requires, regardless of where it will be installed. + The version should match via normal matching rules a dependency either in our `dependencies` or in a level higher than us. + +* dependencies: The dependencies of this dependency, exactly as at the top level. ### See also diff --git a/deps/npm/docs/content/using-npm/config.md b/deps/npm/docs/content/using-npm/config.md index d2c2ba5538bf55..0118e280407797 100644 --- a/deps/npm/docs/content/using-npm/config.md +++ b/deps/npm/docs/content/using-npm/config.md @@ -6,57 +6,45 @@ description: More than you probably want to know about npm configuration ### Description -This article details npm configuration in general. To learn about the `config` command, -see [`npm config`](/commands/npm-config). +This article details npm configuration in general. +To learn about the `config` command, see [`npm config`](/commands/npm-config). npm gets its configuration values from the following sources, sorted by priority: #### Command Line Flags -Putting `--foo bar` on the command line sets the `foo` configuration -parameter to `"bar"`. A `--` argument tells the cli parser to stop -reading flags. Using `--flag` without specifying any value will set -the value to `true`. +Putting `--foo bar` on the command line sets the `foo` configuration parameter to `"bar"`. +A `--` argument tells the cli parser to stop reading flags. +Using `--flag` without specifying any value will set the value to `true`. -Example: `--flag1 --flag2` will set both configuration parameters -to `true`, while `--flag1 --flag2 bar` will set `flag1` to `true`, -and `flag2` to `bar`. Finally, `--flag1 --flag2 -- bar` will set -both configuration parameters to `true`, and the `bar` is taken -as a command argument. +Example: `--flag1 --flag2` will set both configuration parameters to `true`, while `--flag1 --flag2 bar` will set `flag1` to `true`, and `flag2` to `bar`. +Finally, `--flag1 --flag2 -- bar` will set both configuration parameters to `true`, and the `bar` is taken as a command argument. #### Environment Variables -Any environment variables that start with `npm_config_` will be -interpreted as a configuration parameter. For example, putting -`npm_config_foo=bar` in your environment will set the `foo` -configuration parameter to `bar`. Any environment configurations that -are not given a value will be given the value of `true`. Config -values are case-insensitive, so `NPM_CONFIG_FOO=bar` will work the -same. However, please note that inside [`scripts`](/using-npm/scripts) -npm will set its own environment variables and Node will prefer -those lowercase versions over any uppercase ones that you might set. +Any environment variables that start with `npm_config_` will be interpreted as a configuration parameter. +For example, putting `npm_config_foo=bar` in your environment will set the `foo` configuration parameter to `bar`. +Any environment configurations that are not given a value will be given the value of `true`. +Config values are case-insensitive, so `NPM_CONFIG_FOO=bar` will work the same. +However, please note that inside [`scripts`](/using-npm/scripts) npm will set its own environment variables and Node will prefer those lowercase versions over any uppercase ones that you might set. For details see [this issue](https://github.com/npm/npm/issues/14528). -Notice that you need to use underscores instead of dashes, so `--allow-same-version` -would become `npm_config_allow_same_version=true`. +Notice that you need to use underscores instead of dashes, so `--allow-same-version` would become `npm_config_allow_same_version=true`. #### npmrc Files The four relevant files are: * per-project configuration file (`/path/to/my/project/.npmrc`) -* per-user configuration file (defaults to `$HOME/.npmrc`; configurable via CLI - option `--userconfig` or environment variable `$NPM_CONFIG_USERCONFIG`) -* global configuration file (defaults to `$PREFIX/etc/npmrc`; configurable via - CLI option `--globalconfig` or environment variable `$NPM_CONFIG_GLOBALCONFIG`) +* per-user configuration file (defaults to `$HOME/.npmrc`; configurable via CLI option `--userconfig` or environment variable `$NPM_CONFIG_USERCONFIG`) +* global configuration file (defaults to `$PREFIX/etc/npmrc`; configurable via CLI option `--globalconfig` or environment variable `$NPM_CONFIG_GLOBALCONFIG`) * npm's built-in configuration file (`/path/to/npm/npmrc`) See [npmrc](/configuring-npm/npmrc) for more details. #### Default Configs -Run `npm config ls -l` to see a set of configuration parameters that are -internal to npm, and are defaults if nothing else is specified. +Run `npm config ls -l` to see a set of configuration parameters that are internal to npm, and are defaults if nothing else is specified. ### Shorthands and Other CLI Niceties @@ -103,9 +91,8 @@ The following shorthands are parsed on the command-line: * `--ws`: `--workspaces` * `-y`: `--yes` -If the specified configuration param resolves unambiguously to a known -configuration parameter, then it is expanded to that configuration -parameter. For example: +If the specified configuration param resolves unambiguously to a known configuration parameter, then it is expanded to that configuration parameter. +For example: ```bash npm ls --par @@ -113,10 +100,8 @@ npm ls --par npm ls --parseable ``` -If multiple single-character shorthands are strung together, and the -resulting combination is unambiguously not some other configuration -param, then it is expanded to its various component pieces. For -example: +If multiple single-character shorthands are strung together, and the resulting combination is unambiguously not some other configuration param, then it is expanded to its various component pieces. +For example: ```bash npm ls -gpld @@ -131,31 +116,32 @@ npm ls --global --parseable --long --loglevel info * Default: null * Type: null or String -A basic-auth string to use when authenticating against the npm registry. -This will ONLY be used to authenticate against the npm registry. For other -registries you will need to scope it like "//other-registry.tld/:_auth" +A basic-auth string to use when authenticating against the npm +registry. This will ONLY be used to authenticate against the npm +registry. For other registries you will need to scope it like +"//other-registry.tld/:_auth" -Warning: This should generally not be set via a command-line option. It is -safer to use a registry-provided authentication bearer token stored in the -~/.npmrc file by running `npm login`. +Warning: This should generally not be set via a command-line option. +It is safer to use a registry-provided authentication bearer token +stored in the ~/.npmrc file by running `npm login`. #### `access` -* Default: 'public' for new packages, existing packages it will not change the - current level +* Default: 'public' for new packages, existing packages it will not + change the current level * Type: null, "restricted", or "public" If you do not want your scoped package to be publicly viewable (and installable) set `--access=restricted`. -Unscoped packages can not be set to `restricted`. +Unscoped packages cannot be set to `restricted`. -Note: This defaults to not changing the current access level for existing -packages. Specifying a value of `restricted` or `public` during publish will -change the access for an existing package the same way that `npm access set -status` would. +Note: This defaults to not changing the current access level for +existing packages. Specifying a value of `restricted` or `public` +during publish will change the access for an existing package the +same way that `npm access set status` would. @@ -164,9 +150,9 @@ status` would. * 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. +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. @@ -175,8 +161,8 @@ upon by the current project. * Default: false * Type: Boolean -Prevents throwing an error when `npm version` is used to set the new version -to the same value as the current version. +Prevents throwing an error when `npm version` is used to set the new +version to the same value as the current version. @@ -185,10 +171,10 @@ to the same value as the current version. * 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. +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. @@ -197,8 +183,8 @@ submitted. * 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. +The minimum level of vulnerability for `npm audit` to exit with a +non-zero exit code. @@ -207,8 +193,8 @@ exit code. * 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`. +What authentication strategy to use with `login`. Note that if an +`otp` config is given, this value will always be set to `legacy`. @@ -218,14 +204,14 @@ config is given, this value will always be set to `legacy`. * 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. +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`. +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`. @@ -237,9 +223,9 @@ will be used. For example, `foo@latest` might install `foo@1.2` even though 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. +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. @@ -263,16 +249,16 @@ Set to `true` to use default system URL opener. * Type: null or String (can be set multiple times) The Certificate Authority signing certificate that is trusted for SSL -connections to the registry. Values should be in PEM format (Windows calls -it "Base-64 encoded X.509 (.CER)") with newlines replaced by the string -"\n". For example: +connections to the registry. Values should be in PEM format (Windows +calls it "Base-64 encoded X.509 (.CER)") with newlines replaced by +the string "\n". For example: ```ini ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----" ``` -Set to `null` to only allow "known" registrars, or to a specific CA cert to -trust only that specific signing authority. +Set to `null` to only allow "known" registrars, or to a specific CA +cert to trust only that specific signing authority. Multiple CAs can be trusted by specifying an array of certificates: @@ -299,9 +285,10 @@ The location of npm's cache directory. * Default: null * Type: Path -A path to a file containing one or multiple Certificate Authority signing -certificates. Similar to the `ca` setting, but allows for multiple CA's, as -well as for the CA information to be stored in a file on disk. +A path to a file containing one or multiple Certificate Authority +signing certificates. Similar to the `ca` setting, but allows for +multiple CA's, as well as for the CA information to be stored in a +file on disk. @@ -310,8 +297,9 @@ well as for the CA information to be stored in a file on disk. * 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. +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" @@ -324,18 +312,19 @@ npm exec --package yo --package generator-node --call "yo node" * Default: null * Type: null or String (can be set multiple times) -This is a list of CIDR address to be used when configuring limited access -tokens with the `npm token create` command. +This is a list of CIDR address to be used when configuring limited +access tokens with the `npm token create` command. #### `color` -* Default: true unless the NO_COLOR environ is set to something other than '0' +* Default: true unless the NO_COLOR environ is set to something other + than '0' * Type: "always" or Boolean -If false, never shows colors. If `"always"` then always shows colors. If -true, then only prints color codes for tty file descriptors. +If false, never shows colors. If `"always"` then always shows colors. +If true, then only prints color codes for tty file descriptors. @@ -353,20 +342,22 @@ Run git commit hooks when using the `npm version` command. * 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`. +Override CPU architecture of native modules to install. Acceptable +values are same as `cpu` field of package.json, which comes from +`process.arch`. #### `depth` -* Default: `Infinity` if `--all` is set, otherwise `0` +* 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. +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. @@ -459,13 +450,14 @@ The number of lines of context to print in `npm diff`. * 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`. +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. +Note: This is NOT honored by other network related commands, eg +`dist-tags`, `owner`, etc. @@ -484,9 +476,9 @@ The command to run for `npm edit` and `npm config edit`. * Default: false * Type: Boolean -If set to true, then npm will stubbornly refuse to install (or even consider -installing) any package that claims to not be compatible with the current -Node.js version. +If set to true, then npm will stubbornly refuse to install (or even +consider installing) any package that claims to not be compatible +with the current Node.js version. This can be overridden by setting the `--force` flag. @@ -499,28 +491,28 @@ This can be overridden by setting the `--force` flag. Tells to expect a specific number of results from the command. -This config can not be used with: `expect-results` +This config cannot be used with: `expect-results` #### `expect-results` * Default: null * Type: null or Boolean -Tells npm whether or not to expect results from the command. Can be either -true (expect some results) or false (expect no results). +Tells npm whether or not to expect results from the command. Can be +either true (expect some results) or false (expect no results). -This config can not be used with: `expect-result-count` +This config cannot be used with: `expect-result-count` #### `fetch-retries` * Default: 2 * Type: Number -The "retries" config for the `retry` module to use when fetching packages -from the registry. +The "retries" config for the `retry` module to use when fetching +packages from the registry. -npm will retry idempotent read requests to the registry in the case of -network failures or 5xx HTTP errors. +npm will retry idempotent read requests to the registry in the case +of network failures or 5xx HTTP errors. @@ -529,7 +521,8 @@ network failures or 5xx HTTP errors. * Default: 10 * Type: Number -The "factor" config for the `retry` module to use when fetching packages. +The "factor" config for the `retry` module to use when fetching +packages. @@ -573,14 +566,16 @@ 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 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. +* 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). @@ -592,16 +587,17 @@ recommended that you do not use this option! #### `foreground-scripts` -* Default: `false` unless when using `npm pack` or `npm publish` where it - defaults to `true` +* 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. +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. +Note that this will generally make installs run slower, and be much +noisier, but can be useful for debugging. @@ -610,8 +606,8 @@ but can be useful for debugging. * Default: true * Type: Boolean -Format `package-lock.json` or `npm-shrinkwrap.json` as a human readable -file. +Format `package-lock.json` or `npm-shrinkwrap.json` as a human +readable file. @@ -621,8 +617,8 @@ file. * 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. +acknowledging the number of dependencies looking for funding. See +[`npm fund`](/commands/npm-fund) for details. @@ -631,8 +627,9 @@ fund`](/commands/npm-fund) for details. * Default: "git" * Type: String -The command to use for git commands. If git is installed on the computer, -but is not in the `PATH`, then set this to the full path to the git binary. +The command to use for git commands. If git is installed on the +computer, but is not in the `PATH`, then set this to the full path to +the git binary. @@ -641,8 +638,8 @@ but is not in the `PATH`, then set this to the full path to the git binary. * Default: true * Type: Boolean -Tag the commit when using the `npm version` command. Setting this to false -results in no commit being made at all. +Tag the commit when using the `npm version` command. Setting this to +false results in no commit being made at all. @@ -651,12 +648,13 @@ results in no commit being made at all. * 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. +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. +* 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` @@ -687,9 +685,9 @@ The string that starts all the debugging log output. * Type: null or URL A proxy to use for outgoing https requests. If the `HTTPS_PROXY` or -`https_proxy` or `HTTP_PROXY` or `http_proxy` environment variables are set, -proxy settings will be honored by the underlying `make-fetch-happen` -library. +`https_proxy` or `HTTP_PROXY` or `http_proxy` environment variables +are set, proxy settings will be honored by the underlying +`make-fetch-happen` library. @@ -698,12 +696,12 @@ library. * Default: false * Type: Boolean -If true, npm will not exit with an error code when `run` is invoked for a -script that isn't defined in the `scripts` section of `package.json`. This -option can be used when it's desirable to optionally run a script when it's -present and fail if the script fails. This is useful, for example, when -running scripts that may only apply for some builds in an otherwise generic -CI setup. +If true, npm will not exit with an error code when `run` is invoked +for a script that isn't defined in the `scripts` section of +`package.json`. This option can be used when it's desirable to +optionally run a script when it's present and fail if the script +fails. This is useful, for example, when running scripts that may +only apply for some builds in an otherwise generic CI setup. This value is not exported to the environment for child processes. @@ -714,24 +712,27 @@ This value is not exported to the environment for child processes. 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. +Note that commands explicitly intended to run a particular script, +such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm +run` will still run their intended script if `ignore-scripts` is set, +but they will *not* run any pre- or post-scripts. #### `include` * Default: -* Type: "prod", "dev", "optional", or "peer" (can be set multiple times) +* Type: "prod", "dev", "optional", or "peer" (can be set multiple + times) -Option that allows for defining which types of dependencies to install. +Option that allows for defining which types of dependencies to +install. This is the inverse of `--omit=`. -Dependency types specified in `--include` will not be omitted, regardless of -the order in which omit/include are specified on the command-line. +Dependency types specified in `--include` will not be omitted, +regardless of the order in which omit/include are specified on the +command-line. @@ -740,8 +741,8 @@ the order in which omit/include are specified on the command-line. * Default: false * Type: Boolean -Allow installing "staged" published packages, as defined by [npm RFC PR -#92](https://github.com/npm/rfcs/pull/92). +Allow installing "staged" published packages, as defined by [npm RFC +PR #92](https://github.com/npm/rfcs/pull/92). This is experimental, and not implemented by the npm public registry. @@ -754,9 +755,10 @@ This is experimental, and not implemented by the npm public registry. 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. +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. @@ -765,7 +767,8 @@ This value is not exported to the environment for child processes. * Default: "" * Type: String -The value `npm init` should use by default for the package author's email. +The value `npm init` should use by default for the package author's +email. @@ -774,7 +777,8 @@ The value `npm init` should use by default for the package author's email. * Default: "" * Type: String -The value `npm init` should use by default for the package author's name. +The value `npm init` should use by default for the package author's +name. @@ -804,8 +808,8 @@ The value `npm init` should use by default for the package license. 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-package-json](https://github.com/npm/init-package-json) module +for more information, or [npm init](/commands/npm-init). @@ -814,7 +818,8 @@ more information, or [npm init](/commands/npm-init). * Default: false * Type: Boolean -The value `npm init` should use by default for the package's private flag. +The value `npm init` should use by default for the package's private +flag. @@ -823,8 +828,8 @@ The value `npm init` should use by default for the package's private flag. * Default: "commonjs" * Type: String -The value that `npm init` should use by default for the package.json type -field. +The value that `npm init` should use by default for the package.json +type field. @@ -833,8 +838,8 @@ field. * 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. +The value that `npm init` should use by default for the package +version number, if not already set in package.json. @@ -843,9 +848,9 @@ number, if not already set in package.json. * 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. +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. @@ -855,11 +860,12 @@ workspaces. * 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. +(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. @@ -870,8 +876,8 @@ link in place, unhoisted. 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`. +* 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. @@ -882,18 +888,19 @@ Not supported by all npm commands. * Default: false * Type: Boolean -Causes npm to completely ignore `peerDependencies` when building a package -tree, as in npm versions 3 through 6. +Causes npm to completely ignore `peerDependencies` when building a +package tree, as in npm versions 3 through 6. -If a package cannot be installed because of overly strict `peerDependencies` -that collide, it provides a way to move forward resolving the situation. +If a package cannot be installed because of overly strict +`peerDependencies` that collide, it provides a way to move forward +resolving the situation. -This differs from `--omit=peer`, in that `--omit=peer` will avoid unpacking -`peerDependencies` on disk, but will still design a tree such that -`peerDependencies` _could_ be unpacked in a correct place. +This differs from `--omit=peer`, in that `--omit=peer` will avoid +unpacking `peerDependencies` on disk, but will still design a tree +such that `peerDependencies` _could_ be unpacked in a correct place. -Use of `legacy-peer-deps` is not recommended, as it will not enforce the -`peerDependencies` contract that meta-dependencies may rely on. +Use of `legacy-peer-deps` is not recommended, as it will not enforce +the `peerDependencies` contract that meta-dependencies may rely on. @@ -902,8 +909,8 @@ Use of `legacy-peer-deps` is not recommended, as it will not enforce the * Default: null * Type: null or String -Override libc of native modules to install. Acceptable values are same as -`libc` field of package.json +Override libc of native modules to install. Acceptable values are +same as `libc` field of package.json @@ -912,7 +919,8 @@ Override libc of native modules to install. Acceptable values are same as * Default: false * Type: Boolean -Used with `npm ls`, limiting output to only those packages that are linked. +Used with `npm ls`, limiting output to only those packages that are +linked. @@ -921,25 +929,26 @@ Used with `npm ls`, limiting output to only those packages that are linked. * Default: null * Type: IP Address -The IP address of the local interface to use when making connections to the -npm registry. Must be IPv4 in versions of Node prior to 0.12. +The IP address of the local interface to use when making connections +to the npm registry. Must be IPv4 in versions of Node prior to 0.12. #### `location` -* Default: "user" unless `--global` is passed, which will also set this value - to "global" +* 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. +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. +* 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` @@ -947,36 +956,39 @@ instead of the current working directory. See #### `lockfile-version` -* Default: Version 3 if no lockfile, auto-converting v1 lockfiles to v3, - otherwise maintain current lockfile version. +* Default: Version 3 if no lockfile, auto-converting v1 lockfiles to + v3; otherwise, maintain current lockfile version. * Type: null, 1, 2, 3, "1", "2", or "3" Set the lockfile format version to be used in package-lock.json and npm-shrinkwrap-json files. Possible options are: -1: The lockfile version used by npm versions 5 and 6. Lacks some data that -is used during the install, resulting in slower and possibly less -deterministic installs. Prevents lockfile churn when interoperating with -older npm versions. +1: The lockfile version used by npm versions 5 and 6. Lacks some data +that is used during the install, resulting in slower and possibly +less deterministic installs. Prevents lockfile churn when +interoperating with older npm versions. -2: The default lockfile version used by npm version 7 and 8. Includes both -the version 1 lockfile data and version 3 lockfile data, for maximum -determinism and interoperability, at the expense of more bytes on disk. +2: The default lockfile version used by npm version 7 and 8. Includes +both the version 1 lockfile data and version 3 lockfile data, for +maximum determinism and interoperability, at the expense of more +bytes on disk. -3: Only the new lockfile information introduced in npm version 7. Smaller on -disk than lockfile version 2, but not interoperable with older npm versions. -Ideal if all users are on npm version 7 and higher. +3: Only the new lockfile information introduced in npm version 7. +Smaller on disk than lockfile version 2, but not interoperable with +older npm versions. Ideal if all users are on npm version 7 and +higher. #### `loglevel` * Default: "notice" -* Type: "silent", "error", "warn", "notice", "http", "info", "verbose", or - "silly" +* Type: "silent", "error", "warn", "notice", "http", "info", "verbose", + or "silly" -What level of logs to report. All logs are written to a debug log, with the -path to that file printed if the execution of a command fails. +What level of logs to report. All logs are written to a debug log, +with the path to that file printed if the execution of a command +fails. Any logs of a higher level than the setting are shown. The default is "notice". @@ -990,8 +1002,8 @@ See also the `foreground-scripts` config. * Default: A directory named `_logs` inside the cache * Type: null or Path -The location of npm's log directory. See [`npm logging`](/using-npm/logging) -for more information. +The location of npm's log directory. See [`npm +logging`](/using-npm/logging) for more information. @@ -1020,8 +1032,8 @@ Show extended information in `ls`, `search`, and `help-search`. * Default: 15 * Type: Number -The maximum number of connections to use per origin (protocol/host/port -combination). +The maximum number of connections to use per origin +(protocol/host/port combination). @@ -1030,7 +1042,8 @@ combination). * Default: "%s" * Type: String -Commit message which is used by `npm version` when creating version commit. +Commit message which is used by `npm version` when creating version +commit. Any "%s" in the message will be replaced with the version number. @@ -1041,11 +1054,11 @@ Any "%s" in the message will be replaced with the version number. * Default: The path to the node-gyp bin that ships with npm * Type: Path -This is the location of the "node-gyp" bin. By default it uses one that -ships with npm itself. +This is the location of the "node-gyp" bin. By default it uses one +that ships with npm itself. -You can use this config to specify your own "node-gyp" to run when it is -required to build a package. +You can use this config to specify your own "node-gyp" to run when it +is required to build a package. @@ -1055,8 +1068,8 @@ required to build a package. * Type: null or String Options to pass through to Node.js via the `NODE_OPTIONS` environment -variable. This does not impact how npm itself is executed but it does impact -how lifecycle scripts are called. +variable. This does not impact how npm itself is executed but it does +impact how lifecycle scripts are called. @@ -1076,15 +1089,16 @@ Also accepts a comma-delimited string. * Default: false * Type: Boolean -Force offline mode: no network requests will be done during install. To -allow the CLI to fill in missing cache data, see `--prefer-offline`. +Force offline mode: no network requests will be done during install. +To allow the CLI to fill in missing cache data, see +`--prefer-offline`. #### `omit` * Default: 'dev' if the `NODE_ENV` environment variable is set to - 'production', otherwise empty. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -1093,11 +1107,12 @@ 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 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. +If the resulting omit list includes `'dev'`, then the `NODE_ENV` +environment variable will be set to `'production'` for all lifecycle +scripts. @@ -1106,10 +1121,10 @@ variable will be set to `'production'` for all lifecycle scripts. * Default: false * Type: Boolean -This option causes npm to create lock files without a `resolved` key for -registry dependencies. Subsequent installs will need to resolve tarball -endpoints with the configured registry, likely resulting in a longer install -time. +This option causes npm to create lock files without a `resolved` key +for registry dependencies. Subsequent installs will need to resolve +tarball endpoints with the configured registry, likely resulting in a +longer install time. @@ -1118,8 +1133,8 @@ time. * 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`. +Override OS of native modules to install. Acceptable values are same +as `os` field of package.json, which comes from `process.platform`. @@ -1128,11 +1143,12 @@ field of package.json, which comes from `process.platform`. * 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`. +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. +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. @@ -1150,7 +1166,8 @@ Directory in which `npm pack` will save tarballs. * Default: * Type: String (can be set multiple times) -The package or packages to install for [`npm exec`](/commands/npm-exec) +The package or packages to install for [`npm +exec`](/commands/npm-exec) @@ -1159,8 +1176,9 @@ The package or packages to install for [`npm exec`](/commands/npm-exec) * 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. +If set to false, then ignore `package-lock.json` files when +installing. This will also prevent _writing_ `package-lock.json` if +`save` is true. @@ -1169,14 +1187,15 @@ will also prevent _writing_ `package-lock.json` if `save` is true. * Default: false * Type: Boolean -If set to true, the current operation will only use the `package-lock.json`, -ignoring `node_modules`. +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`. +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`. @@ -1185,8 +1204,8 @@ For `list` this means the output will be based on the tree described by the * Default: false * Type: Boolean -Output parseable results from commands that write to standard output. For -`npm search`, this will be tab-separated table format. +Output parseable results from commands that write to standard output. +For `npm search`, this will be tab-separated table format. @@ -1195,8 +1214,8 @@ Output parseable results from commands that write to standard output. For * Default: false * Type: Boolean -Prefer to deduplicate packages if possible, rather than choosing a newer -version of a dependency. +Prefer to deduplicate packages if possible, rather than choosing a +newer version of a dependency. @@ -1205,9 +1224,9 @@ version of a dependency. * Default: false * Type: Boolean -If true, staleness checks for cached data will be bypassed, but missing data -will be requested from the server. To force full offline mode, use -`--offline`. +If true, staleness checks for cached data will be bypassed, but +missing data will be requested from the server. To force full offline +mode, use `--offline`. @@ -1216,20 +1235,20 @@ will be requested from the server. To force full offline mode, use * Default: false * Type: Boolean -If true, staleness checks for cached data will be forced, making the CLI -look for updates immediately even for fresh package data. +If true, staleness checks for cached data will be forced, making the +CLI look for updates immediately even for fresh package data. #### `prefix` -* Default: In global mode, the folder where the node executable is installed. - Otherwise, the nearest parent folder containing either a package.json file - or a node_modules folder. +* Default: In global mode, the folder where the node executable is + installed. Otherwise, the nearest parent folder containing either a + package.json file or a node_modules folder. * Type: Path -The location to install global items. If set on the command line, then it -forces non-global commands to run in the specified folder. +The location to install global items. If set on the command line, +then it forces non-global commands to run in the specified folder. @@ -1238,19 +1257,20 @@ forces non-global commands to run in the specified folder. * Default: "" * Type: String -The "prerelease identifier" to use as a prefix for the "prerelease" part of -a semver. Like the `rc` in `1.2.0-rc.8`. +The "prerelease identifier" to use as a prefix for the "prerelease" +part of a semver. Like the `rc` in `1.2.0-rc.8`. #### `progress` -* Default: `true` when not in CI and both stderr and stdout are TTYs and not - in a dumb terminal +* Default: `true` when not in CI and both stderr and stdout are TTYs + and not in a dumb terminal * Type: Boolean -When set to `true`, npm will display a progress bar during time intensive -operations, if `process.stderr` and `process.stdout` are a TTY. +When set to `true`, npm will display a progress bar during time +intensive operations, if `process.stderr` and `process.stdout` are a +TTY. Set to `false` to suppress the progress bar. @@ -1261,19 +1281,20 @@ Set to `false` to suppress the progress bar. * Default: false * Type: Boolean -When publishing from a supported cloud CI/CD system, the package will be -publicly linked to where it was built and published from. +When publishing from a supported cloud CI/CD system, the package will +be publicly linked to where it was built and published from. -This config can not be used with: `provenance-file` +This config cannot be used with: `provenance-file` #### `provenance-file` * Default: null * Type: Path -When publishing, the provenance bundle at the given path will be used. +When publishing, the provenance bundle at the given path will be +used. -This config can not be used with: `provenance` +This config cannot be used with: `provenance` #### `proxy` @@ -1281,8 +1302,8 @@ This config can not be used with: `provenance` * Type: null, false, or URL A proxy to use for outgoing http requests. If the `HTTP_PROXY` or -`http_proxy` environment variables are set, proxy settings will be honored -by the underlying `request` library. +`http_proxy` environment variables are set, proxy settings will be +honored by the underlying `request` library. @@ -1291,8 +1312,8 @@ by the underlying `request` library. * Default: false * Type: Boolean -This is used to mark a token as unable to publish when configuring limited -access tokens with the `npm token create` command. +This is used to mark a token as unable to publish when configuring +limited access tokens with the `npm token create` command. @@ -1319,13 +1340,13 @@ The base URL of the npm registry. * Default: "npmjs" * Type: "npmjs", "never", "always", or String -Defines behavior for replacing the registry host in a lockfile with the -configured registry. +Defines behavior for replacing the registry host in a lockfile with +the configured registry. The default behavior is to replace package dist URLs from the default -registry (https://registry.npmjs.org) to the configured registry. If set to -"never", then use the registry value. If set to "always", then replace the -registry host with the configured host every time. +registry (https://registry.npmjs.org) to the configured registry. If +set to "never", then use the registry value. If set to "always", then +replace the registry host with the configured host every time. You may also specify a bare hostname (e.g., "registry.npmjs.org"). @@ -1333,7 +1354,8 @@ You may also specify a bare hostname (e.g., "registry.npmjs.org"). #### `save` -* Default: `true` unless when using `npm update` where it defaults to `false` +* Default: `true` unless when using `npm update` where it defaults to + `false` * Type: Boolean Save installed packages to a `package.json` file as dependencies. @@ -1354,7 +1376,8 @@ If a package would be saved at install time by the use of `--save`, `--save-dev`, or `--save-optional`, then also put it in the `bundleDependencies` list. -Ignored if `--save-peer` is set, since peerDependencies cannot be bundled. +Ignored if `--save-peer` is set, since peerDependencies cannot be +bundled. @@ -1365,15 +1388,16 @@ Ignored if `--save-peer` is set, since peerDependencies cannot be bundled. Save installed packages to a package.json file as `devDependencies`. -This config can not be used with: `save-optional`, `save-peer`, `save-prod` +This config cannot be used with: `save-optional`, `save-peer`, +`save-prod` #### `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. +Dependencies saved to package.json will be configured with an exact +version rather than using npm's default semver range operator. @@ -1382,9 +1406,10 @@ rather than using npm's default semver range operator. * Default: false * Type: Boolean -Save installed packages to a package.json file as `optionalDependencies`. +Save installed packages to a package.json file as +`optionalDependencies`. -This config can not be used with: `save-dev`, `save-peer`, `save-prod` +This config cannot be used with: `save-dev`, `save-peer`, `save-prod` #### `save-peer` @@ -1393,20 +1418,21 @@ This config can not be used with: `save-dev`, `save-peer`, `save-prod` Save installed packages to a package.json file as `peerDependencies` -This config can not be used with: `save-dev`, `save-optional`, `save-prod` +This config cannot be used with: `save-dev`, `save-optional`, +`save-prod` #### `save-prefix` * Default: "^" * Type: String -Configure how versions of packages installed to a package.json file via -`--save` or `--save-dev` get prefixed. +Configure how versions of packages installed to a package.json file +via `--save` or `--save-dev` get prefixed. -For example if a package has version `1.2.3`, by default its version is set -to `^1.2.3` which allows minor upgrades for that package, but after `npm -config set save-prefix='~'` it would be set to `~1.2.3` which only allows -patch upgrades. +For example if a package has version `1.2.3`, by default its version +is set to `^1.2.3` which allows minor upgrades for that package, but +after `npm config set save-prefix='~'` it would be set to `~1.2.3` +which only allows patch upgrades. @@ -1415,14 +1441,16 @@ patch upgrades. * Default: false * Type: Boolean -Save installed packages into `dependencies` specifically. This is useful if -a package already exists in `devDependencies` or `optionalDependencies`, but -you want to move it to be a non-optional production dependency. +Save installed packages into `dependencies` specifically. This is +useful if a package already exists in `devDependencies` or +`optionalDependencies`, but you want to move it to be a non-optional +production dependency. -This is the default behavior if `--save` is true, and neither `--save-dev` -or `--save-optional` are true. +This is the default behavior if `--save` is true, and neither +`--save-dev` or `--save-optional` are true. -This config can not be used with: `save-dev`, `save-optional`, `save-peer` +This config cannot be used with: `save-dev`, `save-optional`, +`save-peer` #### `sbom-format` @@ -1438,9 +1466,9 @@ SBOM format to use when generating SBOMs. * Default: "library" * Type: "library", "application", or "framework" -The type of package described by the generated SBOM. For SPDX, this is the -value for the `primaryPackagePurpose` field. For CycloneDX, this is the -value for the `type` field. +The type of package described by the generated SBOM. For SPDX, this +is the value for the `primaryPackagePurpose` field. For CycloneDX, +this is the value for the `type` field. @@ -1480,8 +1508,8 @@ npm init --scope=@foo --yes * Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows * Type: null or String -The shell to use for scripts run with the `npm exec`, `npm run` and `npm -init ` commands. +The shell to use for scripts run with the `npm exec`, `npm run` and +`npm init ` commands. @@ -1499,8 +1527,8 @@ Space-separated options that limit the results from search. * Default: 20 * Type: Number -Number of items to limit search results to. Will not apply at all to legacy -searches. +Number of items to limit search results to. Will not apply at all to +legacy searches. @@ -1518,15 +1546,15 @@ Space-separated options that are always passed to search. * Default: 900 * Type: Number -The age of the cache, in seconds, before another registry request is made if -using legacy search endpoint. +The age of the cache, in seconds, before another registry request is +made if using legacy search endpoint. #### `shell` -* Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" on - Windows +* Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" + on Windows * Type: String The shell to run for the `npm explore` command. @@ -1538,11 +1566,11 @@ The shell to run for the `npm explore` command. * Default: false * Type: Boolean -If set to true, then the `npm version` command will commit the new package -version using `-S` to add a signature. +If set to true, then the `npm version` command will commit the new +package version using `-S` to add a signature. -Note that git requires you to have set up GPG keys in your git configs for -this to work properly. +Note that git requires you to have set up GPG keys in your git +configs for this to work properly. @@ -1551,11 +1579,11 @@ this to work properly. * Default: false * Type: Boolean -If set to true, then the `npm version` command will tag the version using -`-s` to add a signature. +If set to true, then the `npm version` command will tag the version +using `-s` to add a signature. -Note that git requires you to have set up GPG keys in your git configs for -this to work properly. +Note that git requires you to have set up GPG keys in your git +configs for this to work properly. @@ -1565,18 +1593,19 @@ this to work properly. * 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. +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. +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. +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. @@ -1585,8 +1614,8 @@ this warning is treated as a failure. * Default: true * Type: Boolean -Whether or not to do SSL key validation when making requests to the registry -via https. +Whether or not to do SSL key validation when making requests to the +registry via https. See also the `ca` config. @@ -1597,17 +1626,17 @@ See also the `ca` config. * 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. +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. +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. +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. +If used in the `npm publish` command, this is the tag that will be +added to the package submitted to the registry. @@ -1616,13 +1645,14 @@ the package submitted to the registry. * Default: "v" * Type: String -If set, alters the prefix used when tagging a new version when performing a -version increment using `npm version`. To remove the prefix altogether, set -it to the empty string: `""`. +If set, alters the prefix used when tagging a new version when +performing a version increment using `npm version`. To remove the +prefix altogether, set it to the empty string: `""`. -Because other tools may rely on the convention that npm version tags look -like `v1.0.0`, _only use this property if it is absolutely necessary_. In -particular, use care when overriding this setting for public packages. +Because other tools may rely on the convention that npm version tags +look like `v1.0.0`, _only use this property if it is absolutely +necessary_. In particular, use care when overriding this setting for +public packages. @@ -1631,14 +1661,14 @@ particular, use care when overriding this setting for public packages. * Default: false * Type: Boolean -If true, writes timing information to a process specific json file in the -cache or `logs-dir`. The file name ends with `-timing.json`. +If true, writes timing information to a process specific json file in +the cache or `logs-dir`. The file name ends with `-timing.json`. -You can quickly view it with this [json](https://npm.im/json) command line: -`cat ~/.npm/_logs/*-timing.json | npm exec -- json -g`. +You can quickly view it with this [json](https://npm.im/json) command +line: `cat ~/.npm/_logs/*-timing.json | npm exec -- json -g`. -Timing information will also be reported in the terminal. To suppress this -while still writing the timing file, use `--silent`. +Timing information will also be reported in the terminal. To suppress +this while still writing the timing file, use `--silent`. @@ -1647,31 +1677,32 @@ while still writing the timing file, use `--silent`. * Default: 0 * Type: Octal numeric string in range 0000..0777 (0..511) -The "umask" value to use when setting the file creation mode on files and -folders. +The "umask" value to use when setting the file creation mode on files +and folders. -Folders and executables are given a mode which is `0o777` masked against -this value. Other files are given a mode which is `0o666` masked against -this value. +Folders and executables are given a mode which is `0o777` masked +against this value. Other files are given a mode which is `0o666` +masked against this value. -Note that the underlying system will _also_ apply its own umask value to -files and folders that are created, and npm does not circumvent this, but -rather adds the `--umask` config to it. +Note that the underlying system will _also_ apply its own umask value +to files and folders that are created, and npm does not circumvent +this, but rather adds the `--umask` config to it. -Thus, the effective default umask value on most POSIX systems is 0o22, -meaning that folders and executables are created with a mode of 0o755 and -other files are created with a mode of 0o644. +Thus, the effective default umask value on most POSIX systems is +0o22, meaning that folders and executables are created with a mode of +0o755 and other files are created with a mode of 0o644. #### `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. +* 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. +When set to true, npm uses unicode characters in the tree output. +When false, it uses ascii characters instead of unicode glyphs. @@ -1680,8 +1711,8 @@ false, it uses ascii characters instead of unicode glyphs. * Default: true * Type: Boolean -Set to false to suppress the update notification when using an older version -of npm than the latest. +Set to false to suppress the update notification when using an older +version of npm than the latest. @@ -1700,17 +1731,17 @@ Show short usage output about the command specified. workspaces/{workspaces} {ci}" * Type: String -Sets the User-Agent request header. The following fields are replaced with -their actual counterparts: +Sets the User-Agent request header. The following fields are replaced +with their actual counterparts: * `{npm-version}` - The npm version in use * `{node-version}` - The Node.js version in use * `{platform}` - The value of `process.platform` * `{arch}` - The value of `process.arch` -* `{workspaces}` - Set to `true` if the `workspaces` or `workspace` options - are set. -* `{ci}` - The value of the `ci-name` config, if set, prefixed with `ci/`, or - an empty string if `ci-name` is empty. +* `{workspaces}` - Set to `true` if the `workspaces` or `workspace` + options are set. +* `{ci}` - The value of the `ci-name` config, if set, prefixed with + `ci/`, or an empty string if `ci-name` is empty. @@ -1721,9 +1752,9 @@ their actual counterparts: The location of user-level configuration settings. -This may be overridden by the `npm_config_userconfig` environment variable -or the `--userconfig` command line option, but may _not_ be overridden by -settings in the `globalconfig` file. +This may be overridden by the `npm_config_userconfig` environment +variable or the `--userconfig` command line option, but may _not_ be +overridden by settings in the `globalconfig` file. @@ -1743,9 +1774,9 @@ Only relevant when specified explicitly on the command line. * Default: false * Type: Boolean -If true, output the npm version as well as node's `process.versions` map and -the version in the current working directory's `package.json` file if one -exists, and exit successfully. +If true, output the npm version as well as node's `process.versions` +map and the version in the current working directory's `package.json` +file if one exists, and exit successfully. Only relevant when specified explicitly on the command line. @@ -1758,7 +1789,8 @@ Only relevant when specified explicitly on the command line. The program to use to view help content. -Set to `"browser"` to view html help content in the default web browser. +Set to `"browser"` to view html help content in the default web +browser. @@ -1767,7 +1799,8 @@ Set to `"browser"` to view html help content in the default web browser. * Default: null * Type: null or Number -If there are multiple funding sources, which 1-indexed source URL to open. +If there are multiple funding sources, which 1-indexed source URL to +open. @@ -1776,9 +1809,9 @@ If there are multiple funding sources, which 1-indexed source URL to open. * 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. +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: @@ -1787,9 +1820,9 @@ Valid values for the `workspace` config are either: * 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. +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. @@ -1801,13 +1834,14 @@ This value is not exported to the environment for child processes. 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: +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. +- 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. @@ -1816,8 +1850,9 @@ This value is not exported to the environment for child processes. * 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. +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. @@ -1837,7 +1872,8 @@ command line. * Type: null, "dev", or "development" * DEPRECATED: Please use --include=dev instead. -When set to `dev` or `development`, this is an alias for `--include=dev`. +When set to `dev` or `development`, this is an alias for +`--include=dev`. @@ -1845,7 +1881,8 @@ When set to `dev` or `development`, this is an alias for `--include=dev`. * Default: Infinity * Type: Number -* DEPRECATED: This option has been deprecated in favor of `--prefer-online` +* DEPRECATED: This option has been deprecated in favor of + `--prefer-online` `--cache-max=0` is an alias for `--prefer-online` @@ -1855,7 +1892,8 @@ When set to `dev` or `development`, this is an alias for `--include=dev`. * Default: 0 * Type: Number -* DEPRECATED: This option has been deprecated in favor of `--prefer-offline`. +* DEPRECATED: This option has been deprecated in favor of + `--prefer-offline`. `--cache-min=9999 (or bigger)` is an alias for `--prefer-offline`. @@ -1866,13 +1904,13 @@ When set to `dev` or `development`, this is an alias for `--include=dev`. * Default: null * Type: null or String * DEPRECATED: `key` and `cert` are no longer used for most registry - operations. Use registry scoped `keyfile` and `certfile` instead. Example: - //other-registry.tld/:keyfile=/path/to/key.pem + operations. Use registry scoped `keyfile` and `certfile` instead. + Example: //other-registry.tld/:keyfile=/path/to/key.pem //other-registry.tld/:certfile=/path/to/cert.crt -A client certificate to pass when accessing the registry. Values should be -in PEM format (Windows calls it "Base-64 encoded X.509 (.CER)") with -newlines replaced by the string "\n". For example: +A client certificate to pass when accessing the registry. Values +should be in PEM format (Windows calls it "Base-64 encoded X.509 +(.CER)") with newlines replaced by the string "\n". For example: ```ini cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----" @@ -1901,8 +1939,8 @@ Alias for `--include=dev`. * 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`. +Only install direct dependencies in the top level `node_modules`, but +hoist on deeper dependencies. Sets `--install-strategy=shallow`. @@ -1971,19 +2009,20 @@ Alias for `--init-version` * Default: null * Type: null or String * DEPRECATED: `key` and `cert` are no longer used for most registry - operations. Use registry scoped `keyfile` and `certfile` instead. Example: - //other-registry.tld/:keyfile=/path/to/key.pem + operations. Use registry scoped `keyfile` and `certfile` instead. + Example: //other-registry.tld/:keyfile=/path/to/key.pem //other-registry.tld/:certfile=/path/to/cert.crt -A client key to pass when accessing the registry. Values should be in PEM -format with newlines replaced by the string "\n". For example: +A client key to pass when accessing the registry. Values should be in +PEM format with newlines replaced by the string "\n". For example: ```ini key="-----BEGIN PRIVATE KEY-----\nXXXX\nXXXX\n-----END PRIVATE KEY-----" ``` -It is _not_ the path to a key file, though you can set a registry-scoped -"keyfile" path like "//other-registry.tld/:keyfile=/path/to/key.pem". +It is _not_ the path to a key file, though you can set a +registry-scoped "keyfile" path like +"//other-registry.tld/:keyfile=/path/to/key.pem". @@ -1994,10 +2033,10 @@ It is _not_ the path to a key file, though you can set a registry-scoped * 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`. +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`. @@ -2005,9 +2044,11 @@ de-duplicating. Sets `--install-strategy=nested`. * Default: null * Type: null, "prod", or "production" -* DEPRECATED: Use `--omit=dev` to omit dev dependencies from the install. +* DEPRECATED: Use `--omit=dev` to omit dev dependencies from the + install. -When set to `prod` or `production`, this is an alias for `--omit=dev`. +When set to `prod` or `production`, this is an alias for +`--omit=dev`. @@ -2015,8 +2056,8 @@ When set to `prod` or `production`, this is an alias for `--omit=dev`. * Default: null * Type: null or Boolean -* DEPRECATED: Use `--omit=optional` to exclude optional dependencies, or - `--include=optional` to include them. +* DEPRECATED: Use `--omit=optional` to exclude optional dependencies, + or `--include=optional` to include them. Default value does install optional deps unless otherwise omitted. diff --git a/deps/npm/docs/content/using-npm/dependency-selectors.md b/deps/npm/docs/content/using-npm/dependency-selectors.md index 5f7e27ad21848f..9a1502e9349da4 100644 --- a/deps/npm/docs/content/using-npm/dependency-selectors.md +++ b/deps/npm/docs/content/using-npm/dependency-selectors.md @@ -11,13 +11,15 @@ The [`npm query`](/commands/npm-query) command exposes a new dependency selector - Standardizes the shape of, & querying of, dependency graphs with a robust object model, metadata & selector syntax - Leverages existing, known language syntax & operators from CSS to make disparate package information broadly accessible - Unlocks the ability to answer complex, multi-faceted questions about dependencies, their relationships & associative metadata -- Consolidates redundant logic of similar query commands in `npm` (ex. `npm fund`, `npm ls`, `npm outdated`, `npm audit` ...) +- Consolidates redundant logic of similar query commands in `npm` (ex. +`npm fund`, `npm ls`, `npm outdated`, `npm audit` ...) ### Dependency Selector Syntax #### Overview: -- there is no "type" or "tag" selectors (ex. `div, h1, a`) as a dependency/target is the only type of `Node` that can be queried +- there is no "type" or "tag" selectors (ex. +`div, h1, a`) as a dependency/target is the only type of `Node` that can be queried - the term "dependencies" is in reference to any `Node` found in a `tree` returned by `Arborist` #### Combinators @@ -66,13 +68,17 @@ The [`npm query`](/commands/npm-query) command exposes a new dependency selector ##### `:semver(, [selector], [function])` -The `:semver()` pseudo selector allows comparing fields from each node's `package.json` using [semver](https://github.com/npm/node-semver#readme) methods. It accepts up to 3 parameters, all but the first of which are optional. +The `:semver()` pseudo selector allows comparing fields from each node's `package.json` using [semver](https://github.com/npm/node-semver#readme) methods. +It accepts up to 3 parameters, all but the first of which are optional. - `spec` a semver version or range - `selector` an attribute selector for each node (default `[version]`) - `function` a semver method to apply, one of: `satisfies`, `intersects`, `subset`, `gt`, `gte`, `gtr`, `lt`, `lte`, `ltr`, `eq`, `neq` or the special function `infer` (default `infer`) -When the special `infer` function is used the `spec` and the actual value from the node are compared. If both are versions, according to `semver.valid()`, `eq` is used. If both values are ranges, according to `!semver.valid()`, `intersects` is used. If the values are mixed types `satisfies` is used. +When the special `infer` function is used the `spec` and the actual value from the node are compared. +If both are versions, according to `semver.valid()`, `eq` is used. +If both values are ranges, according to `!semver.valid()`, `intersects` is used. +If the values are mixed types `satisfies` is used. Some examples: @@ -82,7 +88,8 @@ Some examples: ##### `:outdated()` -The `:outdated` pseudo selector retrieves data from the registry and returns information about which of your dependencies are outdated. The type parameter may be one of the following: +The `:outdated` pseudo selector retrieves data from the registry and returns information about which of your dependencies are outdated. +The type parameter may be one of the following: - `any` (default) a version exists that is greater than the current one - `in-range` a version exists that is greater than the current one, and satisfies at least one if its parent's dependencies @@ -91,11 +98,14 @@ The `:outdated` pseudo selector retrieves data from the registry and returns inf - `minor` a version exists that is a semver minor greater than the current one - `patch` a version exists that is a semver patch greater than the current one -In addition to the filtering performed by the pseudo selector, some extra data is added to the resulting objects. The following data can be found under the `queryContext` property of each node. +In addition to the filtering performed by the pseudo selector, some extra data is added to the resulting objects. +The following data can be found under the `queryContext` property of each node. - `versions` an array of every available version of the given node -- `outdated.inRange` an array of objects, each with a `from` and `versions`, where `from` is the on-disk location of the node that depends on the current node and `versions` is an array of all available versions that satisfies that dependency. This is only populated if `:outdated(in-range)` is used. -- `outdated.outOfRange` an array of objects, identical in shape to `inRange`, but where the `versions` array is every available version that does not satisfy the dependency. This is only populated if `:outdated(out-of-range)` is used. +- `outdated.inRange` an array of objects, each with a `from` and `versions`, where `from` is the on-disk location of the node that depends on the current node and `versions` is an array of all available versions that satisfies that dependency. +This is only populated if `:outdated(in-range)` is used. +- `outdated.outOfRange` an array of objects, identical in shape to `inRange`, but where the `versions` array is every available version that does not satisfy the dependency. +This is only populated if `:outdated(out-of-range)` is used. Some examples: @@ -104,9 +114,13 @@ Some examples: ##### `:vuln` -The `:vuln` pseudo selector retrieves data from the registry and returns information about which if your dependencies has a known vulnerability. Only dependencies whose current version matches a vulnerability will be returned. For example if you have `semver@7.6.0` in your tree, a vulnerability for `semver` which affects versions `<=6.3.1` will not match. +The `:vuln` pseudo selector retrieves data from the registry and returns information about which if your dependencies has a known vulnerability. +Only dependencies whose current version matches a vulnerability will be returned. +For example if you have `semver@7.6.0` in your tree, a vulnerability for `semver` which affects versions `<=6.3.1` will not match. -You can also filter results by certain attributes in advisories. Currently that includes `severity` and `cwe`. Note that severity filtering is done per severity, it does not include severities "higher" or "lower" than the one specified. +You can also filter results by certain attributes in advisories. +Currently that includes `severity` and `cwe`. +Note that severity filtering is done per severity, it does not include severities "higher" or "lower" than the one specified. In addition to the filtering performed by the pseudo selector, info about each relevant advisory will be added to the `queryContext` attribute of each node under the `advisories` attribute. @@ -121,7 +135,8 @@ Some examples: The attribute selector evaluates the key/value pairs in `package.json` if they are `String`s. -- `[]` attribute selector (ie. existence of attribute) +- `[]` attribute selector (ie. +existence of attribute) - `[attribute=value]` attribute value is equivalent... - `[attribute~=value]` attribute value contains word... - `[attribute*=value]` attribute value contains string... @@ -131,7 +146,10 @@ The attribute selector evaluates the key/value pairs in `package.json` if they a #### `Array` & `Object` Attribute Selectors -The generic `:attr()` pseudo selector standardizes a pattern which can be used for attribute selection of `Object`s, `Array`s or `Arrays` of `Object`s accessible via `Arborist`'s `Node.package` metadata. This allows for iterative attribute selection beyond top-level `String` evaluation. The last argument passed to `:attr()` must be an `attribute` selector or a nested `:attr()`. See examples below: +The generic `:attr()` pseudo selector standardizes a pattern which can be used for attribute selection of `Object`s, `Array`s or `Arrays` of `Object`s accessible via `Arborist`'s `Node.package` metadata. +This allows for iterative attribute selection beyond top-level `String` evaluation. +The last argument passed to `:attr()` must be an `attribute` selector or a nested `:attr()`. +See examples below: #### `Objects` @@ -145,13 +163,14 @@ The generic `:attr()` pseudo selector standardizes a pattern which can be used f Nested objects are expressed as sequential arguments to `:attr()`. ```css -/* return dependencies that have a testling config for opera browsers */ +/* return dependencies that have a [testling config](https://ci.testling.com/guide/advanced_configuration) for opera browsers */ *:attr(testling, browsers, [~=opera]) ``` #### `Arrays` -`Array`s specifically uses a special/reserved `.` character in place of a typical attribute name. `Arrays` also support exact `value` matching when a `String` is passed to the selector. +`Array`s specifically uses a special/reserved `.` character in place of a typical attribute name. +`Arrays` also support exact `value` matching when a `String` is passed to the selector. ##### Example of an `Array` Attribute Selection: ```css @@ -176,7 +195,11 @@ Nested objects are expressed as sequential arguments to `:attr()`. ### Groups -Dependency groups are defined by the package relationships to their ancestors (ie. the dependency types that are defined in `package.json`). This approach is user-centric as the ecosystem has been taught to think about dependencies in these groups first-and-foremost. Dependencies are allowed to be included in multiple groups (ex. a `prod` dependency may also be a `dev` dependency (in that it's also required by another `dev` dependency) & may also be `bundled` - a selector for that type of dependency would look like: `*.prod.dev.bundled`). +Dependency groups are defined by the package relationships to their ancestors (ie. +the dependency types that are defined in `package.json`). +This approach is user-centric as the ecosystem has been taught to think about dependencies in these groups first-and-foremost. +Dependencies are allowed to be included in multiple groups (ex. +a `prod` dependency may also be a `dev` dependency (in that it's also required by another `dev` dependency) & may also be `bundled` - a selector for that type of dependency would look like: `*.prod.dev.bundled`). - `.prod` - `.dev` @@ -185,7 +208,8 @@ Dependency groups are defined by the package relationships to their ancestors (i - `.bundled` - `.workspace` -Please note that currently `workspace` deps are always `prod` dependencies. Additionally the `.root` dependency is also considered a `prod` dependency. +Please note that currently `workspace` deps are always `prod` dependencies. +Additionally the `.root` dependency is also considered a `prod` dependency. ### Programmatic Usage diff --git a/deps/npm/docs/content/using-npm/developers.md b/deps/npm/docs/content/using-npm/developers.md index 0d1096203fc36c..0261d137b36b79 100644 --- a/deps/npm/docs/content/using-npm/developers.md +++ b/deps/npm/docs/content/using-npm/developers.md @@ -6,19 +6,16 @@ description: Developer Guide ### Description -So, you've decided to use npm to develop (and maybe publish/deploy) -your project. +So, you've decided to use npm to develop (and maybe publish/deploy) your project. Fantastic! -There are a few things that you need to do above the simple steps -that your users will do to install your program. +There are a few things that you need to do above the simple steps that your users will do to install your program. ### About These Documents -These are man pages. If you install npm, you should be able to -then do `man npm-thing` to get the documentation on a particular -topic, or `npm help thing` to see the same information. +These are man pages. +If you install npm, you should be able to then do `man npm-thing` to get the documentation on a particular topic, or `npm help thing` to see the same information. ### What is a Package @@ -32,10 +29,7 @@ A package is: * f) a `` that has a "latest" tag satisfying (e) * g) a `git` url that, when cloned, results in (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). +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). Git urls can be of the form: @@ -46,74 +40,62 @@ git+http://user@hostname/project/blah.git#commit-ish git+https://user@hostname/project/blah.git#commit-ish ``` -The `commit-ish` can be any tag, sha, or branch which can be supplied as -an argument to `git checkout`. The default is whatever the repository uses -as its default branch. +The `commit-ish` can be any tag, sha, or branch which can be supplied as an argument to `git checkout`. +The default is whatever the repository uses as its default branch. ### The package.json File -You need to have a `package.json` file in the root of your project to do -much of anything with npm. That is basically the whole interface. +You need to have a `package.json` file in the root of your project to do much of anything with npm. +That is basically the whole interface. -See [`package.json`](/configuring-npm/package-json) for details about what -goes in that file. At the very least, you need: +See [`package.json`](/configuring-npm/package-json) for details about what goes in that file. +At the very least, you need: -* name: This should be a string that identifies your project. Please do - not use the name to specify that it runs on node, or is in JavaScript. - You can use the "engines" field to explicitly state the versions of node - (or whatever else) that your program requires, and it's pretty well - assumed that it's JavaScript. +* name: This should be a string that identifies your project. + Please do not use the name to specify that it runs on node, or is in JavaScript. + You can use the "engines" field to explicitly state the versions of node (or whatever else) that your program requires, and it's pretty well assumed that it's JavaScript. It does not necessarily need to match your github repository name. - So, `node-foo` and `bar-js` are bad names. `foo` or `bar` are better. + So, `node-foo` and `bar-js` are bad names. + `foo` or `bar` are better. * version: A semver-compatible version. -* engines: Specify the versions of node (or whatever else) that your - program runs on. The node API changes a lot, and there may be bugs or - new functionality that you depend on. Be explicit. +* engines: Specify the versions of node (or whatever else) that your program runs on. + The node API changes a lot, and there may be bugs or new functionality that you depend on. + Be explicit. * author: Take some credit. -* scripts: If you have a special compilation or installation script, then - you should put it in the `scripts` object. You should definitely have at - least a basic smoke-test command as the "scripts.test" field. See - [scripts](/using-npm/scripts). +* scripts: If you have a special compilation or installation script, then you should put it in the `scripts` object. + You should definitely have at least a basic smoke-test command as the "scripts.test" field. + See [scripts](/using-npm/scripts). -* main: If you have a single module that serves as the entry point to your - program (like what the "foo" package gives you at require("foo")), then - you need to specify that in the "main" field. +* main: If you have a single module that serves as the entry point to your program (like what the "foo" package gives you at require("foo")), then you need to specify that in the "main" field. -* directories: This is an object mapping names to folders. The best ones - to include are "lib" and "doc", but if you use "man" to specify a folder - full of man pages, they'll get installed just like these ones. +* directories: This is an object mapping names to folders. + The best ones to include are "lib" and "doc", but if you use "man" to specify a folder full of man pages, they'll get installed just like these ones. -You can use `npm init` in the root of your package in order to get you -started with a pretty basic package.json file. See [`npm -init`](/commands/npm-init) for more info. +You can use `npm init` in the root of your package in order to get you started with a pretty basic package.json file. +See [`npm init`](/commands/npm-init) for more info. ### Keeping files *out* of your Package -Use a `.npmignore` file to keep stuff out of your package. If there's no -`.npmignore` file, but there *is* a `.gitignore` file, then npm will ignore -the stuff matched by the `.gitignore` file. If you *want* to include -something that is excluded by your `.gitignore` file, you can create an -empty `.npmignore` file to override it. Like `git`, `npm` looks for -`.npmignore` and `.gitignore` files in all subdirectories of your package, -not only the root directory. +Use a `.npmignore` file to keep stuff out of your package. +If there's no `.npmignore` file, but there *is* a `.gitignore` file, then npm will ignore the stuff matched by the `.gitignore` file. +If you *want* to include something that is excluded by your `.gitignore` file, you can create an empty `.npmignore` file to override it. +Like `git`, `npm` looks for `.npmignore` and `.gitignore` files in all subdirectories of your package, not only the root directory. -`.npmignore` files follow the [same pattern -rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring) -as `.gitignore` files: +`.npmignore` files follow the [same pattern rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring) as `.gitignore` files: * Blank lines or lines starting with `#` are ignored. * Standard glob patterns work. * You can end patterns with a forward slash `/` to specify a directory. * You can negate a pattern by starting it with an exclamation point `!`. -By default, some paths and files are ignored, so there's no -need to add them to `.npmignore` explicitly. Some examples are: +By default, some paths and files are ignored, so there's no need to add them to `.npmignore` explicitly. +Some examples are: * `.*.swp` * `._*` @@ -130,39 +112,28 @@ need to add them to `.npmignore` explicitly. Some examples are: * `CVS` * `npm-debug.log` -Additionally, everything in `node_modules` is ignored, except for -bundled dependencies. npm automatically handles this for you, so don't -bother adding `node_modules` to `.npmignore`. +Additionally, everything in `node_modules` is ignored, except for bundled dependencies. +npm automatically handles this for you, so don't bother adding `node_modules` to `.npmignore`. -The following paths and files are never ignored, so adding them to -`.npmignore` is pointless: +The following paths and files are never ignored, so adding them to `.npmignore` is pointless: * `package.json` * `README` (and its variants) * `LICENSE` / `LICENCE` -If, given the structure of your project, you find `.npmignore` to be a -maintenance headache, you might instead try populating the `files` -property of `package.json`, which is an array of file or directory names -that should be included in your package. Sometimes manually picking -which items to allow is easier to manage than building a block list. +If, given the structure of your project, you find `.npmignore` to be a maintenance headache, you might instead try populating the `files` property of `package.json`, which is an array of file or directory names that should be included in your package. +Sometimes manually picking which items to allow is easier to manage than building a block list. -See [`package.json`](/configuring-npm/package-json) for more info on -what can and can't be ignored. +See [`package.json`](/configuring-npm/package-json) for more info on what can and can't be ignored. #### Testing whether your `.npmignore` or `files` config works -If you want to double check that your package will include only the files -you intend it to when published, you can run the `npm pack` command locally -which will generate a tarball in the working directory, the same way it -does for publishing. +If you want to double check that your package will include only the files you intend it to when published, you can run the `npm pack` command locally which will generate a tarball in the working directory, the same way it does for publishing. ### Link Packages -`npm link` is designed to install a development package and see the -changes in real time without having to keep re-installing it. (You do -need to either re-link or `npm rebuild -g` to update compiled packages, -of course.) +`npm link` is designed to install a development package and see the changes in real time without having to keep re-installing it. +(You do need to either re-link or `npm rebuild -g` to update compiled packages, of course.) More info at [`npm link`](/commands/npm-link). @@ -170,9 +141,8 @@ More info at [`npm link`](/commands/npm-link). **This is important.** -If you can not install it locally, you'll have -problems trying to publish it. Or, worse yet, you'll be able to -publish it, but you'll be publishing a broken or pointless package. +If you cannot install it locally, you'll have problems trying to publish it. +Or, worse yet, you'll be able to publish it, but you'll be publishing a broken or pointless package. So don't do that. In the root of your package, do this: @@ -181,8 +151,8 @@ In the root of your package, do this: npm install . -g ``` -That'll show you that it's working. If you'd rather just create a symlink -package that points to your working directory, then do this: +That'll show you that it's working. +If you'd rather just create a symlink package that points to your working directory, then do this: ```bash npm link @@ -199,12 +169,12 @@ npm install ../my-package to install it locally into the node_modules folder in that other place. -Then go into the node-repl, and try using require("my-thing") to -bring in your module's main module. +Then go into the node-repl, and try using require("my-thing") to bring in your module's main module. ### Create a User Account -Create a user with the adduser command. It works like this: +Create a user with the adduser command. +It works like this: ```bash npm adduser @@ -216,19 +186,17 @@ This is documented better in [npm adduser](/commands/npm-adduser). ### Publish your Package -This part's easy. In the root of your folder, do this: +This part's easy. +In the root of your folder, do this: ```bash npm publish ``` -You can give publish a url to a tarball, or a filename of a tarball, -or a path to a folder. +You can give publish a url to a tarball, or a filename of a tarball, or a path to a folder. -Note that pretty much **everything in that folder will be exposed** -by default. So, if you have secret stuff in there, use a -`.npmignore` file to list out the globs to ignore, or publish -from a fresh checkout. +Note that pretty much **everything in that folder will be exposed** by default. +So, if you have secret stuff in there, use a `.npmignore` file to list out the globs to ignore, or publish from a fresh checkout. ### Brag about it diff --git a/deps/npm/docs/content/using-npm/logging.md b/deps/npm/docs/content/using-npm/logging.md index e55173e1cdafc4..d5fca42f595c2a 100644 --- a/deps/npm/docs/content/using-npm/logging.md +++ b/deps/npm/docs/content/using-npm/logging.md @@ -12,10 +12,11 @@ The `npm` CLI has various mechanisms for showing different levels of information All logs are written to a debug log, with the path to that file printed if the execution of a command fails. -The default location of the logs directory is a directory named `_logs` inside the npm cache. This can be changed with the `logs-dir` config option. +The default location of the logs directory is a directory named `_logs` inside the npm cache. +This can be changed with the `logs-dir` config option. -For example, if you wanted to write all your logs to the current working directory, you could run: `npm install --logs-dir=.`. This is especially helpful in debugging a specific `npm` issue as you can run -a command multiple times with different config values and then diff all the log files. +For example, if you wanted to write all your logs to the current working directory, you could run: `npm install --logs-dir=.`. +This is especially helpful in debugging a specific `npm` issue as you can run a command multiple times with different config values and then diff all the log files. Log files will be removed from the `logs-dir` when the number of log files exceeds `logs-max`, with the oldest logs being deleted first. @@ -55,30 +56,31 @@ The log levels listed above have various corresponding aliases, including: #### `foreground-scripts` -The `npm` CLI began hiding the output of lifecycle scripts for `npm install` as of `v7`. Notably, this means you will not see logs/output from packages that may be using "install scripts" to display information back to you or from your own project's scripts defined in `package.json`. If you'd like to change this behavior & log this output you can set `foreground-scripts` to `true`. +The `npm` CLI began hiding the output of lifecycle scripts for `npm install` as of `v7`. +Notably, this means you will not see logs/output from packages that may be using "install scripts" to display information back to you or from your own project's scripts defined in `package.json`. +If you'd like to change this behavior & log this output you can set `foreground-scripts` to `true`. ### Timing Information -The [`--timing` config](/using-npm/config#timing) can be set which does a few -things: +The [`--timing` config](/using-npm/config#timing) can be set which does a few things: 1. Always shows the full path to the debug log regardless of command exit status 1. Write timing information to a process specific timing file in the cache or `logs-dir` 1. Output timing information to the terminal -This file contains a `timers` object where the keys are an identifier for the -portion of the process being timed and the value is the number of milliseconds it took to complete. +This file contains a `timers` object where the keys are an identifier for the portion of the process being timed and the value is the number of milliseconds it took to complete. -Sometimes it is helpful to get timing information without outputting anything to the terminal. For -example, the performance might be affected by writing to the terminal. In this case you can use -`--timing --silent` which will still write the timing file, but not output anything to the terminal -while running. +Sometimes it is helpful to get timing information without outputting anything to the terminal. +For example, the performance might be affected by writing to the terminal. +In this case you can use +`--timing --silent` which will still write the timing file, but not output anything to the terminal while running. ### Registry Response Headers #### `npm-notice` -The `npm` CLI reads from & logs any `npm-notice` headers that are returned from the configured registry. This mechanism can be used by third-party registries to provide useful information when network-dependent requests occur. +The `npm` CLI reads from & logs any `npm-notice` headers that are returned from the configured registry. +This mechanism can be used by third-party registries to provide useful information when network-dependent requests occur. This header is not cached, and will not be logged if the request is served from the cache. @@ -89,7 +91,8 @@ The `npm` CLI makes a best effort to redact the following from terminal output a - Passwords inside basic auth URLs - npm tokens -However, this behavior should not be relied on to keep all possible sensitive information redacted. If you are concerned about secrets in your log file or terminal output, you can use `--loglevel=silent` and `--logs-max=0` to ensure no logs are written to your terminal or filesystem. +However, this behavior should not be relied on to keep all possible sensitive information redacted. +If you are concerned about secrets in your log file or terminal output, you can use `--loglevel=silent` and `--logs-max=0` to ensure no logs are written to your terminal or filesystem. ### See also diff --git a/deps/npm/docs/content/using-npm/orgs.md b/deps/npm/docs/content/using-npm/orgs.md index 5fe9ac6de377f5..8faf939d0b5e89 100644 --- a/deps/npm/docs/content/using-npm/orgs.md +++ b/deps/npm/docs/content/using-npm/orgs.md @@ -10,13 +10,17 @@ There are three levels of org users: 1. Super admin, controls billing & adding people to the org. 2. Team admin, manages team membership & package access. -3. Developer, works on packages they are given access to. +3. Developer, works on packages they are given access to. -The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a `developers` team that all users are automatically added to. +The super admin is the only person who can add users to the org because it impacts the monthly bill. +The super admin will use the website to manage membership. +Every org has a `developers` team that all users are automatically added to. -The team admin is the person who manages team creation, team membership, and package access for teams. The team admin grants package access to teams, not individuals. +The team admin is the person who manages team creation, team membership, and package access for teams. +The team admin grants package access to teams, not individuals. -The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only. +The developer will be able to access packages based on the teams they are on. +Access is either read-write or read-only. There are two main commands: @@ -31,7 +35,8 @@ There are two main commands: npm team ls :developers ``` -* Each org is automatically given a `developers` team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the `access` command. +* Each org is automatically given a `developers` team, so you can see the whole list of team members in your org. +This team automatically gets read-write access to all packages, but you can change that with the `access` command. * Create a new team: @@ -71,19 +76,19 @@ npm access revoke [] * See what org packages a team member can access: ```bash -npm access ls-packages +npm access list packages ``` * See packages available to a specific team: ```bash -npm access ls-packages +npm access list packages ``` * Check which teams are collaborating on a package: ```bash -npm access ls-collaborators +npm access list collaborators ``` ### See also diff --git a/deps/npm/docs/content/using-npm/package-spec.md b/deps/npm/docs/content/using-npm/package-spec.md index f7844d14426853..f4a3c191987421 100644 --- a/deps/npm/docs/content/using-npm/package-spec.md +++ b/deps/npm/docs/content/using-npm/package-spec.md @@ -6,12 +6,9 @@ description: Package name specifier ### Description -Commands like `npm install` and the dependency sections in the -`package.json` use a package name specifier. This can be many different -things that all refer to a "package". Examples include a package name, -git url, tarball, or local directory. These will generally be referred -to as `` in the help output for the npm commands that use -this package name specifier. +Commands like `npm install` and the dependency sections in the `package.json` use a package name specifier. +This can be many different things that all refer to a "package". Examples include a package name, git url, tarball, or local directory. +These will generally be referred to as `` in the help output for the npm commands that use this package name specifier. ### Package name @@ -20,10 +17,8 @@ this package name specifier. * `[<@scope>/]@` * `[<@scope>/]@` -Refers to a package by name, with or without a scope, and optionally -tag, version, or version range. This is typically used in combination -with the [registry](/using-npm/config#registry) config to refer to a -package in a registry. +Refers to a package by name, with or without a scope, and optionally tag, version, or version range. +This is typically used in combination with the [registry](/using-npm/config#registry) config to refer to a package in a registry. Examples: * `npm` @@ -36,15 +31,10 @@ Examples: * `@npm:` -Primarily used by commands like `npm install` and in the dependency -sections in the `package.json`, this refers to a package by an alias. -The `` is the name of the package as it is reified in the -`node_modules` folder, and the `` refers to a package name as -found in the configured registry. +Primarily used by commands like `npm install` and in the dependency sections in the `package.json`, this refers to a package by an alias. +The `` is the name of the package as it is reified in the `node_modules` folder, and the `` refers to a package name as found in the configured registry. -See `Package name` above for more info on referring to a package by -name, and [registry](/using-npm/config#registry) for configuring which -registry is used when referring to a package by name. +See `Package name` above for more info on referring to a package by name, and [registry](/using-npm/config#registry) for configuring which registry is used when referring to a package by name. Examples: * `semver:@npm:@npmcli/semver-with-patch` @@ -55,12 +45,10 @@ Examples: * `` -This refers to a package on the local filesystem. Specifically this is -a folder with a `package.json` file in it. This *should* always be -prefixed with a `/` or `./` (or your OS equivalent) to reduce confusion. -npm currently will parse a string with more than one `/` in it as a -folder, but this is legacy behavior that may be removed in a future -version. +This refers to a package on the local filesystem. +Specifically this is a folder with a `package.json` file in it. +This *should* always be prefixed with a `/` or `./` (or your OS equivalent) to reduce confusion. +npm currently will parse a string with more than one `/` in it as a folder, but this is legacy behavior that may be removed in a future version. Examples: @@ -77,18 +65,17 @@ Examples: * `./my-package.tgz` * `https://registry.npmjs.org/semver/-/semver-1.0.0.tgz` -Refers to a package in a tarball format, either on the local filesystem -or remotely via url. This is the format that packages exist in when -uploaded to a registry. +Refers to a package in a tarball format, either on the local filesystem or remotely via url. +This is the format that packages exist in when uploaded to a registry. ### git urls * `` * `/` -Refers to a package in a git repo. This can be a full git url, git -shorthand, or a username/package on GitHub. You can specify a -git tag, branch, or other git ref by appending `#ref`. +Refers to a package in a git repo. +This can be a full git url, git shorthand, or a username/package on GitHub. +You can specify a git tag, branch, or other git ref by appending `#ref`. Examples: diff --git a/deps/npm/docs/content/using-npm/registry.md b/deps/npm/docs/content/using-npm/registry.md index d12bd9d23fda7c..a707b97ac5a9bf 100644 --- a/deps/npm/docs/content/using-npm/registry.md +++ b/deps/npm/docs/content/using-npm/registry.md @@ -6,66 +6,44 @@ description: The JavaScript Package Registry ### Description -To resolve packages by name and version, npm talks to a registry website -that implements the CommonJS Package Registry specification for reading -package info. +To resolve packages by name and version, npm talks to a registry website that implements the CommonJS Package Registry specification for reading package info. npm is configured to use the **npm public registry** at - by default. Use of the npm public registry is -subject to terms of use available at . - -You can configure npm to use any compatible registry you like, and even run -your own registry. Use of someone else's registry may be governed by their -terms of use. - -npm's package registry implementation supports several -write APIs as well, to allow for publishing packages and managing user -account information. - -The registry URL used is determined by the scope of the package (see -[`scope`](/using-npm/scope). If no scope is specified, the default registry is -used, which is supplied by the [`registry` config](/using-npm/config#registry) -parameter. See [`npm config`](/commands/npm-config), -[`npmrc`](/configuring-npm/npmrc), and [`config`](/using-npm/config) for more on -managing npm's configuration. -Authentication configuration such as auth tokens and certificates are configured -specifically scoped to an individual registry. See -[Auth Related Configuration](/configuring-npm/npmrc#auth-related-configuration) - -When the default registry is used in a package-lock or shrinkwrap it has the -special meaning of "the currently configured registry". If you create a lock -file while using the default registry you can switch to another registry and -npm will install packages from the new registry, but if you create a lock -file while using a custom registry packages will be installed from that -registry even after you change to another registry. + by default. +Use of the npm public registry is subject to terms of use available at . + +You can configure npm to use any compatible registry you like, and even run your own registry. +Use of someone else's registry may be governed by their terms of use. + +npm's package registry implementation supports several write APIs as well, to allow for publishing packages and managing user account information. + +The registry URL used is determined by the scope of the package (see [`scope`](/using-npm/scope). +If no scope is specified, the default registry is used, which is supplied by the [`registry` config](/using-npm/config#registry) parameter. +See [`npm config`](/commands/npm-config), [`npmrc`](/configuring-npm/npmrc), and [`config`](/using-npm/config) for more on managing npm's configuration. +Authentication configuration such as auth tokens and certificates are configured specifically scoped to an individual registry. +See [Auth Related Configuration](/configuring-npm/npmrc#auth-related-configuration) + +When the default registry is used in a package-lock or shrinkwrap it has the special meaning of "the currently configured registry". If you create a lock file while using the default registry you can switch to another registry and npm will install packages from the new registry, but if you create a lock file while using a custom registry packages will be installed from that registry even after you change to another registry. ### Does npm send any information about me back to the registry? Yes. -When making requests of the registry npm adds two headers with information -about your environment: - -* `Npm-Scope` – If your project is scoped, this header will contain its - scope. In the future npm hopes to build registry features that use this - information to allow you to customize your experience for your - organization. -* `Npm-In-CI` – Set to "true" if npm believes this install is running in a - continuous integration environment, "false" otherwise. This is detected by - looking for the following environment variables: `CI`, `TDDIUM`, - `JENKINS_URL`, `bamboo.buildKey`. If you'd like to learn more you may find - the [original PR](https://github.com/npm/npm-registry-client/pull/129) - interesting. - This is used to gather better metrics on how npm is used by humans, versus - build farms. - -The npm registry does not try to correlate the information in these headers -with any authenticated accounts that may be used in the same requests. +When making requests of the registry npm adds two headers with information about your environment: + +* `Npm-Scope` – If your project is scoped, this header will contain its scope. +In the future npm hopes to build registry features that use this information to allow you to customize your experience for your organization. +* `Npm-In-CI` – Set to "true" if npm believes this install is running in a continuous integration environment, "false" otherwise. +This is detected by looking for the following environment variables: `CI`, `TDDIUM`, + `JENKINS_URL`, `bamboo.buildKey`. +If you'd like to learn more you may find the [original PR](https://github.com/npm/npm-registry-client/pull/129) interesting. + This is used to gather better metrics on how npm is used by humans, versus build farms. + +The npm registry does not try to correlate the information in these headers with any authenticated accounts that may be used in the same requests. ### How can I prevent my package from being published in the official registry? -Set `"private": true` in your `package.json` to prevent it from being -published at all, or +Set `"private": true` in your `package.json` to prevent it from being published at all, or `"publishConfig":{"registry":"http://my-internal-registry.local"}` to force it to be published only to your internal/private registry. diff --git a/deps/npm/docs/content/using-npm/removal.md b/deps/npm/docs/content/using-npm/removal.md index 3b94a7d18f9d7c..9b431aaf7f38a0 100644 --- a/deps/npm/docs/content/using-npm/removal.md +++ b/deps/npm/docs/content/using-npm/removal.md @@ -16,20 +16,17 @@ Or, if that fails, please proceed to more severe uninstalling methods. ### More Severe Uninstalling -Usually, the above instructions are sufficient. That will remove -npm, but leave behind anything you've installed. +Usually, the above instructions are sufficient. +That will remove npm, but leave behind anything you've installed. -If that doesn't work, or if you require more drastic measures, -continue reading. +If that doesn't work, or if you require more drastic measures, continue reading. -Note that this is only necessary for globally-installed packages. Local -installs are completely contained within a project's `node_modules` -folder. Delete that folder, and everything is gone unless a package's -install script is particularly ill-behaved. +Note that this is only necessary for globally-installed packages. +Local installs are completely contained within a project's `node_modules` folder. +Delete that folder, and everything is gone unless a package's install script is particularly ill-behaved. -This assumes that you installed node and npm in the default place. If -you configured node with a different `--prefix`, or installed npm with a -different prefix setting, then adjust the paths accordingly, replacing +This assumes that you installed node and npm in the default place. +If you configured node with a different `--prefix`, or installed npm with a different prefix setting, then adjust the paths accordingly, replacing `/usr/local` with your install prefix. To remove everything npm-related manually: @@ -38,17 +35,15 @@ To remove everything npm-related manually: rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm* ``` -If you installed things *with* npm, then your best bet is to uninstall -them with npm first, and then install them again once you have a -proper install. This can help find any symlinks that are lying -around: +If you installed things *with* npm, then your best bet is to uninstall them with npm first, and then install them again once you have a proper install. +This can help find any symlinks that are lying around: ```bash ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm ``` -Prior to version 0.3, npm used shim files for executables and node -modules. To track those down, you can do the following: +Prior to version 0.3, npm used shim files for executables and node modules. +To track those down, you can do the following: ```bash find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ; diff --git a/deps/npm/docs/content/using-npm/scope.md b/deps/npm/docs/content/using-npm/scope.md index d5dcef2d097a7e..ed069752b63add 100644 --- a/deps/npm/docs/content/using-npm/scope.md +++ b/deps/npm/docs/content/using-npm/scope.md @@ -6,35 +6,29 @@ description: Scoped packages ### Description -All npm packages have a name. Some package names also have a scope. A scope -follows the usual rules for package names (URL-safe characters, no leading dots -or underscores). When used in package names, scopes are preceded by an `@` symbol -and followed by a slash, e.g. +All npm packages have a name. +Some package names also have a scope. +A scope follows the usual rules for package names (URL-safe characters, no leading dots or underscores). +When used in package names, scopes are preceded by an `@` symbol and followed by a slash, e.g. ```bash @somescope/somepackagename ``` -Scopes are a way of grouping related packages together, and also affect a few -things about the way npm treats the package. +Scopes are a way of grouping related packages together, and also affect a few things about the way npm treats the package. -Each npm user/organization has their own scope, and only you can add packages -in your scope. This means you don't have to worry about someone taking your -package name ahead of you. Thus it is also a good way to signal official packages -for organizations. +Each npm user/organization has their own scope, and only you can add packages in your scope. +This means you don't have to worry about someone taking your package name ahead of you. +Thus it is also a good way to signal official packages for organizations. -Scoped packages can be published and installed as of `npm@2` and are supported -by the primary npm registry. Unscoped packages can depend on scoped packages and -vice versa. The npm client is backwards-compatible with unscoped registries, -so it can be used to work with scoped and unscoped registries at the same time. +Scoped packages can be published and installed as of `npm@2` and are supported by the primary npm registry. +Unscoped packages can depend on scoped packages and vice versa. +The npm client is backwards-compatible with unscoped registries, so it can be used to work with scoped and unscoped registries at the same time. ### Installing scoped packages -Scoped packages are installed to a sub-folder of the regular installation -folder, e.g. if your other packages are installed in `node_modules/packagename`, -scoped modules will be installed in `node_modules/@myorg/packagename`. The scope -folder (`@myorg`) is simply the name of the scope preceded by an `@` symbol, and can -contain any number of scoped packages. +Scoped packages are installed to a sub-folder of the regular installation folder, e.g. if your other packages are installed in `node_modules/packagename`, scoped modules will be installed in `node_modules/@myorg/packagename`. +The scope folder (`@myorg`) is simply the name of the scope preceded by an `@` symbol, and can contain any number of scoped packages. A scoped package is installed by referencing it by name, preceded by an `@` symbol, in `npm install`: @@ -51,26 +45,22 @@ Or in `package.json`: } ``` -Note that if the `@` symbol is omitted, in either case, npm will instead attempt to -install from GitHub; see [`npm install`](/commands/npm-install). +Note that if the `@` symbol is omitted, in either case, npm will instead attempt to install from GitHub; see [`npm install`](/commands/npm-install). ### Requiring scoped packages -Because scoped packages are installed into a scope folder, you have to -include the name of the scope when requiring them in your code, e.g. +Because scoped packages are installed into a scope folder, you have to include the name of the scope when requiring them in your code, e.g. ```javascript require('@myorg/mypackage') ``` -There is nothing special about the way Node treats scope folders. This -simply requires the `mypackage` module in the folder named `@myorg`. +There is nothing special about the way Node treats scope folders. +This simply requires the `mypackage` module in the folder named `@myorg`. ### Publishing scoped packages -Scoped packages can be published from the CLI as of `npm@2` and can be -published to any registry that supports them, including the primary npm -registry. +Scoped packages can be published from the CLI as of `npm@2` and can be published to any registry that supports them, including the primary npm registry. (As of 2015-04-19, and with npm 2.0 or better, the primary npm registry **does** support scoped packages.) @@ -84,36 +74,27 @@ Publishing to a scope, you have two options: - Publishing to your user scope (example: `@username/module`) - Publishing to an organization scope (example: `@org/module`) -If publishing a public module to an organization scope, you must -first either create an organization with the name of the scope -that you'd like to publish to or be added to an existing organization -with the appropriate permissions. For example, if you'd like to -publish to `@org`, you would need to create the `org` organization -on npmjs.com prior to trying to publish. +If publishing a public module to an organization scope, you must first either create an organization with the name of the scope that you'd like to publish to or be added to an existing organization with the appropriate permissions. +For example, if you'd like to publish to `@org`, you would need to create the `org` organization on npmjs.com prior to trying to publish. -Scoped packages are not public by default. You will need to specify -`--access public` with the initial `npm publish` command. This will publish -the package and set access to `public` as if you had run `npm access public` -after publishing. You do not need to do this when publishing new versions of -an existing scoped package. +Scoped packages are not public by default. +You will need to specify +`--access public` with the initial `npm publish` command. +This will publish the package and set access to `public` as if you had run `npm access public` after publishing. +You do not need to do this when publishing new versions of an existing scoped package. #### Publishing private scoped packages to the npm registry -To publish a private scoped package to the npm registry, you must have -an [npm Private Modules](https://docs.npmjs.com/private-modules/intro) -account. +To publish a private scoped package to the npm registry, you must have an [npm Private Modules](https://docs.npmjs.com/private-modules/intro) account. You can then publish the module with `npm publish` or `npm publish ---access restricted`, and it will be present in the npm registry, with -restricted access. You can then change the access permissions, if -desired, with `npm access` or on the npmjs.com website. +--access restricted`, and it will be present in the npm registry, with restricted access. +You can then change the access permissions, if desired, with `npm access` or on the npmjs.com website. ### Associating a scope with a registry -Scopes can be associated with a separate registry. This allows you to -seamlessly use a mix of packages from the primary npm registry and one or more -private registries, such as [GitHub Packages](https://github.com/features/packages) or the open source [Verdaccio](https://verdaccio.org) -project. +Scopes can be associated with a separate registry. +This allows you to seamlessly use a mix of packages from the primary npm registry and one or more private registries, such as [GitHub Packages](https://github.com/features/packages) or the open source [Verdaccio](https://verdaccio.org) project. You can associate a scope with a registry at login, e.g. @@ -121,8 +102,7 @@ You can associate a scope with a registry at login, e.g. npm login --registry=http://reg.example.com --scope=@myco ``` -Scopes have a many-to-one relationship with registries: one registry can -host multiple scopes, but a scope only ever points to one registry. +Scopes have a many-to-one relationship with registries: one registry can host multiple scopes, but a scope only ever points to one registry. You can also associate a scope with a registry using `npm config`: @@ -130,8 +110,8 @@ You can also associate a scope with a registry using `npm config`: npm config set @myco:registry=http://reg.example.com ``` -Once a scope is associated with a registry, any `npm install` for a package -with that scope will request packages from that registry instead. Any +Once a scope is associated with a registry, any `npm install` for a package with that scope will request packages from that registry instead. +Any `npm publish` for a package name that contains the scope will be published to that registry instead. diff --git a/deps/npm/docs/content/using-npm/scripts.md b/deps/npm/docs/content/using-npm/scripts.md index 9ce43d5b9f82d0..03a25b33a678d6 100644 --- a/deps/npm/docs/content/using-npm/scripts.md +++ b/deps/npm/docs/content/using-npm/scripts.md @@ -6,13 +6,12 @@ description: How npm handles the "scripts" field ### Description -The `"scripts"` property of your `package.json` file supports a number -of built-in scripts and their preset life cycle events as well as -arbitrary scripts. These all can be executed by running -`npm run `. *Pre* and *post* -commands with matching names will be run for those as well (e.g. `premyscript`, -`myscript`, `postmyscript`). Scripts from dependencies can be run with -`npm explore -- npm run `. +The `"scripts"` property of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. +These all can be executed by running `npm run `. +*Pre* and *post* commands with matching names will be run for those as well (e.g. +`premyscript`, +`myscript`, `postmyscript`). +Scripts from dependencies can be run with `npm explore -- npm run `. ### Pre & Post Scripts @@ -30,42 +29,38 @@ To create "pre" or "post" scripts for any scripts defined in the } ``` -In this example `npm run compress` would execute these scripts as -described. +In this example `npm run compress` would execute these scripts as described. ### Life Cycle Scripts -There are some special life cycle scripts that happen only in certain -situations. These scripts happen in addition to the `pre`, `post`, and +There are some special life cycle scripts that happen only in certain situations. +These scripts happen in addition to the `pre`, `post`, and `` scripts. * `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`, `dependencies` **prepare** (since `npm@4.0.0`) -* Runs BEFORE the package is packed, i.e. during `npm publish` - and `npm pack` +* Runs BEFORE the package is packed, i.e. +during `npm publish` and `npm pack` * Runs on local `npm install` without any arguments * Runs AFTER `prepublish`, but BEFORE `prepublishOnly` * Runs for a package if it's being installed as a link through `npm install ` -* NOTE: If a package being installed through git 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. +* NOTE: If a package being installed through git 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. * As of `npm@7` these scripts run in the background. To see the output, run with: `--foreground-scripts`. **prepublish** (DEPRECATED) -* Does not run during `npm publish`, but does run during `npm ci` - and `npm install`. See below for more info. +* Does not run during `npm publish`, but does run during `npm ci` and `npm install`. +See below for more info. **prepublishOnly** * Runs BEFORE the package is prepared and packed, ONLY on `npm publish`. **prepack** * Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependency). -* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command. +* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, whereas, "`npm pack`" is a CLI defined command. **postpack** * Runs AFTER the tarball has been generated but before it is moved to its final destination (if at all, publish does not save the tarball locally) @@ -78,30 +73,33 @@ situations. These scripts happen in addition to the `pre`, `post`, **Deprecation Note: prepublish** -Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape). +Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). +It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). +As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. +A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape). See for a much lengthier justification, with further reading, for this change. **Use Cases** -If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a `prepublish` script. This includes tasks such as: +If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a `prepublish` script. +This includes tasks such as: * Compiling CoffeeScript source code into JavaScript. * Creating minified versions of JavaScript source code. * Fetching remote resources that your package will use. -The advantage of doing these things at `prepublish` time is that they can be done once, in a single place, thus reducing complexity and variability. Additionally, this means that: +The advantage of doing these things at `prepublish` time is that they can be done once, in a single place, thus reducing complexity and variability. +Additionally, this means that: -* You can depend on `coffee-script` as a `devDependency`, and thus - your users don't need to have it installed. -* You don't need to include minifiers in your package, reducing - the size for your users. -* You don't need to rely on your users having `curl` or `wget` or - other system tools on the target machines. +* You can depend on `coffee-script` as a `devDependency`, and thus your users don't need to have it installed. +* You don't need to include minifiers in your package, reducing the size for your users. +* You don't need to rely on your users having `curl` or `wget` or other system tools on the target machines. #### Dependencies -The `dependencies` script is run any time an `npm` command causes changes to the `node_modules` directory. It is run AFTER the changes have been applied and the `package.json` and `package-lock.json` files have been updated. +The `dependencies` script is run any time an `npm` command causes changes to the `node_modules` directory. +It is run AFTER the changes have been applied and the `package.json` and `package-lock.json` files have been updated. ### Life Cycle Operation Order @@ -119,7 +117,7 @@ The `dependencies` script is run any time an `npm` command causes changes to the * `prepare` * `postprepare` - These all run after the actual installation of modules into +These all run after the actual installation of modules into `node_modules`, in order, with no internal actions happening in between #### [`npm diff`](/commands/npm-diff) @@ -138,10 +136,7 @@ These also run when you run `npm install -g ` * `prepare` * `postprepare` -If there is a `binding.gyp` file in the root of your package and you -haven't defined your own `install` or `preinstall` scripts, npm will -default the `install` command to compile using node-gyp via `node-gyp -rebuild` +If there is a `binding.gyp` file in the root of your package and you haven't defined your own `install` or `preinstall` scripts, npm will default the `install` command to compile using node-gyp via `node-gyp rebuild` These are run from the scripts of `` @@ -167,14 +162,13 @@ These are run from the scripts of `` * `postinstall` * `prepare` -`prepare` is only run if the current directory is a symlink (e.g. with -linked packages) +`prepare` is only run if the current directory is a symlink (e.g. +with linked packages) #### [`npm restart`](/commands/npm-restart) -If there is a `restart` script defined, these events are run, otherwise -`stop` and `start` are both run if present, including their `pre` and -`post` iterations) +If there is a `restart` script defined, these events are run; otherwise, +`stop` and `start` are both run if present, including their `pre` and `post` iterations) * `prerestart` * `restart` @@ -192,9 +186,8 @@ If there is a `restart` script defined, these events are run, otherwise * `start` * `poststart` -If there is a `server.js` file in the root of your package, then npm -will default the `start` command to `node server.js`. `prestart` and -`poststart` will still run in this case. +If there is a `server.js` file in the root of your package, then npm will default the `start` command to `node server.js`. +`prestart` and `poststart` will still run in this case. #### [`npm stop`](/commands/npm-stop) @@ -216,13 +209,15 @@ will default the `start` command to `node server.js`. `prestart` and #### A Note on a lack of [`npm uninstall`](/commands/npm-uninstall) scripts -While npm v6 had `uninstall` lifecycle scripts, npm v7 does not. Removal of a package can happen for a wide variety of reasons, and there's no clear way to currently give the script enough context to be useful. +While npm v6 had `uninstall` lifecycle scripts, npm v7 does not. +Removal of a package can happen for a wide variety of reasons, and there's no clear way to currently give the script enough context to be useful. + Reasons for a package removal include: * a user directly uninstalled this package -* a user uninstalled a dependant package and so this dependency is being uninstalled -* a user uninstalled a dependant package but another package also depends on this version +* a user uninstalled a dependent package and so this dependency is being uninstalled +* a user uninstalled a dependent package but another package also depends on this version * this version has been merged as a duplicate with another version * etc. @@ -230,13 +225,15 @@ Due to the lack of necessary context, `uninstall` lifecycle scripts are not impl ### Working Directory for Scripts -Scripts are always run from the root of the package folder, regardless of what the current working directory is when `npm` is invoked. This means your scripts can reliably assume they are running in the package root. +Scripts are always run from the root of the package folder, regardless of what the current working directory is when `npm` is invoked. +This means your scripts can reliably assume they are running in the package root. If you want your script to behave differently based on the directory you were in when you ran `npm`, you can use the `INIT_CWD` environment variable, which holds the full path you were in when you ran `npm run`. #### Historical Behavior in Older npm Versions -For npm v6 and earlier, scripts were generally run from the root of the package, but there were rare cases and bugs in older versions where this was not guaranteed. If your package must support very old npm versions, you may wish to add a safeguard in your scripts (for example, by checking process.cwd()). +For npm v6 and earlier, scripts were generally run from the root of the package, but there were rare cases and bugs in older versions where this was not guaranteed. +If your package must support very old npm versions, you may wish to add a safeguard in your scripts (for example, by checking process.cwd()). For more details, see: - [npm v7 release notes](https://github.com/npm/cli/releases/tag/v7.0.0) @@ -244,20 +241,16 @@ For more details, see: ### User -When npm is run as root, scripts are always run with the effective uid -and gid of the working directory owner. +When npm is run as root, scripts are always run with the effective uid and gid of the working directory owner. ### Environment -Package scripts run in an environment where many pieces of information -are made available regarding the setup of npm and the current state of -the process. +Package scripts run in an environment where many pieces of information are made available regarding the setup of npm and the current state of the process. #### path -If you depend on modules that define executable scripts, like test -suites, then those executables will be added to the `PATH` for -executing the scripts. So, if your package.json has this: +If you depend on modules that define executable scripts, like test suites, then those executables will be added to the `PATH` for executing the scripts. +So, if your package.json has this: ```json { @@ -271,31 +264,22 @@ executing the scripts. So, if your package.json has this: } ``` -then you could run `npm start` to execute the `bar` script, which is -exported into the `node_modules/.bin` directory on `npm install`. +then you could run `npm start` to execute the `bar` script, which is exported into the `node_modules/.bin` directory on `npm install`. #### package.json vars -The package.json fields are tacked onto the `npm_package_` prefix. So, -for instance, if you had `{"name":"foo", "version":"1.2.5"}` in your -package.json file, then your package scripts would have the -`npm_package_name` environment variable set to "foo", and the -`npm_package_version` set to "1.2.5". You can access these variables -in your code with `process.env.npm_package_name` and -`process.env.npm_package_version`, and so on for other fields. +The package.json fields are tacked onto the `npm_package_` prefix. +So, for instance, if you had `{"name":"foo", "version":"1.2.5"}` in your package.json file, then your package scripts would have the `npm_package_name` environment variable set to "foo", and the `npm_package_version` set to "1.2.5". You can access these variables in your code with `process.env.npm_package_name` and `process.env.npm_package_version`, and so on for other fields. See [`package.json`](/configuring-npm/package-json) for more on package configs. #### current lifecycle event -Lastly, the `npm_lifecycle_event` environment variable is set to -whichever stage of the cycle is being executed. So, you could have a -single script used for different parts of the process which switches -based on what's currently happening. +Lastly, the `npm_lifecycle_event` environment variable is set to whichever stage of the cycle is being executed. +So, you could have a single script used for different parts of the process which switches based on what's currently happening. Objects are flattened following this format, so if you had -`{"scripts":{"install":"foo.js"}}` in your package.json, then you'd -see this in the script: +`{"scripts":{"install":"foo.js"}}` in your package.json, then you'd see this in the script: ```bash process.env.npm_package_scripts_install === "foo.js" @@ -314,13 +298,12 @@ For example, if your package.json contains this: } ``` -then `scripts/install.js` will be called for the install and post-install -stages of the lifecycle. Since `scripts/install.js` is running for two -different phases, it would be wise in this case to look at the +then `scripts/install.js` will be called for the install and post-install stages of the lifecycle. +Since `scripts/install.js` is running for two different phases, it would be wise in this case to look at the `npm_lifecycle_event` environment variable. -If you want to run a make command, you can do so. This works just -fine: +If you want to run a make command, you can do so. +This works just fine: ```json { @@ -334,36 +317,30 @@ fine: ### Exiting -Scripts are run by passing the line as a script argument to `/bin/sh` on POSIX systems or `cmd.exe` on Windows. You can control which shell is used by setting the [`script-shell`](/using-npm/config#script-shell) configuration option. +Scripts are run by passing the line as a script argument to `/bin/sh` on POSIX systems or `cmd.exe` on Windows. +You can control which shell is used by setting the [`script-shell`](/using-npm/config#script-shell) configuration option. -If the script exits with a code other than 0, then this will abort the -process. +If the script exits with a code other than 0, then this will abort the process. -Note that these script files don't have to be Node.js or even -JavaScript programs. They just have to be some kind of executable -file. +Note that these script files don't have to be Node.js or even JavaScript programs. +They just have to be some kind of executable file. ### Best Practices * Don't exit with a non-zero error code unless you *really* mean it. - If the failure is minor or only will prevent some optional features, then - it's better to just print a warning and exit successfully. -* Try not to use scripts to do what npm can do for you. Read through - [`package.json`](/configuring-npm/package-json) to see all the things that you can specify and enable - by simply describing your package appropriately. In general, this - will lead to a more robust and consistent state. -* Inspect the env to determine where to put things. For instance, if - the `npm_config_binroot` environment variable is set to `/home/user/bin`, then - don't try to install executables into `/usr/local/bin`. The user - probably set it up that way for a reason. -* Don't prefix your script commands with "sudo". If root permissions - are required for some reason, then it'll fail with that error, and - the user will sudo the npm command in question. -* Don't use `install`. Use a `.gyp` file for compilation, and `prepare` - for anything else. You should almost never have to explicitly set a - preinstall or install script. If you are doing this, please consider if - there is another option. The only valid use of `install` or `preinstall` - scripts is for compilation which must be done on the target architecture. + If the failure is minor or only will prevent some optional features, then it's better to just print a warning and exit successfully. +* Try not to use scripts to do what npm can do for you. +Read through [`package.json`](/configuring-npm/package-json) to see all the things that you can specify and enable by simply describing your package appropriately. +In general, this will lead to a more robust and consistent state. +* Inspect the env to determine where to put things. +For instance, if the `npm_config_binroot` environment variable is set to `/home/user/bin`, then don't try to install executables into `/usr/local/bin`. +The user probably set it up that way for a reason. +* Don't prefix your script commands with "sudo". If root permissions are required for some reason, then it'll fail with that error, and the user will sudo the npm command in question. +* Don't use `install`. +Use a `.gyp` file for compilation, and `prepare` for anything else. +You should almost never have to explicitly set a preinstall or install script. +If you are doing this, please consider if there is another option. +The only valid use of `install` or `preinstall` scripts is for compilation which must be done on the target architecture. ### See Also diff --git a/deps/npm/docs/content/using-npm/workspaces.md b/deps/npm/docs/content/using-npm/workspaces.md index 34819b801e5fbc..e7f87ed2609cc2 100644 --- a/deps/npm/docs/content/using-npm/workspaces.md +++ b/deps/npm/docs/content/using-npm/workspaces.md @@ -6,25 +6,17 @@ description: Working with workspaces ### Description -**Workspaces** is a generic term that refers to the set of features in the -npm cli that provides support for managing multiple packages from your local -file system from within a singular top-level, root package. - -This set of features makes up for a much more streamlined workflow handling -linked packages from the local file system. It automates the linking process -as part of `npm install` and removes the need to manually use `npm link` in -order to add references to packages that should be symlinked into the current -`node_modules` folder. - -We also refer to these packages being auto-symlinked during `npm install` as a -single **workspace**, meaning it's a nested package within the current local -file system that is explicitly defined in the [`package.json`](/configuring-npm/package-json#workspaces) +**Workspaces** is a generic term that refers to the set of features in the npm cli that provides support for managing multiple packages from your local file system from within a singular top-level, root package. + +This set of features makes up for a much more streamlined workflow handling linked packages from the local file system. +It automates the linking process as part of `npm install` and removes the need to manually use `npm link` in order to add references to packages that should be symlinked into the current `node_modules` folder. + +We also refer to these packages being auto-symlinked during `npm install` as a single **workspace**, meaning it's a nested package within the current local file system that is explicitly defined in the [`package.json`](/configuring-npm/package-json#workspaces) `workspaces` configuration. ### Defining workspaces -Workspaces are usually defined via the `workspaces` property of the -[`package.json`](/configuring-npm/package-json#workspaces) file, e.g: +Workspaces are usually defined via the `workspaces` property of the [`package.json`](/configuring-npm/package-json#workspaces) file, e.g: ```json { @@ -35,9 +27,7 @@ Workspaces are usually defined via the `workspaces` property of the } ``` -Given the above `package.json` example living at a current working -directory `.` that contains a folder named `packages/a` that itself contains -a `package.json` inside it, defining a Node.js package, e.g: +Given the above `package.json` example living at a current working directory `.` that contains a folder named `packages/a` that itself contains a `package.json` inside it, defining a Node.js package, e.g: ``` . @@ -47,12 +37,9 @@ a `package.json` inside it, defining a Node.js package, e.g: | `-- package.json ``` -The expected result once running `npm install` in this current working -directory `.` is that the folder `packages/a` will get symlinked to the -`node_modules` folder of the current working dir. +The expected result once running `npm install` in this current working directory `.` is that the folder `packages/a` will get symlinked to the `node_modules` folder of the current working dir. -Below is a post `npm install` example, given that same previous example -structure of files and folders: +Below is a post `npm install` example, given that same previous example structure of files and folders: ``` . @@ -67,22 +54,19 @@ structure of files and folders: ### Getting started with workspaces -You may automate the required steps to define a new workspace using -[npm init](/commands/npm-init). For example in a project that already has a -`package.json` defined you can run: +You may automate the required steps to define a new workspace using [npm init](/commands/npm-init). +For example in a project that already has a `package.json` defined you can run: ``` npm init -w ./packages/a ``` -This command will create the missing folders and a new `package.json` -file (if needed) while also making sure to properly configure the +This command will create the missing folders and a new `package.json` file (if needed) while also making sure to properly configure the `"workspaces"` property of your root project `package.json`. ### Adding dependencies to a workspace -It's possible to directly add/remove/update dependencies of your workspaces -using the [`workspace` config](/using-npm/config#workspace). +It's possible to directly add/remove/update dependencies of your workspaces using the [`workspace` config](/using-npm/config#workspace). For example, assuming the following structure: @@ -96,24 +80,18 @@ For example, assuming the following structure: `-- package.json ``` -If you want to add a dependency named `abbrev` from the registry as a -dependency of your workspace **a**, you may use the workspace config to tell -the npm installer that package should be added as a dependency of the provided -workspace: +If you want to add a dependency named `abbrev` from the registry as a dependency of your workspace **a**, you may use the workspace config to tell the npm installer that package should be added as a dependency of the provided workspace: ``` npm install abbrev -w a ``` -Note: other installing commands such as `uninstall`, `ci`, etc will also -respect the provided `workspace` configuration. +Note: other installing commands such as `uninstall`, `ci`, etc will also respect the provided `workspace` configuration. ### Using workspaces -Given the [specifics of how Node.js handles module resolution](https://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together) it's possible to consume any defined workspace -by its declared `package.json` `name`. Continuing from the example defined -above, let's also create a Node.js script that will require the workspace `a` -example module, e.g: +Given the [specifics of how Node.js handles module resolution](https://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together) it's possible to consume any defined workspace by its declared `package.json` `name`. +Continuing from the example defined above, let's also create a Node.js script that will require the workspace `a` example module, e.g: ``` // ./packages/a/index.js @@ -129,19 +107,15 @@ When running it with: `node lib/index.js` This demonstrates how the nature of `node_modules` resolution allows for -**workspaces** to enable a portable workflow for requiring each **workspace** -in such a way that is also easy to [publish](/commands/npm-publish) these -nested workspaces to be consumed elsewhere. +**workspaces** to enable a portable workflow for requiring each **workspace** in such a way that is also easy to [publish](/commands/npm-publish) these nested workspaces to be consumed elsewhere. ### Running commands in the context of workspaces -You can use the `workspace` configuration option to run commands in the context -of a configured workspace. -Additionally, if your current directory is in a workspace, the `workspace` -configuration is implicitly set, and `prefix` is set to the root workspace. +You can use the `workspace` configuration option to run commands in the context of a configured workspace. +Additionally, if your current directory is in a workspace, the `workspace` configuration is implicitly set, and `prefix` is set to the root workspace. -Following is a quick example on how to use the `npm run` command in the context -of nested workspaces. For a project containing multiple workspaces, e.g: +Following is a quick example on how to use the `npm run` command in the context of nested workspaces. +For a project containing multiple workspaces, e.g: ``` . @@ -153,8 +127,8 @@ of nested workspaces. For a project containing multiple workspaces, e.g: `-- package.json ``` -By running a command using the `workspace` option, it's possible to run the -given command in the context of that specific workspace. e.g: +By running a command using the `workspace` option, it's possible to run the given command in the context of that specific workspace. +e.g: ``` npm run test --workspace=a @@ -169,8 +143,7 @@ cd packages/a && npm run test Either will run the `test` script defined within the `./packages/a/package.json` file. -Please note that you can also specify this argument multiple times in the -command-line in order to target multiple workspaces, e.g: +Please note that you can also specify this argument multiple times in the command-line in order to target multiple workspaces, e.g: ``` npm run test --workspace=a --workspace=b @@ -181,9 +154,8 @@ Or run the command for each workspace within the 'packages' folder: npm run test --workspace=packages ``` -It's also possible to use the `workspaces` (plural) configuration option to -enable the same behavior but running that command in the context of **all** -configured workspaces. e.g: +It's also possible to use the `workspaces` (plural) configuration option to enable the same behavior but running that command in the context of **all** configured workspaces. +e.g: ``` npm run test --workspaces diff --git a/deps/npm/docs/lib/index.js b/deps/npm/docs/lib/index.js index b88d20cca35585..5e40f48882cad4 100644 --- a/deps/npm/docs/lib/index.js +++ b/deps/npm/docs/lib/index.js @@ -38,7 +38,7 @@ const getCommandByDoc = (docFile, docExt) => { // special case for `npx`: // `npx` is not technically a command in and of itself, - // so it just needs the usage of npm exex + // so it just needs the usage of npm exec const srcName = name === 'npx' ? 'exec' : name const { params, usage = [''], workspaces } = require(`../../lib/commands/${srcName}`) const usagePrefix = name === 'npx' ? 'npx' : `npm ${name}` diff --git a/deps/npm/docs/output/commands/npm-access.html b/deps/npm/docs/output/commands/npm-access.html index 6de939b0cc21a8..69d3f84ca3cfab 100644 --- a/deps/npm/docs/output/commands/npm-access.html +++ b/deps/npm/docs/output/commands/npm-access.html @@ -141,9 +141,9 @@
-

+

npm-access - @11.6.1 + @11.6.2

Set access level on published packages
@@ -165,58 +165,23 @@

Table of contents

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.

+

For all of the subcommands, npm access will perform actions on the packages in the current working directory if no package name is passed to the subcommand.

    -
  • -

    public / restricted (deprecated): -Set a package to be either publicly accessible or restricted.

    -
    • -
  • -

    grant / revoke (deprecated): -Add or remove the ability of users and teams to have read-only or read-write -access to a package.

    -
    • -
  • -

    2fa-required / 2fa-not-required (deprecated): -Configure whether a package requires that anyone publishing it have two-factor -authentication enabled on their account.

    -
    • -
  • -

    ls-packages (deprecated): -Show all of the packages a user or a team is able to access, along with the -access level, except for read-only public packages (it won't print the whole -registry listing)

    -
    • -
  • -

    ls-collaborators (deprecated): -Show all of the access privileges for a package. Will only show permissions -for packages to which you have at least read access. If <user> is passed in, -the list is filtered only to teams that user happens to belong to.

    -
    • -
  • -

    edit (not implemented)

    -
    • +
  • 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>.

+

npm access always operates directly on the current registry, configurable from the command line using --registry=<registry url>.

Unscoped packages are always public.

-

Scoped packages default to restricted, but you can either publish them as -public using npm publish --access=public, or set their access as public using -npm access public after the initial publish.

+

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.
    • +
  • 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 +

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

@@ -227,8 +192,8 @@

json

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.
    • +
  • 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

@@ -236,10 +201,10 @@

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.

    +

    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/"
      • diff --git a/deps/npm/docs/output/commands/npm-adduser.html b/deps/npm/docs/output/commands/npm-adduser.html index 3134c49fd177c2..161be0cbf13350 100644 --- a/deps/npm/docs/output/commands/npm-adduser.html +++ b/deps/npm/docs/output/commands/npm-adduser.html @@ -141,9 +141,9 @@
      -

      +

      npm-adduser - @11.6.1 + @11.6.2

      Add a registry user account
      @@ -160,12 +160,11 @@

      Table of contents

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

      -

      When you run npm adduser, the CLI automatically generates a legacy token of publish type. For more information, see About legacy tokens.

      -

      When using legacy for your auth-type, the username, password, and -email are read in from prompts.

      +

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

      +

      When you run npm adduser, the CLI automatically generates a legacy token of publish type. +For more information, see About legacy tokens.

      +

      When using legacy for your auth-type, the username, password, and email are read in from prompts.

      Configuration

      registry

        @@ -199,8 +198,8 @@

        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.

      +

      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
        • diff --git a/deps/npm/docs/output/commands/npm-audit.html b/deps/npm/docs/output/commands/npm-audit.html index bc9b25ab27fedb..c98c2a9720c770 100644 --- a/deps/npm/docs/output/commands/npm-audit.html +++ b/deps/npm/docs/output/commands/npm-audit.html @@ -141,9 +141,9 @@
        -

        +

        npm-audit - @11.6.1 + @11.6.2

        Run a security audit
        @@ -157,37 +157,26 @@

        Table of contents

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

        +

        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.

        +

        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:

        $ 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 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:
          2. @@ -218,39 +207,26 @@

          Audit Signatures

          Keys response:

          • expires: null or a simplified extended ISO 8601 format: YYYY-MM-DDTHH:mm:ss.sssZ
            • -
          • keydid: sha256 fingerprint of the public key
            • +
          • 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.

          Audit Endpoints

          -

          There are two audit endpoints that npm may use to fetch vulnerability -information: the Bulk Advisory endpoint and the Quick Audit endpoint.

          +

          There are two audit endpoints that npm may use to fetch vulnerability information: the Bulk Advisory endpoint and the Quick Audit endpoint.

          Bulk Advisory Endpoint

          -

          As of version 7, npm uses the much faster Bulk Advisory endpoint to -optimize the speed of calculating audit results.

          -

          npm will generate a JSON payload with the name and list of versions of each -package in the tree, and POST it to the default configured registry at -the path /-/npm/v1/security/advisories/bulk.

          -

          Any packages in the tree that do not have a version field in their -package.json file will be ignored. If any --omit options are specified -(either via the --omit config, or one of the -shorthands such as --production, --only=dev, and so on), then packages will -be omitted from the submitted payload as appropriate.

          -

          If the registry responds with an error, or with an invalid response, then -npm will attempt to load advisory data from the Quick Audit endpoint.

          -

          The expected result will contain a set of advisory objects for each -dependency that matches the advisory range. Each advisory object contains -a name, url, id, severity, vulnerable_versions, and title.

          -

          npm then uses these advisory objects to calculate vulnerabilities and -meta-vulnerabilities of the dependencies within the tree.

          +

          As of version 7, npm uses the much faster Bulk Advisory endpoint to optimize the speed of calculating audit results.

          +

          npm will generate a JSON payload with the name and list of versions of each package in the tree, and POST it to the default configured registry at the path /-/npm/v1/security/advisories/bulk.

          +

          Any packages in the tree that do not have a version field in their package.json file will be ignored. +If any --omit options are specified (either via the --omit config, or one of the shorthands such as --production, --only=dev, and so on), then packages will be omitted from the submitted payload as appropriate.

          +

          If the registry responds with an error, or with an invalid response, then npm will attempt to load advisory data from the Quick Audit endpoint.

          +

          The expected result will contain a set of advisory objects for each dependency that matches the advisory range. +Each advisory object contains a name, url, id, severity, vulnerable_versions, and title.

          +

          npm then uses these advisory objects to calculate vulnerabilities and meta-vulnerabilities of the dependencies within the tree.

          Quick Audit Endpoint

          -

          If the Bulk Advisory endpoint returns an error, or invalid data, npm will -attempt to load advisory data from the Quick Audit endpoint, which is -considerably slower in most cases.

          -

          The full package tree as found in package-lock.json is submitted, along -with the following pieces of additional metadata:

          +

          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
            • @@ -261,63 +237,38 @@

            Quick Audit Endpoint

            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.

            +

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

            npm uses the @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.

            +

            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.

            +

            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.

            Examples

            -

            Scan your project for vulnerabilities and automatically install any compatible -updates to vulnerable dependencies:

            +

            Scan your project for vulnerabilities and automatically install any compatible updates to vulnerable dependencies:

            $ npm audit fix
            -

            Run audit fix without modifying node_modules, but still updating the -pkglock:

            +

            Run audit fix without modifying node_modules, but still updating the pkglock:

            $ npm audit fix --package-lock-only

            Skip updating devDependencies:

            $ npm audit fix --only=prod
            -

            Have audit fix install SemVer-major updates to toplevel dependencies, not -just SemVer-compatible ones:

            +

            Have audit fix install SemVer-major updates to toplevel dependencies, not just SemVer-compatible ones:

            $ 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:

            +

            Do a dry run to get an idea of what audit fix will do, and also output install information in JSON format:

            $ npm audit fix --dry-run --json
            -

            Scan your project for vulnerabilities and just show the details, without -fixing anything:

            +

            Scan your project for vulnerabilities and just show the details, without fixing anything:

            $ npm audit

            Get the detailed audit report in JSON format:

            @@ -332,19 +283,20 @@

            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.

          +

          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.

          +

          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
            • @@ -356,14 +308,16 @@

            force

          • 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 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.
            • +
          • 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).
            • @@ -377,8 +331,8 @@

            json

          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.
            • +
          • 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

          @@ -386,71 +340,77 @@

          package-lock-only

        2. Default: false
        3. Type: Boolean
      -

      If set to true, the current operation will only use the package-lock.json, -ignoring node_modules.

      +

      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.

      +

      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.

      +

      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.
        • +'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.

      +

      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)
        • +
      • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
      -

      Option that allows for defining which types of dependencies to install.

      +

      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.

      +

      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
        • +
      • 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.

      +

      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.

      +

      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.

      +

      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
        • @@ -458,9 +418,9 @@

        workspace

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

      +

      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

        @@ -469,13 +429,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -484,18 +445,19 @@

      include-workspace-root

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

    +

    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.

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

    +

    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
      • diff --git a/deps/npm/docs/output/commands/npm-bugs.html b/deps/npm/docs/output/commands/npm-bugs.html index a2a8d3ff15d42a..a1464fa983236a 100644 --- a/deps/npm/docs/output/commands/npm-bugs.html +++ b/deps/npm/docs/output/commands/npm-bugs.html @@ -141,9 +141,9 @@
      -

      +

      npm-bugs - @11.6.1 + @11.6.2

      Report bugs for a package in a web browser
      @@ -159,11 +159,8 @@

      Table of contents

      alias: issues

      Description

      -

      This command tries to guess at the likely location of a package's bug -tracker URL or the mailto URL of the support email, and then tries to -open it using the --browser config param. If no -package name is provided, it will search for a package.json in the current -folder and use the name property.

      +

      This command tries to guess at the likely location of a package's bug tracker URL or the mailto URL of the support email, and then tries to open it using the --browser config param. +If no package name is provided, it will search for a package.json in the current folder and use the name property.

      Configuration

      browser

        @@ -185,9 +182,9 @@

        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.

      +

      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
        • @@ -195,9 +192,9 @@

        workspace

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

      +

      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

        @@ -206,13 +203,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -221,9 +219,10 @@

      include-workspace-root

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

    +

    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

      diff --git a/deps/npm/docs/output/commands/npm-cache.html b/deps/npm/docs/output/commands/npm-cache.html index 24bc76d6f68f38..312cff4a1bce7a 100644 --- a/deps/npm/docs/output/commands/npm-cache.html +++ b/deps/npm/docs/output/commands/npm-cache.html @@ -141,9 +141,9 @@
      -

      +

      npm-cache - @11.6.1 + @11.6.2

      Manipulates packages cache
      @@ -170,11 +170,13 @@

      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.

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

        +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: @@ -201,12 +203,19 @@

        npm cache npx

      Details

      -

      npm stores cache data in an opaque directory within the configured cache, named _cacache. This directory is a 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 stores cache data in an opaque directory within the configured cache, named _cacache. +This directory is a 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.

      +

      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

      diff --git a/deps/npm/docs/output/commands/npm-ci.html b/deps/npm/docs/output/commands/npm-ci.html index d0e1018f3e85aa..95fea4d7bb9bcb 100644 --- a/deps/npm/docs/output/commands/npm-ci.html +++ b/deps/npm/docs/output/commands/npm-ci.html @@ -141,9 +141,9 @@
      -

      +

      npm-ci - @11.6.1 + @11.6.2

      Clean install a project
      @@ -159,28 +159,21 @@

      Table of contents

      aliases: clean-install, ic, install-clean, isntall-clean

      Description

      -

      This command is similar to 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.

      +

      This command is similar to 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.
        • +
      • 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, +

      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

      @@ -210,11 +203,12 @@

      install-strategy

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

    +(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
      • @@ -222,10 +216,10 @@

      legacy-bundling

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

    +

    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
      • @@ -233,77 +227,82 @@

      global-style

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

    +

    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.
      • +'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.

    +

    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)
      • +
    • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
    -

    Option that allows for defining which types of dependencies to install.

    +

    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.

    +

    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.

    +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
      • +
    • 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.

    +

    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.

    +

    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 for details on what is -submitted.

    +

    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 for details +on what is submitted.

    • Default: true
      • @@ -311,35 +310,37 @@

    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.

    +

    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 for details.

    +acknowledging the number of dependencies looking for funding. See +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.

    +

    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.

    +

    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
      • @@ -347,9 +348,9 @@

      workspace

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

    +

    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

      @@ -358,13 +359,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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

    @@ -373,18 +375,19 @@

    include-workspace-root

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

    +

    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.

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

    +

    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
      • diff --git a/deps/npm/docs/output/commands/npm-completion.html b/deps/npm/docs/output/commands/npm-completion.html index 6d9d5e216fc254..62c34b3e664752 100644 --- a/deps/npm/docs/output/commands/npm-completion.html +++ b/deps/npm/docs/output/commands/npm-completion.html @@ -141,9 +141,9 @@
      -

      +

      npm-completion - @11.6.1 + @11.6.2

      Tab Completion for npm
      @@ -159,20 +159,15 @@

      Table of contents

      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:

      +

      The synopsis above loads the completions into your current shell. +Adding it to your ~/.bashrc or ~/.zshrc will make the completions available everywhere:

      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 +

      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.

      +

      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
        • diff --git a/deps/npm/docs/output/commands/npm-config.html b/deps/npm/docs/output/commands/npm-config.html index 9b9a8b83aa7fc9..e8551dcacd9e96 100644 --- a/deps/npm/docs/output/commands/npm-config.html +++ b/deps/npm/docs/output/commands/npm-config.html @@ -141,9 +141,9 @@
        -

        +

        npm-config - @11.6.1 + @11.6.2

        Manage the npm configuration files
        @@ -165,38 +165,33 @@

        Table of contents

        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 for more information about the npmrc -files.

        -

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

        +

        npm gets its config settings from the command line, environment variables, npmrc files, and in some cases, the package.json file.

        +

        See npmrc for more information about the npmrc files.

        +

        See 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

        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 is passed.

        +

        Sets each of the config keys to the value provided. +Modifies the user configuration file unless 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.

        +

        Note: for backwards compatibility, npm config set key value is supported as an alias for npm config set key=value.

        get

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

        npm config list
        -

        Show all the config settings. Use -l to also show defaults. Use --json -to show the settings in json format.

        +

        Show all the config settings. +Use -l to also show defaults. +Use --json to show the settings in json format.

        delete

        npm config delete key [key ...]
        @@ -204,14 +199,14 @@

        delete

        edit

        npm config edit
        -

        Opens the config file in an editor. Use the --global flag to edit the -global config.

        +

        Opens the config file in an editor. +Use the --global flag to edit the global config.

        fix

        npm config fix
        -

        Attempts to repair invalid configuration items. Usually this means -attaching authentication config (i.e. _auth, _authToken) to the -configured registry.

        +

        Attempts to repair invalid configuration items. +Usually this means attaching authentication config (i.e. +_auth, _authToken) to the configured registry.

        Configuration

        json

          @@ -220,8 +215,8 @@

          json

        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.
          • +
        • 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

        @@ -229,12 +224,13 @@

        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 for more on the differences in behavior.

      +

      Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

        -
      • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
        • +
      • 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
      @@ -247,17 +243,18 @@

      editor

      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"
        • +
      • 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 for more on the differences in behavior.

      +

      When set to "global" mode, packages are installed into the prefix +folder instead of the current working directory. See +folders for more on the differences in +behavior.

        -
      • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
        • +
      • 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
      diff --git a/deps/npm/docs/output/commands/npm-dedupe.html b/deps/npm/docs/output/commands/npm-dedupe.html index 39d4a8215f93ae..761d5129fac3b3 100644 --- a/deps/npm/docs/output/commands/npm-dedupe.html +++ b/deps/npm/docs/output/commands/npm-dedupe.html @@ -141,9 +141,9 @@
      -

      +

      npm-dedupe - @11.6.1 + @11.6.2

      Reduce duplication in the package tree
      @@ -159,9 +159,7 @@

      Table of contents

      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.

      +

      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
@@ -175,9 +173,7 @@ 
      Description
      
 +-- 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.

      +

      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
@@ -185,23 +181,15 @@ 
      Description
      
 `-- 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.

      +

      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.

      +

      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

        @@ -209,11 +197,12 @@

        install-strategy

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

      +(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
        • @@ -221,10 +210,10 @@

        legacy-bundling

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

      +

      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
        • @@ -232,73 +221,78 @@

        global-style

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

      +

      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.

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

      +

      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.
        • +'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.

      +

      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)
        • +
      • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
      -

      Option that allows for defining which types of dependencies to install.

      +

      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.

      +

      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.

      +

      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 for details on what is -submitted.

      +

      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 for details +on what is submitted.

      • Default: true
        • @@ -306,35 +300,37 @@

      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.

      +

      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 for details.

      +acknowledging the number of dependencies looking for funding. See +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.

      +

      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.

      +

      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
        • @@ -342,9 +338,9 @@

        workspace

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

      +

      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

        @@ -353,13 +349,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -368,18 +365,19 @@

      include-workspace-root

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

    +

    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.

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

    +

    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
      • diff --git a/deps/npm/docs/output/commands/npm-deprecate.html b/deps/npm/docs/output/commands/npm-deprecate.html index 8e849c1f4310b9..c3292a349b8cc7 100644 --- a/deps/npm/docs/output/commands/npm-deprecate.html +++ b/deps/npm/docs/output/commands/npm-deprecate.html @@ -141,9 +141,9 @@
      -

      +

      npm-deprecate - @11.6.1 + @11.6.2

      Deprecate a version of a package
      @@ -158,22 +158,19 @@

      Table of contents

      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 as well as specific -versions, so you can do something like this:

      +

      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 as well as specific versions, so you can do something like this:

      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:

      +

      SemVer ranges passed to this command are interpreted such that they do include prerelease versions. +For example:

      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.

      +

      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

        @@ -186,21 +183,22 @@

        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.

      +

      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.

      +

      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
        • diff --git a/deps/npm/docs/output/commands/npm-diff.html b/deps/npm/docs/output/commands/npm-diff.html index 5aed1d2d24efa6..18e0aaf07f306d 100644 --- a/deps/npm/docs/output/commands/npm-diff.html +++ b/deps/npm/docs/output/commands/npm-diff.html @@ -141,9 +141,9 @@
        -

        +

        npm-diff - @11.6.1 + @11.6.2

        The registry diff command
        @@ -157,20 +157,14 @@

        Table of contents

        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.

        +

        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:

          +

          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:

          npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1

          On success, output looks like:

          @@ -187,50 +181,29 @@

          Description

          "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:

          +

          Given the flexible nature of npm specs, you can also target local directories or git repos just like when using npm install:

          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.

          +

          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.

          +

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

          +

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

          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.

          +

          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:

          +

          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:

          npm diff --diff=pkg@2.0.0

          It will effectively be an alias to @@ -238,30 +211,20 @@

          Description

        • 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:

          +

          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:

          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.

        +

        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:

        +

        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:

        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.

        +

        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

          @@ -318,12 +281,13 @@

          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 for more on the differences in behavior.

        +

        Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

          -
        • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
          • +
        • 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
        @@ -332,21 +296,21 @@

        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.

      +

      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.

      +

      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.

      +

      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
        • @@ -354,9 +318,9 @@

        workspace

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

      +

      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

        @@ -365,13 +329,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -380,9 +345,10 @@

      include-workspace-root

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

    +

    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

      diff --git a/deps/npm/docs/output/commands/npm-dist-tag.html b/deps/npm/docs/output/commands/npm-dist-tag.html index ea71a6cd2f07e0..b7d2d1bf7cec7c 100644 --- a/deps/npm/docs/output/commands/npm-dist-tag.html +++ b/deps/npm/docs/output/commands/npm-dist-tag.html @@ -141,9 +141,9 @@
      -

      +

      npm-dist-tag - @11.6.1 + @11.6.2

      Modify package distribution tags
      @@ -164,68 +164,52 @@

      Description

      Add, remove, and enumerate distribution tags on a package:

      • -

        add: Tags the specified version of the package with the specified tag, -or the --tag config if not specified. If you have -two-factor authentication on auth-and-writes then you’ll need to include a -one-time password on the command line with ---otp <one-time password>, or go through a second factor flow based on your authtype.

        +

        add: Tags the specified version of the package with the specified tag, or the --tag config if not specified. +If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with --otp <one-time password>, or 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

        +

        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.

        +

        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:

      +

      A tag can be used when installing packages as a reference to a version instead of using a specific version number:

      npm install <name>@<tag>

      When installing dependencies, a preferred tagged version may be specified:

      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.

      +

      (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, +

      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.

      +

      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.

      +

      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.

      +

      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
        • @@ -233,9 +217,9 @@

        workspace

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

      +

      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

        @@ -244,13 +228,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -259,9 +244,10 @@

      include-workspace-root

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

    +

    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

      diff --git a/deps/npm/docs/output/commands/npm-docs.html b/deps/npm/docs/output/commands/npm-docs.html index 53807940f4ed99..64524857304ef5 100644 --- a/deps/npm/docs/output/commands/npm-docs.html +++ b/deps/npm/docs/output/commands/npm-docs.html @@ -141,9 +141,9 @@
      -

      +

      npm-docs - @11.6.1 + @11.6.2

      Open documentation for a package in a web browser
      @@ -159,11 +159,9 @@

      Table of contents

      alias: home

      Description

      -

      This command tries to guess at the likely location of a package's -documentation URL, and then tries to open it using the ---browser config param. You can pass multiple -package names at once. If no package name is provided, it will search for a -package.json in the current folder and use the name property.

      +

      This command tries to guess at the likely location of a package's documentation URL, and then tries to open it using the --browser config param. +You can pass multiple package names at once. +If no package name is provided, it will search for a package.json in the current folder and use the name property.

      Configuration

      browser

        @@ -185,9 +183,9 @@

        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.

      +

      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
        • @@ -195,9 +193,9 @@

        workspace

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

      +

      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

        @@ -206,13 +204,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -221,9 +220,10 @@

      include-workspace-root

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

    +

    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

      diff --git a/deps/npm/docs/output/commands/npm-doctor.html b/deps/npm/docs/output/commands/npm-doctor.html index 13ea85e0c3de68..f5c65a6ad7db19 100644 --- a/deps/npm/docs/output/commands/npm-doctor.html +++ b/deps/npm/docs/output/commands/npm-doctor.html @@ -141,9 +141,9 @@
      -

      +

      npm-doctor - @11.6.1 + @11.6.2

      Check the health of your npm environment
      @@ -158,81 +158,56 @@

      Table of contents

      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:

      +

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

      +

      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.

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

      +

      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! +

      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.

      +

      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.

      +

      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.
        • +
      • 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.

      +

      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

        diff --git a/deps/npm/docs/output/commands/npm-edit.html b/deps/npm/docs/output/commands/npm-edit.html index 74d4e35f5b1e7a..b058b0bb0c8223 100644 --- a/deps/npm/docs/output/commands/npm-edit.html +++ b/deps/npm/docs/output/commands/npm-edit.html @@ -141,9 +141,9 @@
        -

        +

        npm-edit - @11.6.1 + @11.6.2

        Edit an installed package
        @@ -158,14 +158,9 @@

        Table of contents

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

        -

        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.

        +

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

        +

        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

          diff --git a/deps/npm/docs/output/commands/npm-exec.html b/deps/npm/docs/output/commands/npm-exec.html index f4914f1139f9ac..b6b91582f0d828 100644 --- a/deps/npm/docs/output/commands/npm-exec.html +++ b/deps/npm/docs/output/commands/npm-exec.html @@ -141,9 +141,9 @@
          -

          +

          npm-exec - @11.6.1 + @11.6.2

          Run a command from a local or remote npm package
          @@ -162,72 +162,43 @@

          Table of contents

          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:

          +

          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.
            • +
          • 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.

          +

          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.

          +

          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:

          +

          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:

          +

          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:

          +

          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:

          +

          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

          @@ -242,8 +213,9 @@

          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.

        +

        Optional companion option for npm exec, npx that allows for +specifying a custom command to be run along with the installed +packages.

        npm exec --package yo --package generator-node --call "yo node"

        workspace

        @@ -251,9 +223,9 @@

        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.

      +

      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
        • @@ -261,9 +233,9 @@

        workspace

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

      +

      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

        @@ -272,13 +244,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -287,18 +260,17 @@

      include-workspace-root

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

    +

    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:

    +

    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:

    +

    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
@@ -308,13 +280,8 @@ 
    Examples
    
 $ npx -c 'eslint && say "hooray, lint passed"'

    Workspaces support

    -

    You may use the workspace or -workspaces configs in order to run an -arbitrary command from an npm package (either one installed locally, or fetched -remotely) in the context of the specified workspaces. -If no positional argument or --call option is provided, it will open an -interactive subshell in the context of each of these configured workspaces one -at a time.

    +

    You may use the workspace or workspaces configs in order to run an arbitrary command from an npm package (either one installed locally, or fetched remotely) in the context of the specified workspaces. +If no positional argument or --call option is provided, it will open an interactive subshell in the context of each of these configured workspaces one at a time.

    Given a project with configured workspaces, e.g:

    .
 +-- package.json
@@ -326,85 +293,70 @@ 
    Workspaces support
    
    `-- c
        `-- package.json
    -

    Assuming the workspace configuration is properly set up at the root level -package.json file. e.g:

    +

    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, in this example -we're using eslint to lint any js file found within each workspace folder:

    +

    You can execute an arbitrary command from a package in the context of each of the configured workspaces when using the workspaces config options, in this example we're using eslint to lint any js file found within each workspace folder:

    npm exec --ws -- eslint ./*.js

    Filtering workspaces

    -

    It's also possible to execute a command in a single workspace using the -workspace config along with a name or directory path:

    +

    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:

    +

    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.

    +

    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.
      • +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 -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.
      • +
    • 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 for more on -how the cache works.

    +

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

    +

    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.

    +

    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.

    +

    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.

    +

    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)
      • +
    • 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

    @@ -413,8 +365,7 @@

    workspaces

  • Type: Boolean
  • Default: false
    • -

    Run scripts in the context of all configured workspaces for the current -project.

    +

    Run scripts in the context of all configured workspaces for the current project.

    See Also

    • npm run
      • diff --git a/deps/npm/docs/output/commands/npm-explain.html b/deps/npm/docs/output/commands/npm-explain.html index 460d779e69e52a..c1576d6630c503 100644 --- a/deps/npm/docs/output/commands/npm-explain.html +++ b/deps/npm/docs/output/commands/npm-explain.html @@ -141,9 +141,9 @@
      -

      +

      npm-explain - @11.6.1 + @11.6.2

      Explain installed packages
      @@ -159,10 +159,8 @@

      Table of contents

      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.

      +

      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:

      glob@7.1.6
@@ -177,10 +175,8 @@ 
      Description
      
     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.

      +

      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.

      $ npm explain node_modules/nyc/node_modules/find-up
 find-up@3.0.0 dev
 node_modules/nyc/node_modules/find-up
@@ -198,8 +194,8 @@ 
      json

    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.
      • +
    • 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

    @@ -207,9 +203,9 @@

    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.

    +

    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
      • @@ -217,9 +213,9 @@

      workspace

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

    +

    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

      diff --git a/deps/npm/docs/output/commands/npm-explore.html b/deps/npm/docs/output/commands/npm-explore.html index 1494fc9744dddf..6e0775684d9123 100644 --- a/deps/npm/docs/output/commands/npm-explore.html +++ b/deps/npm/docs/output/commands/npm-explore.html @@ -141,9 +141,9 @@
      -

      +

      npm-explore - @11.6.1 + @11.6.2

      Browse an installed package
      @@ -159,19 +159,16 @@

      Table of contents

      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:

      +

      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:

      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.

      +

      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
        • +
      • Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" +on Windows
      • Type: String

      The shell to run for the npm explore command.

      diff --git a/deps/npm/docs/output/commands/npm-find-dupes.html b/deps/npm/docs/output/commands/npm-find-dupes.html index 50c5a998cd387a..36654d5b7be6cb 100644 --- a/deps/npm/docs/output/commands/npm-find-dupes.html +++ b/deps/npm/docs/output/commands/npm-find-dupes.html @@ -141,9 +141,9 @@
      -

      +

      npm-find-dupes - @11.6.1 + @11.6.2

      Find duplication in the package tree
      @@ -157,8 +157,7 @@

      Table of contents

      npm find-dupes

      Description

      -

      Runs npm dedupe in --dry-run mode, making npm only output the -duplications, without actually changing the package tree.

      +

      Runs npm dedupe in --dry-run mode, making npm only output the duplications, without actually changing the package tree.

      Configuration

      install-strategy

        @@ -166,11 +165,12 @@

        install-strategy

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

      +(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
        • @@ -178,10 +178,10 @@

        legacy-bundling

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

      +

      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
        • @@ -189,73 +189,78 @@

        global-style

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

      +

      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.

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

      +

      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.
        • +'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.

      +

      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)
        • +
      • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
      -

      Option that allows for defining which types of dependencies to install.

      +

      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.

      +

      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.

      +

      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 for details on what is -submitted.

      +

      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 for details +on what is submitted.

      • Default: true
        • @@ -263,24 +268,25 @@

      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.

      +

      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 for details.

      +acknowledging the number of dependencies looking for funding. See +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.

      +

      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
        • @@ -288,9 +294,9 @@

        workspace

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

      +

      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

        @@ -299,13 +305,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -314,18 +321,19 @@

      include-workspace-root

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

    +

    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.

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

    +

    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
      • diff --git a/deps/npm/docs/output/commands/npm-fund.html b/deps/npm/docs/output/commands/npm-fund.html index dcc7431d5df662..b50ef08583fb2b 100644 --- a/deps/npm/docs/output/commands/npm-fund.html +++ b/deps/npm/docs/output/commands/npm-fund.html @@ -141,9 +141,9 @@
      -

      +

      npm-fund - @11.6.1 + @11.6.2

      Retrieve funding information
      @@ -157,25 +157,17 @@

      Table of contents

      npm fund [<package-spec>]

      Description

      -

      This command retrieves information on how to fund the dependencies of a -given project. If no package name is provided, it will list all -dependencies that are looking for funding in a tree structure, listing -the type of funding and the url to visit. If a package name is provided -then it tries to open its funding url using the ---browser config param; if there are multiple -funding sources for the package, the user will be instructed to pass the +

      This command retrieves information on how to fund the dependencies of a given project. +If no package name is provided, it will list all dependencies that are looking for funding in a tree structure, listing the type of funding and the url to visit. +If a package name is provided then it tries to open its funding url using the --browser config param; if there are multiple funding sources for the package, the user will be instructed to pass the --which option to disambiguate.

      -

      The list will avoid duplicated entries and will stack all packages that -share the same url as a single entry. Thus, the list does not have the -same shape of the output from npm ls.

      +

      The list will avoid duplicated entries and will stack all packages that share the same url as a single entry. +Thus, the list does not have the same shape of the output from npm ls.

      Example

      Workspaces support

      -

      It's possible to filter the results to only include a single workspace -and its dependencies using the -workspace config option.

      +

      It's possible to filter the results to only include a single workspace and its dependencies using the workspace config option.

      Example:

      -

      Here's an example running npm fund in a project with a configured -workspace a:

      +

      Here's an example running npm fund in a project with a configured workspace a:

      $ npm fund
 test-workspaces-fund@1.0.0
 +-- https://example.com/a
@@ -187,8 +179,7 @@ 
      Example:
      
 `-- 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:

      +

      And here is an example of the expected result when filtering only by a specific workspace a in the same project:

      $ npm fund -w a
 test-workspaces-fund@1.0.0
 `-- https://example.com/a
@@ -204,8 +195,8 @@ 
      json

    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.
      • +
    • 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

    @@ -219,20 +210,21 @@

    browser

    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.
      • +
    • 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.

    +

    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.

    +

    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
      • @@ -240,16 +232,17 @@

      workspace

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

    +

    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.

    +

    If there are multiple funding sources, which 1-indexed source URL to +open.

    See Also

    • package spec
      • diff --git a/deps/npm/docs/output/commands/npm-help-search.html b/deps/npm/docs/output/commands/npm-help-search.html index 09c02d8b480da0..302450849aa5bb 100644 --- a/deps/npm/docs/output/commands/npm-help-search.html +++ b/deps/npm/docs/output/commands/npm-help-search.html @@ -141,9 +141,9 @@
      -

      +

      npm-help-search - @11.6.1 + @11.6.2

      Search npm help documentation
      @@ -158,12 +158,10 @@

      Table of contents

      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.

      +

      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.

      +

      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

        diff --git a/deps/npm/docs/output/commands/npm-help.html b/deps/npm/docs/output/commands/npm-help.html index 256b7a6deb333f..fcf951538a0cbc 100644 --- a/deps/npm/docs/output/commands/npm-help.html +++ b/deps/npm/docs/output/commands/npm-help.html @@ -141,9 +141,9 @@
        -

        +

        npm-help - @11.6.1 + @11.6.2

        Get help on npm
        @@ -161,10 +161,8 @@

        Table of contents

        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.

        +

        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

          @@ -172,7 +170,8 @@

          viewer

        • Type: String

        The program to use to view help content.

        -

        Set to "browser" to view html help content in the default web browser.

        +

        Set to "browser" to view html help content in the default web +browser.

        See Also

        • npm
          • diff --git a/deps/npm/docs/output/commands/npm-init.html b/deps/npm/docs/output/commands/npm-init.html index dda6a33269b396..a614375240ac91 100644 --- a/deps/npm/docs/output/commands/npm-init.html +++ b/deps/npm/docs/output/commands/npm-init.html @@ -141,9 +141,9 @@
          -

          +

          npm-init - @11.6.1 + @11.6.2

          Create a package.json file
          @@ -160,14 +160,10 @@

          Table of contents

          aliases: create, innit

          Description

          -

          npm init <initializer> can be used to set up a new or existing npm -package.

          +

          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, 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:

          +which will be installed by 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
            • @@ -175,38 +171,30 @@

            Description

          • 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:

          +

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

          +

          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:

          +

          Create a new React-based project using create-react-app:

          $ npm init react-app ./my-react-app
          -

          Create a new esm-compatible package using -create-esm:

          +

          Create a new esm-compatible package using create-esm:

          $ mkdir my-esm-lib && cd my-esm-lib
 $ npm init esm --yes
          @@ -222,11 +210,8 @@

          Examples

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

          +

          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
@@ -234,28 +219,19 @@ 
          Workspaces support
          
 
          You may generate a new workspace using the legacy init:
          
 
          $ 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:
          
+
          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, 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:
          
+
          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, 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:
          
 
          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 .:
          
+
          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
@@ -272,7 +248,8 @@ 
          init-author-name
          
 
        • Default: ""
          • 
 
        • Type: String
          •
        -

        The value npm init should use by default for the package author's name.

        +

        The value npm init should use by default for the package author's +name.

        init-author-url

        • Default: ""
          • @@ -293,28 +270,29 @@

          init-module

        A module that will be loaded by the npm init command. See the documentation for the -init-package-json module for -more information, or npm init.

        +init-package-json module +for more information, or npm init.

        init-type

        • Default: "commonjs"
        • Type: String
        -

        The value that npm init should use by default for the package.json type -field.

        +

        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.

        +

        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.

        +

        The value npm init should use by default for the package's private +flag.

        yes

        • Default: null
          • @@ -333,14 +311,16 @@

          force

        • 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 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.
          • +
        • 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).
          • @@ -373,9 +353,9 @@

          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.

        +

        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
          • @@ -383,9 +363,9 @@

          workspace

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

        +

        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

          @@ -394,13 +374,14 @@

          workspaces

        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:

        +

        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.
          • +
        • 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

        @@ -408,17 +389,19 @@

        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.

      +

      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.

      +

      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

        diff --git a/deps/npm/docs/output/commands/npm-install-ci-test.html b/deps/npm/docs/output/commands/npm-install-ci-test.html index 9e97224c4da051..5ce09186ea55cd 100644 --- a/deps/npm/docs/output/commands/npm-install-ci-test.html +++ b/deps/npm/docs/output/commands/npm-install-ci-test.html @@ -141,9 +141,9 @@
        -

        +

        npm-install-ci-test - @11.6.1 + @11.6.2

        Install a project with a clean slate and run tests
        @@ -167,11 +167,12 @@

        install-strategy

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

      +(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
        • @@ -179,10 +180,10 @@

        legacy-bundling

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

      +

      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
        • @@ -190,77 +191,82 @@

        global-style

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

      +

      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.
        • +'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.

      +

      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)
        • +
      • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
      -

      Option that allows for defining which types of dependencies to install.

      +

      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.

      +

      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.

      +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
        • +
      • 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.

      +

      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.

      +

      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 for details on what is -submitted.

      +

      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 for details +on what is submitted.

      • Default: true
        • @@ -268,35 +274,37 @@

      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.

      +

      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 for details.

      +acknowledging the number of dependencies looking for funding. See +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.

      +

      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.

      +

      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
        • @@ -304,9 +312,9 @@

        workspace

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

      +

      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

        @@ -315,13 +323,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -330,18 +339,19 @@

      include-workspace-root

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

    +

    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.

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

    +

    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
      • diff --git a/deps/npm/docs/output/commands/npm-install-test.html b/deps/npm/docs/output/commands/npm-install-test.html index 675c5691071f47..e1db52fb95b05b 100644 --- a/deps/npm/docs/output/commands/npm-install-test.html +++ b/deps/npm/docs/output/commands/npm-install-test.html @@ -141,9 +141,9 @@
      -

      +

      npm-install-test - @11.6.1 + @11.6.2

      Install package(s) and run tests
      @@ -159,12 +159,13 @@

      Table of contents

      alias: it

      Description

      -

      This command runs an npm install followed immediately by an npm test. It -takes exactly the same arguments as npm install.

      +

      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
        • +
      • Default: true unless when using npm update where it defaults to +false
      • Type: Boolean

      Save installed packages to a package.json file as dependencies.

      @@ -176,19 +177,20 @@

      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.

    +

    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 for more on the differences in behavior.

    +

    Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

      -
    • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
      • +
    • 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
    @@ -198,11 +200,12 @@

    install-strategy

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

    +(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
      • @@ -210,10 +213,10 @@

      legacy-bundling

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

    +

    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
      • @@ -221,115 +224,122 @@

      global-style

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

    +

    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.
      • +'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.

    +

    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)
      • +
    • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
    -

    Option that allows for defining which types of dependencies to install.

    +

    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.

    +

    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.

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

    +

    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.

    +

    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.

    +

    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.

    +

    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
      • +
    • 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.

    +

    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.

    +

    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 for details on what is -submitted.

    +

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

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

    • Default: true
      • @@ -337,56 +347,59 @@

    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.

    +

    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 for details.

    +acknowledging the number of dependencies looking for funding. See +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.

    +

    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.

    +

    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.

    +

    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

    +

    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.

    +

    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
      • @@ -394,9 +407,9 @@

      workspace

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

    +

    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

      @@ -405,13 +418,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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

    @@ -420,18 +434,19 @@

    include-workspace-root

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

    +

    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.

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

    +

    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
      • diff --git a/deps/npm/docs/output/commands/npm-install.html b/deps/npm/docs/output/commands/npm-install.html index d5e1bc001c1f29..f439db3cb17c69 100644 --- a/deps/npm/docs/output/commands/npm-install.html +++ b/deps/npm/docs/output/commands/npm-install.html @@ -141,9 +141,9 @@
      -

      +

      npm-install - @11.6.1 + @11.6.2

      Install a package
      @@ -159,60 +159,41 @@

      Table of contents

      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:

      +

      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 and -npm shrinkwrap.

      +

      See package-lock.json and npm shrinkwrap.

      A package is:

        -
      • a) a folder containing a program described by a -package.json file
        • +
      • a) a folder containing a program described by a 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) with (c)
        • -
      • e) a <name>@<tag> (see npm dist-tag) that -points to (d)
        • +
      • d) a <name>@<version> that is published on the registry (see registry) with (c)
        • +
      • e) a <name>@<tag> (see 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).

      +

      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.

        -

        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.

        +

        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.

        +

        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.

        +

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

        +

        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.

        @@ -223,18 +204,14 @@

        Description

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

        +

        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.

        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.
          • +
        • 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:

        npm install ./package.tgz
@@ -242,28 +219,27 @@ 
        Description

      • 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://"

        +

        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:

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

        +

        Do a <name>@<tag> install, where <tag> is the "tag" config. +(See config. +The config's default value is latest.)

        +

        In most cases, this will install the version of the modules tagged as latest on the npm registry.

        Example:

        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:

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

          +

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

          @@ -279,27 +255,22 @@

          Description

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

        +

        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.

          +

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

          +

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

        -

        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.

        +

        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.

        +

        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:

        npm install sax
 npm install githubname/reponame
@@ -312,13 +283,10 @@ 
        Description

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

        +

        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.

        Examples:

        npm install my-react@npm:react
 npm install jquery2@npm:jquery@2
@@ -329,8 +297,7 @@ 
        Description
        
 
      • 
 
        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.
        
+If the tag does not exist in the registry data for that package, then this will fail.
        
 
        Example:
        
 
        npm install sax@latest
 npm install @myorg/mypackage@latest
@@ -338,8 +305,8 @@ 
        Description
        
 
        • 
 
      • 
 
        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.
        
+
        Install the specified version of the package.
+This will fail if the version has not been published to the registry.
        
 
        Example:
        
 
        npm install sax@0.1.1
 npm install @myorg/privatepackage@1.5.0
@@ -348,10 +315,8 @@ 
        Description
        
 
      • 
 
        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.
        
-
        Note that most version ranges must be put in quotes so that your shell
-will treat it as a single argument.
        
+This will follow the same rules for resolving dependencies described in package.json.
        
+
        Note that most version ranges must be put in quotes so that your shell will treat it as a single argument.
        
 
        Example:
        
 
        npm install sax@">=0.1.0 <0.2.0"
 npm install @myorg/privatepackage@"16 - 17"
@@ -359,26 +324,18 @@ 
        Description
        
 
        • 
 
      • 
 
        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.
        
+
        Installs the package from the hosted git provider, cloning it with git.
+For a full git remote url, only that URL will be attempted.
        
 
        <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:
        
+
        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
          • 
@@ -403,17 +360,11 @@ 
          Description
          
 
 
        • 
 
          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.
          
+
          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:
          
 
          npm install mygithubuser/myproject
 npm install github:mygithubuser/myproject
@@ -421,46 +372,31 @@ 
          Description
          
 
          • 
 
        • 
 
          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.
          
+
          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:
          
 
          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.
          
+
          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:
          
 
          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.
          
+
          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:
          
 
          npm install gitlab:mygitlabuser/myproject
 npm install gitlab:myusr/myproj#semver:^5.0
@@ -471,26 +407,21 @@ 
          Description
          
 For example:
          
 
          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.
          
+
          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.
          
 
          npm install sax --force
 
          
 
          Configuration
          
-
          See the config help doc.  Many of the configuration
-params have some effect on installation, since that's most of what npm
-does.
          
+
          See the 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
            • 
+
          • Default: true unless when using npm update where it defaults to
+false
            • 
 
          • Type: Boolean
            • 
 
          
 
          Save installed packages to a package.json file as dependencies.
          
@@ -502,19 +433,20 @@ 
          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.
        
+
        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 for more on the differences in behavior.
        
+
        Operates in "global" mode, so that packages are installed into the
+prefix folder instead of the current working directory. See
+folders for more on the differences in
+behavior.
        
 
          
-
        • packages are installed into the {prefix}/lib/node_modules folder, instead
-of the current working directory.
          • 
+
        • 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
          • 
 
        
@@ -524,11 +456,12 @@ 
        install-strategy
        
 
      • 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.

      +(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
        • @@ -536,10 +469,10 @@

        legacy-bundling

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

      +

      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
        • @@ -547,115 +480,122 @@

        global-style

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

      +

      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.
        • +'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.

      +

      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)
        • +
      • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
      -

      Option that allows for defining which types of dependencies to install.

      +

      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.

      +

      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.

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

      +

      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.

      +

      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.

      +

      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.

      +

      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
        • +
      • 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.

      +

      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.

      +

      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 for details on what is -submitted.

      +

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

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

      • Default: true
        • @@ -663,56 +603,59 @@

      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.

      +

      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 for details.

      +acknowledging the number of dependencies looking for funding. See +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.

      +

      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.

      +

      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.

      +

      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

      +

      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.

      +

      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
        • @@ -720,9 +663,9 @@

        workspace

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

      +

      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

        @@ -731,13 +674,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -746,29 +690,28 @@

      include-workspace-root

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

    +

    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.

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

    +

    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:

    +

    Given a package{dep} structure: A{B,C}, B{C}, C{D}, the npm install algorithm produces:

    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.

    +

    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:

    A
 +-- B
@@ -776,12 +719,9 @@ 
    Algorithm
    
    `-- 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 for a more detailed description of -the specific folder structures that npm creates.

    +

    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 for a more detailed description of the specific folder structures that npm creates.

    See Also

    • npm folders
      • diff --git a/deps/npm/docs/output/commands/npm-link.html b/deps/npm/docs/output/commands/npm-link.html index a0ec6f93bf1bb0..72ab0b3ada6997 100644 --- a/deps/npm/docs/output/commands/npm-link.html +++ b/deps/npm/docs/output/commands/npm-link.html @@ -141,9 +141,9 @@
      -

      +

      npm-link - @11.6.1 + @11.6.2

      Symlink a package folder
      @@ -159,25 +159,17 @@

      Table of contents

      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.

      +

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

      +

      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. +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:

      cd ~/projects/node-redis    # go into the package directory
 npm link                    # creates global link
@@ -185,10 +177,10 @@ 
      Description
      
 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:

      +~/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:

      cd ~/projects/node-bloggy  # go into the dir of your main project
 npm link ../node-redis     # link the dir of your dependency
      @@ -196,38 +188,26 @@

      Description

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

      +

      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) your -link command must include that scope, e.g.

      +

      If your linked package is scoped (see scope) your link command must include that scope, e.g.

      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.

      +

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

      +

      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
        • +
      • Default: true unless when using npm update where it defaults to +false
      • Type: Boolean

      Save installed packages to a package.json file as dependencies.

      @@ -239,19 +219,20 @@

      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.

    +

    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 for more on the differences in behavior.

    +

    Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

      -
    • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
      • +
    • 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
    @@ -261,11 +242,12 @@

    install-strategy

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

    +(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
      • @@ -273,10 +255,10 @@

      legacy-bundling

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

    +

    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
      • @@ -284,73 +266,78 @@

      global-style

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

    +

    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.

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

    +

    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.
      • +'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.

    +

    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)
      • +
    • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
    -

    Option that allows for defining which types of dependencies to install.

    +

    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.

    +

    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.

    +

    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 for details on what is -submitted.

    +

    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 for details +on what is submitted.

    • Default: true
      • @@ -358,35 +345,37 @@

    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.

    +

    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 for details.

    +acknowledging the number of dependencies looking for funding. See +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.

    +

    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.

    +

    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
      • @@ -394,9 +383,9 @@

      workspace

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

    +

    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

      @@ -405,13 +394,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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

    @@ -420,18 +410,19 @@

    include-workspace-root

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

    +

    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.

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

    +

    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
      • diff --git a/deps/npm/docs/output/commands/npm-login.html b/deps/npm/docs/output/commands/npm-login.html index b7999fa2aa6a31..1031b01ae7559b 100644 --- a/deps/npm/docs/output/commands/npm-login.html +++ b/deps/npm/docs/output/commands/npm-login.html @@ -141,9 +141,9 @@
      -

      +

      npm-login - @11.6.1 + @11.6.2

      Login to a registry user account
      @@ -159,17 +159,15 @@

      Table of contents

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

      -

      When you run npm login, the CLI automatically generates a legacy token of publish type. For more information, see About legacy tokens.

      -

      When using legacy for your auth-type, the username and password, are -read in from prompts.

      +.npmrc file. +If no registry is specified, the default registry will be used (see config).

      +

      When you run npm login, the CLI automatically generates a legacy token of publish type. +For more information, see 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.

      +

      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

        @@ -203,8 +201,8 @@

        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.

      +

      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
        • diff --git a/deps/npm/docs/output/commands/npm-logout.html b/deps/npm/docs/output/commands/npm-logout.html index badb71414a10e1..2959f2369d51b9 100644 --- a/deps/npm/docs/output/commands/npm-logout.html +++ b/deps/npm/docs/output/commands/npm-logout.html @@ -141,9 +141,9 @@
        -

        +

        npm-logout - @11.6.1 + @11.6.2

        Log out of the registry
        @@ -158,14 +158,11 @@

        Table of contents

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

        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.

        +

        If --scope is provided, this will find the credentials for the registry connected to that scope, if set.

        Configuration

        registry

          diff --git a/deps/npm/docs/output/commands/npm-ls.html b/deps/npm/docs/output/commands/npm-ls.html index 2ed521baac545d..2bbca3b4a70bc2 100644 --- a/deps/npm/docs/output/commands/npm-ls.html +++ b/deps/npm/docs/output/commands/npm-ls.html @@ -141,9 +141,9 @@
          -

          +

          npm-ls - @11.6.1 + @11.6.2

          List installed packages
          @@ -159,25 +159,18 @@

          Table of contents

          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.

          -

          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:

          -
          npm@11.6.1 /path/to/npm
+
          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.
          
+
          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:
          
+
          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.
          
+
          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
          
@@ -185,9 +178,9 @@ 
          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.

        +

        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
          • @@ -195,8 +188,8 @@

          json

        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.
          • +
        • 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

        @@ -210,86 +203,95 @@

        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.

      +

      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 for more on the differences in behavior.

      +

      Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

        -
      • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
        • +
      • 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
        • +
      • 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.

      +

      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.
        • +'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.

      +

      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)
        • +
      • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
      -

      Option that allows for defining which types of dependencies to install.

      +

      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.

      +

      Dependency types specified in --include will not be omitted, +regardless of the order in which omit/include are specified on the +command-line.

      • Default: false
      • Type: Boolean
      -

      Used with npm ls, limiting output to only those packages that are linked.

      +

      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.

      +

      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.

      +

      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.
        • +
      • 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.

      +

      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.

      +

      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
        • @@ -297,9 +299,9 @@

        workspace

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

      +

      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

        @@ -308,13 +310,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -323,18 +326,19 @@

      include-workspace-root

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

    +

    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.

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

    +

    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
      • diff --git a/deps/npm/docs/output/commands/npm-org.html b/deps/npm/docs/output/commands/npm-org.html index 5556ff2bb29aab..9082d54b259491 100644 --- a/deps/npm/docs/output/commands/npm-org.html +++ b/deps/npm/docs/output/commands/npm-org.html @@ -141,9 +141,9 @@
      -

      +

      npm-org - @11.6.1 + @11.6.2

      Manage orgs
      @@ -181,9 +181,8 @@

      Example

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

      +

      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

        @@ -196,10 +195,10 @@

        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.

      +

      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
        • @@ -207,8 +206,8 @@

        json

      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.
        • +
      • 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

      @@ -216,8 +215,8 @@

      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.

    +

    Output parseable results from commands that write to standard output. +For npm search, this will be tab-separated table format.

    See Also

    • using orgs
      • diff --git a/deps/npm/docs/output/commands/npm-outdated.html b/deps/npm/docs/output/commands/npm-outdated.html index 072d8d989dc62a..441b0a65170d69 100644 --- a/deps/npm/docs/output/commands/npm-outdated.html +++ b/deps/npm/docs/output/commands/npm-outdated.html @@ -141,9 +141,9 @@
      -

      +

      npm-outdated - @11.6.1 + @11.6.2

      Check for outdated packages
      @@ -157,37 +157,24 @@

      Table of contents

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

      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.
        • +
      • 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.
        • +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.
      • 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
        • +
      • 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.
        • +
      • 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

      $ npm outdated
@@ -208,20 +195,14 @@ 
      An example

      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.
        • +
      • 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

      @@ -229,9 +210,9 @@

      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.

    +

    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
      • @@ -239,8 +220,8 @@

      json

    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.
      • +
    • 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

    @@ -254,19 +235,20 @@

    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.

    +

    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 for more on the differences in behavior.

    +

    Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

      -
    • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
      • +
    • 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
    @@ -275,9 +257,9 @@

    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.

    +

    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
      • @@ -285,9 +267,9 @@

      workspace

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

    +

    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

      @@ -295,13 +277,13 @@

      before

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

    +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
      • diff --git a/deps/npm/docs/output/commands/npm-owner.html b/deps/npm/docs/output/commands/npm-owner.html index 2010274188f7a7..c846c1f6ca6339 100644 --- a/deps/npm/docs/output/commands/npm-owner.html +++ b/deps/npm/docs/output/commands/npm-owner.html @@ -141,9 +141,9 @@
      -

      +

      npm-owner - @11.6.1 + @11.6.2

      Manage package owners
      @@ -163,19 +163,17 @@

      Table of contents

      Description

      Manage ownership of published packages.

        -
      • ls: List all the users who have access to modify a package and push new -versions. Handy when you need to know who to bug for help.
        • -
      • add: Add a new user as a maintainer of a package. This user is enabled -to modify metadata, publish new versions, and add other owners.
        • -
      • rm: Remove a user from the package owner list. This immediately revokes -their privileges.
        • +
      • ls: List all the users who have access to modify a package and push new versions. +Handy when you need to know who to bug for help.
        • +
      • add: Add a new user as a maintainer of a package. +This user is enabled to modify metadata, publish new versions, and add other owners.
        • +
      • rm: Remove a user from the package owner list. +This immediately revokes their privileges.
      -

      Note that there is only one level of access. Either you can modify a package, -or you can't. Future versions may contain more fine-grained access levels, but -that is not implemented at this time.

      -

      If you have two-factor authentication enabled with auth-and-writes (see -npm-profile) then you'll need to go through a second factor -flow when changing ownership or include an otp on the command line with --otp.

      +

      Note that there is only one level of access. +Either you can modify a package, or you can't. +Future versions may contain more fine-grained access levels, but that is not implemented at this time.

      +

      If you have two-factor authentication enabled with auth-and-writes (see npm-profile) then you'll need to go through a second factor flow when changing ownership or include an otp on the command line with --otp.

      Configuration

      registry

        @@ -188,18 +186,18 @@

        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.

      +

      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.

      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.

      +

      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
        • @@ -207,9 +205,9 @@

        workspace

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

      +

      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

        @@ -218,13 +216,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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.

      See Also

      diff --git a/deps/npm/docs/output/commands/npm-pack.html b/deps/npm/docs/output/commands/npm-pack.html index 0404e149ee1e25..c8172c92333766 100644 --- a/deps/npm/docs/output/commands/npm-pack.html +++ b/deps/npm/docs/output/commands/npm-pack.html @@ -141,9 +141,9 @@
      -

      +

      npm-pack - @11.6.1 + @11.6.2

      Create a tarball from a package
      @@ -162,12 +162,13 @@

      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.

    +

    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.

    json

    • Default: false
      • @@ -175,8 +176,8 @@

      json

    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.
      • +
    • 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.

    pack-destination

    @@ -190,9 +191,9 @@

    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.

    +

    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
      • @@ -200,9 +201,9 @@

      workspace

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

    +

    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

      @@ -211,13 +212,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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

    @@ -226,9 +228,10 @@

    include-workspace-root

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

    +

    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.

    ignore-scripts

      @@ -236,18 +239,12 @@

      ignore-scripts

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

    +

    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.

    Description

    -

    For anything that's installable (that is, a package folder, tarball, -tarball url, git url, name@tag, name@version, name, or scoped name), this -command will fetch it to the cache, copy the tarball to the current working -directory as <name>-<version>.tgz, and then write the filenames out to -stdout.

    -

    If the same package is specified multiple times, then the file will be -overwritten the second time.

    +

    For anything that's installable (that is, a package folder, tarball, tarball url, git url, name@tag, name@version, name, or scoped name), this command will fetch it to the cache, copy the tarball to the current working directory as <name>-<version>.tgz, and then write the filenames out to stdout.

    +

    If the same package is specified multiple times, then the file will be overwritten the second time.

    If no arguments are supplied, then npm packs the current package folder.

    See Also

      diff --git a/deps/npm/docs/output/commands/npm-ping.html b/deps/npm/docs/output/commands/npm-ping.html index b7068897ea54e0..3c99ecd918e10b 100644 --- a/deps/npm/docs/output/commands/npm-ping.html +++ b/deps/npm/docs/output/commands/npm-ping.html @@ -141,9 +141,9 @@
      -

      +

      npm-ping - @11.6.1 + @11.6.2

      Ping npm registry
      diff --git a/deps/npm/docs/output/commands/npm-pkg.html b/deps/npm/docs/output/commands/npm-pkg.html index a45e0c14dab19d..64c2c9b83796ca 100644 --- a/deps/npm/docs/output/commands/npm-pkg.html +++ b/deps/npm/docs/output/commands/npm-pkg.html @@ -141,9 +141,9 @@
      -

      +

      npm-pkg - @11.6.1 + @11.6.2

      Manages your package.json
      @@ -163,73 +163,54 @@

      Table of contents

      Description

      A command that automates the management of package.json files. -npm pkg provide 3 different sub commands that allow you to modify or retrieve -values for given object keys in your package.json.

      -

      The syntax to retrieve and set fields is a dot separated representation of -the nested object properties to be found within your package.json, it's the -same notation used in npm view to retrieve information -from the registry manifest, below you can find more examples on how to use it.

      +npm pkg provide 3 different sub commands that allow you to modify or retrieve values for given object keys in your package.json.

      +

      The syntax to retrieve and set fields is a dot separated representation of the nested object properties to be found within your package.json, it's the same notation used in npm view to retrieve information from the registry manifest, below you can find more examples on how to use it.

      Returned values are always in json format.

      • npm pkg get <field>

        Retrieves a value key, defined in your package.json file.

        -

        For example, in order to retrieve the name of the current package, you -can run:

        +

        For example, in order to retrieve the name of the current package, you can run:

        npm pkg get name

        It's also possible to retrieve multiple values at once:

        npm pkg get name version
        -

        You can view child fields by separating them with a period. To retrieve -the value of a test script value, you would run the following command:

        +

        You can view child fields by separating them with a period. +To retrieve the value of a test script value, you would run the following command:

        npm pkg get scripts.test
        -

        For fields that are arrays, requesting a non-numeric field will return -all of the values from the objects in the list. For example, to get all -the contributor emails for a package, you would run:

        +

        For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list. +For example, to get all the contributor emails for a package, you would run:

        npm pkg get contributors.email
        -

        You may also use numeric indices in square braces to specifically select -an item in an array field. To just get the email address of the first -contributor in the list, you can run:

        +

        You may also use numeric indices in square braces to specifically select an item in an array field. +To just get the email address of the first contributor in the list, you can run:

        npm pkg get contributors[0].email
        -

        For complex fields you can also name a property in square brackets -to specifically select a child field. This is especially helpful -with the exports object:

        +

        For complex fields you can also name a property in square brackets to specifically select a child field. +This is especially helpful with the exports object:

        npm pkg get "exports[.].require"

      • npm pkg set <field>=<value>

        -

        Sets a value in your package.json based on the field value. When -saving to your package.json file the same set of rules used during -npm install and other cli commands that touches the package.json file -are used, making sure to respect the existing indentation and possibly -applying some validation prior to saving values to the file.

        -

        The same syntax used to retrieve values from your package can also be used -to define new properties or overriding existing ones, below are some -examples of how the dot separated syntax can be used to edit your -package.json file.

        -

        Defining a new bin named mynewcommand in your package.json that points -to a file cli.js:

        +

        Sets a value in your package.json based on the field value. +When saving to your package.json file the same set of rules used during npm install and other cli commands that touches the package.json file are used, making sure to respect the existing indentation and possibly applying some validation prior to saving values to the file.

        +

        The same syntax used to retrieve values from your package can also be used to define new properties or overriding existing ones, below are some examples of how the dot separated syntax can be used to edit your package.json file.

        +

        Defining a new bin named mynewcommand in your package.json that points to a file cli.js:

        npm pkg set bin.mynewcommand=cli.js

        Setting multiple fields at once is also possible:

        npm pkg set description='Awesome package' engines.node='>=10'
        -

        It's also possible to add to array values, for example to add a new -contributor entry:

        +

        It's also possible to add to array values, for example to add a new contributor entry:

        npm pkg set contributors[0].name='Foo' contributors[0].email='foo@bar.ca'
        -

        You may also append items to the end of an array using the special -empty bracket notation:

        +

        You may also append items to the end of an array using the special empty bracket notation:

        npm pkg set contributors[].name='Foo' contributors[].name='Bar'
        -

        It's also possible to parse values as json prior to saving them to your -package.json file, for example in order to set a "private": true -property:

        +

        It's also possible to parse values as json prior to saving them to your package.json file, for example in order to set a "private": true property:

        npm pkg set private=true --json

        It also enables saving values as numbers:

        @@ -239,32 +220,23 @@

        Description

      • npm pkg delete <key>

        Deletes a key from your package.json

        -

        The same syntax used to set values from your package can also be used -to remove existing ones. For example, in order to remove a script named -build:

        +

        The same syntax used to set values from your package can also be used to remove existing ones. +For example, in order to remove a script named build:

        npm pkg delete scripts.build

      • npm pkg fix

        -

        Auto corrects common errors in your package.json. npm already -does this during publish, which leads to subtle (mostly harmless) -differences between the contents of your package.json file and the -manifest that npm uses during installation.

        +

        Auto corrects common errors in your package.json. +npm already does this during publish, which leads to subtle (mostly harmless) differences between the contents of your package.json file and the manifest that npm uses during installation.

      Workspaces support

      -

      You can set/get/delete items across your configured workspaces by using the -workspace or -workspaces config options.

      -

      For example, setting a funding value across all configured workspaces -of a project:

      +

      You can set/get/delete items across your configured workspaces by using the workspace or workspaces config options.

      +

      For example, setting a funding value across all configured workspaces of a project:

      npm pkg set funding=https://example.com --ws
      -

      When using npm pkg get to retrieve info from your configured workspaces, the -returned result will be in a json format in which top level keys are the -names of each workspace, the values of these keys will be the result values -returned from each of the configured workspaces, e.g:

      +

      When using npm pkg get to retrieve info from your configured workspaces, the returned result will be in a json format in which top level keys are the names of each workspace, the values of these keys will be the result values returned from each of the configured workspaces, e.g:

      npm pkg get name version --ws
 {
   "a": {
@@ -289,14 +261,16 @@ 
      force
      
 
    • 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 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.
      • 
+
    • 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).
      • 
@@ -310,8 +284,8 @@ 
      json

    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.
      • +
    • 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

    @@ -319,9 +293,9 @@

    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.

    +

    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
      • @@ -329,9 +303,9 @@

      workspace

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

    +

    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

      @@ -340,13 +314,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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.

    See Also

    diff --git a/deps/npm/docs/output/commands/npm-prefix.html b/deps/npm/docs/output/commands/npm-prefix.html index 6d84a9cb7ed2d7..df4c70981f3bc0 100644 --- a/deps/npm/docs/output/commands/npm-prefix.html +++ b/deps/npm/docs/output/commands/npm-prefix.html @@ -141,9 +141,9 @@
    -

    +

    npm-prefix - @11.6.1 + @11.6.2

    Display prefix
    @@ -158,11 +158,10 @@

    Table of contents

    Note: This command is unaware of workspaces.

    Description

    -

    Print the local prefix to standard output. This is the closest parent directory -to contain a package.json file or node_modules directory, unless -g is -also specified.

    -

    If -g is specified, this will be the value of the global prefix. See -npm config for more detail.

    +

    Print the local prefix to standard output. +This is the closest parent directory to contain a package.json file or node_modules directory, unless -g is also specified.

    +

    If -g is specified, this will be the value of the global prefix. +See npm config for more detail.

    Example

    npm prefix
 /usr/local/projects/foo
@@ -176,12 +175,13 @@ 
    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 for more on the differences in behavior.
    
+
    Operates in "global" mode, so that packages are installed into the
+prefix folder instead of the current working directory. See
+folders for more on the differences in
+behavior.
    
 
      
-
    • packages are installed into the {prefix}/lib/node_modules folder, instead
-of the current working directory.
      • 
+
    • 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
      • 
 
    
diff --git a/deps/npm/docs/output/commands/npm-profile.html b/deps/npm/docs/output/commands/npm-profile.html
index a56b6dfbabc03a..e6632924f28ecb 100644
--- a/deps/npm/docs/output/commands/npm-profile.html
+++ b/deps/npm/docs/output/commands/npm-profile.html
@@ -141,9 +141,9 @@
 
 
    
 
    
-
    
+
    
     npm-profile
-    @11.6.1
+    @11.6.2
 
    
 Change settings on your registry profile
 
    
@@ -161,12 +161,11 @@ 
    Table of contents

    Note: This command is unaware of workspaces.

    Description

    -

    Change your profile information on the registry. Note that this command -depends on the registry implementation, so third-party registries may not -support this interface.

    +

    Change your profile information on the registry. +Note that this command depends on the registry implementation, so third-party registries may not support this interface.

      -
    • npm profile get [<property>]: Display all of the properties of your -profile, or one or more specific properties. It looks like:
      • +
    • npm profile get [<property>]: Display all of the properties of your profile, or one or more specific properties. +It looks like:
    name: example
 email: e@example.com (verified)
@@ -181,26 +180,22 @@ 
    Description
    • -

      npm profile set <property> <value>: Set the value of a profile -property. You can set the following properties this way: email, fullname, -homepage, freenode, twitter, github

      +

      npm profile set <property> <value>: Set the value of a profile property. +You can set the following properties this way: email, fullname, homepage, freenode, twitter, github

    • -

      npm profile set password: Change your password. This is interactive, -you'll be prompted for your current password and a new password. You'll -also be prompted for an OTP if you have two-factor authentication -enabled.

      +

      npm profile set password: Change your password. +This is interactive, you'll be prompted for your current password and a new password. +You'll also be prompted for an OTP if you have two-factor authentication enabled.

    • -

      npm profile enable-2fa [auth-and-writes|auth-only]: Enables two-factor -authentication. Defaults to auth-and-writes mode. Modes are:

      +

      npm profile enable-2fa [auth-and-writes|auth-only]: Enables two-factor authentication. +Defaults to auth-and-writes mode. +Modes are:

        -
      • auth-only: Require an OTP when logging in or making changes to your -account's authentication. The OTP will be required on both the website -and the command line.
        • -
      • auth-and-writes: Requires an OTP at all the times auth-only does, -and also requires one when publishing a module, setting the latest -dist-tag, or changing access via npm access and npm owner.
        • +
      • auth-only: Require an OTP when logging in or making changes to your account's authentication. +The OTP will be required on both the website and the command line.
        • +
      • auth-and-writes: Requires an OTP at all the times auth-only does, and also requires one when publishing a module, setting the latest dist-tag, or changing access via npm access and npm owner.
    • @@ -223,8 +218,8 @@

      json

    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.
      • +
    • 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

    @@ -232,17 +227,17 @@

    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.

    +

    Output parseable results from commands that write to standard output. +For npm search, this will be tab-separated table format.

    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.

    +

    This is a one-time password from a two-factor authenticator. It's +needed when publishing or changing package permissions with npm access.

    +

    If not set, and a registry response fails with a challenge for a +one-time password, npm will prompt on the command line for one.

    See Also

    • npm adduser
      • diff --git a/deps/npm/docs/output/commands/npm-prune.html b/deps/npm/docs/output/commands/npm-prune.html index 9fb094f24b17b6..921556183dc5b0 100644 --- a/deps/npm/docs/output/commands/npm-prune.html +++ b/deps/npm/docs/output/commands/npm-prune.html @@ -141,9 +141,9 @@
      -

      +

      npm-prune - @11.6.1 + @11.6.2

      Remove extraneous packages
      @@ -157,55 +157,54 @@

      Table of contents

      npm prune [[<@scope>/]<pkg>...]

      Description

      -

      This command removes "extraneous" packages. If a package name is provided, -then only packages matching one of the supplied names are removed.

      -

      Extraneous packages are those present in the node_modules folder that are -not listed as any package's dependency list.

      -

      If the --omit=dev flag is specified or the NODE_ENV environment -variable is set to production, this command will remove the packages -specified in your devDependencies.

      +

      This command removes "extraneous" packages. +If a package name is provided, then only packages matching one of the supplied names are removed.

      +

      Extraneous packages are those present in the node_modules folder that are not listed as any package's dependency list.

      +

      If the --omit=dev flag is specified or the NODE_ENV environment variable is set to production, this command will remove the packages specified in your devDependencies.

      If the --dry-run flag is used then no changes will actually be made.

      -

      If the --json flag is used, then the changes npm prune made (or would -have made with --dry-run) are printed as a JSON object.

      -

      In normal operation, extraneous modules are pruned automatically, so you'll -only need this command with the --production flag. However, in the real -world, operation is not always "normal". When crashes or mistakes happen, -this command can help clean up any resulting garbage.

      +

      If the --json flag is used, then the changes npm prune made (or would have made with --dry-run) are printed as a JSON object.

      +

      In normal operation, extraneous modules are pruned automatically, so you'll only need this command with the --production flag. +However, in the real world, operation is not always "normal". When crashes or mistakes happen, this command can help clean up any resulting garbage.

      Configuration

      omit

      • Default: 'dev' if the NODE_ENV environment variable is set to -'production', otherwise empty.
        • +'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.

      +

      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)
        • +
      • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
      -

      Option that allows for defining which types of dependencies to install.

      +

      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.

      +

      Dependency types specified in --include will not be omitted, +regardless of the order in which omit/include are specified on the +command-line.

      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.

      +

      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.

      json

      • Default: false
        • @@ -213,39 +212,39 @@

        json

      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.
        • +
      • 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.

      foreground-scripts

        -
      • Default: false unless when using npm pack or npm publish where it -defaults to true
        • +
      • 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.

      +

      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.

      +

      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.

      +

      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
        • @@ -253,9 +252,9 @@

        workspace

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

      +

      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

        @@ -264,13 +263,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -279,18 +279,19 @@

      include-workspace-root

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

    +

    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.

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

    +

    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 uninstall
      • diff --git a/deps/npm/docs/output/commands/npm-publish.html b/deps/npm/docs/output/commands/npm-publish.html index fc2ba1cb268b56..df7247cdabc52b 100644 --- a/deps/npm/docs/output/commands/npm-publish.html +++ b/deps/npm/docs/output/commands/npm-publish.html @@ -141,9 +141,9 @@
      -

      +

      npm-publish - @11.6.1 + @11.6.2

      Publish a package
      @@ -158,128 +158,106 @@

      Table of contents

      Description

      Publishes a package to the registry so that it can be installed by name.

      -

      By default npm will publish to the public registry. This can be -overridden by specifying a different default registry or using a -scope in the name, combined with a -scope-configured registry (see -package.json).

      -

      A package is interpreted the same way as other commands (like -npm install) and can be:

      +

      By default npm will publish to the public registry. +This can be overridden by specifying a different default registry or using a scope in the name, combined with a scope-configured registry (see package.json).

      +

      A package is interpreted the same way as other commands (like npm install) and can be:

        -
      • a) a folder containing a program described by a -package.json file
        • +
      • a) a folder containing a program described by a 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) with (c)
        • -
      • e) a <name>@<tag> (see npm dist-tag) that -points to (d)
        • +
      • d) a <name>@<version> that is published on the registry (see registry) with (c)
        • +
      • e) a <name>@<tag> (see 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)
      -

      The publish will fail if the package name and version combination already -exists in the specified registry.

      -

      Once a package is published with a given name and version, that specific -name and version combination can never be used again, even if it is removed -with npm unpublish.

      -

      As of npm@5, both a sha1sum and an integrity field with a sha512sum of the -tarball will be submitted to the registry during publication. Subsequent -installs will use the strongest supported algorithm to verify downloads.

      -

      Similar to --dry-run see npm pack, which figures -out the files to be included and packs them into a tarball to be uploaded -to the registry.

      +

      The publish will fail if the package name and version combination already exists in the specified registry.

      +

      Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with npm unpublish.

      +

      As of npm@5, both a sha1sum and an integrity field with a sha512sum of the tarball will be submitted to the registry during publication. +Subsequent installs will use the strongest supported algorithm to verify downloads.

      +

      Similar to --dry-run see npm pack, which figures out the files to be included and packs them into a tarball to be uploaded to the registry.

      Files included in package

      -

      To see what will be included in your package, run npm pack --dry-run. All -files are included by default, with the following exceptions:

      +

      To see what will be included in your package, run npm pack --dry-run. +All files are included by default, with the following exceptions:

      • -

        Certain files that are relevant to package installation and distribution -are always included. For example, package.json, README.md, +

        Certain files that are relevant to package installation and distribution are always included. +For example, package.json, README.md, LICENSE, and so on.

      • -

        If there is a "files" list in -package.json, then only the files -specified will be included. (If directories are specified, then they -will be walked recursively and their contents included, subject to the -same ignore rules.)

        +

        If there is a "files" list in package.json, then only the files specified will be included. +(If directories are specified, then they will be walked recursively and their contents included, subject to the same ignore rules.)

      • -

        If there is a .gitignore or .npmignore file, then ignored files in -that and all child directories will be excluded from the package. If -both files exist, then the .gitignore is ignored, and only the +

        If there is a .gitignore or .npmignore file, then ignored files in that and all child directories will be excluded from the package. +If both files exist, then the .gitignore is ignored, and only the .npmignore is used.

        -

        .npmignore files follow the same pattern -rules -as .gitignore files

        +

        .npmignore files follow the same pattern rules as .gitignore files

      • -

        If the file matches certain patterns, then it will never be included, -unless explicitly added to the "files" list in package.json, or -un-ignored with a ! rule in a .npmignore or .gitignore file.

        +

        If the file matches certain patterns, then it will never be included, unless explicitly added to the "files" list in package.json, or un-ignored with a ! rule in a .npmignore or .gitignore file.

      • Symbolic links are never included in npm packages.

      -

      See developers for full details on what's -included in the published package, as well as details on how the package is -built.

      -

      See package.json for more info on -what can and can't be ignored.

      +

      See developers for full details on what's included in the published package, as well as details on how the package is built.

      +

      See package.json for more info on what can and can't be ignored.

      Configuration

      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.

      +

      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.

      +

      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.

      access

        -
      • Default: 'public' for new packages, existing packages it will not change the -current level
        • +
      • Default: 'public' for new packages, existing packages it will not +change the current level
      • Type: null, "restricted", or "public"

      If you do not want your scoped package to be publicly viewable (and installable) set --access=restricted.

      -

      Unscoped packages can not be set to restricted.

      -

      Note: This defaults to not changing the current access level for existing -packages. Specifying a value of restricted or public during publish will -change the access for an existing package the same way that npm access set status would.

      +

      Unscoped packages cannot be set to restricted.

      +

      Note: This defaults to not changing the current access level for +existing packages. Specifying a value of restricted or public +during publish will change the access for an existing package the +same way that npm access set status would.

      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.

      +

      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.

      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.

      +

      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.

      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.

      +

      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
        • @@ -287,9 +265,9 @@

        workspace

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

      +

      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

        @@ -298,13 +276,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -313,25 +292,27 @@

      include-workspace-root

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

    +

    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.

    provenance

    • Default: false
    • Type: Boolean
    -

    When publishing from a supported cloud CI/CD system, the package will be -publicly linked to where it was built and published from.

    -

    This config can not be used with: provenance-file

    +

    When publishing from a supported cloud CI/CD system, the package will +be publicly linked to where it was built and published from.

    +

    This config cannot be used with: provenance-file

    provenance-file

    • Default: null
    • Type: Path
    -

    When publishing, the provenance bundle at the given path will be used.

    -

    This config can not be used with: provenance

    +

    When publishing, the provenance bundle at the given path will be +used.

    +

    This config cannot be used with: provenance

    See Also

    • package spec
      • diff --git a/deps/npm/docs/output/commands/npm-query.html b/deps/npm/docs/output/commands/npm-query.html index 62523343b2e3d6..0e4aab89d146dc 100644 --- a/deps/npm/docs/output/commands/npm-query.html +++ b/deps/npm/docs/output/commands/npm-query.html @@ -141,9 +141,9 @@
      -

      +

      npm-query - @11.6.1 + @11.6.2

      Dependency selector query
      @@ -157,8 +157,7 @@

      Table of contents

      npm query <selector>

      Description

      -

      The npm query command allows for usage of css selectors in order to retrieve -an array of dependency objects.

      +

      The npm query command allows for usage of css selectors in order to retrieve an array of dependency objects.

      Piping npm query to other commands

      # find all dependencies with postinstall scripts & uninstall them
 npm query ":attr(scripts, [postinstall])" | jq 'map(.name)|join("\n")' -r | xargs -I {} npm uninstall {}
@@ -273,33 +272,30 @@ 
      Example Response Output
      
   ...

      Expecting a certain number of results

      -

      One common use of npm query is to make sure there is only one version of -a certain dependency in your tree. This is especially common for -ecosystems like that rely on typescript where having state split -across two different but identically-named packages causes bugs. You -can use the --expect-results or --expect-result-count in your setup -to ensure that npm will exit with an exit code if your tree doesn't look -like you want it to.

      +

      One common use of npm query is to make sure there is only one version of a certain dependency in your tree. +This is especially common for ecosystems like that rely on typescript where having state split across two different but identically-named packages causes bugs. +You can use the --expect-results or --expect-result-count in your setup to ensure that npm will exit with an exit code if your tree doesn't look like you want it to.

      $ npm query '#react' --expect-result-count=1
      -

      Perhaps you want to quickly check if there are any production -dependencies that could be updated:

      +

      Perhaps you want to quickly check if there are any production dependencies that could be updated:

      $ npm query ':root>:outdated(in-range).prod' --no-expect-results

      Package lock only mode

      -

      If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. This means that information from the package.json files of your dependencies will not be included in the result set (e.g. description, homepage, engines).

      +

      If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. +This means that information from the package.json files of your dependencies will not be included in the result set (e.g. description, homepage, engines).

      Configuration

      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 for more on the differences in behavior.

      +

      Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

        -
      • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
        • +
      • 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
      @@ -308,9 +304,9 @@

      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.

    +

    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
      • @@ -318,9 +314,9 @@

      workspace

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

    +

    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

      @@ -329,13 +325,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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

    @@ -344,36 +341,38 @@

    include-workspace-root

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

    +

    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.

    package-lock-only

    • Default: false
    • Type: Boolean
    -

    If set to true, the current operation will only use the package-lock.json, -ignoring node_modules.

    +

    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.

    +

    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.

    expect-results

    • Default: null
    • Type: null or Boolean
    -

    Tells npm whether or not to expect results from the command. Can be either -true (expect some results) or false (expect no results).

    -

    This config can not be used with: expect-result-count

    +

    Tells npm whether or not to expect results from the command. Can be +either true (expect some results) or false (expect no results).

    +

    This config cannot be used with: expect-result-count

    expect-result-count

    • Default: null
    • Type: null or Number

    Tells to expect a specific number of results from the command.

    -

    This config can not be used with: expect-results

    +

    This config cannot be used with: expect-results

    See Also

    • dependency selectors
      • diff --git a/deps/npm/docs/output/commands/npm-rebuild.html b/deps/npm/docs/output/commands/npm-rebuild.html index 5ef17aa9dee0cb..9eac53b7fe6079 100644 --- a/deps/npm/docs/output/commands/npm-rebuild.html +++ b/deps/npm/docs/output/commands/npm-rebuild.html @@ -141,9 +141,9 @@
      -

      +

      npm-rebuild - @11.6.1 + @11.6.2

      Rebuild a package
      @@ -176,19 +176,21 @@

      Description

      "install": "node-gyp rebuild" } -

      This default behavior is suppressed if the package.json has its own install or preinstall scripts. It is also suppressed if the package specifies "gypfile": false

      +

      This default behavior is suppressed if the package.json has its own install or preinstall scripts. +It is also suppressed if the package specifies "gypfile": false

      Configuration

      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 for more on the differences in behavior.

      +

      Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

        -
      • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
        • +
      • 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
      @@ -199,38 +201,38 @@

    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.

    +

    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.

    foreground-scripts

      -
    • Default: false unless when using npm pack or npm publish where it -defaults to true
      • +
    • 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.

    +

    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.

    +

    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.

    +

    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
      • @@ -238,9 +240,9 @@

      workspace

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

    +

    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

      @@ -249,13 +251,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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

    @@ -264,18 +267,19 @@

    include-workspace-root

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

    +

    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.

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

    +

    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
      • diff --git a/deps/npm/docs/output/commands/npm-repo.html b/deps/npm/docs/output/commands/npm-repo.html index 2e84dbf16a757b..2fa1fcc138f40b 100644 --- a/deps/npm/docs/output/commands/npm-repo.html +++ b/deps/npm/docs/output/commands/npm-repo.html @@ -141,9 +141,9 @@
      -

      +

      npm-repo - @11.6.1 + @11.6.2

      Open package repository page in the browser
      @@ -157,11 +157,8 @@

      Table of contents

      npm repo [<pkgname> [<pkgname> ...]]

      Description

      -

      This command tries to guess at the likely location of a package's -repository URL, and then tries to open it using the ---browser config param. If no package name is -provided, it will search for a package.json in the current folder and use the -repository property.

      +

      This command tries to guess at the likely location of a package's repository URL, and then tries to open it using the --browser config param. +If no package name is provided, it will search for a package.json in the current folder and use the repository property.

      Configuration

      browser

        @@ -183,9 +180,9 @@

        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.

      +

      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
        • @@ -193,9 +190,9 @@

        workspace

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

      +

      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

        @@ -204,13 +201,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -219,9 +217,10 @@

      include-workspace-root

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

    +

    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

      diff --git a/deps/npm/docs/output/commands/npm-restart.html b/deps/npm/docs/output/commands/npm-restart.html index a7452c91b6971d..14fdcfe42503bf 100644 --- a/deps/npm/docs/output/commands/npm-restart.html +++ b/deps/npm/docs/output/commands/npm-restart.html @@ -141,9 +141,9 @@
      -

      +

      npm-restart - @11.6.1 + @11.6.2

      Restart a package
      @@ -157,16 +157,15 @@

      Table of contents

      npm restart [-- <args>]

      Description

      -

      This restarts a project. It is equivalent to running npm run restart.

      -

      If the current project has a "restart" script specified in -package.json, then the following scripts will be run:

      +

      This restarts a project. +It is equivalent to running npm run restart.

      +

      If the current project has a "restart" script specified in package.json, then the following scripts will be run:

      1. prerestart
      2. restart
      3. postrestart
      -

      If it does not have a "restart" script specified, but it does have -stop and/or start scripts, then the following scripts will be run:

      +

      If it does not have a "restart" script specified, but it does have stop and/or start scripts, then the following scripts will be run:

      1. prerestart
      2. prestop
        3. @@ -184,16 +183,16 @@

        ignore-scripts

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

    +

    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.

    script-shell

    • Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
    • Type: null or String
    -

    The shell to use for scripts run with the npm exec, npm run and npm init <package-spec> commands.

    +

    The shell to use for scripts run with the npm exec, npm run and +npm init <package-spec> commands.

    See Also

    • npm run
      • diff --git a/deps/npm/docs/output/commands/npm-root.html b/deps/npm/docs/output/commands/npm-root.html index 180bba6d23fda3..0498af80a8b4f2 100644 --- a/deps/npm/docs/output/commands/npm-root.html +++ b/deps/npm/docs/output/commands/npm-root.html @@ -141,9 +141,9 @@
      -

      +

      npm-root - @11.6.1 + @11.6.2

      Display npm root
      @@ -159,8 +159,8 @@

      Table of contents

      Note: This command is unaware of workspaces.

      Description

      Print the effective node_modules folder to standard out.

      -

      Useful for using npm in shell scripts that do things with the -node_modules folder. For example:

      +

      Useful for using npm in shell scripts that do things with the node_modules folder. +For example:

      #!/bin/bash
 global_node_modules="$(npm root --global)"
 echo "Global packages installed in: ${global_node_modules}"
@@ -171,12 +171,13 @@ 
      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 for more on the differences in behavior.

    +

    Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

      -
    • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
      • +
    • 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
    diff --git a/deps/npm/docs/output/commands/npm-run.html b/deps/npm/docs/output/commands/npm-run.html index af9b18e0a5ffdd..b481925c92e9c3 100644 --- a/deps/npm/docs/output/commands/npm-run.html +++ b/deps/npm/docs/output/commands/npm-run.html @@ -141,9 +141,9 @@
    -

    +

    npm-run - @11.6.1 + @11.6.2

    Run arbitrary package scripts
    @@ -159,55 +159,38 @@

    Table of contents

    aliases: run-script, rum, urn

    Description

    -

    This runs an arbitrary command from a package's "scripts" object. If no +

    This runs an arbitrary command from a package's "scripts" object. +If no "command" is provided, it will list the available scripts.

    -

    run[-script] is used by the test, start, restart, and stop commands, but -can be called directly, as well. When the scripts in the package are -printed out, they're separated into lifecycle (test, start, restart) and -directly-run scripts.

    -

    Any positional arguments are passed to the specified script. Use -- to -pass --prefixed flags and options which would otherwise be parsed by npm.

    +

    run[-script] is used by the test, start, restart, and stop commands, but can be called directly, as well. +When the scripts in the package are printed out, they're separated into lifecycle (test, start, restart) and directly-run scripts.

    +

    Any positional arguments are passed to the specified script. +Use -- to pass --prefixed flags and options which would otherwise be parsed by npm.

    For example:

    npm run test -- --grep="pattern"
    -

    The arguments will only be passed to the script specified after npm run -and not to any pre or post script.

    -

    The env script is a special built-in command that can be used to list -environment variables that will be available to the script at runtime. If an -"env" command is defined in your package, it will take precedence over the -built-in.

    -

    In addition to the shell's pre-existing PATH, npm run adds -node_modules/.bin to the PATH provided to scripts. Any binaries -provided by locally-installed dependencies can be used without the -node_modules/.bin prefix. For example, if there is a devDependency on -tap in your package, you should write:

    +

    The arguments will only be passed to the script specified after npm run and not to any pre or post script.

    +

    The env script is a special built-in command that can be used to list environment variables that will be available to the script at runtime. +If an "env" command is defined in your package, it will take precedence over the built-in.

    +

    In addition to the shell's pre-existing PATH, npm run adds node_modules/.bin to the PATH provided to scripts. +Any binaries provided by locally-installed dependencies can be used without the node_modules/.bin prefix. +For example, if there is a devDependency on tap in your package, you should write:

    "scripts": {"test": "tap test/*.js"}

    instead of

    "scripts": {"test": "node_modules/.bin/tap test/*.js"}
    -

    The actual shell your script is run within is platform dependent. By default, -on Unix-like systems it is the /bin/sh command, on Windows it is -cmd.exe. +

    The actual shell your script is run within is platform dependent. +By default, on Unix-like systems it is the /bin/sh command, on Windows it is cmd.exe. The actual shell referred to by /bin/sh also depends on the system. -You can customize the shell with the -script-shell config.

    -

    Scripts are run from the root of the package folder, regardless of what the -current working directory is when npm run is called. If you want your -script to use different behavior based on what subdirectory you're in, you -can use the INIT_CWD environment variable, which holds the full path you -were in when you ran npm run.

    -

    npm run sets the NODE environment variable to the node executable -with which npm is executed.

    -

    If you try to run a script without having a node_modules directory and it -fails, you will be given a warning to run npm install, just in case you've -forgotten.

    +You can customize the shell with the script-shell config.

    +

    Scripts are run from the root of the package folder, regardless of what the current working directory is when npm run is called. +If you want your script to use different behavior based on what subdirectory you're in, you can use the INIT_CWD environment variable, which holds the full path you were in when you ran npm run.

    +

    npm run sets the NODE environment variable to the node executable with which npm is executed.

    +

    If you try to run a script without having a node_modules directory and it fails, you will be given a warning to run npm install, just in case you've forgotten.

    Workspaces support

    -

    You may use the workspace or -workspaces configs in order to run an -arbitrary command from a package's "scripts" object in the context of the -specified workspaces. If no "command" is provided, it will list the available -scripts for each of these configured workspaces.

    +

    You may use the workspace or workspaces configs in order to run an arbitrary command from a package's "scripts" object in the context of the specified workspaces. +If no "command" is provided, it will list the available scripts for each of these configured workspaces.

    Given a project with configured workspaces, e.g:

    .
 +-- package.json
@@ -219,39 +202,33 @@ 
    Workspaces support
    
    `-- c
        `-- package.json
    -

    Assuming the workspace configuration is properly set up at the root level -package.json file. e.g:

    +

    Assuming the workspace configuration is properly set up at the root level package.json file. +e.g:

    {
     "workspaces": [ "./packages/*" ]
 }
    -

    And that each of the configured workspaces has a configured test script, -we can run tests in all of them using the -workspaces config:

    +

    And that each of the configured workspaces has a configured test script, we can run tests in all of them using the workspaces config:

    npm test --workspaces

    Filtering workspaces

    -

    It's also possible to run a script in a single workspace using the workspace -config along with a name or directory path:

    +

    It's also possible to run a script in a single workspace using the workspace config along with a name or directory path:

    npm test --workspace=a
    -

    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:

    +

    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 test -w a -w b
    -

    This last command will run test in both ./packages/a and ./packages/b -packages.

    +

    This last command will run test in both ./packages/a and ./packages/b packages.

    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.

    +

    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
      • @@ -259,9 +236,9 @@

      workspace

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

    +

    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

      @@ -270,13 +247,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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

    @@ -285,21 +263,22 @@

    include-workspace-root

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

    +

    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.

    if-present

    • Default: false
    • Type: Boolean
    -

    If true, npm will not exit with an error code when run is invoked for a -script that isn't defined in the scripts section of package.json. This -option can be used when it's desirable to optionally run a script when it's -present and fail if the script fails. This is useful, for example, when -running scripts that may only apply for some builds in an otherwise generic -CI setup.

    +

    If true, npm will not exit with an error code when run is invoked +for a script that isn't defined in the scripts section of +package.json. This option can be used when it's desirable to +optionally run a script when it's present and fail if the script +fails. This is useful, for example, when running scripts that may +only apply for some builds in an otherwise generic CI setup.

    This value is not exported to the environment for child processes.

    ignore-scripts

      @@ -307,27 +286,28 @@

      ignore-scripts

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

    +

    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.

    foreground-scripts

      -
    • Default: false unless when using npm pack or npm publish where it -defaults to true
      • +
    • 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.

    +

    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.

    script-shell

    • Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
    • Type: null or String
    -

    The shell to use for scripts run with the npm exec, npm run and npm init <package-spec> commands.

    +

    The shell to use for scripts run with the npm exec, npm run and +npm init <package-spec> commands.

    See Also

    • npm scripts
      • diff --git a/deps/npm/docs/output/commands/npm-sbom.html b/deps/npm/docs/output/commands/npm-sbom.html index d5efc52ca684b7..1aa1d701f3570f 100644 --- a/deps/npm/docs/output/commands/npm-sbom.html +++ b/deps/npm/docs/output/commands/npm-sbom.html @@ -141,9 +141,9 @@
      -

      +

      npm-sbom - @11.6.1 + @11.6.2

      Generate a Software Bill of Materials (SBOM)
      @@ -157,9 +157,8 @@

      Table of contents

      npm sbom

      Description

      -

      The npm sbom command generates a Software Bill of Materials (SBOM) listing the -dependencies for the current project. SBOMs can be generated in either -SPDX or CycloneDX format.

      +

      The npm sbom command generates a Software Bill of Materials (SBOM) listing the dependencies for the current project. +SBOMs can be generated in either SPDX or CycloneDX format.

      Example CycloneDX SBOM

      {
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
@@ -345,36 +344,37 @@ 
      Example SPDX SBOM
      
 }

      Package lock only mode

      -

      If package-lock-only is enabled, only the information in the package -lock (or shrinkwrap) is loaded. This means that information from the -package.json files of your dependencies will not be included in the -result set (e.g. description, homepage, engines).

      +

      If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. +This means that information from the package.json files of your dependencies will not be included in the result set (e.g. +description, homepage, engines).

      Configuration

      omit

      • Default: 'dev' if the NODE_ENV environment variable is set to -'production', otherwise empty.
        • +'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.

      +

      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.

      package-lock-only

      • Default: false
      • Type: Boolean
      -

      If set to true, the current operation will only use the package-lock.json, -ignoring node_modules.

      +

      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.

      +

      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.

      sbom-format

      • Default: null
        • @@ -386,17 +386,17 @@

        sbom-type

      • Default: "library"
      • Type: "library", "application", or "framework"
      -

      The type of package described by the generated SBOM. For SPDX, this is the -value for the primaryPackagePurpose field. For CycloneDX, this is the -value for the type field.

      +

      The type of package described by the generated SBOM. For SPDX, this +is the value for the primaryPackagePurpose field. For CycloneDX, +this is the value for the type field.

      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.

      +

      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
        • @@ -404,9 +404,9 @@

        workspace

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

      +

      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

        @@ -415,13 +415,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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.

      See Also

      diff --git a/deps/npm/docs/output/commands/npm-search.html b/deps/npm/docs/output/commands/npm-search.html index 0e949b6c37edb4..82bf85d1347d26 100644 --- a/deps/npm/docs/output/commands/npm-search.html +++ b/deps/npm/docs/output/commands/npm-search.html @@ -141,9 +141,9 @@
      -

      +

      npm-search - @11.6.1 + @11.6.2

      Search for packages
      @@ -160,23 +160,17 @@

      Table of contents

      Note: This command is unaware of workspaces.

      Description

      -

      Search the registry for packages matching the search terms. npm search -performs a linear, incremental, lexically-ordered search through package -metadata for all files in the registry. If your terminal has color -support, it will further highlight the matches in the results. This can -be disabled with the config item color

      -

      Additionally, using the --searchopts and --searchexclude options -paired with more search terms will include and exclude further patterns. -The main difference between --searchopts and the standard search terms -is that the former does not highlight results in the output and you can -use them more fine-grained filtering. Additionally, you can add both of -these to your config to change default search filtering behavior.

      -

      Search also allows targeting of maintainers in search results, by prefixing -their npm username with =.

      -

      If a term starts with /, then it's interpreted as a regular expression -and supports standard JavaScript RegExp syntax. In this case search will -ignore a trailing / . (Note you must escape or quote many regular -expression characters in most shells.)

      +

      Search the registry for packages matching the search terms. +npm search +performs a linear, incremental, lexically-ordered search through package metadata for all files in the registry. +If your terminal has color support, it will further highlight the matches in the results. +This can be disabled with the config item color

      +

      Additionally, using the --searchopts and --searchexclude options paired with more search terms will include and exclude further patterns. +The main difference between --searchopts and the standard search terms is that the former does not highlight results in the output and you can use them more fine-grained filtering. +Additionally, you can add both of these to your config to change default search filtering behavior.

      +

      Search also allows targeting of maintainers in search results, by prefixing their npm username with =.

      +

      If a term starts with /, then it's interpreted as a regular expression and supports standard JavaScript RegExp syntax. +In this case search will ignore a trailing / . (Note you must escape or quote many regular expression characters in most shells.)

      Configuration

      json

        @@ -185,24 +179,25 @@

        json

      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.
        • +
      • 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.

      color

        -
      • Default: true unless the NO_COLOR environ is set to something other than '0'
        • +
      • Default: true unless the NO_COLOR environ is set to something other +than '0'
      • Type: "always" or Boolean
      -

      If false, never shows colors. If "always" then always shows colors. If -true, then only prints color codes for tty file descriptors.

      +

      If false, never shows colors. If "always" then always shows colors. +If true, then only prints color codes for tty file descriptors.

      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.

      +

      Output parseable results from commands that write to standard output. +For npm search, this will be tab-separated table format.

      description

      • Default: true
        • @@ -214,8 +209,8 @@

        searchlimit

      • Default: 20
      • Type: Number
      -

      Number of items to limit search results to. Will not apply at all to legacy -searches.

      +

      Number of items to limit search results to. Will not apply at all to +legacy searches.

      searchopts

      • Default: ""
        • @@ -239,23 +234,24 @@

        prefer-online

      • Default: false
      • Type: Boolean
      -

      If true, staleness checks for cached data will be forced, making the CLI -look for updates immediately even for fresh package data.

      +

      If true, staleness checks for cached data will be forced, making the +CLI look for updates immediately even for fresh package data.

      prefer-offline

      • Default: false
      • Type: Boolean
      -

      If true, staleness checks for cached data will be bypassed, but missing data -will be requested from the server. To force full offline mode, use ---offline.

      +

      If true, staleness checks for cached data will be bypassed, but +missing data will be requested from the server. To force full offline +mode, use --offline.

      offline

      • Default: false
      • Type: Boolean
      -

      Force offline mode: no network requests will be done during install. To -allow the CLI to fill in missing cache data, see --prefer-offline.

      +

      Force offline mode: no network requests will be done during install. +To allow the CLI to fill in missing cache data, see +--prefer-offline.

      See Also

      • npm registry
        • diff --git a/deps/npm/docs/output/commands/npm-shrinkwrap.html b/deps/npm/docs/output/commands/npm-shrinkwrap.html index 018a01194a2c6b..f898acb8713c23 100644 --- a/deps/npm/docs/output/commands/npm-shrinkwrap.html +++ b/deps/npm/docs/output/commands/npm-shrinkwrap.html @@ -141,9 +141,9 @@
        -

        +

        npm-shrinkwrap - @11.6.1 + @11.6.2

        Lock down dependency versions for publication
        @@ -158,12 +158,9 @@

        Table of contents

        Note: This command is unaware of workspaces.

        Description

        -

        This command repurposes package-lock.json into a publishable -npm-shrinkwrap.json or simply creates a new one. The file created and -updated by this command will then take precedence over any other existing -or future package-lock.json files. For a detailed explanation of the -design and purpose of package locks in npm, see -package-lock-json.

        +

        This command repurposes package-lock.json into a publishable npm-shrinkwrap.json or simply creates a new one. +The file created and updated by this command will then take precedence over any other existing or future package-lock.json files. +For a detailed explanation of the design and purpose of package locks in npm, see package-lock-json.

        See Also

        • npm install
          • diff --git a/deps/npm/docs/output/commands/npm-star.html b/deps/npm/docs/output/commands/npm-star.html index a8378d9eddcb28..4c8a18633f1d59 100644 --- a/deps/npm/docs/output/commands/npm-star.html +++ b/deps/npm/docs/output/commands/npm-star.html @@ -141,9 +141,9 @@
          -

          +

          npm-star - @11.6.1 + @11.6.2

          Mark your favorite packages
          @@ -158,9 +158,10 @@

          Table of contents

          Note: This command is unaware of workspaces.

          Description

          -

          "Starring" a package means that you have some interest in it. It's -a vaguely positive way to show that you care.

          -

          It's a boolean thing. Starring repeatedly has no additional effect.

          +

          "Starring" a package means that you have some interest in it. +It's a vaguely positive way to show that you care.

          +

          It's a boolean thing. +Starring repeatedly has no additional effect.

          More

          There's also these extra commands to help you manage your favorite packages:

          Unstar

          @@ -177,21 +178,22 @@

          registry

          The base URL of the npm registry.

          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.
            • +
          • 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.

          +

          When set to true, npm uses unicode characters in the tree output. +When false, it uses ascii characters instead of unicode glyphs.

          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.

          +

          This is a one-time password from a two-factor authenticator. It's +needed when publishing or changing package permissions with npm access.

          +

          If not set, and a registry response fails with a challenge for a +one-time password, npm will prompt on the command line for one.

          See Also

          • package spec
            • diff --git a/deps/npm/docs/output/commands/npm-stars.html b/deps/npm/docs/output/commands/npm-stars.html index a33c0b9265dba3..cbf6a3e230b327 100644 --- a/deps/npm/docs/output/commands/npm-stars.html +++ b/deps/npm/docs/output/commands/npm-stars.html @@ -141,9 +141,9 @@
            -

            +

            npm-stars - @11.6.1 + @11.6.2

            View packages marked as favorites
            @@ -158,10 +158,8 @@

            Table of contents

            Note: This command is unaware of workspaces.

            Description

            -

            If you have starred a lot of neat things and want to find them again -quickly this command lets you do just that.

            -

            You may also want to see your friend's favorite packages, in this case -you will most certainly enjoy this command.

            +

            If you have starred a lot of neat things and want to find them again quickly this command lets you do just that.

            +

            You may also want to see your friend's favorite packages, in this case you will most certainly enjoy this command.

            Configuration

            registry

              diff --git a/deps/npm/docs/output/commands/npm-start.html b/deps/npm/docs/output/commands/npm-start.html index 97a0291b3f1b9c..dc5efc037fbf76 100644 --- a/deps/npm/docs/output/commands/npm-start.html +++ b/deps/npm/docs/output/commands/npm-start.html @@ -141,9 +141,9 @@
              -

              +

              npm-start - @11.6.1 + @11.6.2

              Start a package
              @@ -157,15 +157,11 @@

              Table of contents

              npm start [-- <args>]

              Description

              -

              This runs a predefined command specified in the "start" property of -a package's "scripts" object.

              -

              If the "scripts" object does not define a "start" property, npm -will run node server.js.

              -

              Note that this is different from the default node behavior of running -the file specified in a package's "main" attribute when evoking with -node .

              -

              As of npm@2.0.0, you can -use custom arguments when executing scripts. Refer to npm run for more details.

              +

              This runs a predefined command specified in the "start" property of a package's "scripts" object.

              +

              If the "scripts" object does not define a "start" property, npm will run node server.js.

              +

              Note that this is different from the default node behavior of running the file specified in a package's "main" attribute when evoking with node .

              +

              As of npm@2.0.0, you can use custom arguments when executing scripts. +Refer to npm run for more details.

              Example

              {
   "scripts": {
@@ -188,16 +184,16 @@ 
              ignore-scripts
              
 
            • 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.

            +

            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.

            script-shell

            • Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
            • Type: null or String
            -

            The shell to use for scripts run with the npm exec, npm run and npm init <package-spec> commands.

            +

            The shell to use for scripts run with the npm exec, npm run and +npm init <package-spec> commands.

            See Also

            • npm run
              • diff --git a/deps/npm/docs/output/commands/npm-stop.html b/deps/npm/docs/output/commands/npm-stop.html index c68c845a808f7d..c0adcdc7ba495d 100644 --- a/deps/npm/docs/output/commands/npm-stop.html +++ b/deps/npm/docs/output/commands/npm-stop.html @@ -141,9 +141,9 @@
              -

              +

              npm-stop - @11.6.1 + @11.6.2

              Stop a package
              @@ -157,10 +157,8 @@

              Table of contents

              npm stop [-- <args>]

              Description

              -

              This runs a predefined command specified in the "stop" property of a -package's "scripts" object.

              -

              Unlike with npm start, there is no default script -that will run if the "stop" property is not defined.

              +

              This runs a predefined command specified in the "stop" property of a package's "scripts" object.

              +

              Unlike with npm start, there is no default script that will run if the "stop" property is not defined.

              Example

              {
   "scripts": {
@@ -183,16 +181,16 @@ 
              ignore-scripts
              
 
            • 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.

            +

            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.

            script-shell

            • Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
            • Type: null or String
            -

            The shell to use for scripts run with the npm exec, npm run and npm init <package-spec> commands.

            +

            The shell to use for scripts run with the npm exec, npm run and +npm init <package-spec> commands.

            See Also

            • npm run
              • diff --git a/deps/npm/docs/output/commands/npm-team.html b/deps/npm/docs/output/commands/npm-team.html index 2684e0daf1ef78..8e88ded725cef9 100644 --- a/deps/npm/docs/output/commands/npm-team.html +++ b/deps/npm/docs/output/commands/npm-team.html @@ -141,9 +141,9 @@
              -

              +

              npm-team - @11.6.1 + @11.6.2

              Manage organization teams and team memberships
              @@ -162,26 +162,21 @@

              Table of contents

              Note: This command is unaware of workspaces.

              Description

              -

              Used to manage teams in organizations, and change team memberships. Does not -handle permissions for packages.

              -

              Teams must always be fully qualified with the organization/scope they belong to -when operating on them, separated by a colon (:). That is, if you have a -newteam team in an org organization, you must always refer to that team -as @org:newteam in these commands.

              -

              If you have two-factor authentication enabled in auth-and-writes mode, then -you can provide a code from your authenticator with [--otp <otpcode>]. -If you don't include this then you will be taken through a second factor flow based -on your authtype.

              +

              Used to manage teams in organizations, and change team memberships. +Does not handle permissions for packages.

              +

              Teams must always be fully qualified with the organization/scope they belong to when operating on them, separated by a colon (:). +That is, if you have a newteam team in an org organization, you must always refer to that team as @org:newteam in these commands.

              +

              If you have two-factor authentication enabled in auth-and-writes mode, then you can provide a code from your authenticator with [--otp <otpcode>]. +If you don't include this then you will be taken through a second factor flow based on your authtype.

              • create / destroy: -Create a new team, or destroy an existing one. Note: You cannot remove the -developers team, learn more.

                +Create a new team, or destroy an existing one. +Note: You cannot remove the developers team, learn more.

                Here's how to create a new team newteam under the org org:

                npm team create @org:newteam
                -

                You should see a confirming message such as: +@org:newteam once the new -team has been created.

                +

                You should see a confirming message such as: +@org:newteam once the new team has been created.

              • add: @@ -194,8 +189,7 @@

                Description

              • rm: Using npm team rm you can also remove users from a team they belong to.

                -

                Here's an example removing user username from newteam team -in org organization:

                +

                Here's an example removing user username from newteam team in org organization:

                npm team rm @org:newteam username

                Once the user is removed a confirmation message is displayed: @@ -203,9 +197,8 @@

                Description

              • ls: -If performed on an organization name, will return a list of existing teams -under that organization. If performed on a team, it will instead return a list -of all users belonging to that particular team.

                +If performed on an organization name, will return a list of existing teams under that organization. +If performed on a team, it will instead return a list of all users belonging to that particular team.

                Here's an example of how to list all teams from an org named org:

                npm team ls @org
                @@ -215,15 +208,11 @@

                Description

              Details

              -

              npm team always operates directly on the current registry, configurable from -the command line using --registry=<registry url>.

              -

              You must be a team admin to create teams and manage team membership, under -the given organization. Listing teams and team memberships may be done by -any member of the organization.

              -

              Organization creation and management of team admins and organization members -is done through the website, not the npm CLI.

              -

              To use teams to manage permissions on packages belonging to your organization, -use the npm access command to grant or revoke the appropriate permissions.

              +

              npm team always operates directly on the current registry, configurable from the command line using --registry=<registry url>.

              +

              You must be a team admin to create teams and manage team membership, under the given organization. +Listing teams and team memberships may be done by any member of the organization.

              +

              Organization creation and management of team admins and organization members is done through the website, not the npm CLI.

              +

              To use teams to manage permissions on packages belonging to your organization, use the npm access command to grant or revoke the appropriate permissions.

              Configuration

              registry

                @@ -236,17 +225,17 @@

                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.

              +

              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.

              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.

              +

              Output parseable results from commands that write to standard output. +For npm search, this will be tab-separated table format.

              json

              • Default: false
                • @@ -254,8 +243,8 @@

                json

              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.
                • +
              • In npm pkg set it enables parsing set values with JSON.parse() +before saving them to your package.json.

              Not supported by all npm commands.

              See Also

              diff --git a/deps/npm/docs/output/commands/npm-test.html b/deps/npm/docs/output/commands/npm-test.html index cb8f2a62584cdc..d2fd55d9c7d547 100644 --- a/deps/npm/docs/output/commands/npm-test.html +++ b/deps/npm/docs/output/commands/npm-test.html @@ -141,9 +141,9 @@
              -

              +

              npm-test - @11.6.1 + @11.6.2

              Test a package
              @@ -159,8 +159,7 @@

              Table of contents

              aliases: tst, t

              Description

              -

              This runs a predefined command specified in the "test" property of -a package's "scripts" object.

              +

              This runs a predefined command specified in the "test" property of a package's "scripts" object.

              Example

              {
   "scripts": {
@@ -181,16 +180,16 @@ 
              ignore-scripts
              
 
            • 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.

            +

            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.

            script-shell

            • Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
            • Type: null or String
            -

            The shell to use for scripts run with the npm exec, npm run and npm init <package-spec> commands.

            +

            The shell to use for scripts run with the npm exec, npm run and +npm init <package-spec> commands.

            See Also

            • npm run
              • diff --git a/deps/npm/docs/output/commands/npm-token.html b/deps/npm/docs/output/commands/npm-token.html index 1f94cb012dd5ee..f45149f9fb9463 100644 --- a/deps/npm/docs/output/commands/npm-token.html +++ b/deps/npm/docs/output/commands/npm-token.html @@ -141,9 +141,9 @@
              -

              +

              npm-token - @11.6.1 + @11.6.2

              Manage your authentication tokens
              @@ -163,8 +163,8 @@

              Description

              This lets you list, create and revoke authentication tokens.

              • npm token list: -Shows a table of all active authentication tokens. You can request -this as JSON with --json or tab-separated values with --parseable.
                • +Shows a table of all active authentication tokens. +You can request this as JSON with --json or tab-separated values with --parseable. 
              Read only token npm_1f… with id 7f3134 created 2017-10-21
 
@@ -177,28 +177,21 @@ 
              Description
              
 
                
 
              • 
 
                npm token create [--read-only] [--cidr=<cidr-ranges>]:
-Create a new authentication token. It can be --read-only, or accept
-a list of
-CIDR
-ranges with which to limit use of this token. This will prompt you for
-your password, and, if you have two-factor authentication enabled, an
-otp.
                
-
                Currently, the cli can not generate automation tokens. Please refer to
-the docs
-website
-for more information on generating automation tokens.
                
+Create a new authentication token.
+It can be --read-only, or accept a list of CIDR ranges with which to limit use of this token.
+This will prompt you for your password, and, if you have two-factor authentication enabled, an otp.
                
+
                Currently, the cli cannot generate automation tokens.
+Please refer to the docs website for more information on generating automation tokens.
                
 
                • 
 
              
 
              Created publish token a73c9572-f1b9-8983-983d-ba3ac3cc913d
 
              
 
                
 
              • npm token revoke <token|id>:
-Immediately removes an authentication token from the registry.  You
-will no longer be able to use it.  This can accept both complete
-tokens (such as those you get back from npm token create, and those
-found in your .npmrc), and ids as seen in the parseable or json
-output of npm token list.  This will NOT accept the truncated token
-found in the normal npm token list output.
                • 
+Immediately removes an authentication token from the registry.
+You will no longer be able to use it.
+This can accept both complete tokens (such as those you get back from npm token create, and those found in your .npmrc), and ids as seen in the parseable or json output of npm token list.
+This will NOT accept the truncated token found in the normal npm token list output.
 
              
 
              Configuration
              
 
              read-only
              
@@ -206,15 +199,15 @@ 
              read-only
              
 
            • Default: false
              • 
 
            • Type: Boolean
              •
            -

            This is used to mark a token as unable to publish when configuring limited -access tokens with the npm token create command.

            +

            This is used to mark a token as unable to publish when configuring +limited access tokens with the npm token create command.

            cidr

            • Default: null
            • Type: null or String (can be set multiple times)
            -

            This is a list of CIDR address to be used when configuring limited access -tokens with the npm token create command.

            +

            This is a list of CIDR address to be used when configuring limited +access tokens with the npm token create command.

            registry

            -

            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.

            +

            This is a one-time password from a two-factor authenticator. It's +needed when publishing or changing package permissions with npm access.

            +

            If not set, and a registry response fails with a challenge for a +one-time password, npm will prompt on the command line for one.

            See Also

            • npm adduser
              • diff --git a/deps/npm/docs/output/commands/npm-undeprecate.html b/deps/npm/docs/output/commands/npm-undeprecate.html index 635f8d5a7f3ff8..c1d80ebb5b58ee 100644 --- a/deps/npm/docs/output/commands/npm-undeprecate.html +++ b/deps/npm/docs/output/commands/npm-undeprecate.html @@ -141,9 +141,9 @@
              -

              +

              npm-undeprecate - @11.6.1 + @11.6.2

              Undeprecate a version of a package
              @@ -158,10 +158,8 @@

              Table of contents

              Note: This command is unaware of workspaces.

              Description

              -

              This command will update the npm registry entry for a package, removing any -deprecation warnings that currently exist.

              -

              It works in the same way as npm deprecate, except -that this command removes deprecation warnings instead of adding them.

              +

              This command will update the npm registry entry for a package, removing any deprecation warnings that currently exist.

              +

              It works in the same way as npm deprecate, except that this command removes deprecation warnings instead of adding them.

              Configuration

              registry

                @@ -174,21 +172,22 @@

                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.

              +

              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.

              +

              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

              • npm deprecate
                • diff --git a/deps/npm/docs/output/commands/npm-uninstall.html b/deps/npm/docs/output/commands/npm-uninstall.html index b1f0b329f79420..8d594127caa15c 100644 --- a/deps/npm/docs/output/commands/npm-uninstall.html +++ b/deps/npm/docs/output/commands/npm-uninstall.html @@ -141,9 +141,9 @@
                -

                +

                npm-uninstall - @11.6.1 + @11.6.2

                Remove a package
                @@ -159,28 +159,20 @@

                Table of contents

                aliases: unlink, remove, rm, r, un

                Description

                -

                This uninstalls a package, completely removing everything npm installed -on its behalf.

                +

                This uninstalls a package, completely removing everything npm installed on its behalf.

                It also removes the package from the dependencies, devDependencies, -optionalDependencies, and peerDependencies objects in your -package.json.

                -

                Further, if you have an npm-shrinkwrap.json or package-lock.json, npm -will update those files as well.

                -

                --no-save will tell npm not to remove the package from your -package.json, npm-shrinkwrap.json, or package-lock.json files.

                -

                --save or -S will tell npm to remove the package from your -package.json, npm-shrinkwrap.json, and package-lock.json files. -This is the default, but you may need to use this if you have for -instance save=false in your npmrc file

                -

                In global mode (ie, with -g or --global appended to the command), -it uninstalls the current package context as a global package. +optionalDependencies, and peerDependencies objects in your package.json.

                +

                Further, if you have an npm-shrinkwrap.json or package-lock.json, npm will update those files as well.

                +

                --no-save will tell npm not to remove the package from your package.json, npm-shrinkwrap.json, or package-lock.json files.

                +

                --save or -S will tell npm to remove the package from your package.json, npm-shrinkwrap.json, and package-lock.json files. +This is the default, but you may need to use this if you have for instance save=false in your npmrc file

                +

                In global mode (ie, with -g or --global appended to the command), it uninstalls the current package context as a global package. --no-save is ignored in this case.

                Scope is optional and follows the usual rules for scope.

                Examples

                npm uninstall sax
                -

                sax will no longer be in your package.json, npm-shrinkwrap.json, or -package-lock.json files.

                +

                sax will no longer be in your package.json, npm-shrinkwrap.json, or package-lock.json files.

                npm uninstall lodash --no-save

                lodash will not be removed from your package.json, @@ -188,7 +180,8 @@

                Examples

                Configuration

                save

                  -
                • Default: true unless when using npm update where it defaults to false
                  • +
                • Default: true unless when using npm update where it defaults to +false
                • Type: Boolean

                Save installed packages to a package.json file as dependencies.

                @@ -200,12 +193,13 @@

                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 for more on the differences in behavior.

              +

              Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

                -
              • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
                • +
              • 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
              @@ -214,9 +208,9 @@

              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.

            +

            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
              • @@ -224,9 +218,9 @@

              workspace

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

            +

            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

              @@ -235,13 +229,14 @@

              workspaces

            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:

            +

            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.
              • +
            • 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

            @@ -250,18 +245,19 @@

            include-workspace-root

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

          +

          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.

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

          +

          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 prune
            • diff --git a/deps/npm/docs/output/commands/npm-unpublish.html b/deps/npm/docs/output/commands/npm-unpublish.html index 3049dcf2045b38..97c04a4eea2ecc 100644 --- a/deps/npm/docs/output/commands/npm-unpublish.html +++ b/deps/npm/docs/output/commands/npm-unpublish.html @@ -141,9 +141,9 @@
            -

            +

            npm-unpublish - @11.6.1 + @11.6.2

            Remove a package from the registry
            @@ -156,39 +156,30 @@

            Table of contents

            Synopsis

            npm unpublish [<package-spec>]
            -

            To learn more about how the npm registry treats unpublish, see our -unpublish policies.

            +

            To learn more about how the npm registry treats unpublish, see our unpublish policies.

            Warning

            -

            Consider using the deprecate command instead, -if your intent is to encourage users to upgrade, or if you no longer -want to maintain a package.

            +

            Consider using the deprecate command instead, if your intent is to encourage users to upgrade, or if you no longer want to maintain a package.

            Description

            -

            This removes a package version from the registry, deleting its entry and -removing the tarball.

            -

            The npm registry will return an error if you are not logged -in.

            -

            If you do not specify a package name at all, the name and version to be -unpublished will be pulled from the project in the current directory.

            -

            If you specify a package name but do not specify a version or if you -remove all of a package's versions then the registry will remove the -root package entry entirely.

            -

            Even if you unpublish a package version, that specific name and version -combination can never be reused. In order to publish the package again, -you must use a new version number. If you unpublish the entire package, -you may not publish any new versions of that package until 24 hours have -passed.

            +

            This removes a package version from the registry, deleting its entry and removing the tarball.

            +

            The npm registry will return an error if you are not logged in.

            +

            If you do not specify a package name at all, the name and version to be unpublished will be pulled from the project in the current directory.

            +

            If you specify a package name but do not specify a version or if you remove all of a package's versions then the registry will remove the root package entry entirely.

            +

            Even if you unpublish a package version, that specific name and version combination can never be reused. +In order to publish the package again, you must use a new version number. +If you unpublish the entire package, you may not publish any new versions of that package until 24 hours have passed.

            Configuration

            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.

            +

            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
              • @@ -200,14 +191,16 @@

              force

            • 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 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.
              • +
            • 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).
              • @@ -219,9 +212,9 @@

              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.

            +

            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
              • @@ -229,9 +222,9 @@

              workspace

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

            +

            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

              @@ -240,13 +233,14 @@

              workspaces

            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:

            +

            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.
              • +
            • 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.

            See Also

            diff --git a/deps/npm/docs/output/commands/npm-unstar.html b/deps/npm/docs/output/commands/npm-unstar.html index 8e38bd18e80d5d..b3976de6064321 100644 --- a/deps/npm/docs/output/commands/npm-unstar.html +++ b/deps/npm/docs/output/commands/npm-unstar.html @@ -141,9 +141,9 @@
            -

            +

            npm-unstar - @11.6.1 + @11.6.2

            Remove an item from your favorite packages
            @@ -158,8 +158,7 @@

            Table of contents

            Note: This command is unaware of workspaces.

            Description

            -

            "Unstarring" a package is the opposite of npm star, -it removes an item from your list of favorite packages.

            +

            "Unstarring" a package is the opposite of npm star, it removes an item from your list of favorite packages.

            More

            There's also these extra commands to help you manage your favorite packages:

            Star

            @@ -175,21 +174,22 @@

            registry

            The base URL of the npm registry.

            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.
              • +
            • 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.

            +

            When set to true, npm uses unicode characters in the tree output. +When false, it uses ascii characters instead of unicode glyphs.

            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.

            +

            This is a one-time password from a two-factor authenticator. It's +needed when publishing or changing package permissions with npm access.

            +

            If not set, and a registry response fails with a challenge for a +one-time password, npm will prompt on the command line for one.

            See Also

            • npm star
              • diff --git a/deps/npm/docs/output/commands/npm-update.html b/deps/npm/docs/output/commands/npm-update.html index 454eaed4bc987d..ecd560cc49574c 100644 --- a/deps/npm/docs/output/commands/npm-update.html +++ b/deps/npm/docs/output/commands/npm-update.html @@ -141,9 +141,9 @@
              -

              +

              npm-update - @11.6.1 + @11.6.2

              Update packages
              @@ -159,24 +159,15 @@

              Table of contents

              aliases: up, upgrade, udpate

              Description

              -

              This command will update all the packages listed to the latest version -(specified by the tag config), respecting the semver -constraints of both your package and its dependencies (if they also require the -same package).

              +

              This command will update all the packages listed to the latest version (specified by the tag config), respecting the semver constraints of both your package and its dependencies (if they also require the same package).

              It will also install missing packages.

              -

              If the -g flag is specified, this command will update globally installed -packages.

              -

              If no package name is specified, all packages in the specified location (global -or local) will be updated.

              -

              Note that by default npm update will not update the semver values of direct -dependencies in your project package.json. If you want to also update -values in package.json you can run: npm update --save (or add the -save=true option to a configuration file -to make that the default behavior).

              +

              If the -g flag is specified, this command will update globally installed packages.

              +

              If no package name is specified, all packages in the specified location (global or local) will be updated.

              +

              Note that by default npm update will not update the semver values of direct dependencies in your project package.json. +If you want to also update values in package.json you can run: npm update --save (or add the save=true option to a configuration file to make that the default behavior).

              Example

              -

              For the examples below, assume that the current package is app and it depends -on dependencies, dep1 (dep2, .. etc.). The published versions of dep1 -are:

              +

              For the examples below, assume that the current package is app and it depends on dependencies, dep1 (dep2, .. etc.). +The published versions of dep1 are:

              {
   "dist-tags": { "latest": "1.2.2" },
   "versions": [
@@ -206,9 +197,9 @@ 
              Tilde Dependencies
              
   "dep1": "~1.1.1"
 }
              -

              In this case, running npm update will install dep1@1.1.2. Even though the -latest tag points to 1.2.2, this version does not satisfy ~1.1.1, which is -equivalent to >=1.1.1 <1.2.0. So the highest-sorting version that satisfies +

              In this case, running npm update will install dep1@1.1.2. +Even though the latest tag points to 1.2.2, this version does not satisfy ~1.1.1, which is equivalent to >=1.1.1 <1.2.0. +So the highest-sorting version that satisfies ~1.1.1 is used, which is 1.1.2.

              Caret Dependencies below 1.0.0

              Suppose app has a caret dependency on a version below 1.0.0, for example:

              @@ -222,8 +213,7 @@

              Caret Dependencies below 1.0.0

              "dep1": "^0.4.0" } -

              Then npm update will install dep1@0.4.1, because that is the highest-sorting -version that satisfies ^0.4.0 (>= 0.4.0 <0.5.0)

              +

              Then npm update will install dep1@0.4.1, because that is the highest-sorting version that satisfies ^0.4.0 (>= 0.4.0 <0.5.0)

              Subdependencies

              Suppose your app now also has a dependency on dep2

              {
@@ -242,25 +232,19 @@ 
              Subdependencies
              
   }
 }
              -

              Then npm update will install dep1@1.1.2 because that is the highest -version that dep2 allows. npm will prioritize having a single version -of dep1 in your tree rather than two when that single version can -satisfy the semver requirements of multiple dependencies in your tree. -In this case if you really did need your package to use a newer version -you would need to use npm install.

              +

              Then npm update will install dep1@1.1.2 because that is the highest version that dep2 allows. +npm will prioritize having a single version of dep1 in your tree rather than two when that single version can satisfy the semver requirements of multiple dependencies in your tree. +In this case if you really did need your package to use a newer version you would need to use npm install.

              Updating Globally-Installed Packages

              -

              npm update -g will apply the update action to each globally installed -package that is outdated -- that is, has a version that is different from -wanted.

              -

              Note: Globally installed packages are treated as if they are installed with a -caret semver range specified. So if you require to update to latest you may -need to run npm install -g [<pkg>...]

              -

              NOTE: If a package has been upgraded to a version newer than latest, it will -be downgraded.

              +

              npm update -g will apply the update action to each globally installed package that is outdated -- that is, has a version that is different from wanted.

              +

              Note: Globally installed packages are treated as if they are installed with a caret semver range specified. +So if you require to update to latest you may need to run npm install -g [<pkg>...]

              +

              NOTE: If a package has been upgraded to a version newer than latest, it will be downgraded.

              Configuration

              save

                -
              • Default: true unless when using npm update where it defaults to false
                • +
              • Default: true unless when using npm update where it defaults to +false
              • Type: Boolean

              Save installed packages to a package.json file as dependencies.

              @@ -272,12 +256,13 @@

              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 for more on the differences in behavior.

            +

            Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

              -
            • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
              • +
            • 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
            @@ -287,11 +272,12 @@

            install-strategy

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

          +(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
            • @@ -299,10 +285,10 @@

            legacy-bundling

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

          +

          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
            • @@ -310,97 +296,103 @@

            global-style

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

          +

          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.
            • +'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.

          +

          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)
            • +
          • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
          -

          Option that allows for defining which types of dependencies to install.

          +

          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.

          +

          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.

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

          +

          If set to false, then ignore package-lock.json files when +installing. This will also prevent writing package-lock.json if +save is true.

          foreground-scripts

            -
          • Default: false unless when using npm pack or npm publish where it -defaults to true
            • +
          • 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.

          +

          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.

          +

          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 for details on what is -submitted.

          +

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

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

          • Default: true
            • @@ -408,35 +400,37 @@

          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.

          +

          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 for details.

          +acknowledging the number of dependencies looking for funding. See +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.

          +

          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.

          +

          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
            • @@ -444,9 +438,9 @@

            workspace

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

          +

          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

            @@ -455,13 +449,14 @@

            workspaces

          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:

          +

          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.
            • +
          • 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

          @@ -470,18 +465,19 @@

          include-workspace-root

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

        +

        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.

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

        +

        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
          • diff --git a/deps/npm/docs/output/commands/npm-version.html b/deps/npm/docs/output/commands/npm-version.html index fc8141c11a29e3..c2462e2b5bd62f 100644 --- a/deps/npm/docs/output/commands/npm-version.html +++ b/deps/npm/docs/output/commands/npm-version.html @@ -141,9 +141,9 @@
          -

          +

          npm-version - @11.6.1 + @11.6.2

          Bump a package version
          @@ -164,8 +164,8 @@

          allow-same-version

        • Default: false
        • Type: Boolean
        -

        Prevents throwing an error when npm version is used to set the new version -to the same value as the current version.

        +

        Prevents throwing an error when npm version is used to set the new +version to the same value as the current version.

        commit-hooks

        • Default: true
          • @@ -177,8 +177,8 @@

          git-tag-version

        • Default: true
        • Type: Boolean
        -

        Tag the commit when using the npm version command. Setting this to false -results in no commit being made at all.

        +

        Tag the commit when using the npm version command. Setting this to +false results in no commit being made at all.

        json

        • Default: false
          • @@ -186,8 +186,8 @@

          json

        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.
          • +
        • 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.

        preid

        @@ -195,25 +195,25 @@

        preid

      • Default: ""
      • Type: String
      -

      The "prerelease identifier" to use as a prefix for the "prerelease" part of -a semver. Like the rc in 1.2.0-rc.8.

      +

      The "prerelease identifier" to use as a prefix for the "prerelease" +part of a semver. Like the rc in 1.2.0-rc.8.

      sign-git-tag

      • Default: false
      • Type: Boolean
      -

      If set to true, then the npm version command will tag the version using --s to add a signature.

      -

      Note that git requires you to have set up GPG keys in your git configs for -this to work properly.

      +

      If set to true, then the npm version command will tag the version +using -s to add a signature.

      +

      Note that git requires you to have set up GPG keys in your git +configs for this to work properly.

      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.

      +

      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
        • @@ -221,9 +221,9 @@

        workspace

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

      +

      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

        @@ -232,13 +232,14 @@

        workspaces

      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:

      +

      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.
        • +
      • 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

      @@ -246,71 +247,62 @@

      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.

    +

    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.

    +

    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.

    Description

    -

    Run this in a package directory to bump the version and write the new data -back to package.json, package-lock.json, and, if present, +

    Run this in a package directory to bump the version and write the new data back to package.json, package-lock.json, and, if present, npm-shrinkwrap.json.

    -

    The newversion argument should be a valid semver string, a valid second -argument to semver.inc (one -of patch, minor, major, prepatch, preminor, premajor, -prerelease), or from-git. In the second case, the existing version will -be incremented by 1 in the specified field. from-git will try to read -the latest git tag, and use that as the new npm version.

    -

    If run in a git repo, it will also create a version commit and tag. This -behavior is controlled by git-tag-version (see below), and can be -disabled on the command line by running npm --no-git-tag-version version. -It will fail if the working directory is not clean, unless the -f or ---force flag is set.

    -

    If supplied with -m or --message config option, -npm will use it as a commit message when creating a version commit. If the -message config contains %s then that will be replaced with the resulting -version number. For example:

    +

    The newversion argument should be a valid semver string, a valid second argument to semver.inc (one of patch, minor, major, prepatch, preminor, premajor, prerelease), or from-git. +In the second case, the existing version will be incremented by 1 in the specified field. +from-git will try to read the latest git tag, and use that as the new npm version.

    +

    If run in a git repo, it will also create a version commit and tag. +This behavior is controlled by git-tag-version (see below), and can be disabled on the command line by running npm --no-git-tag-version version. +It will fail if the working directory is not clean, unless the -f or --force flag is set.

    +

    If supplied with -m or --message config option, npm will use it as a commit message when creating a version commit. +If the message config contains %s then that will be replaced with the resulting version number. +For example:

    npm version patch -m "Upgrade to %s for reasons"
    -

    If the sign-git-tag config is set, then the -tag will be signed using the -s flag to git. Note that you must have a default -GPG key set up in your git config for this to work properly. For example:

    +

    If the sign-git-tag config is set, then the tag will be signed using the -s flag to git. +Note that you must have a default GPG key set up in your git config for this to work properly. +For example:

    $ npm config set sign-git-tag true
 $ npm version patch
 
-You need a passphrase to unlock the secret key for
-user: "isaacs (http://blog.izs.me/) <i@izs.me>"
+You need a passphrase to unlock the secret key for user: "isaacs (http://blog.izs.me/) <i@izs.me>"
 2048-bit RSA key, ID 6C481CF6, created 2010-08-31
 
 Enter passphrase:
    -

    If preversion, version, or postversion are in the scripts property -of the package.json, they will be executed as part of running npm version.

    +

    If preversion, version, or postversion are in the scripts property of the package.json, they will be executed as part of running npm version.

    The exact order of execution is as follows:

      -
    1. Check to make sure the git working directory is clean before we get -started. Your scripts may add files to the commit in future steps. +
    2. Check to make sure the git working directory is clean before we get started. +Your scripts may add files to the commit in future steps. This step is skipped if the --force flag is set.
      3. -
    3. Run the preversion script. These scripts have access to the old -version in package.json. A typical use would be running your full -test suite before deploying. Any files you want added to the commit -should be explicitly added using git add.
      4. -
    4. Bump version in package.json as requested (patch, minor, -major, etc).
      5. -
    5. Run the version script. These scripts have access to the new version -in package.json (so they can incorporate it into file headers in -generated files for example). Again, scripts should explicitly add -generated files to the commit using git add.
      6. +
    6. Run the preversion script. +These scripts have access to the old version in package.json. +A typical use would be running your full test suite before deploying. +Any files you want added to the commit should be explicitly added using git add.
      7. +
    7. Bump version in package.json as requested (patch, minor, major, etc).
      8. +
    8. Run the version script. +These scripts have access to the new version in package.json (so they can incorporate it into file headers in generated files for example). +Again, scripts should explicitly add generated files to the commit using git add.
    9. Commit and tag.
      10. -
    10. Run the postversion script. Use it to clean up the file system or -automatically push the commit and/or tag.
      11. +
    11. Run the postversion script. +Use it to clean up the file system or automatically push the commit and/or tag.

    Take the following example:

    {
@@ -321,10 +313,9 @@ 
    Description
    
   }
 }
    -

    This runs all your tests and proceeds only if they pass. Then runs your -build script, and adds everything in the dist directory to the commit. -After the commit, it pushes the new commit and tag up to the server, and -deletes the build/temp directory.

    +

    This runs all your tests and proceeds only if they pass. +Then runs your build script, and adds everything in the dist directory to the commit. +After the commit, it pushes the new commit and tag up to the server, and deletes the build/temp directory.

    See Also

    • npm init
      • diff --git a/deps/npm/docs/output/commands/npm-view.html b/deps/npm/docs/output/commands/npm-view.html index 5c0c234e5e5cfa..e48ae33a4c619d 100644 --- a/deps/npm/docs/output/commands/npm-view.html +++ b/deps/npm/docs/output/commands/npm-view.html @@ -141,9 +141,9 @@
      -

      +

      npm-view - @11.6.1 + @11.6.2

      View registry info
      @@ -170,48 +170,43 @@

      Description

      npm view ronn@0.3.5 dependencies

      By default, npm view shows data about the current project context (by looking for a package.json). -To show field data for the current project use a file path (i.e. .):

      +To show field data for the current project use a file path (i.e. +.):

      npm view . dependencies

      You can view child fields by separating them with a period. To view the git repository URL for the latest version of npm, you would run the following command:

      npm view npm repository.url
      -

      This makes it easy to view information about a dependency with a bit of -shell scripting. For example, to view all the data about the version of -opts that ronn depends on, you could write the following:

      +

      This makes it easy to view information about a dependency with a bit of shell scripting. +For example, to view all the data about the version of opts that ronn depends on, you could write the following:

      npm view opts@$(npm view ronn dependencies.opts)
      -

      For fields that are arrays, requesting a non-numeric field will return -all of the values from the objects in the list. For example, to get all -the contributor email addresses for the express package, you would run:

      +

      For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list. +For example, to get all the contributor email addresses for the express package, you would run:

      npm view express contributors.email
      -

      You may also use numeric indices in square braces to specifically select -an item in an array field. To just get the email address of the first -contributor in the list, you can run:

      +

      You may also use numeric indices in square braces to specifically select an item in an array field. +To just get the email address of the first contributor in the list, you can run:

      npm view express contributors[0].email

      If the field value you are querying for is a property of an object, you should run:

      npm view express time'[4.8.0]'

      Multiple fields may be specified, and will be printed one after another. -For example, to get all the contributor names and email addresses, you -can do this:

      +For example, to get all the contributor names and email addresses, you can do this:

      npm view express contributors.name contributors.email
      -

      "Person" fields are shown as a string if they would be shown as an -object. So, for example, this will show the list of npm contributors in -the shortened string format. (See package.json for more on this.)

      +

      "Person" fields are shown as a string if they would be shown as an object. +So, for example, this will show the list of npm contributors in the shortened string format. +(See package.json for more on this.)

      npm view npm contributors
      -

      If a version range is provided, then data will be printed for every -matching version of the package. This will show which version of jsdom -was required by each matching version of yui3:

      +

      If a version range is provided, then data will be printed for every matching version of the package. +This will show which version of jsdom was required by each matching version of yui3:

      npm view yui3@'>0.5.4' dependencies.jsdom
      -

      To show the connect package version history, you can do -this:

      +

      To show the connect package version history, you can do this:

      npm view connect versions

      Configuration

      @@ -222,8 +217,8 @@

      json

    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.
      • +
    • 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

    @@ -231,9 +226,9 @@

    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.

    +

    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
      • @@ -241,9 +236,9 @@

      workspace

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

    +

    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

      @@ -252,13 +247,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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

    @@ -267,19 +263,17 @@

    include-workspace-root

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

    +

    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.

    Output

    -

    If only a single string field for a single version is output, then it -will not be colorized or quoted, to enable piping the output to -another command. If the field is an object, it will be output as a JavaScript object literal.

    +

    If only a single string field for a single version is output, then it will not be colorized or quoted, to enable piping the output to another command. +If the field is an object, it will be output as a JavaScript object literal.

    If the --json flag is given, the outputted fields will be JSON.

    -

    If the version range matches multiple versions then each printed value -will be prefixed with the version it applies to.

    -

    If multiple fields are requested, then each of them is prefixed with -the field name.

    +

    If the version range matches multiple versions then each printed value will be prefixed with the version it applies to.

    +

    If multiple fields are requested, then each of them is prefixed with the field name.

    See Also

    • package spec
      • diff --git a/deps/npm/docs/output/commands/npm-whoami.html b/deps/npm/docs/output/commands/npm-whoami.html index 075357c3fd2ab0..f7407455d0de8b 100644 --- a/deps/npm/docs/output/commands/npm-whoami.html +++ b/deps/npm/docs/output/commands/npm-whoami.html @@ -141,9 +141,9 @@
      -

      +

      npm-whoami - @11.6.1 + @11.6.2

      Display npm username
      @@ -159,11 +159,8 @@

      Table of contents

      Note: This command is unaware of workspaces.

      Description

      Display the npm username of the currently logged-in user.

      -

      If logged into a registry that provides token-based authentication, then -connect to the /-/whoami registry endpoint to find the username -associated with the token, and print to standard output.

      -

      If logged into a registry that uses Basic Auth, then simply print the -username portion of the authentication string.

      +

      If logged into a registry that provides token-based authentication, then connect to the /-/whoami registry endpoint to find the username associated with the token, and print to standard output.

      +

      If logged into a registry that uses Basic Auth, then simply print the username portion of the authentication string.

      Configuration

      registry

        diff --git a/deps/npm/docs/output/commands/npm.html b/deps/npm/docs/output/commands/npm.html index 478502a9a979c7..6bb3e7ffd89962 100644 --- a/deps/npm/docs/output/commands/npm.html +++ b/deps/npm/docs/output/commands/npm.html @@ -141,9 +141,9 @@
        -

        +

        npm - @11.6.1 + @11.6.2

        javascript package manager
        @@ -158,113 +158,87 @@

        Table of contents

        Note: This command is unaware of workspaces.

        Version

        -

        11.6.1

        +

        11.6.2

        Description

        -

        npm is the package manager for the Node JavaScript platform. It puts -modules in place so that node can find them, and manages dependency -conflicts intelligently.

        -

        It is extremely configurable to support a variety of use cases. Most -commonly, you use it to publish, discover, install, and develop node -programs.

        +

        npm is the package manager for the Node JavaScript platform. +It puts modules in place so that node can find them, and manages dependency conflicts intelligently.

        +

        It is extremely configurable to support a variety of use cases. +Most commonly, you use it to publish, discover, install, and develop node programs.

        Run npm help to get a list of available commands.

        Important

        -

        npm comes preconfigured to use npm's public registry at -https://registry.npmjs.org by default. Use of the npm public registry is -subject to terms of use available at -https://docs.npmjs.com/policies/terms.

        -

        You can configure npm to use any compatible registry you like, and even -run your own registry. Use of someone else's registry is governed by -their terms of use.

        +

        npm comes preconfigured to use npm's public registry at https://registry.npmjs.org by default. +Use of the npm public registry is subject to terms of use available at https://docs.npmjs.com/policies/terms.

        +

        You can configure npm to use any compatible registry you like, and even run your own registry. +Use of someone else's registry is governed by their terms of use.

        Introduction

        You probably got npm because you want to install stuff.

        -

        The very first thing you will most likely want to run in any node -program is npm install to install its dependencies.

        -

        You can also run npm install blerg to install the latest version of -"blerg". Check out npm install for more -info. It can do a lot of stuff.

        -

        Use the npm search command to show everything that's available in the -public registry. Use npm ls to show everything you've installed.

        +

        The very first thing you will most likely want to run in any node program is npm install to install its dependencies.

        +

        You can also run npm install blerg to install the latest version of "blerg". Check out npm install for more info. +It can do a lot of stuff.

        +

        Use the npm search command to show everything that's available in the public registry. +Use npm ls to show everything you've installed.

        Dependencies

        -

        If a package lists a dependency using a git URL, npm will install that -dependency using the git -command and will generate an error if it is not installed.

        -

        If one of the packages npm tries to install is a native node module and -requires compiling of C++ Code, npm will use -node-gyp for that task. -For a Unix system, node-gyp -needs Python, make and a buildchain like GCC. On Windows, -Python and Microsoft Visual Studio C++ are needed. For more information -visit the node-gyp repository and -the node-gyp Wiki.

        +

        If a package lists a dependency using a git URL, npm will install that dependency using the git command and will generate an error if it is not installed.

        +

        If one of the packages npm tries to install is a native node module and requires compiling of C++ Code, npm will use node-gyp for that task. +For a Unix system, node-gyp needs Python, make and a buildchain like GCC. On Windows, Python and Microsoft Visual Studio C++ are needed. +For more information visit the node-gyp repository and the node-gyp Wiki.

        Directories

        -

        See folders to learn about where npm puts -stuff.

        +

        See folders to learn about where npm puts stuff.

        In particular, npm has two modes of operation:

        • local mode: -npm installs packages into the current project directory, which -defaults to the current working directory. Packages install to -./node_modules, and bins to ./node_modules/.bin.
          • +npm installs packages into the current project directory, which defaults to the current working directory. +Packages install to ./node_modules, and bins to ./node_modules/.bin.
        • global mode: -npm installs packages into the install prefix at -$npm_config_prefix/lib/node_modules and bins to -$npm_config_prefix/bin.
          • +npm installs packages into the install prefix at $npm_config_prefix/lib/node_modules and bins to $npm_config_prefix/bin.
        -

        Local mode is the default. Use -g or --global on any command to -run in global mode instead.

        +

        Local mode is the default. +Use -g or --global on any command to run in global mode instead.

        Developer Usage

        -

        If you're using npm to develop and publish your code, check out the -following help topics:

        +

        If you're using npm to develop and publish your code, check out the following help topics:

        • json: -Make a package.json file. See -package.json.
          • +Make a package.json file. +See package.json.
        • link: -Links your current working code into Node's path, so that you don't -have to reinstall every time you make a change. Use npm link to do this.
          • +Links your current working code into Node's path, so that you don't have to reinstall every time you make a change. +Use npm link to do this.
        • install: -It's a good idea to install things if you don't need the symbolic -link. Especially, installing other peoples code from the registry is -done via npm install
          • +It's a good idea to install things if you don't need the symbolic link. +Especially, installing other peoples code from the registry is done via npm install
        • adduser: -Create an account or log in. When you do this, npm will store -credentials in the user config file.
          • +Create an account or log in. +When you do this, npm will store credentials in the user config file.
        • publish: -Use the npm publish command to upload your -code to the registry.
          • +Use the npm publish command to upload your code to the registry.

        Configuration

        -

        npm is extremely configurable. It reads its configuration options from -5 places.

        +

        npm is extremely configurable. +It reads its configuration options from 5 places.

        • Command line switches: -Set a config with --key val. All keys take a value, even if they -are booleans (the config parser doesn't know what the options are at -the time of parsing). If you do not provide a value (--key) then -the option is set to boolean true.
          • +Set a config with --key val. +All keys take a value, even if they are booleans (the config parser doesn't know what the options are at the time of parsing). +If you do not provide a value (--key) then the option is set to boolean true.
        • Environment Variables: -Set any config by prefixing the name in an environment variable with -npm_config_. For example, export npm_config_key=val.
          • +Set any config by prefixing the name in an environment variable with npm_config_. +For example, export npm_config_key=val.
        • User Configs: -The file at $HOME/.npmrc is an ini-formatted list of configs. If -present, it is parsed. If the userconfig option is set in the cli -or env, that file will be used instead.
          • +The file at $HOME/.npmrc is an ini-formatted list of configs. +If present, it is parsed. +If the userconfig option is set in the cli or env, that file will be used instead.
        • Global Configs: -The file found at ./etc/npmrc (relative to the global prefix will be -parsed if it is found. See npm prefix for -more info on the global prefix. If the globalconfig option is set -in the cli, env, or user config, then that file is parsed instead.
          • +The file found at ./etc/npmrc (relative to the global prefix will be parsed if it is found. +See npm prefix for more info on the global prefix. +If the globalconfig option is set in the cli, env, or user config, then that file is parsed instead.
        • Defaults: -npm's default configuration options are defined in -lib/utils/config/definitions.js. These must not be changed.
          • +npm's default configuration options are defined in lib/utils/config/definitions.js. +These must not be changed.
        -

        See config for much much more information.

        +

        See config for much, much, more information.

        Contributions

        Patches welcome!

        -

        If you would like to help, but don't know what to work on, read the -contributing -guidelines and -check the issues list.

        +

        If you would like to help, but don't know what to work on, read the contributing guidelines and check the issues list.

        Bugs

        When you find issues, please report them: https://github.com/npm/cli/issues

        diff --git a/deps/npm/docs/output/commands/npx.html b/deps/npm/docs/output/commands/npx.html index 0bb1f85d654af4..1358a8399dce97 100644 --- a/deps/npm/docs/output/commands/npx.html +++ b/deps/npm/docs/output/commands/npx.html @@ -141,9 +141,9 @@
        -

        +

        npx - @11.6.1 + @11.6.2

        Run a command from a local or remote npm package
        @@ -160,77 +160,51 @@

        Table of contents

        npx --package=foo -c '<cmd> [args...]'

        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.

        -

        Whatever packages are specified by the --package option will be -provided in the PATH of the executed command, along with any locally -installed package executables. The --package option may be -specified multiple times, to execute the supplied command in an environment -where all specified packages are available.

        -

        If any requested packages are not present in the local project -dependencies, then they are installed to a folder in the npm cache, which -is added to the PATH environment variable in the executed process. A -prompt is printed (which can be suppressed by providing either --yes or ---no).

        -

        Package names provided without a specifier will be matched with whatever -version exists in the local project. Package names with a specifier will -only be considered a match if they have the exact same name and version as -the local dependency.

        -

        If no -c or --call option is provided, then the positional arguments -are used to generate the command string. If no --package options -are provided, then npm will attempt to determine the executable name from -the package specifier provided as the first positional argument according -to the following heuristic:

        +

        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.

        +

        Whatever packages are specified by the --package option will be provided in the PATH of the executed command, along with any locally installed package executables. +The --package option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available.

        +

        If any requested packages are not present in the local project dependencies, then they are installed to a folder in the npm cache, which is added to the PATH environment variable in the executed process. +A prompt is printed (which can be suppressed by providing either --yes or --no).

        +

        Package names provided without a specifier will be matched with whatever version exists in the local project. +Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency.

        +

        If no -c or --call option is provided, then the positional arguments are used to generate the command string. +If no --package options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic:

          -
        • If the package has a single entry in its bin field in package.json, -or if all entries are aliases of the same command, then that command -will be used.
          • -
        • If the package has multiple bin entries, and one of them matches the -unscoped portion of the name field, then that command will be used.
          • -
        • If this does not result in exactly one option (either because there are -no bin entries, or none of them match the name of the package), then +
        • 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.

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

        +

        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:

        +

        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:

        +

        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:

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

        +

        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

        Examples

        -

        Run the version of tap in the local dependencies, with the provided -arguments:

        +

        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:

        +

        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
@@ -240,31 +214,26 @@ 
        Examples
        
 $ npx -c 'eslint && say "hooray, lint passed"'

        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.

        +

        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.
          • +
        • 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 have been removed. Use NODE_OPTIONS instead: e.g., +
        • 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 have been removed. +Use NODE_OPTIONS instead: e.g., NODE_OPTIONS="--trace-warnings --trace-exit" npx foo --random=true
        • 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.
          • +
        • The --shell option is replaced with --script-shell, but maintained in the npx executable for backwards compatibility.

        See Also

          diff --git a/deps/npm/docs/output/configuring-npm/folders.html b/deps/npm/docs/output/configuring-npm/folders.html index 81e6bfe9f90df2..5b0f7946324bdf 100644 --- a/deps/npm/docs/output/configuring-npm/folders.html +++ b/deps/npm/docs/output/configuring-npm/folders.html @@ -141,9 +141,9 @@
          -

          +

          folders - @11.6.1 + @11.6.2

          Folder Structures Used by npm
          @@ -154,99 +154,69 @@

          Table of contents

          Description

          -

          npm puts various things on your computer. That's its job.

          +

          npm puts various things on your computer. +That's its job.

          This document will tell you what it puts where.

          tl;dr

            -
          • Local install (default): puts stuff in ./node_modules of the current -package root.
            • -
          • Global install (with -g): puts stuff in /usr/local or wherever node -is installed.
            • +
          • Local install (default): puts stuff in ./node_modules of the current package root.
            • +
          • Global install (with -g): puts stuff in /usr/local or wherever node is installed.
          • Install it locally if you're going to require() it.
          • Install it globally if you're going to run it on the command line.
          • If you need both, then install it in both places, or use npm link.

          prefix Configuration

          -

          The prefix config defaults to the location where -node is installed. On most systems, this is /usr/local. On Windows, it's -%AppData%\npm. On Unix systems, it's one level up, since node is typically -installed at {prefix}/bin/node rather than {prefix}/node.exe.

          +

          The prefix config defaults to the location where node is installed. +On most systems, this is /usr/local. +On Windows, it's %AppData%\npm. +On Unix systems, it's one level up, since node is typically installed at {prefix}/bin/node rather than {prefix}/node.exe.

          When the global flag is set, npm installs things into this prefix. -When it is not set, it uses the root of the current package, or the -current working directory if not in a package already.

          +When it is not set, it uses the root of the current package, or the current working directory if not in a package already.

          Node Modules

          Packages are dropped into the node_modules folder under the prefix. -When installing locally, this means that you can -require("packagename") to load its main module, or -require("packagename/lib/path/to/sub/module") to load other modules.

          +When installing locally, this means that you can require("packagename") to load its main module, or require("packagename/lib/path/to/sub/module") to load other modules.

          Global installs on Unix systems go to {prefix}/lib/node_modules. -Global installs on Windows go to {prefix}/node_modules (that is, no -lib folder.)

          -

          Scoped packages are installed the same way, except they are grouped together -in a sub-folder of the relevant node_modules folder with the name of that -scope prefix by the @ symbol, e.g. npm install @myorg/package would place -the package in {prefix}/node_modules/@myorg/package. See -scope for more details.

          +Global installs on Windows go to {prefix}/node_modules (that is, no lib folder.)

          +

          Scoped packages are installed the same way, except they are grouped together in a sub-folder of the relevant node_modules folder with the name of that scope prefix by the @ symbol, e.g. npm install @myorg/package would place the package in {prefix}/node_modules/@myorg/package. +See scope for more details.

          If you wish to require() a package, then install it locally.

          Executables

          -

          When in global mode, executables are linked into {prefix}/bin on Unix, -or directly into {prefix} on Windows. Ensure that path is in your -terminal's PATH environment to run them.

          -

          When in local mode, executables are linked into -./node_modules/.bin so that they can be made available to scripts run -through npm. (For example, so that a test runner will be in the path -when you run npm test.)

          +

          When in global mode, executables are linked into {prefix}/bin on Unix, or directly into {prefix} on Windows. +Ensure that path is in your terminal's PATH environment to run them.

          +

          When in local mode, executables are linked into ./node_modules/.bin so that they can be made available to scripts run through npm. +(For example, so that a test runner will be in the path when you run npm test.)

          Man Pages

          When in global mode, man pages are linked into {prefix}/share/man.

          When in local mode, man pages are not installed.

          Man pages are not installed on Windows systems.

          Cache

          -

          See npm cache. Cache files are stored in ~/.npm on Posix, or -%LocalAppData%/npm-cache on Windows.

          +

          See npm cache. +Cache files are stored in ~/.npm on Posix, or %LocalAppData%/npm-cache on Windows.

          This is controlled by the cache config param.

          More Information

          -

          When installing locally, npm first tries to find an appropriate -prefix folder. This is so that npm install foo@1.2.3 will install -to the sensible root of your package, even if you happen to have cded -into some other folder.

          -

          Starting at the $PWD, npm will walk up the folder tree checking for a -folder that contains either a package.json file, or a node_modules -folder. If such a thing is found, then that is treated as the effective -"current directory" for the purpose of running npm commands. (This -behavior is inspired by and similar to git's .git-folder seeking -logic when running git commands in a working dir.)

          +

          When installing locally, npm first tries to find an appropriate prefix folder. +This is so that npm install foo@1.2.3 will install to the sensible root of your package, even if you happen to have cded into some other folder.

          +

          Starting at the $PWD, npm will walk up the folder tree checking for a folder that contains either a package.json file, or a node_modules folder. +If such a thing is found, then that is treated as the effective "current directory" for the purpose of running npm commands. +(This behavior is inspired by and similar to git's .git-folder seeking logic when running git commands in a working dir.)

          If no package root is found, then the current folder is used.

          -

          When you run npm install foo@1.2.3, then the package is loaded into -the cache, and then unpacked into ./node_modules/foo. Then, any of -foo's dependencies are similarly unpacked into -./node_modules/foo/node_modules/....

          -

          Any bin files are symlinked to ./node_modules/.bin/, so that they may -be found by npm scripts when necessary.

          +

          When you run npm install foo@1.2.3, then the package is loaded into the cache, and then unpacked into ./node_modules/foo. +Then, any of foo's dependencies are similarly unpacked into ./node_modules/foo/node_modules/....

          +

          Any bin files are symlinked to ./node_modules/.bin/, so that they may be found by npm scripts when necessary.

          Global Installation

          -

          If the global config is set to true, then npm will -install packages "globally".

          -

          For global installation, packages are installed roughly the same way, -but using the folders described above.

          +

          If the global config is set to true, then npm will install packages "globally".

          +

          For global installation, packages are installed roughly the same way, but using the folders described above.

          Cycles, Conflicts, and Folder Parsimony

          -

          Cycles are handled using the property of node's module system that it -walks up the directories looking for node_modules folders. So, at every -stage, if a package is already installed in an ancestor node_modules -folder, then it is not installed at the current location.

          -

          Consider the case above, where foo -> bar -> baz. Imagine if, in -addition to that, baz depended on bar, so you'd have: -foo -> bar -> baz -> bar -> baz .... However, since the folder -structure is: foo/node_modules/bar/node_modules/baz, there's no need to -put another copy of bar into .../baz/node_modules, since when baz calls -require("bar"), it will get the copy that is installed in -foo/node_modules/bar.

          -

          This shortcut is only used if the exact same -version would be installed in multiple nested node_modules folders. It -is still possible to have a/node_modules/b/node_modules/a if the two -"a" packages are different versions. However, without repeating the -exact same package multiple times, an infinite regress will always be -prevented.

          -

          Another optimization can be made by installing dependencies at the -highest level possible, below the localized "target" folder (hoisting). +

          Cycles are handled using the property of node's module system that it walks up the directories looking for node_modules folders. +So, at every stage, if a package is already installed in an ancestor node_modules folder, then it is not installed at the current location.

          +

          Consider the case above, where foo -> bar -> baz. +Imagine if, in addition to that, baz depended on bar, so you'd have: +foo -> bar -> baz -> bar -> baz .... +However, since the folder structure is: foo/node_modules/bar/node_modules/baz, there's no need to put another copy of bar into .../baz/node_modules, since when baz calls require("bar"), it will get the copy that is installed in foo/node_modules/bar.

          +

          This shortcut is only used if the exact same version would be installed in multiple nested node_modules folders. +It is still possible to have a/node_modules/b/node_modules/a if the two "a" packages are different versions. +However, without repeating the exact same package multiple times, an infinite regress will always be prevented.

          +

          Another optimization can be made by installing dependencies at the highest level possible, below the localized "target" folder (hoisting). Since version 3, npm hoists dependencies by default.

          Example

          Consider this dependency graph:

          @@ -262,8 +232,7 @@

          Example

          `-- quux@3.x `-- bar -

          In this case, we might expect a folder structure like this -(with all dependencies hoisted to the highest level possible):

          +

          In this case, we might expect a folder structure like this (with all dependencies hoisted to the highest level possible):

          foo
 +-- node_modules
     +-- blerg (1.2.5) <---[A]
@@ -274,29 +243,22 @@ 
          Example
          
     +-- baz (1.2.3) <---[D]
     +-- quux (3.2.0) <---[E]
          -

          Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are -installed in foo's node_modules folder.

          -

          Even though the latest copy of blerg is 1.3.7, foo has a specific -dependency on version 1.2.5. So, that gets installed at [A]. Since the -parent installation of blerg satisfies bar's dependency on blerg@1.x, -it does not install another copy under [B].

          -

          Bar [B] also has dependencies on baz and asdf. Because it depends on baz@2.x, it cannot -re-use the baz@1.2.3 installed in the parent node_modules folder [D], -and must install its own copy [C]. In order to minimize duplication, npm hoists -dependencies to the top level by default, so asdf is installed under [A].

          +

          Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are installed in foo's node_modules folder.

          +

          Even though the latest copy of blerg is 1.3.7, foo has a specific dependency on version 1.2.5. +So, that gets installed at [A]. +Since the parent installation of blerg satisfies bar's dependency on blerg@1.x, it does not install another copy under [B].

          +

          Bar [B] also has dependencies on baz and asdf. +Because it depends on baz@2.x, it cannot re-use the baz@1.2.3 installed in the parent node_modules folder [D], and must install its own copy [C]. +In order to minimize duplication, npm hoists dependencies to the top level by default, so asdf is installed under [A].

          Underneath bar, the baz -> quux -> bar dependency creates a cycle. -However, because bar is already in quux's ancestry [B], it does not -unpack another copy of bar into that folder. Likewise, quux's [E] -folder tree is empty, because its dependency on bar is satisfied -by the parent folder copy installed at [B].

          +However, because bar is already in quux's ancestry [B], it does not unpack another copy of bar into that folder. +Likewise, quux's [E] folder tree is empty, because its dependency on bar is satisfied by the parent folder copy installed at [B].

          For a graphical breakdown of what is installed where, use npm ls.

          Publishing

          -

          Upon publishing, npm will look in the node_modules folder. If any of -the items there are not in the bundleDependencies array, then they will -not be included in the package tarball.

          -

          This allows a package maintainer to install all of their dependencies -(and dev dependencies) locally, but only re-publish those items that -cannot be found elsewhere. See package.json for more information.

          +

          Upon publishing, npm will look in the node_modules folder. +If any of the items there are not in the bundleDependencies array, then they will not be included in the package tarball.

          +

          This allows a package maintainer to install all of their dependencies (and dev dependencies) locally, but only re-publish those items that cannot be found elsewhere. +See package.json for more information.

          See also

          • package.json
            • diff --git a/deps/npm/docs/output/configuring-npm/install.html b/deps/npm/docs/output/configuring-npm/install.html index 2bb5048a227b03..2c55261fc691f4 100644 --- a/deps/npm/docs/output/configuring-npm/install.html +++ b/deps/npm/docs/output/configuring-npm/install.html @@ -141,9 +141,9 @@
            -

            +

            install - @11.6.1 + @11.6.2

            Download and install node and npm
            @@ -154,58 +154,40 @@

            Table of contents

            Description

            -

            To publish and install packages to and from the public npm registry, you -must install Node.js and the npm command line interface using either a Node -version manager or a Node installer. We strongly recommend using a Node -version manager to install Node.js and npm. We do not recommend using a -Node installer, since the Node installation process installs npm in a -directory with local permissions and can cause permissions errors when you -run npm packages globally.

            +

            To publish and install packages to and from the public npm registry, you must install Node.js and the npm command line interface using either a Node version manager or a Node installer. +We strongly recommend using a Node version manager to install Node.js and npm. We do not recommend using a +Node installer, since the Node installation process installs npm in a directory with local permissions and can cause permissions errors when you run npm packages globally.

            Overview

            Checking your version of npm and Node.js

            -

            To see if you already have Node.js and npm installed and check the -installed version, run the following commands:

            +

            To see if you already have Node.js and npm installed and check the installed version, run the following commands:

            node -v
 npm -v

            Using a Node version manager to install Node.js and npm

            -

            Node version managers allow you to install and switch between multiple -versions of Node.js and npm on your system so you can test your -applications on multiple versions of npm to ensure they work for users on -different versions. You can -search for them on GitHub.

            +

            Node version managers allow you to install and switch between multiple versions of Node.js and npm on your system so you can test your applications on multiple versions of npm to ensure they work for users on different versions. +You can search for them on GitHub.

            Using a Node installer to install Node.js and npm

            -

            If you are unable to use a Node version manager, you can use a Node -installer to install both Node.js and npm on your system.

            +

            If you are unable to use a Node version manager, you can use a Node installer to install both Node.js and npm on your system.

            macOS or Windows Node installers

            -

            If you're using macOS or Windows, use one of the installers from the -Node.js download page. Be sure to -install the version labeled LTS. Other versions have not yet been -tested with npm.

            +

            If you're using macOS or Windows, use one of the installers from the Node.js download page. +Be sure to install the version labeled LTS. Other versions have not yet been tested with npm.

            Linux or other operating systems Node installers

            -

            If you're using Linux or another operating system, use one of the following -installers:

            +

            If you're using Linux or another operating system, use one of the following installers:

            -

            Or see this page to -install npm for Linux in the way many Linux developers prefer.

            +

            Or see this page to install npm for Linux in the way many Linux developers prefer.

          diff --git a/deps/npm/docs/output/configuring-npm/npm-global.html b/deps/npm/docs/output/configuring-npm/npm-global.html index 81e6bfe9f90df2..5b0f7946324bdf 100644 --- a/deps/npm/docs/output/configuring-npm/npm-global.html +++ b/deps/npm/docs/output/configuring-npm/npm-global.html @@ -141,9 +141,9 @@
          -

          +

          folders - @11.6.1 + @11.6.2

          Folder Structures Used by npm
          @@ -154,99 +154,69 @@

          Table of contents

          Description

          -

          npm puts various things on your computer. That's its job.

          +

          npm puts various things on your computer. +That's its job.

          This document will tell you what it puts where.

          tl;dr

            -
          • Local install (default): puts stuff in ./node_modules of the current -package root.
            • -
          • Global install (with -g): puts stuff in /usr/local or wherever node -is installed.
            • +
          • Local install (default): puts stuff in ./node_modules of the current package root.
            • +
          • Global install (with -g): puts stuff in /usr/local or wherever node is installed.
          • Install it locally if you're going to require() it.
          • Install it globally if you're going to run it on the command line.
          • If you need both, then install it in both places, or use npm link.

          prefix Configuration

          -

          The prefix config defaults to the location where -node is installed. On most systems, this is /usr/local. On Windows, it's -%AppData%\npm. On Unix systems, it's one level up, since node is typically -installed at {prefix}/bin/node rather than {prefix}/node.exe.

          +

          The prefix config defaults to the location where node is installed. +On most systems, this is /usr/local. +On Windows, it's %AppData%\npm. +On Unix systems, it's one level up, since node is typically installed at {prefix}/bin/node rather than {prefix}/node.exe.

          When the global flag is set, npm installs things into this prefix. -When it is not set, it uses the root of the current package, or the -current working directory if not in a package already.

          +When it is not set, it uses the root of the current package, or the current working directory if not in a package already.

          Node Modules

          Packages are dropped into the node_modules folder under the prefix. -When installing locally, this means that you can -require("packagename") to load its main module, or -require("packagename/lib/path/to/sub/module") to load other modules.

          +When installing locally, this means that you can require("packagename") to load its main module, or require("packagename/lib/path/to/sub/module") to load other modules.

          Global installs on Unix systems go to {prefix}/lib/node_modules. -Global installs on Windows go to {prefix}/node_modules (that is, no -lib folder.)

          -

          Scoped packages are installed the same way, except they are grouped together -in a sub-folder of the relevant node_modules folder with the name of that -scope prefix by the @ symbol, e.g. npm install @myorg/package would place -the package in {prefix}/node_modules/@myorg/package. See -scope for more details.

          +Global installs on Windows go to {prefix}/node_modules (that is, no lib folder.)

          +

          Scoped packages are installed the same way, except they are grouped together in a sub-folder of the relevant node_modules folder with the name of that scope prefix by the @ symbol, e.g. npm install @myorg/package would place the package in {prefix}/node_modules/@myorg/package. +See scope for more details.

          If you wish to require() a package, then install it locally.

          Executables

          -

          When in global mode, executables are linked into {prefix}/bin on Unix, -or directly into {prefix} on Windows. Ensure that path is in your -terminal's PATH environment to run them.

          -

          When in local mode, executables are linked into -./node_modules/.bin so that they can be made available to scripts run -through npm. (For example, so that a test runner will be in the path -when you run npm test.)

          +

          When in global mode, executables are linked into {prefix}/bin on Unix, or directly into {prefix} on Windows. +Ensure that path is in your terminal's PATH environment to run them.

          +

          When in local mode, executables are linked into ./node_modules/.bin so that they can be made available to scripts run through npm. +(For example, so that a test runner will be in the path when you run npm test.)

          Man Pages

          When in global mode, man pages are linked into {prefix}/share/man.

          When in local mode, man pages are not installed.

          Man pages are not installed on Windows systems.

          Cache

          -

          See npm cache. Cache files are stored in ~/.npm on Posix, or -%LocalAppData%/npm-cache on Windows.

          +

          See npm cache. +Cache files are stored in ~/.npm on Posix, or %LocalAppData%/npm-cache on Windows.

          This is controlled by the cache config param.

          More Information

          -

          When installing locally, npm first tries to find an appropriate -prefix folder. This is so that npm install foo@1.2.3 will install -to the sensible root of your package, even if you happen to have cded -into some other folder.

          -

          Starting at the $PWD, npm will walk up the folder tree checking for a -folder that contains either a package.json file, or a node_modules -folder. If such a thing is found, then that is treated as the effective -"current directory" for the purpose of running npm commands. (This -behavior is inspired by and similar to git's .git-folder seeking -logic when running git commands in a working dir.)

          +

          When installing locally, npm first tries to find an appropriate prefix folder. +This is so that npm install foo@1.2.3 will install to the sensible root of your package, even if you happen to have cded into some other folder.

          +

          Starting at the $PWD, npm will walk up the folder tree checking for a folder that contains either a package.json file, or a node_modules folder. +If such a thing is found, then that is treated as the effective "current directory" for the purpose of running npm commands. +(This behavior is inspired by and similar to git's .git-folder seeking logic when running git commands in a working dir.)

          If no package root is found, then the current folder is used.

          -

          When you run npm install foo@1.2.3, then the package is loaded into -the cache, and then unpacked into ./node_modules/foo. Then, any of -foo's dependencies are similarly unpacked into -./node_modules/foo/node_modules/....

          -

          Any bin files are symlinked to ./node_modules/.bin/, so that they may -be found by npm scripts when necessary.

          +

          When you run npm install foo@1.2.3, then the package is loaded into the cache, and then unpacked into ./node_modules/foo. +Then, any of foo's dependencies are similarly unpacked into ./node_modules/foo/node_modules/....

          +

          Any bin files are symlinked to ./node_modules/.bin/, so that they may be found by npm scripts when necessary.

          Global Installation

          -

          If the global config is set to true, then npm will -install packages "globally".

          -

          For global installation, packages are installed roughly the same way, -but using the folders described above.

          +

          If the global config is set to true, then npm will install packages "globally".

          +

          For global installation, packages are installed roughly the same way, but using the folders described above.

          Cycles, Conflicts, and Folder Parsimony

          -

          Cycles are handled using the property of node's module system that it -walks up the directories looking for node_modules folders. So, at every -stage, if a package is already installed in an ancestor node_modules -folder, then it is not installed at the current location.

          -

          Consider the case above, where foo -> bar -> baz. Imagine if, in -addition to that, baz depended on bar, so you'd have: -foo -> bar -> baz -> bar -> baz .... However, since the folder -structure is: foo/node_modules/bar/node_modules/baz, there's no need to -put another copy of bar into .../baz/node_modules, since when baz calls -require("bar"), it will get the copy that is installed in -foo/node_modules/bar.

          -

          This shortcut is only used if the exact same -version would be installed in multiple nested node_modules folders. It -is still possible to have a/node_modules/b/node_modules/a if the two -"a" packages are different versions. However, without repeating the -exact same package multiple times, an infinite regress will always be -prevented.

          -

          Another optimization can be made by installing dependencies at the -highest level possible, below the localized "target" folder (hoisting). +

          Cycles are handled using the property of node's module system that it walks up the directories looking for node_modules folders. +So, at every stage, if a package is already installed in an ancestor node_modules folder, then it is not installed at the current location.

          +

          Consider the case above, where foo -> bar -> baz. +Imagine if, in addition to that, baz depended on bar, so you'd have: +foo -> bar -> baz -> bar -> baz .... +However, since the folder structure is: foo/node_modules/bar/node_modules/baz, there's no need to put another copy of bar into .../baz/node_modules, since when baz calls require("bar"), it will get the copy that is installed in foo/node_modules/bar.

          +

          This shortcut is only used if the exact same version would be installed in multiple nested node_modules folders. +It is still possible to have a/node_modules/b/node_modules/a if the two "a" packages are different versions. +However, without repeating the exact same package multiple times, an infinite regress will always be prevented.

          +

          Another optimization can be made by installing dependencies at the highest level possible, below the localized "target" folder (hoisting). Since version 3, npm hoists dependencies by default.

          Example

          Consider this dependency graph:

          @@ -262,8 +232,7 @@

          Example

          `-- quux@3.x `-- bar -

          In this case, we might expect a folder structure like this -(with all dependencies hoisted to the highest level possible):

          +

          In this case, we might expect a folder structure like this (with all dependencies hoisted to the highest level possible):

          foo
 +-- node_modules
     +-- blerg (1.2.5) <---[A]
@@ -274,29 +243,22 @@ 
          Example
          
     +-- baz (1.2.3) <---[D]
     +-- quux (3.2.0) <---[E]
          -

          Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are -installed in foo's node_modules folder.

          -

          Even though the latest copy of blerg is 1.3.7, foo has a specific -dependency on version 1.2.5. So, that gets installed at [A]. Since the -parent installation of blerg satisfies bar's dependency on blerg@1.x, -it does not install another copy under [B].

          -

          Bar [B] also has dependencies on baz and asdf. Because it depends on baz@2.x, it cannot -re-use the baz@1.2.3 installed in the parent node_modules folder [D], -and must install its own copy [C]. In order to minimize duplication, npm hoists -dependencies to the top level by default, so asdf is installed under [A].

          +

          Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are installed in foo's node_modules folder.

          +

          Even though the latest copy of blerg is 1.3.7, foo has a specific dependency on version 1.2.5. +So, that gets installed at [A]. +Since the parent installation of blerg satisfies bar's dependency on blerg@1.x, it does not install another copy under [B].

          +

          Bar [B] also has dependencies on baz and asdf. +Because it depends on baz@2.x, it cannot re-use the baz@1.2.3 installed in the parent node_modules folder [D], and must install its own copy [C]. +In order to minimize duplication, npm hoists dependencies to the top level by default, so asdf is installed under [A].

          Underneath bar, the baz -> quux -> bar dependency creates a cycle. -However, because bar is already in quux's ancestry [B], it does not -unpack another copy of bar into that folder. Likewise, quux's [E] -folder tree is empty, because its dependency on bar is satisfied -by the parent folder copy installed at [B].

          +However, because bar is already in quux's ancestry [B], it does not unpack another copy of bar into that folder. +Likewise, quux's [E] folder tree is empty, because its dependency on bar is satisfied by the parent folder copy installed at [B].

          For a graphical breakdown of what is installed where, use npm ls.

          Publishing

          -

          Upon publishing, npm will look in the node_modules folder. If any of -the items there are not in the bundleDependencies array, then they will -not be included in the package tarball.

          -

          This allows a package maintainer to install all of their dependencies -(and dev dependencies) locally, but only re-publish those items that -cannot be found elsewhere. See package.json for more information.

          +

          Upon publishing, npm will look in the node_modules folder. +If any of the items there are not in the bundleDependencies array, then they will not be included in the package tarball.

          +

          This allows a package maintainer to install all of their dependencies (and dev dependencies) locally, but only re-publish those items that cannot be found elsewhere. +See package.json for more information.

          See also

          • package.json
            • diff --git a/deps/npm/docs/output/configuring-npm/npm-json.html b/deps/npm/docs/output/configuring-npm/npm-json.html index 873593bdd303cf..bd50e9c1f15907 100644 --- a/deps/npm/docs/output/configuring-npm/npm-json.html +++ b/deps/npm/docs/output/configuring-npm/npm-json.html @@ -141,9 +141,9 @@
            -

            +

            package.json - @11.6.1 + @11.6.2

            Specifics of npm's package.json handling
            @@ -154,69 +154,60 @@

            Table of contents

            Description

            -

            This document is all you need to know about what's required in your -package.json file. It must be actual JSON, not just a JavaScript object -literal.

            -

            A lot of the behavior described in this document is affected by the config -settings described in config.

            +

            This document is all you need to know about what's required in your package.json file. +It must be actual JSON, not just a JavaScript object literal.

            +

            A lot of the behavior described in this document is affected by the config settings described in config.

            name

            -

            If you plan to publish your package, the most important things in your -package.json are the name and version fields as they will be required. The -name and version together form an identifier that is assumed to be -completely unique. Changes to the package should come along with changes -to the version. If you don't plan to publish your package, the name and -version fields are optional.

            +

            If you plan to publish your package, the most important things in your package.json are the name and version fields as they will be required. +The name and version together form an identifier that is assumed to be completely unique. +Changes to the package should come along with changes to the version. +If you don't plan to publish your package, the name and version fields are optional.

            The name is what your thing is called.

            Some rules:

              -
            • The name must be less than or equal to 214 characters. This includes the -scope for scoped packages.
              • -
            • The names of scoped packages can begin with a dot or an underscore. This -is not permitted without a scope.
              • +
            • The name must be less than or equal to 214 characters. +This includes the scope for scoped packages.
              • +
            • The names of scoped packages can begin with a dot or an underscore. +This is not permitted without a scope.
            • New packages must not have uppercase letters in the name.
              • -
            • The name ends up being part of a URL, an argument on the command line, -and a folder name. Therefore, the name can't contain any non-URL-safe -characters.
              • +
            • The name ends up being part of a URL, an argument on the command line, and a folder name. +Therefore, the name can't contain any non-URL-safe characters.

            Some tips:

            • Don't use the same name as a core Node module.
              • -
            • Don't put "js" or "node" in the name. It's assumed that it's js, since -you're writing a package.json file, and you can specify the engine using -the "engines" field. (See below.)
              • -
            • The name will probably be passed as an argument to require(), so it -should be something short, but also reasonably descriptive.
              • -
            • You may want to check the npm registry to see if there's something by -that name already, before you get too attached to it. +
            • Don't put "js" or "node" in the name. +It's assumed that it's js, since you're writing a package.json file, and you can specify the engine using the "engines" field. +(See below.)
              • +
            • The name will probably be passed as an argument to require(), so it should be something short, but also reasonably descriptive.
              • +
            • You may want to check the npm registry to see if there's something by that name already, before you get too attached to it. https://www.npmjs.com/
            -

            A name can be optionally prefixed by a scope, e.g. @npm/example. See -scope for more detail.

            +

            A name can be optionally prefixed by a scope, e.g. @npm/example. +See scope for more detail.

            version

            -

            If you plan to publish your package, the most important things in your -package.json are the name and version fields as they will be required. The -name and version together form an identifier that is assumed to be -completely unique. Changes to the package should come along with changes -to the version. If you don't plan to publish your package, the name and -version fields are optional.

            -

            Version must be parseable by -node-semver, which is bundled with -npm as a dependency. (npm install semver to use it yourself.)

            +

            If you plan to publish your package, the most important things in your package.json are the name and version fields as they will be required. +The name and version together form an identifier that is assumed to be completely unique. +Changes to the package should come along with changes to the version. +If you don't plan to publish your package, the name and version fields are optional.

            +

            Version must be parseable by node-semver, which is bundled with npm as a dependency. +(npm install semver to use it yourself.)

            description

            -

            Put a description in it. It's a string. This helps people discover your -package, as it's listed in npm search.

            +

            Put a description in it. +It's a string. +This helps people discover your package, as it's listed in npm search.

            keywords

            -

            Put keywords in it. It's an array of strings. This helps people discover -your package as it's listed in npm search.

            +

            Put keywords in it. +It's an array of strings. +This helps people discover your package as it's listed in npm search.

            homepage

            The URL to the project homepage.

            Example:

            "homepage": "https://github.com/npm/example#readme"

            bugs

            -

            The URL to your project's issue tracker and / or the email address to which -issues should be reported. These are helpful for people who encounter -issues with your package.

            +

            The URL to your project's issue tracker and / or the email address to which issues should be reported. +These are helpful for people who encounter issues with your package.

            It should look like this:

            {
   "bugs": {
@@ -225,38 +216,30 @@ 
            bugs
            
   }
 }
            -

            You can specify either one or both values. If you want to provide only a -URL, you can specify the value for "bugs" as a simple string instead of an -object.

            +

            You can specify either one or both values. +If you want to provide only a URL, you can specify the value for "bugs" as a simple string instead of an object.

            If a URL is provided, it will be used by the npm bugs command.

            license

            -

            You should specify a license for your package so that people know how they -are permitted to use it, and any restrictions you're placing on it.

            -

            If you're using a common license such as BSD-2-Clause or MIT, add a current -SPDX license identifier for the license you're using, like this:

            +

            You should specify a license for your package so that people know how they are permitted to use it, and any restrictions you're placing on it.

            +

            If you're using a common license such as BSD-2-Clause or MIT, add a current SPDX license identifier for the license you're using, like this:

            {
   "license" : "BSD-3-Clause"
 }
            -

            You can check the full list of SPDX license -IDs. Ideally, you should pick one that is -OSI approved.

            -

            If your package is licensed under multiple common licenses, use an SPDX -license expression syntax version 2.0 -string, like this:

            +

            You can check the full list of SPDX license IDs. +Ideally, you should pick one that is OSI approved.

            +

            If your package is licensed under multiple common licenses, use an SPDX license expression syntax version 2.0 string, like this:

            {
   "license" : "(ISC OR GPL-3.0)"
 }
            -

            If you are using a license that hasn't been assigned an SPDX identifier, or if -you are using a custom license, use a string value like this one:

            +

            If you are using a license that hasn't been assigned an SPDX identifier, or if you are using a custom license, use a string value like this one:

            {
   "license" : "SEE LICENSE IN <filename>"
 }

            Then include a file named <filename> at the top level of the package.

            -

            Some old packages used license objects or a "licenses" property containing -an array of license objects:

            +

            Some old packages used license objects or a "licenses" property containing an array of license objects:

            // Not valid metadata
 {
   "license" : {
@@ -279,7 +262,8 @@ 
            license
            
   ]
 }
            -

            Those styles are now deprecated. Instead, use SPDX expressions, like this:

            +

            Those styles are now deprecated. +Instead, use SPDX expressions, like this:

            {
   "license": "ISC"
 }
@@ -288,25 +272,23 @@ 
            license
            
   "license": "(MIT OR Apache-2.0)"
 }
            -

            Finally, if you do not wish to grant others the right to use a private or -unpublished package under any terms:

            +

            Finally, if you do not wish to grant others the right to use a private or unpublished package under any terms:

            {
   "license": "UNLICENSED"
 }

            Consider also setting "private": true to prevent accidental publication.

            people fields: author, contributors

            -

            The "author" is one person. "contributors" is an array of people. A -"person" is an object with a "name" field and optionally "url" and "email", -like this:

            +

            The "author" is one person. +"contributors" is an array of people. +A "person" is an object with a "name" field and optionally "url" and "email", like this:

            {
   "name" : "Barney Rubble",
   "email" : "barney@npmjs.com",
   "url" : "http://barnyrubble.npmjs.com/"
 }
            -

            Or you can shorten that all into a single string, and npm will parse it for -you:

            +

            Or you can shorten that all into a single string, and npm will parse it for you:

            {
   "author": "Barney Rubble <barney@npmjs.com> (http://barnyrubble.npmjs.com/)"
 }
@@ -314,9 +296,7 @@ 
            people fields: author, contributorsBoth email and url are optional either way.
            
 
            npm also sets a top-level "maintainers" field with your npm user info.
            
 
            funding
            
-
            You can specify an object containing a URL that provides up-to-date
-information about ways to help fund development of your package, a
-string URL, or an array of objects and string URLs:
            
+
            You can specify an object containing a URL that provides up-to-date information about ways to help fund development of your package, a string URL, or an array of objects and string URLs:
            
 
            {
   "funding": {
     "type" : "individual",
@@ -349,26 +329,18 @@ 
            funding
            
   ]
 }
 
            
-
            Users can use the npm fund subcommand to list the funding URLs of all
-dependencies of their project, direct and indirect. A shortcut to visit
-each funding URL is also available when providing the project name such as:
-npm fund <projectname> (when there are multiple URLs, the first one will
-be visited)
            
+
            Users can use the npm fund subcommand to list the funding URLs of all dependencies of their project, direct and indirect.
+A shortcut to visit each funding URL is also available when providing the project name such as:
+npm fund <projectname> (when there are multiple URLs, the first one will be visited)
            
 
            files
            
-
            The optional files field is an array of file patterns that describes the
-entries to be included when your package is installed as a dependency. File
-patterns follow a similar syntax to .gitignore, but reversed: including a
-file, directory, or glob pattern (*, **/*, and such) will make it so
-that file is included in the tarball when it's packed. Omitting the field
-will make it default to ["*"], which means it will include all files.
            
-
            Some special files and directories are also included or excluded regardless
-of whether they exist in the files array (see below).
            
-
            You can also provide a .npmignore file in the root of your package or in
-subdirectories, which will keep files from being included. At the root of
-your package it will not override the "files" field, but in subdirectories
-it will. The .npmignore file works just like a .gitignore. If there is
-a .gitignore file, and .npmignore is missing, .gitignore's contents
-will be used instead.
            
+
            The optional files field is an array of file patterns that describes the entries to be included when your package is installed as a dependency.
+File patterns follow a similar syntax to .gitignore, but reversed: including a file, directory, or glob pattern (*, **/*, and such) will make it so that file is included in the tarball when it's packed.
+Omitting the field will make it default to ["*"], which means it will include all files.
            
+
            Some special files and directories are also included or excluded regardless of whether they exist in the files array (see below).
            
+
            You can also provide a .npmignore file in the root of your package or in subdirectories, which will keep files from being included.
+At the root of your package it will not override the "files" field, but in subdirectories it will.
+The .npmignore file works just like a .gitignore.
+If there is a .gitignore file, and .npmignore is missing, .gitignore's contents will be used instead.
            
 
            Certain files are always included, regardless of settings:
            
 
              
 
            • package.json
              • 
@@ -394,15 +366,13 @@ 
              files
              
 
            • config.gypi
              • 
 
            • node_modules
              • 
 
            • npm-debug.log
              • 
-
            • package-lock.json (use
-npm-shrinkwrap.json
-if you wish it to be published)
              • 
+
            • package-lock.json (use npm-shrinkwrap.json if you wish it to be published)
              • 
 
            • pnpm-lock.yaml
              • 
 
            • yarn.lock
              • 
 
            • bun.lockb
              • 
 
            
-
            Most of these ignored files can be included specifically if included in
-the files globs.  Exceptions to this are:
            
+
            Most of these ignored files can be included specifically if included in the files globs.
+Exceptions to this are:
            
 
              
 
            • .git
              • 
 
            • .npmrc
              • 
@@ -412,36 +382,25 @@ 
              files
              
 
            • yarn.lock
              • 
 
            • bun.lockb
              • 
 
            
-
            These can not be included.
            
+
            These cannot be included.
            
 
            exports
            
-
            The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package. For more details see the node.js documentation on package entry points
            
+
            The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package.
+For more details see the node.js documentation on package entry points
            
 
            main
            
-
            The main field is a module ID that is the primary entry point to your
-program.  That is, if your package is named foo, and a user installs it,
-and then does require("foo"), then your main module's exports object will
-be returned.
            
+
            The main field is a module ID that is the primary entry point to your program.
+That is, if your package is named foo, and a user installs it, and then does require("foo"), then your main module's exports object will be returned.
            
 
            This should be a module relative to the root of your package folder.
            
-
            For most modules, it makes the most sense to have a main script and often
-not much else.
            
+
            For most modules, it makes the most sense to have a main script and often not much else.
            
 
            If main is not set, it defaults to index.js in the package's root folder.
            
 
            browser
            
-
            If your module is meant to be used client-side the browser field should be
-used instead of the main field. This is helpful to hint users that it might
-rely on primitives that aren't available in Node.js modules. (e.g.
-window)
            
+
            If your module is meant to be used client-side the browser field should be used instead of the main field.
+This is helpful to hint users that it might rely on primitives that aren't available in Node.js modules.
+(e.g. window)
            
 
            bin
            
-
            A lot of packages have one or more executable files that they'd like to
-install into the PATH. npm makes this pretty easy (in fact, it uses this
-feature to install the "npm" executable.)
            
-
            To use this, supply a bin field in your package.json which is a map of
-command name to local file name. When this package is installed globally,
-that file will be either linked inside the global bins directory or
-a cmd (Windows Command File) will be created which executes the specified
-file in the bin field, so it is available to run by name or name.cmd (on
-Windows PowerShell). When this package is installed as a dependency in another
-package, the file will be linked where it will be available to that package
-either directly by npm exec or by name in other scripts when invoking them
-via npm run.
            
+
            A lot of packages have one or more executable files that they'd like to install into the PATH. npm makes this pretty easy (in fact, it uses this feature to install the "npm" executable.)
            
+
            To use this, supply a bin field in your package.json which is a map of command name to local file name.
+When this package is installed globally, that file will be either linked inside the global bins directory or a cmd (Windows Command File) will be created which executes the specified file in the bin field, so it is available to run by name or name.cmd (on Windows PowerShell).
+When this package is installed as a dependency in another package, the file will be linked where it will be available to that package either directly by npm exec or by name in other scripts when invoking them via npm run.
            
 
            For example, myapp could have this:
            
 
            {
   "bin": {
@@ -449,12 +408,9 @@ 
            bin
            
   }
 }
 
            
-
            So, when you install myapp, in case of unix-like OS it'll create a symlink
-from the cli.js script to /usr/local/bin/myapp and in case of windows it
-will create a cmd file usually at C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd
-which runs the cli.js script.
            
-
            If you have a single executable, and its name should be the name of the
-package, then you can just supply it as a string.  For example:
            
+
            So, when you install myapp, in case of unix-like OS it'll create a symlink from the cli.js script to /usr/local/bin/myapp and in case of windows it will create a cmd file usually at C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd which runs the cli.js script.
            
+
            If you have a single executable, and its name should be the name of the package, then you can just supply it as a string.
+For example:
            
 
            {
   "name": "my-program",
   "version": "1.2.5",
@@ -470,18 +426,13 @@ 
            bin
            
   }
 }
 
            
-
            Please make sure that your file(s) referenced in bin starts with
-#!/usr/bin/env node, otherwise the scripts are started without the node
-executable!
            
+
            Please make sure that your file(s) referenced in bin starts with #!/usr/bin/env node; otherwise, the scripts are started without the node executable!
            
 
            Note that you can also set the executable files using directories.bin.
            
-
            See folders for more info on
-executables.
            
+
            See folders for more info on executables.
            
 
            man
            
-
            Specify either a single file or an array of filenames to put in place for
-the man program to find.
            
-
            If only a single file is provided, then it's installed such that it is the
-result from man <pkgname>, regardless of its actual filename.  For
-example:
            
+
            Specify either a single file or an array of filenames to put in place for the man program to find.
            
+
            If only a single file is provided, then it's installed such that it is the result from man <pkgname>, regardless of its actual filename.
+For example:
            
 
            {
   "name": "foo",
   "version": "1.2.3",
@@ -505,9 +456,8 @@ 
            man
            
 }
 
            
 
            will create files to do man foo and man foo-bar.
            
-
            Man files must end with a number, and optionally a .gz suffix if they are
-compressed.  The number dictates which man section the file is installed
-into.
            
+
            Man files must end with a number, and optionally a .gz suffix if they are compressed.
+The number dictates which man section the file is installed into.
            
 
            {
   "name": "foo",
   "version": "1.2.3",
@@ -521,26 +471,20 @@ 
            man
            
 
            
 
            will create entries for man foo and man 2 foo
            
 
            directories
            
-
            The CommonJS Packages spec
-details a few ways that you can indicate the structure of your package
-using a directories object. If you look at npm's
-package.json, you'll see that it
-has directories for doc, lib, and man.
            
+
            The CommonJS Packages spec details a few ways that you can indicate the structure of your package using a directories object.
+If you look at npm's package.json, you'll see that it has directories for doc, lib, and man.
            
 
            In the future, this information may be used in other creative ways.
            
 
            directories.bin
            
-
            If you specify a bin directory in directories.bin, all the files in
-that folder will be added.
            
-
            Because of the way the bin directive works, specifying both a bin path
-and setting directories.bin is an error. If you want to specify
-individual files, use bin, and for all the files in an existing bin
-directory, use directories.bin.
            
+
            If you specify a bin directory in directories.bin, all the files in that folder will be added.
            
+
            Because of the way the bin directive works, specifying both a bin path and setting directories.bin is an error.
+If you want to specify individual files, use bin, and for all the files in an existing bin directory, use directories.bin.
            
 
            directories.man
            
-
            A folder that is full of man pages.  Sugar to generate a "man" array by
-walking the folder.
            
+
            A folder that is full of man pages.
+Sugar to generate a "man" array by walking the folder.
            
 
            repository
            
-
            Specify the place where your code lives. This is helpful for people who
-want to contribute.  If the git repo is on GitHub, then the npm repo
-command will be able to find you.
            
+
            Specify the place where your code lives.
+This is helpful for people who want to contribute.
+If the git repo is on GitHub, then the npm repo command will be able to find you.
            
 
            Do it like this:
            
 
            {
   "repository": {
@@ -549,12 +493,10 @@ 
            repository
            
   }
 }
 
            
-
            The URL should be a publicly available (perhaps read-only) URL that can be
-handed directly to a VCS program without any modification.  It should not
-be a URL to an html project page that you put in your browser.  It's for
-computers.
            
-
            For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the
-same shortcut syntax you use for npm install:
            
+
            The URL should be a publicly available (perhaps read-only) URL that can be handed directly to a VCS program without any modification.
+It should not be a URL to an html project page that you put in your browser.
+It's for computers.
            
+
            For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same shortcut syntax you use for npm install:
            
 
            {
   "repository": "npm/example",
 
@@ -567,9 +509,7 @@ 
            repository
            
   "repository": "gitlab:user/repo"
 }
 
            
-
            If the package.json for your package is not in the root directory (for
-example if it is part of a monorepo), you can specify the directory in
-which it lives:
            
+
            If the package.json for your package is not in the root directory (for example if it is part of a monorepo), you can specify the directory in which it lives:
            
 
            {
   "repository": {
     "type": "git",
@@ -579,15 +519,12 @@ 
            repository
            
 }
 
            
 
            scripts
            
-
            The "scripts" property is a dictionary containing script commands that are
-run at various times in the lifecycle of your package.  The key is the
-lifecycle event, and the value is the command to run at that point.
            
-
            See scripts to find out more about writing package
-scripts.
            
+
            The "scripts" property is a dictionary containing script commands that are run at various times in the lifecycle of your package.
+The key is the lifecycle event, and the value is the command to run at that point.
            
+
            See scripts to find out more about writing package scripts.
            
 
            config
            
-
            A "config" object can be used to set configuration parameters used in
-package scripts that persist across upgrades.  For instance, if a package
-had the following:
            
+
            A "config" object can be used to set configuration parameters used in package scripts that persist across upgrades.
+For instance, if a package had the following:
            
 
            {
   "name": "foo",
   "config": {
@@ -595,15 +532,13 @@ 
            config
            
   }
 }
 
            
-
            It could also have a "start" script that referenced the
-npm_package_config_port environment variable.
            
+
            It could also have a "start" script that referenced the npm_package_config_port environment variable.
            
 
            dependencies
            
-
            Dependencies are specified in a simple object that maps a package name to a
-version range. The version range is a string which has one or more
-space-separated descriptors.  Dependencies can also be identified with a
-tarball or git URL.
            
-
            Please do not put test harnesses or transpilers or other "development"
-time tools in your dependencies object.  See devDependencies, below.
            
+
            Dependencies are specified in a simple object that maps a package name to a version range.
+The version range is a string which has one or more space-separated descriptors.
+Dependencies can also be identified with a tarball or git URL.
            
+
            Please do not put test harnesses or transpilers or other "development" time tools in your dependencies object.
+See devDependencies, below.
            
 
            See semver for more details about specifying version ranges.
            
 
              
 
            • version Must match version exactly
              • 
@@ -611,8 +546,7 @@ 
              dependencies
              
 
            • >=version etc
              • 
 
            • <version
              • 
 
            • <=version
              • 
-
            • ~version "Approximately equivalent to version"  See
-semver
              • 
+
            • ~version "Approximately equivalent to version"  See semver
              • 
 
            • ^version "Compatible with version"  See semver
              • 
 
            • 1.2.x 1.2.0, 1.2.1, etc., but not 1.3.0
              • 
 
            • http://... See 'URLs as Dependencies' below
              • 
@@ -647,33 +581,24 @@ 
              dependencies

            URLs as Dependencies

            You may specify a tarball URL in place of a version range.

            -

            This tarball will be downloaded and installed locally to your package at -install time.

            +

            This tarball will be downloaded and installed locally to your package at install time.

            Git URLs as Dependencies

            Git URLs are of the form:

            <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 is used.

            +

            <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 is used.

            Examples:

            git+ssh://git@github.com:npm/cli.git#v1.0.27
 git+ssh://git@github.com:npm/cli#semver:^5.0
 git+https://isaacs@github.com/npm/cli.git
 git://github.com/npm/cli.git#v1.0.27
            -

            When installing from a git repository, the presence of certain fields in the -package.json will cause npm to believe it needs to perform a build. To do so -your repository will be cloned into a temporary directory, all of its deps -installed, relevant scripts run, and the resulting directory packed and -installed.

            -

            This flow will occur if your git dependency uses workspaces, or if any of the -following scripts are present:

            +

            When installing from a git repository, the presence of certain fields in the package.json will cause npm to believe it needs to perform a build. +To do so your repository will be cloned into a temporary directory, all of its deps installed, relevant scripts run, and the resulting directory packed and installed.

            +

            This flow will occur if your git dependency uses workspaces, or if any of the following scripts are present:

            • build
            • prepare
              • @@ -682,13 +607,11 @@

              Git URLs as Dependencies

            • install
            • postinstall
            -

            If your git repository includes pre-built artifacts, you will likely want to -make sure that none of the above scripts are defined, or your dependency -will be rebuilt for every installation.

            +

            If your git repository includes pre-built artifacts, you will likely want to make sure that none of the above scripts are defined, or your dependency will be rebuilt for every installation.

            GitHub URLs

            As of version 1.1.65, you can refer to GitHub URLs as just "foo": -"user/foo-project". Just as with git URLs, a commit-ish suffix can be -included. For example:

            +"user/foo-project". Just as with git URLs, a commit-ish suffix can be included. +For example:

            {
   "name": "foo",
   "version": "0.0.0",
@@ -700,15 +623,15 @@ 
            GitHub URLs
            
 }

            Local Paths

            -

            As of version 2.0.0 you can provide a path to a local directory that -contains a package. Local paths can be saved using npm install -S or npm install --save, using any of these forms:

            +

            As of version 2.0.0 you can provide a path to a local directory that contains a package. +Local paths can be saved using npm install -S or npm install --save, using any of these forms:

            ../foo/bar
 ~/foo/bar
 ./foo/bar
 /foo/bar
            -

            in which case they will be normalized to a relative path and added to your -package.json. For example:

            +

            in which case they will be normalized to a relative path and added to your package.json. +For example:

            {
   "name": "baz",
   "dependencies": {
@@ -716,24 +639,15 @@ 
            Local Paths
            
   }
 }
            -

            This feature is helpful for local offline development and creating tests -that require npm installing where you don't want to hit an external server, -but should not be used when publishing your package to the public registry.

            -

            note: Packages linked by local path will not have their own -dependencies installed when npm install is run. You must -run npm install from inside the local path itself.

            +

            This feature is helpful for local offline development and creating tests that require npm installing where you don't want to hit an external server, but should not be used when publishing your package to the public registry.

            +

            note: Packages linked by local path will not have their own dependencies installed when npm install is run. +You must run npm install from inside the local path itself.

            devDependencies

            -

            If someone is planning on downloading and using your module in their -program, then they probably don't want or need to download and build the -external test or documentation framework that you use.

            -

            In this case, it's best to map these additional items in a -devDependencies object.

            -

            These things will be installed when doing npm link or npm install from -the root of a package, and can be managed like any other npm configuration -param. See config for more on the topic.

            -

            For build steps that are not platform-specific, such as compiling -CoffeeScript or other languages to JavaScript, use the prepare script to -do this, and make the required package a devDependency.

            +

            If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use.

            +

            In this case, it's best to map these additional items in a devDependencies object.

            +

            These things will be installed when doing npm link or npm install from the root of a package, and can be managed like any other npm configuration param. +See config for more on the topic.

            +

            For build steps that are not platform-specific, such as compiling CoffeeScript or other languages to JavaScript, use the prepare script to do this, and make the required package a devDependency.

            For example:

            {
   "name": "@npm/ethopia-waza",
@@ -748,16 +662,11 @@ 
            devDependencies
            
   "main": "lib/waza.js"
 }
            -

            The prepare script will be run before publishing, so that users can -consume the functionality without requiring them to compile it themselves. -In dev mode (ie, locally running npm install), it'll run this script as -well, so that you can test it easily.

            +

            The prepare script will be run before publishing, so that users can consume the functionality without requiring them to compile it themselves. +In dev mode (ie, locally running npm install), it'll run this script as well, so that you can test it easily.

            peerDependencies

            -

            In some cases, you want to express the compatibility of your package with a -host tool or library, while not necessarily doing a require of this host. -This is usually referred to as a plugin. Notably, your module may be -exposing a specific interface, expected and specified by the host -documentation.

            +

            In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a require of this host. +This is usually referred to as a plugin. Notably, your module may be exposing a specific interface, expected and specified by the host documentation.

            For example:

            {
   "name": "@npm/tea-latte",
@@ -767,31 +676,23 @@ 
            peerDependencies
            
   }
 }
            -

            This ensures your package @npm/tea-latte can be installed along with the -second major version of the host package @npm/tea only. npm install tea-latte could possibly yield the following dependency graph:

            +

            This ensures your package @npm/tea-latte can be installed along with the second major version of the host package @npm/tea only. +npm install tea-latte could possibly yield the following dependency graph:

            ├── @npm/tea-latte@1.3.5
 └── @npm/tea@2.2.0
            -

            In npm versions 3 through 6, peerDependencies were not automatically -installed, and would raise a warning if an invalid version of the peer -dependency was found in the tree. As of npm v7, peerDependencies are -installed by default.

            -

            Trying to install another plugin with a conflicting requirement may cause -an error if the tree cannot be resolved correctly. For this reason, make -sure your plugin requirement is as broad as possible, and not to lock it -down to specific patch versions.

            -

            Assuming the host complies with semver, only changes -in the host package's major version will break your plugin. Thus, if you've -worked with every 1.x version of the host package, use "^1.0" or "1.x" -to express this. If you depend on features introduced in 1.5.2, use -"^1.5.2".

            +

            In npm versions 3 through 6, peerDependencies were not automatically installed, and would raise a warning if an invalid version of the peer dependency was found in the tree. +As of npm v7, peerDependencies are installed by default.

            +

            Trying to install another plugin with a conflicting requirement may cause an error if the tree cannot be resolved correctly. +For this reason, make sure your plugin requirement is as broad as possible, and not to lock it down to specific patch versions.

            +

            Assuming the host complies with semver, only changes in the host package's major version will break your plugin. +Thus, if you've worked with every 1.x version of the host package, use "^1.0" or "1.x" to express this. +If you depend on features introduced in 1.5.2, use "^1.5.2".

            peerDependenciesMeta

            -

            The peerDependenciesMeta field serves to provide npm more information on how -your peer dependencies are to be used. Specifically, it allows peer -dependencies to be marked as optional. Npm will not automatically install -optional peer dependencies. This allows you to -integrate and interact with a variety of host packages without requiring -all of them to be installed.

            +

            The peerDependenciesMeta field serves to provide npm more information on how your peer dependencies are to be used. +Specifically, it allows peer dependencies to be marked as optional. +Npm will not automatically install optional peer dependencies. +This allows you to integrate and interact with a variety of host packages without requiring all of them to be installed.

            For example:

            {
   "name": "@npm/tea-latte",
@@ -808,12 +709,8 @@ 
            peerDependenciesMeta
            
 }

            bundleDependencies

            -

            This defines an array of package names that will be bundled when publishing -the package.

            -

            In cases where you need to preserve npm packages locally or have them -available through a single file download, you can bundle the packages in a -tarball file by specifying the package names in the bundleDependencies -array and executing npm pack.

            +

            This defines an array of package names that will be bundled when publishing the package.

            +

            In cases where you need to preserve npm packages locally or have them available through a single file download, you can bundle the packages in a tarball file by specifying the package names in the bundleDependencies array and executing npm pack.

            For example:

            If we define a package.json like this:

            {
@@ -826,21 +723,18 @@ 
            bundleDependencies
            
 }

            we can obtain @npm/awesome-web-framework-1.0.0.tgz file by running npm pack. -This file contains the dependencies @npm/renderized and @npm/super-streams which -can be installed in a new project by executing npm install awesome-web-framework-1.0.0.tgz. Note that the package names do not -include any versions, as that information is specified in dependencies.

            +This file contains the dependencies @npm/renderized and @npm/super-streams which can be installed in a new project by executing npm install awesome-web-framework-1.0.0.tgz. +Note that the package names do not include any versions, as that information is specified in dependencies.

            If this is spelled "bundledDependencies", then that is also honored.

            -

            Alternatively, "bundleDependencies" can be defined as a boolean value. A -value of true will bundle all dependencies, a value of false will bundle -none.

            +

            Alternatively, "bundleDependencies" can be defined as a boolean value. +A value of true will bundle all dependencies, a value of false will bundle none.

            optionalDependencies

            -

            If a dependency can be used, but you would like npm to proceed if it cannot -be found or fails to install, then you may put it in the -optionalDependencies object. This is a map of package name to version or -URL, just like the dependencies object. The difference is that build -failures do not cause installation to fail. Running npm install --omit=optional will prevent these dependencies from being installed.

            -

            It is still your program's responsibility to handle the lack of the -dependency. For example, something like this:

            +

            If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the optionalDependencies object. +This is a map of package name to version or URL, just like the dependencies object. +The difference is that build failures do not cause installation to fail. +Running npm install --omit=optional will prevent these dependencies from being installed.

            +

            It is still your program's responsibility to handle the lack of the dependency. +For example, something like this:

            try {
   var foo = require('@npm/foo')
   var fooVersion = require('@npm/foo/package.json').version
@@ -857,34 +751,23 @@ 
            optionalDependencies
            
   foo.doFooThings()
 }
            -

            Entries in optionalDependencies will override entries of the same name in -dependencies, so it's usually best to only put in one place.

            +

            Entries in optionalDependencies will override entries of the same name in dependencies, so it's usually best to only put in one place.

            overrides

            -

            If you need to make specific changes to dependencies of your dependencies, for -example replacing the version of a dependency with a known security issue, -replacing an existing dependency with a fork, or making sure that the same -version of a package is used everywhere, then you may add an override.

            -

            Overrides provide a way to replace a package in your dependency tree with -another version, or another package entirely. These changes can be scoped as -specific or as vague as desired.

            +

            If you need to make specific changes to dependencies of your dependencies, for example replacing the version of a dependency with a known security issue, replacing an existing dependency with a fork, or making sure that the same version of a package is used everywhere, then you may add an override.

            +

            Overrides provide a way to replace a package in your dependency tree with another version, or another package entirely. +These changes can be scoped as specific or as vague as desired.

            Overrides are only considered in the root package.json file for a project. -Overrides in installed dependencies (including -workspaces) are not considered in dependency tree -resolution. Published packages may dictate their resolutions by pinning -dependencies or using an -npm-shrinkwrap.json file.

            -

            To make sure the package @npm/foo is always installed as version 1.0.0 no matter -what version your dependencies rely on:

            +Overrides in installed dependencies (including workspaces) are not considered in dependency tree resolution. +Published packages may dictate their resolutions by pinning dependencies or using an npm-shrinkwrap.json file.

            +

            To make sure the package @npm/foo is always installed as version 1.0.0 no matter what version your dependencies rely on:

            {
   "overrides": {
     "@npm/foo": "1.0.0"
   }
 }
            -

            The above is a short hand notation, the full object form can be used to allow -overriding a package itself as well as a child of the package. This will cause -@npm/foo to always be 1.0.0 while also making @npm/bar at any depth beyond @npm/foo -also 1.0.0:

            +

            The above is a short hand notation, the full object form can be used to allow overriding a package itself as well as a child of the package. +This will cause @npm/foo to always be 1.0.0 while also making @npm/bar at any depth beyond @npm/foo also 1.0.0:

            {
   "overrides": {
     "@npm/foo": {
@@ -894,8 +777,7 @@ 
            overrides
            
   }
 }
            -

            To only override @npm/foo to be 1.0.0 when it's a child (or grandchild, or great -grandchild, etc) of the package @npm/bar:

            +

            To only override @npm/foo to be 1.0.0 when it's a child (or grandchild, or great grandchild, etc) of the package @npm/bar:

            {
   "overrides": {
     "@npm/bar": {
@@ -904,8 +786,8 @@ 
            overrides
            
   }
 }
            -

            Keys can be nested to any arbitrary length. To override @npm/foo only when it's a -child of @npm/bar and only when @npm/bar is a child of @npm/baz:

            +

            Keys can be nested to any arbitrary length. +To override @npm/foo only when it's a child of @npm/bar and only when @npm/bar is a child of @npm/baz:

            {
   "overrides": {
     "@npm/baz": {
@@ -926,11 +808,8 @@ 
            overrides
            
   }
 }
            -

            You may not set an override for a package that you directly depend on unless -both the dependency and the override itself share the exact same spec. To make -this limitation easier to deal with, overrides may also be defined as a -reference to a spec for a direct dependency by prefixing the name of the -package you wish the version to match with a $.

            +

            You may not set an override for a package that you directly depend on unless both the dependency and the override itself share the exact same spec. +To make this limitation easier to deal with, overrides may also be defined as a reference to a spec for a direct dependency by prefixing the name of the package you wish the version to match with a $.

            {
   "dependencies": {
     "@npm/foo": "^1.0.0"
@@ -955,23 +834,18 @@ 
            engines
            
   }
 }
            -

            And, like with dependencies, if you don't specify the version (or if you -specify "*" as the version), then any version of node will do.

            -

            You can also use the "engines" field to specify which versions of npm are -capable of properly installing your program. For example:

            +

            And, like with dependencies, if you don't specify the version (or if you specify "*" as the version), then any version of node will do.

            +

            You can also use the "engines" field to specify which versions of npm are capable of properly installing your program. +For example:

            {
   "engines": {
     "npm": "~1.0.20"
   }
 }
            -

            Unless the user has set the -engine-strict config flag, this field is -advisory only and will only produce warnings when your package is installed as a -dependency.

            +

            Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.

            os

            -

            You can specify which operating systems your -module will run on:

            +

            You can specify which operating systems your module will run on:

            {
   "os": [
     "darwin",
@@ -979,8 +853,7 @@ 
            os
            
   ]
 }
            -

            You can also block instead of allowing operating systems, just prepend the -blocked os with a '!':

            +

            You can also block instead of allowing operating systems, just prepend the blocked os with a '!':

            {
   "os": [
     "!win32"
@@ -988,11 +861,9 @@ 
            os
            
 }

            The host operating system is determined by process.platform

            -

            It is allowed to both block and allow an item, although there isn't any -good reason to do this.

            +

            It is allowed to both block and allow an item, although there isn't any good reason to do this.

            cpu

            -

            If your code only runs on certain cpu architectures, -you can specify which ones.

            +

            If your code only runs on certain cpu architectures, you can specify which ones.

            {
   "cpu": [
     "x64",
@@ -1010,8 +881,8 @@ 
            cpu

            The host architecture is determined by process.arch

            libc

            -

            If your code only runs or builds in certain versions of libc, you can -specify which ones. This field only applies if os is linux.

            +

            If your code only runs or builds in certain versions of libc, you can specify which ones. +This field only applies if os is linux.

            {
   "os": "linux",
   "libc": "glibc"
@@ -1021,10 +892,17 @@ 
            devEngines
            
 
            The devEngines field aids engineers working on a codebase to all be using the same tooling.
            
 
            You can specify a devEngines property in your package.json which will run before install, ci, and run commands.
            
 
            
-
            Note: engines and devEngines differ in object shape. They also function very differently. engines is designed to alert the user when a dependency uses a differening npm or node version that the project it's being used in, whereas devEngines is used to alert people interacting with the source code of a project.
            
+
            Note: engines and devEngines differ in object shape.
+They also function very differently.
+engines is designed to alert the user when a dependency uses a different npm or node version than the project it's being used in, whereas devEngines is used to alert people interacting with the source code of a project.
            
 
            
-
            The supported keys under the devEngines property are cpu, os, libc, runtime, and packageManager. Each property can be an object or an array of objects. Objects must contain name, and optionally can specify version, and onFail. onFail can be warn, error, or ignore, and if left undefined is of the same value as error. npm will assume that you're running with node.
-Here's an example of a project that will fail if the environment is not node and npm. If you set runtime.name or packageManager.name to any other string, it will fail within the npm CLI.
            
+
            The supported keys under the devEngines property are cpu, os, libc, runtime, and packageManager.
+Each property can be an object or an array of objects.
+Objects must contain name, and optionally can specify version, and onFail.
+onFail can be warn, error, or ignore, and if left undefined is of the same value as error.
+npm will assume that you're running with node.
+Here's an example of a project that will fail if the environment is not node and npm.
+If you set runtime.name or packageManager.name to any other string, it will fail within the npm CLI.
            
 
            {
   "devEngines": {
     "runtime": {
@@ -1039,31 +917,17 @@ 
            devEngines
            
 }
 
            
 
            private
            
-
            If you set "private": true in your package.json, then npm will refuse to
-publish it.
            
+
            If you set "private": true in your package.json, then npm will refuse to publish it.
            
 
            This is a way to prevent accidental publication of private repositories.
-If you would like to ensure that a given package is only ever published to
-a specific registry (for example, an internal registry), then use the
-publishConfig dictionary described below to override the registry
-config param at publish-time.
            
+If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the publishConfig dictionary described below to override the registry config param at publish-time.
            
 
            publishConfig
            
-
            This is a set of config values that will be used at publish-time. It's
-especially handy if you want to set the tag, registry or access, so that
-you can ensure that a given package is not tagged with "latest", published
-to the global public registry or that a scoped module is private by
-default.
            
-
            See config to see the list of config options that
-can be overridden.
            
+
            This is a set of config values that will be used at publish-time.
+It's especially handy if you want to set the tag, registry or access, so that you can ensure that a given package is not tagged with "latest", published to the global public registry or that a scoped module is private by default.
            
+
            See config to see the list of config options that can be overridden.
            
 
            workspaces
            
-
            The optional workspaces field is an array of file patterns that describes
-locations within the local file system that the install client should look
-up to find each workspace that needs to be
-symlinked to the top level node_modules folder.
            
-
            It can describe either the direct paths of the folders to be used as
-workspaces or it can define globs that will resolve to these same folders.
            
-
            In the following example, all folders located inside the folder
-./packages will be treated as workspaces as long as they have valid
-package.json files inside them:
            
+
            The optional workspaces field is an array of file patterns that describes locations within the local file system that the install client should look up to find each workspace that needs to be symlinked to the top level node_modules folder.
            
+
            It can describe either the direct paths of the folders to be used as workspaces or it can define globs that will resolve to these same folders.
            
+
            In the following example, all folders located inside the folder ./packages will be treated as workspaces as long as they have valid package.json files inside them:
            
 
            {
   "name": "workspace-example",
   "workspaces": [
@@ -1077,20 +941,16 @@ 
            DEFAULT VALUES
            
 
              
 
            • 
 
              "scripts": {"start": "node server.js"}
              
-
              If there is a server.js file in the root of your package, then npm will
-default the start command to node server.js.
              
+
              If there is a server.js file in the root of your package, then npm will default the start command to node server.js.
              
 
              • 
 
            • 
 
              "scripts":{"install": "node-gyp rebuild"}
              
-
              If there is a binding.gyp file in the root of your package and you have
-not defined an install or preinstall script, npm will default the
-install command to compile using node-gyp.
              
+
              If there is a binding.gyp file in the root of your package and you have not defined an install or preinstall script, npm will default the install command to compile using node-gyp.
              
 
              • 
 
            • 
 
              "contributors": [...]
              
-
              If there is an AUTHORS file in the root of your package, npm will treat
-each line as a Name <email> (url) format, where email and url are
-optional.  Lines which start with a # or are blank, will be ignored.
              
+
              If there is an AUTHORS file in the root of your package, npm will treat each line as a Name <email> (url) format, where email and url are optional.
+Lines which start with a # or are blank, will be ignored.
              
 
              • 
 
            
 
            SEE ALSO
            
diff --git a/deps/npm/docs/output/configuring-npm/npm-shrinkwrap-json.html b/deps/npm/docs/output/configuring-npm/npm-shrinkwrap-json.html
index 5a2bac10b85068..db174340c220bf 100644
--- a/deps/npm/docs/output/configuring-npm/npm-shrinkwrap-json.html
+++ b/deps/npm/docs/output/configuring-npm/npm-shrinkwrap-json.html
@@ -141,9 +141,9 @@
 
 
            
 
            
-
            
+
            
     npm-shrinkwrap.json
-    @11.6.1
+    @11.6.2
 
            
 A publishable lockfile
 
            
@@ -154,21 +154,13 @@ 
            Table of contents
            
 
            
 
 
            Description
            
-
            npm-shrinkwrap.json is a file created by npm shrinkwrap. It is identical to
-package-lock.json, with one major caveat: Unlike package-lock.json,
+
            npm-shrinkwrap.json is a file created by npm shrinkwrap.
+It is identical to package-lock.json, with one major caveat: Unlike package-lock.json,
 npm-shrinkwrap.json may be included when publishing a package.
            
-
            The recommended use-case for npm-shrinkwrap.json is applications deployed
-through the publishing process on the registry: for example, daemons and
-command-line tools intended as global installs or devDependencies. It's
-strongly discouraged for library authors to publish this file, since that
-would prevent end users from having control over transitive dependency
-updates.
            
-
            If both package-lock.json and npm-shrinkwrap.json are present in a
-package root, npm-shrinkwrap.json will be preferred over the
-package-lock.json file.
            
-
            For full details and description of the npm-shrinkwrap.json file format,
-refer to the manual page for
-package-lock.json.
            
+
            The recommended use-case for npm-shrinkwrap.json is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs or devDependencies.
+It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates.
            
+
            If both package-lock.json and npm-shrinkwrap.json are present in a package root, npm-shrinkwrap.json will be preferred over the package-lock.json file.
            
+
            For full details and description of the npm-shrinkwrap.json file format, refer to the manual page for package-lock.json.
            
 
            See also
            
 
              
 
            • npm shrinkwrap
              • 
diff --git a/deps/npm/docs/output/configuring-npm/npmrc.html b/deps/npm/docs/output/configuring-npm/npmrc.html
index 2bbb1cf843f7e3..819e8c80b66213 100644
--- a/deps/npm/docs/output/configuring-npm/npmrc.html
+++ b/deps/npm/docs/output/configuring-npm/npmrc.html
@@ -141,9 +141,9 @@
 
 
              
 
              
-
              
+
              
     npmrc
-    @11.6.1
+    @11.6.2
 
              
 The npm config files
 
              
@@ -154,12 +154,9 @@ 
              Table of contents
              
 
              
 
 
              Description
              
-
              npm gets its config settings from the command line, environment variables,
-and npmrc files.
              
-
              The npm config command can be used to update and edit the contents of the
-user and global npmrc files.
              
-
              For a list of available configuration options, see
-config.
              
+
              npm gets its config settings from the command line, environment variables, and npmrc files.
              
+
              The npm config command can be used to update and edit the contents of the user and global npmrc files.
              
+
              For a list of available configuration options, see config.
              
 
              Files
              
 
              The four relevant files are:
              
 
                
@@ -169,23 +166,24 @@ 
                Files
                
 
              • npm builtin config file (/path/to/npm/npmrc)
                • 
 
              
 
              All npm config files are an ini-formatted list of key = value parameters.
-Environment variables can be replaced using ${VARIABLE_NAME}. By default
-if the variable is not defined, it is left unreplaced. By adding ? after
-variable name they can be forced to evaluate to an empty string instead. For
-example:
              
+Environment variables can be replaced using ${VARIABLE_NAME}.
+By default if the variable is not defined, it is left unreplaced.
+By adding ? after variable name they can be forced to evaluate to an empty string instead.
+For example:
              
 
              cache = ${HOME}/.npm-packages
 node-options = "${NODE_OPTIONS?} --use-system-ca"
 
              
-
              Each of these files is loaded, and config options are resolved in priority
-order.  For example, a setting in the userconfig file would override the
-setting in the globalconfig file.
              
-
              Array values are specified by adding "[]" after the key name. For example:
              
+
              Each of these files is loaded, and config options are resolved in priority order.
+For example, a setting in the userconfig file would override the setting in the globalconfig file.
              
+
              Array values are specified by adding "[]" after the key name.
+For example:
              
 
              key[] = "first value"
 key[] = "second value"
 
              
 
              Comments
              
 
              Lines in .npmrc files are interpreted as comments when they begin with a
-; or # character. .npmrc files are parsed by
+; or # character.
+.npmrc files are parsed by
 npm/ini, which specifies this comment syntax.
              
 
              For example:
              
 
              # last modified: 01 Jan 2016
@@ -193,32 +191,24 @@ 
              Comments
              
 @myscope:registry=https://mycustomregistry.example.org
 
              
 
              Per-project config file
              
-
              When working locally in a project, a .npmrc file in the root of the
-project (ie, a sibling of node_modules and package.json) will set
-config values specific to this project.
              
-
              Note that this only applies to the root of the project that you're running
-npm in.  It has no effect when your module is published.  For example, you
-can't publish a module that forces itself to install globally, or in a
-different location.
              
-
              Additionally, this file is not read in global mode, such as when running
-npm install -g.
              
+
              When working locally in a project, a .npmrc file in the root of the project (ie, a sibling of node_modules and package.json) will set config values specific to this project.
              
+
              Note that this only applies to the root of the project that you're running npm in.
+It has no effect when your module is published.
+For example, you can't publish a module that forces itself to install globally, or in a different location.
              
+
              Additionally, this file is not read in global mode, such as when running npm install -g.
              
 
              Per-user config file
              
-
              $HOME/.npmrc (or the userconfig param, if set in the environment or on
-the command line)
              
+
              $HOME/.npmrc (or the userconfig param, if set in the environment or on the command line)
              
 
              Global config file
              
-
              $PREFIX/etc/npmrc (or the globalconfig param, if set above): This file
-is an ini-file formatted list of key = value parameters.  Environment
-variables can be replaced as above.
              
+
              $PREFIX/etc/npmrc (or the globalconfig param, if set above): This file is an ini-file formatted list of key = value parameters.
+Environment variables can be replaced as above.
              
 
              Built-in config file
              
 
              path/to/npm/itself/npmrc
              
-
              This is an unchangeable "builtin" configuration file that npm keeps
-consistent across updates.  Set fields in here using the ./configure
-script that comes with npm.  This is primarily for distribution maintainers
-to override default configs in a standard and consistent manner.
              
+
              This is an unchangeable "builtin" configuration file that npm keeps consistent across updates.
+Set fields in here using the ./configure script that comes with npm.
+This is primarily for distribution maintainers to override default configs in a standard and consistent manner.
              
 
-
              The settings _auth, _authToken, username, _password, certfile,
-and keyfile must all be scoped to a specific registry. This ensures that
-npm will never send credentials to the wrong host.
              
+
              The settings _auth, _authToken, username, _password, certfile, and keyfile must all be scoped to a specific registry.
+This ensures that npm will never send credentials to the wrong host.
              
 
              The full list is:
              
 
                
 
              • _auth (base64 authentication string)
                • 
@@ -231,9 +221,8 @@ 
 
              • keyfile (path to key file)
                • 
 
              
 
              In order to scope these values, they must be prefixed by a URI fragment.
-If the credential is meant for any request to a registry on a single host,
-the scope may look like //registry.npmjs.org/:. If it must be scoped to a
-specific path on the host that path may also be provided, such as
+If the credential is meant for any request to a registry on a single host, the scope may look like //registry.npmjs.org/:.
+If it must be scoped to a specific path on the host that path may also be provided, such as
 //my-custom-registry.org/unique/path:.
              
 
              ; bad config
 _authToken=MYTOKEN
diff --git a/deps/npm/docs/output/configuring-npm/package-json.html b/deps/npm/docs/output/configuring-npm/package-json.html
index 873593bdd303cf..bd50e9c1f15907 100644
--- a/deps/npm/docs/output/configuring-npm/package-json.html
+++ b/deps/npm/docs/output/configuring-npm/package-json.html
@@ -141,9 +141,9 @@
 
 
              
 
              
-
              
+
              
     package.json
-    @11.6.1
+    @11.6.2
 
              
 Specifics of npm's package.json handling
 
              
@@ -154,69 +154,60 @@ 
              Table of contents
              
 
              
 
 
              Description
              
-
              This document is all you need to know about what's required in your
-package.json file.  It must be actual JSON, not just a JavaScript object
-literal.
              
-
              A lot of the behavior described in this document is affected by the config
-settings described in config.
              
+
              This document is all you need to know about what's required in your package.json file.
+It must be actual JSON, not just a JavaScript object literal.
              
+
              A lot of the behavior described in this document is affected by the config settings described in config.
              
 
              name
              
-
              If you plan to publish your package, the most important things in your
-package.json are the name and version fields as they will be required. The
-name and version together form an identifier that is assumed to be
-completely unique.  Changes to the package should come along with changes
-to the version. If you don't plan to publish your package, the name and
-version fields are optional.
              
+
              If you plan to publish your package, the most important things in your package.json are the name and version fields as they will be required.
+The name and version together form an identifier that is assumed to be completely unique.
+Changes to the package should come along with changes to the version.
+If you don't plan to publish your package, the name and version fields are optional.
              
 
              The name is what your thing is called.
              
 
              Some rules:
              
 
                
-
              • The name must be less than or equal to 214 characters. This includes the
-scope for scoped packages.
                • 
-
              • The names of scoped packages can begin with a dot or an underscore. This
-is not permitted without a scope.
                • 
+
              • The name must be less than or equal to 214 characters.
+This includes the scope for scoped packages.
                • 
+
              • The names of scoped packages can begin with a dot or an underscore.
+This is not permitted without a scope.
                • 
 
              • New packages must not have uppercase letters in the name.
                • 
-
              • The name ends up being part of a URL, an argument on the command line,
-and a folder name. Therefore, the name can't contain any non-URL-safe
-characters.
                • 
+
              • The name ends up being part of a URL, an argument on the command line, and a folder name.
+Therefore, the name can't contain any non-URL-safe characters.
                • 
 
              
 
              Some tips:
              
 
                
 
              • Don't use the same name as a core Node module.
                • 
-
              • Don't put "js" or "node" in the name.  It's assumed that it's js, since
-you're writing a package.json file, and you can specify the engine using
-the "engines" field.  (See below.)
                • 
-
              • The name will probably be passed as an argument to require(), so it
-should be something short, but also reasonably descriptive.
                • 
-
              • You may want to check the npm registry to see if there's something by
-that name already, before you get too attached to it.
+
              • Don't put "js" or "node" in the name.
+It's assumed that it's js, since you're writing a package.json file, and you can specify the engine using the "engines" field.
+(See below.)
                • 
+
              • The name will probably be passed as an argument to require(), so it should be something short, but also reasonably descriptive.
                • 
+
              • You may want to check the npm registry to see if there's something by that name already, before you get too attached to it.
 https://www.npmjs.com/
                • 
 
              
-
              A name can be optionally prefixed by a scope, e.g. @npm/example. See
-scope for more detail.
              
+
              A name can be optionally prefixed by a scope, e.g. @npm/example.
+See scope for more detail.
              
 
              version
              
-
              If you plan to publish your package, the most important things in your
-package.json are the name and version fields as they will be required. The
-name and version together form an identifier that is assumed to be
-completely unique.  Changes to the package should come along with changes
-to the version. If you don't plan to publish your package, the name and
-version fields are optional.
              
-
              Version must be parseable by
-node-semver, which is bundled with
-npm as a dependency.  (npm install semver to use it yourself.)
              
+
              If you plan to publish your package, the most important things in your package.json are the name and version fields as they will be required.
+The name and version together form an identifier that is assumed to be completely unique.
+Changes to the package should come along with changes to the version.
+If you don't plan to publish your package, the name and version fields are optional.
              
+
              Version must be parseable by node-semver, which is bundled with npm as a dependency.
+(npm install semver to use it yourself.)
              
 
              description
              
-
              Put a description in it.  It's a string.  This helps people discover your
-package, as it's listed in npm search.
              
+
              Put a description in it.
+It's a string.
+This helps people discover your package, as it's listed in npm search.
              
 
              keywords
              
-
              Put keywords in it.  It's an array of strings.  This helps people discover
-your package as it's listed in npm search.
              
+
              Put keywords in it.
+It's an array of strings.
+This helps people discover your package as it's listed in npm search.
              
 
              homepage
              
 
              The URL to the project homepage.
              
 
              Example:
              
 
              "homepage": "https://github.com/npm/example#readme"
 
              
 
              bugs
              
-
              The URL to your project's issue tracker and / or the email address to which
-issues should be reported. These are helpful for people who encounter
-issues with your package.
              
+
              The URL to your project's issue tracker and / or the email address to which issues should be reported.
+These are helpful for people who encounter issues with your package.
              
 
              It should look like this:
              
 
              {
   "bugs": {
@@ -225,38 +216,30 @@ 
              bugs
              
   }
 }
 
              
-
              You can specify either one or both values. If you want to provide only a
-URL, you can specify the value for "bugs" as a simple string instead of an
-object.
              
+
              You can specify either one or both values.
+If you want to provide only a URL, you can specify the value for "bugs" as a simple string instead of an object.
              
 
              If a URL is provided, it will be used by the npm bugs command.
              
 
              license
              
-
              You should specify a license for your package so that people know how they
-are permitted to use it, and any restrictions you're placing on it.
              
-
              If you're using a common license such as BSD-2-Clause or MIT, add a current
-SPDX license identifier for the license you're using, like this:
              
+
              You should specify a license for your package so that people know how they are permitted to use it, and any restrictions you're placing on it.
              
+
              If you're using a common license such as BSD-2-Clause or MIT, add a current SPDX license identifier for the license you're using, like this:
              
 
              {
   "license" : "BSD-3-Clause"
 }
 
              
-
              You can check the full list of SPDX license
-IDs.  Ideally, you should pick one that is
-OSI approved.
              
-
              If your package is licensed under multiple common licenses, use an SPDX
-license expression syntax version 2.0
-string, like this:
              
+
              You can check the full list of SPDX license IDs.
+Ideally, you should pick one that is OSI approved.
              
+
              If your package is licensed under multiple common licenses, use an SPDX license expression syntax version 2.0 string, like this:
              
 
              {
   "license" : "(ISC OR GPL-3.0)"
 }
 
              
-
              If you are using a license that hasn't been assigned an SPDX identifier, or if
-you are using a custom license, use a string value like this one:
              
+
              If you are using a license that hasn't been assigned an SPDX identifier, or if you are using a custom license, use a string value like this one:
              
 
              {
   "license" : "SEE LICENSE IN <filename>"
 }
 
              
 
              Then include a file named <filename> at the top level of the package.
              
-
              Some old packages used license objects or a "licenses" property containing
-an array of license objects:
              
+
              Some old packages used license objects or a "licenses" property containing an array of license objects:
              
 
              // Not valid metadata
 {
   "license" : {
@@ -279,7 +262,8 @@ 
              license
              
   ]
 }
 
              
-
              Those styles are now deprecated. Instead, use SPDX expressions, like this:
              
+
              Those styles are now deprecated.
+Instead, use SPDX expressions, like this:
              
 
              {
   "license": "ISC"
 }
@@ -288,25 +272,23 @@ 
              license
              
   "license": "(MIT OR Apache-2.0)"
 }
 
              
-
              Finally, if you do not wish to grant others the right to use a private or
-unpublished package under any terms:
              
+
              Finally, if you do not wish to grant others the right to use a private or unpublished package under any terms:
              
 
              {
   "license": "UNLICENSED"
 }
 
              
 
              Consider also setting "private": true to prevent accidental publication.
              
 
              people fields: author, contributors
              
-
              The "author" is one person.  "contributors" is an array of people.  A
-"person" is an object with a "name" field and optionally "url" and "email",
-like this:
              
+
              The "author" is one person.
+"contributors" is an array of people.
+A "person" is an object with a "name" field and optionally "url" and "email", like this:
              
 
              {
   "name" : "Barney Rubble",
   "email" : "barney@npmjs.com",
   "url" : "http://barnyrubble.npmjs.com/"
 }
 
              
-
              Or you can shorten that all into a single string, and npm will parse it for
-you:
              
+
              Or you can shorten that all into a single string, and npm will parse it for you:
              
 
              {
   "author": "Barney Rubble <barney@npmjs.com> (http://barnyrubble.npmjs.com/)"
 }
@@ -314,9 +296,7 @@ 
              people fields: author, contributorsBoth email and url are optional either way.
              
 
              npm also sets a top-level "maintainers" field with your npm user info.
              
 
              funding
              
-
              You can specify an object containing a URL that provides up-to-date
-information about ways to help fund development of your package, a
-string URL, or an array of objects and string URLs:
              
+
              You can specify an object containing a URL that provides up-to-date information about ways to help fund development of your package, a string URL, or an array of objects and string URLs:
              
 
              {
   "funding": {
     "type" : "individual",
@@ -349,26 +329,18 @@ 
              funding
              
   ]
 }
 
              
-
              Users can use the npm fund subcommand to list the funding URLs of all
-dependencies of their project, direct and indirect. A shortcut to visit
-each funding URL is also available when providing the project name such as:
-npm fund <projectname> (when there are multiple URLs, the first one will
-be visited)
              
+
              Users can use the npm fund subcommand to list the funding URLs of all dependencies of their project, direct and indirect.
+A shortcut to visit each funding URL is also available when providing the project name such as:
+npm fund <projectname> (when there are multiple URLs, the first one will be visited)
              
 
              files
              
-
              The optional files field is an array of file patterns that describes the
-entries to be included when your package is installed as a dependency. File
-patterns follow a similar syntax to .gitignore, but reversed: including a
-file, directory, or glob pattern (*, **/*, and such) will make it so
-that file is included in the tarball when it's packed. Omitting the field
-will make it default to ["*"], which means it will include all files.
              
-
              Some special files and directories are also included or excluded regardless
-of whether they exist in the files array (see below).
              
-
              You can also provide a .npmignore file in the root of your package or in
-subdirectories, which will keep files from being included. At the root of
-your package it will not override the "files" field, but in subdirectories
-it will. The .npmignore file works just like a .gitignore. If there is
-a .gitignore file, and .npmignore is missing, .gitignore's contents
-will be used instead.
              
+
              The optional files field is an array of file patterns that describes the entries to be included when your package is installed as a dependency.
+File patterns follow a similar syntax to .gitignore, but reversed: including a file, directory, or glob pattern (*, **/*, and such) will make it so that file is included in the tarball when it's packed.
+Omitting the field will make it default to ["*"], which means it will include all files.
              
+
              Some special files and directories are also included or excluded regardless of whether they exist in the files array (see below).
              
+
              You can also provide a .npmignore file in the root of your package or in subdirectories, which will keep files from being included.
+At the root of your package it will not override the "files" field, but in subdirectories it will.
+The .npmignore file works just like a .gitignore.
+If there is a .gitignore file, and .npmignore is missing, .gitignore's contents will be used instead.
              
 
              Certain files are always included, regardless of settings:
              
 
                
 
              • package.json
                • 
@@ -394,15 +366,13 @@ 
                files
                
 
              • config.gypi
                • 
 
              • node_modules
                • 
 
              • npm-debug.log
                • 
-
              • package-lock.json (use
-npm-shrinkwrap.json
-if you wish it to be published)
                • 
+
              • package-lock.json (use npm-shrinkwrap.json if you wish it to be published)
                • 
 
              • pnpm-lock.yaml
                • 
 
              • yarn.lock
                • 
 
              • bun.lockb
                • 
 
              
-
              Most of these ignored files can be included specifically if included in
-the files globs.  Exceptions to this are:
              
+
              Most of these ignored files can be included specifically if included in the files globs.
+Exceptions to this are:
              
 
                
 
              • .git
                • 
 
              • .npmrc
                • 
@@ -412,36 +382,25 @@ 
                files
                
 
              • yarn.lock
                • 
 
              • bun.lockb
                • 
 
              
-
              These can not be included.
              
+
              These cannot be included.
              
 
              exports
              
-
              The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package. For more details see the node.js documentation on package entry points
              
+
              The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package.
+For more details see the node.js documentation on package entry points
              
 
              main
              
-
              The main field is a module ID that is the primary entry point to your
-program.  That is, if your package is named foo, and a user installs it,
-and then does require("foo"), then your main module's exports object will
-be returned.
              
+
              The main field is a module ID that is the primary entry point to your program.
+That is, if your package is named foo, and a user installs it, and then does require("foo"), then your main module's exports object will be returned.
              
 
              This should be a module relative to the root of your package folder.
              
-
              For most modules, it makes the most sense to have a main script and often
-not much else.
              
+
              For most modules, it makes the most sense to have a main script and often not much else.
              
 
              If main is not set, it defaults to index.js in the package's root folder.
              
 
              browser
              
-
              If your module is meant to be used client-side the browser field should be
-used instead of the main field. This is helpful to hint users that it might
-rely on primitives that aren't available in Node.js modules. (e.g.
-window)
              
+
              If your module is meant to be used client-side the browser field should be used instead of the main field.
+This is helpful to hint users that it might rely on primitives that aren't available in Node.js modules.
+(e.g. window)
              
 
              bin
              
-
              A lot of packages have one or more executable files that they'd like to
-install into the PATH. npm makes this pretty easy (in fact, it uses this
-feature to install the "npm" executable.)
              
-
              To use this, supply a bin field in your package.json which is a map of
-command name to local file name. When this package is installed globally,
-that file will be either linked inside the global bins directory or
-a cmd (Windows Command File) will be created which executes the specified
-file in the bin field, so it is available to run by name or name.cmd (on
-Windows PowerShell). When this package is installed as a dependency in another
-package, the file will be linked where it will be available to that package
-either directly by npm exec or by name in other scripts when invoking them
-via npm run.
              
+
              A lot of packages have one or more executable files that they'd like to install into the PATH. npm makes this pretty easy (in fact, it uses this feature to install the "npm" executable.)
              
+
              To use this, supply a bin field in your package.json which is a map of command name to local file name.
+When this package is installed globally, that file will be either linked inside the global bins directory or a cmd (Windows Command File) will be created which executes the specified file in the bin field, so it is available to run by name or name.cmd (on Windows PowerShell).
+When this package is installed as a dependency in another package, the file will be linked where it will be available to that package either directly by npm exec or by name in other scripts when invoking them via npm run.
              
 
              For example, myapp could have this:
              
 
              {
   "bin": {
@@ -449,12 +408,9 @@ 
              bin
              
   }
 }
 
              
-
              So, when you install myapp, in case of unix-like OS it'll create a symlink
-from the cli.js script to /usr/local/bin/myapp and in case of windows it
-will create a cmd file usually at C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd
-which runs the cli.js script.
              
-
              If you have a single executable, and its name should be the name of the
-package, then you can just supply it as a string.  For example:
              
+
              So, when you install myapp, in case of unix-like OS it'll create a symlink from the cli.js script to /usr/local/bin/myapp and in case of windows it will create a cmd file usually at C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd which runs the cli.js script.
              
+
              If you have a single executable, and its name should be the name of the package, then you can just supply it as a string.
+For example:
              
 
              {
   "name": "my-program",
   "version": "1.2.5",
@@ -470,18 +426,13 @@ 
              bin
              
   }
 }
 
              
-
              Please make sure that your file(s) referenced in bin starts with
-#!/usr/bin/env node, otherwise the scripts are started without the node
-executable!
              
+
              Please make sure that your file(s) referenced in bin starts with #!/usr/bin/env node; otherwise, the scripts are started without the node executable!
              
 
              Note that you can also set the executable files using directories.bin.
              
-
              See folders for more info on
-executables.
              
+
              See folders for more info on executables.
              
 
              man
              
-
              Specify either a single file or an array of filenames to put in place for
-the man program to find.
              
-
              If only a single file is provided, then it's installed such that it is the
-result from man <pkgname>, regardless of its actual filename.  For
-example:
              
+
              Specify either a single file or an array of filenames to put in place for the man program to find.
              
+
              If only a single file is provided, then it's installed such that it is the result from man <pkgname>, regardless of its actual filename.
+For example:
              
 
              {
   "name": "foo",
   "version": "1.2.3",
@@ -505,9 +456,8 @@ 
              man
              
 }
 
              
 
              will create files to do man foo and man foo-bar.
              
-
              Man files must end with a number, and optionally a .gz suffix if they are
-compressed.  The number dictates which man section the file is installed
-into.
              
+
              Man files must end with a number, and optionally a .gz suffix if they are compressed.
+The number dictates which man section the file is installed into.
              
 
              {
   "name": "foo",
   "version": "1.2.3",
@@ -521,26 +471,20 @@ 
              man
              
 
              
 
              will create entries for man foo and man 2 foo
              
 
              directories
              
-
              The CommonJS Packages spec
-details a few ways that you can indicate the structure of your package
-using a directories object. If you look at npm's
-package.json, you'll see that it
-has directories for doc, lib, and man.
              
+
              The CommonJS Packages spec details a few ways that you can indicate the structure of your package using a directories object.
+If you look at npm's package.json, you'll see that it has directories for doc, lib, and man.
              
 
              In the future, this information may be used in other creative ways.
              
 
              directories.bin
              
-
              If you specify a bin directory in directories.bin, all the files in
-that folder will be added.
              
-
              Because of the way the bin directive works, specifying both a bin path
-and setting directories.bin is an error. If you want to specify
-individual files, use bin, and for all the files in an existing bin
-directory, use directories.bin.
              
+
              If you specify a bin directory in directories.bin, all the files in that folder will be added.
              
+
              Because of the way the bin directive works, specifying both a bin path and setting directories.bin is an error.
+If you want to specify individual files, use bin, and for all the files in an existing bin directory, use directories.bin.
              
 
              directories.man
              
-
              A folder that is full of man pages.  Sugar to generate a "man" array by
-walking the folder.
              
+
              A folder that is full of man pages.
+Sugar to generate a "man" array by walking the folder.
              
 
              repository
              
-
              Specify the place where your code lives. This is helpful for people who
-want to contribute.  If the git repo is on GitHub, then the npm repo
-command will be able to find you.
              
+
              Specify the place where your code lives.
+This is helpful for people who want to contribute.
+If the git repo is on GitHub, then the npm repo command will be able to find you.
              
 
              Do it like this:
              
 
              {
   "repository": {
@@ -549,12 +493,10 @@ 
              repository
              
   }
 }
 
              
-
              The URL should be a publicly available (perhaps read-only) URL that can be
-handed directly to a VCS program without any modification.  It should not
-be a URL to an html project page that you put in your browser.  It's for
-computers.
              
-
              For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the
-same shortcut syntax you use for npm install:
              
+
              The URL should be a publicly available (perhaps read-only) URL that can be handed directly to a VCS program without any modification.
+It should not be a URL to an html project page that you put in your browser.
+It's for computers.
              
+
              For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same shortcut syntax you use for npm install:
              
 
              {
   "repository": "npm/example",
 
@@ -567,9 +509,7 @@ 
              repository
              
   "repository": "gitlab:user/repo"
 }
 
              
-
              If the package.json for your package is not in the root directory (for
-example if it is part of a monorepo), you can specify the directory in
-which it lives:
              
+
              If the package.json for your package is not in the root directory (for example if it is part of a monorepo), you can specify the directory in which it lives:
              
 
              {
   "repository": {
     "type": "git",
@@ -579,15 +519,12 @@ 
              repository
              
 }
 
              
 
              scripts
              
-
              The "scripts" property is a dictionary containing script commands that are
-run at various times in the lifecycle of your package.  The key is the
-lifecycle event, and the value is the command to run at that point.
              
-
              See scripts to find out more about writing package
-scripts.
              
+
              The "scripts" property is a dictionary containing script commands that are run at various times in the lifecycle of your package.
+The key is the lifecycle event, and the value is the command to run at that point.
              
+
              See scripts to find out more about writing package scripts.
              
 
              config
              
-
              A "config" object can be used to set configuration parameters used in
-package scripts that persist across upgrades.  For instance, if a package
-had the following:
              
+
              A "config" object can be used to set configuration parameters used in package scripts that persist across upgrades.
+For instance, if a package had the following:
              
 
              {
   "name": "foo",
   "config": {
@@ -595,15 +532,13 @@ 
              config
              
   }
 }
 
              
-
              It could also have a "start" script that referenced the
-npm_package_config_port environment variable.
              
+
              It could also have a "start" script that referenced the npm_package_config_port environment variable.
              
 
              dependencies
              
-
              Dependencies are specified in a simple object that maps a package name to a
-version range. The version range is a string which has one or more
-space-separated descriptors.  Dependencies can also be identified with a
-tarball or git URL.
              
-
              Please do not put test harnesses or transpilers or other "development"
-time tools in your dependencies object.  See devDependencies, below.
              
+
              Dependencies are specified in a simple object that maps a package name to a version range.
+The version range is a string which has one or more space-separated descriptors.
+Dependencies can also be identified with a tarball or git URL.
              
+
              Please do not put test harnesses or transpilers or other "development" time tools in your dependencies object.
+See devDependencies, below.
              
 
              See semver for more details about specifying version ranges.
              
 
                
 
              • version Must match version exactly
                • 
@@ -611,8 +546,7 @@ 
                dependencies
                
 
              • >=version etc
                • 
 
              • <version
                • 
 
              • <=version
                • 
-
              • ~version "Approximately equivalent to version"  See
-semver
                • 
+
              • ~version "Approximately equivalent to version"  See semver
                • 
 
              • ^version "Compatible with version"  See semver
                • 
 
              • 1.2.x 1.2.0, 1.2.1, etc., but not 1.3.0
                • 
 
              • http://... See 'URLs as Dependencies' below
                • 
@@ -647,33 +581,24 @@ 
                dependencies
                
 
              
 
              URLs as Dependencies
              
 
              You may specify a tarball URL in place of a version range.
              
-
              This tarball will be downloaded and installed locally to your package at
-install time.
              
+
              This tarball will be downloaded and installed locally to your package at install time.
              
 
              Git URLs as Dependencies
              
 
              Git URLs are of the form:
              
 
              <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 is used.
              
+
              <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 is used.
              
 
              Examples:
              
 
              git+ssh://git@github.com:npm/cli.git#v1.0.27
 git+ssh://git@github.com:npm/cli#semver:^5.0
 git+https://isaacs@github.com/npm/cli.git
 git://github.com/npm/cli.git#v1.0.27
 
              
-
              When installing from a git repository, the presence of certain fields in the
-package.json will cause npm to believe it needs to perform a build. To do so
-your repository will be cloned into a temporary directory, all of its deps
-installed, relevant scripts run, and the resulting directory packed and
-installed.
              
-
              This flow will occur if your git dependency uses workspaces, or if any of the
-following scripts are present:
              
+
              When installing from a git repository, the presence of certain fields in the package.json will cause npm to believe it needs to perform a build.
+To do so your repository will be cloned into a temporary directory, all of its deps installed, relevant scripts run, and the resulting directory packed and installed.
              
+
              This flow will occur if your git dependency uses workspaces, or if any of the following scripts are present:
              
 
                
 
              • build
                • 
 
              • prepare
                • 
@@ -682,13 +607,11 @@ 
                Git URLs as Dependencies
                
 
              • install
                • 
 
              • postinstall
                • 
 
              
-
              If your git repository includes pre-built artifacts, you will likely want to
-make sure that none of the above scripts are defined, or your dependency
-will be rebuilt for every installation.
              
+
              If your git repository includes pre-built artifacts, you will likely want to make sure that none of the above scripts are defined, or your dependency will be rebuilt for every installation.
              
 
              GitHub URLs
              
 
              As of version 1.1.65, you can refer to GitHub URLs as just "foo":
-"user/foo-project".  Just as with git URLs, a commit-ish suffix can be
-included.  For example:
              
+"user/foo-project".  Just as with git URLs, a commit-ish suffix can be included.
+For example:
              
 
              {
   "name": "foo",
   "version": "0.0.0",
@@ -700,15 +623,15 @@ 
              GitHub URLs
              
 }
 
              
 
              Local Paths
              
-
              As of version 2.0.0 you can provide a path to a local directory that
-contains a package. Local paths can be saved using npm install -S or npm install --save, using any of these forms:
              
+
              As of version 2.0.0 you can provide a path to a local directory that contains a package.
+Local paths can be saved using npm install -S or npm install --save, using any of these forms:
              
 
              ../foo/bar
 ~/foo/bar
 ./foo/bar
 /foo/bar
 
              
-
              in which case they will be normalized to a relative path and added to your
-package.json. For example:
              
+
              in which case they will be normalized to a relative path and added to your package.json.
+For example:
              
 
              {
   "name": "baz",
   "dependencies": {
@@ -716,24 +639,15 @@ 
              Local Paths
              
   }
 }
 
              
-
              This feature is helpful for local offline development and creating tests
-that require npm installing where you don't want to hit an external server,
-but should not be used when publishing your package to the public registry.
              
-
              note: Packages linked by local path will not have their own
-dependencies installed when npm install is run.  You must
-run npm install from inside the local path itself.
              
+
              This feature is helpful for local offline development and creating tests that require npm installing where you don't want to hit an external server, but should not be used when publishing your package to the public registry.
              
+
              note: Packages linked by local path will not have their own dependencies installed when npm install is run.
+You must run npm install from inside the local path itself.
              
 
              devDependencies
              
-
              If someone is planning on downloading and using your module in their
-program, then they probably don't want or need to download and build the
-external test or documentation framework that you use.
              
-
              In this case, it's best to map these additional items in a
-devDependencies object.
              
-
              These things will be installed when doing npm link or npm install from
-the root of a package, and can be managed like any other npm configuration
-param.  See config for more on the topic.
              
-
              For build steps that are not platform-specific, such as compiling
-CoffeeScript or other languages to JavaScript, use the prepare script to
-do this, and make the required package a devDependency.
              
+
              If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use.
              
+
              In this case, it's best to map these additional items in a devDependencies object.
              
+
              These things will be installed when doing npm link or npm install from the root of a package, and can be managed like any other npm configuration param.
+See config for more on the topic.
              
+
              For build steps that are not platform-specific, such as compiling CoffeeScript or other languages to JavaScript, use the prepare script to do this, and make the required package a devDependency.
              
 
              For example:
              
 
              {
   "name": "@npm/ethopia-waza",
@@ -748,16 +662,11 @@ 
              devDependencies
              
   "main": "lib/waza.js"
 }
 
              
-
              The prepare script will be run before publishing, so that users can
-consume the functionality without requiring them to compile it themselves.
-In dev mode (ie, locally running npm install), it'll run this script as
-well, so that you can test it easily.
              
+
              The prepare script will be run before publishing, so that users can consume the functionality without requiring them to compile it themselves.
+In dev mode (ie, locally running npm install), it'll run this script as well, so that you can test it easily.
              
 
              peerDependencies
              
-
              In some cases, you want to express the compatibility of your package with a
-host tool or library, while not necessarily doing a require of this host.
-This is usually referred to as a plugin. Notably, your module may be
-exposing a specific interface, expected and specified by the host
-documentation.
              
+
              In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a require of this host.
+This is usually referred to as a plugin. Notably, your module may be exposing a specific interface, expected and specified by the host documentation.
              
 
              For example:
              
 
              {
   "name": "@npm/tea-latte",
@@ -767,31 +676,23 @@ 
              peerDependencies
              
   }
 }
 
              
-
              This ensures your package @npm/tea-latte can be installed along with the
-second major version of the host package @npm/tea only. npm install tea-latte could possibly yield the following dependency graph:
              
+
              This ensures your package @npm/tea-latte can be installed along with the second major version of the host package @npm/tea only.
+npm install tea-latte could possibly yield the following dependency graph:
              
 
              ├── @npm/tea-latte@1.3.5
 └── @npm/tea@2.2.0
 
              
-
              In npm versions 3 through 6, peerDependencies were not automatically
-installed, and would raise a warning if an invalid version of the peer
-dependency was found in the tree.  As of npm v7, peerDependencies are
-installed by default.
              
-
              Trying to install another plugin with a conflicting requirement may cause
-an error if the tree cannot be resolved correctly. For this reason, make
-sure your plugin requirement is as broad as possible, and not to lock it
-down to specific patch versions.
              
-
              Assuming the host complies with semver, only changes
-in the host package's major version will break your plugin. Thus, if you've
-worked with every 1.x version of the host package, use "^1.0" or "1.x"
-to express this. If you depend on features introduced in 1.5.2, use
-"^1.5.2".
              
+
              In npm versions 3 through 6, peerDependencies were not automatically installed, and would raise a warning if an invalid version of the peer dependency was found in the tree.
+As of npm v7, peerDependencies are installed by default.
              
+
              Trying to install another plugin with a conflicting requirement may cause an error if the tree cannot be resolved correctly.
+For this reason, make sure your plugin requirement is as broad as possible, and not to lock it down to specific patch versions.
              
+
              Assuming the host complies with semver, only changes in the host package's major version will break your plugin.
+Thus, if you've worked with every 1.x version of the host package, use "^1.0" or "1.x" to express this.
+If you depend on features introduced in 1.5.2, use "^1.5.2".
              
 
              peerDependenciesMeta
              
-
              The peerDependenciesMeta field serves to provide npm more information on how
-your peer dependencies are to be used. Specifically, it allows peer
-dependencies to be marked as optional. Npm will not automatically install
-optional peer dependencies. This allows you to
-integrate and interact with a variety of host packages without requiring
-all of them to be installed.
              
+
              The peerDependenciesMeta field serves to provide npm more information on how your peer dependencies are to be used.
+Specifically, it allows peer dependencies to be marked as optional.
+Npm will not automatically install optional peer dependencies.
+This allows you to integrate and interact with a variety of host packages without requiring all of them to be installed.
              
 
              For example:
              
 
              {
   "name": "@npm/tea-latte",
@@ -808,12 +709,8 @@ 
              peerDependenciesMeta
              
 }
 
              
 
              bundleDependencies
              
-
              This defines an array of package names that will be bundled when publishing
-the package.
              
-
              In cases where you need to preserve npm packages locally or have them
-available through a single file download, you can bundle the packages in a
-tarball file by specifying the package names in the bundleDependencies
-array and executing npm pack.
              
+
              This defines an array of package names that will be bundled when publishing the package.
              
+
              In cases where you need to preserve npm packages locally or have them available through a single file download, you can bundle the packages in a tarball file by specifying the package names in the bundleDependencies array and executing npm pack.
              
 
              For example:
              
 
              If we define a package.json like this:
              
 
              {
@@ -826,21 +723,18 @@ 
              bundleDependencies
              
 }
 
              
 
              we can obtain @npm/awesome-web-framework-1.0.0.tgz file by running npm pack.
-This file contains the dependencies @npm/renderized and @npm/super-streams which
-can be installed in a new project by executing npm install awesome-web-framework-1.0.0.tgz.  Note that the package names do not
-include any versions, as that information is specified in dependencies.
              
+This file contains the dependencies @npm/renderized and @npm/super-streams which can be installed in a new project by executing npm install awesome-web-framework-1.0.0.tgz.
+Note that the package names do not include any versions, as that information is specified in dependencies.
              
 
              If this is spelled "bundledDependencies", then that is also honored.
              
-
              Alternatively, "bundleDependencies" can be defined as a boolean value. A
-value of true will bundle all dependencies, a value of false will bundle
-none.
              
+
              Alternatively, "bundleDependencies" can be defined as a boolean value.
+A value of true will bundle all dependencies, a value of false will bundle none.
              
 
              optionalDependencies
              
-
              If a dependency can be used, but you would like npm to proceed if it cannot
-be found or fails to install, then you may put it in the
-optionalDependencies object.  This is a map of package name to version or
-URL, just like the dependencies object.  The difference is that build
-failures do not cause installation to fail.  Running npm install --omit=optional will prevent these dependencies from being installed.
              
-
              It is still your program's responsibility to handle the lack of the
-dependency.  For example, something like this:
              
+
              If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the optionalDependencies object.
+This is a map of package name to version or URL, just like the dependencies object.
+The difference is that build failures do not cause installation to fail.
+Running npm install --omit=optional will prevent these dependencies from being installed.
              
+
              It is still your program's responsibility to handle the lack of the dependency.
+For example, something like this:
              
 
              try {
   var foo = require('@npm/foo')
   var fooVersion = require('@npm/foo/package.json').version
@@ -857,34 +751,23 @@ 
              optionalDependencies
              
   foo.doFooThings()
 }
 
              
-
              Entries in optionalDependencies will override entries of the same name in
-dependencies, so it's usually best to only put in one place.
              
+
              Entries in optionalDependencies will override entries of the same name in dependencies, so it's usually best to only put in one place.
              
 
              overrides
              
-
              If you need to make specific changes to dependencies of your dependencies, for
-example replacing the version of a dependency with a known security issue,
-replacing an existing dependency with a fork, or making sure that the same
-version of a package is used everywhere, then you may add an override.
              
-
              Overrides provide a way to replace a package in your dependency tree with
-another version, or another package entirely. These changes can be scoped as
-specific or as vague as desired.
              
+
              If you need to make specific changes to dependencies of your dependencies, for example replacing the version of a dependency with a known security issue, replacing an existing dependency with a fork, or making sure that the same version of a package is used everywhere, then you may add an override.
              
+
              Overrides provide a way to replace a package in your dependency tree with another version, or another package entirely.
+These changes can be scoped as specific or as vague as desired.
              
 
              Overrides are only considered in the root package.json file for a project.
-Overrides in installed dependencies (including
-workspaces) are not considered in dependency tree
-resolution. Published packages may dictate their resolutions by pinning
-dependencies or using an
-npm-shrinkwrap.json file.
              
-
              To make sure the package @npm/foo is always installed as version 1.0.0 no matter
-what version your dependencies rely on:
              
+Overrides in installed dependencies (including workspaces) are not considered in dependency tree resolution.
+Published packages may dictate their resolutions by pinning dependencies or using an npm-shrinkwrap.json file.
              
+
              To make sure the package @npm/foo is always installed as version 1.0.0 no matter what version your dependencies rely on:
              
 
              {
   "overrides": {
     "@npm/foo": "1.0.0"
   }
 }
 
              
-
              The above is a short hand notation, the full object form can be used to allow
-overriding a package itself as well as a child of the package. This will cause
-@npm/foo to always be 1.0.0 while also making @npm/bar at any depth beyond @npm/foo
-also 1.0.0:
              
+
              The above is a short hand notation, the full object form can be used to allow overriding a package itself as well as a child of the package.
+This will cause @npm/foo to always be 1.0.0 while also making @npm/bar at any depth beyond @npm/foo also 1.0.0:
              
 
              {
   "overrides": {
     "@npm/foo": {
@@ -894,8 +777,7 @@ 
              overrides
              
   }
 }
 
              
-
              To only override @npm/foo to be 1.0.0 when it's a child (or grandchild, or great
-grandchild, etc) of the package @npm/bar:
              
+
              To only override @npm/foo to be 1.0.0 when it's a child (or grandchild, or great grandchild, etc) of the package @npm/bar:
              
 
              {
   "overrides": {
     "@npm/bar": {
@@ -904,8 +786,8 @@ 
              overrides
              
   }
 }
 
              
-
              Keys can be nested to any arbitrary length. To override @npm/foo only when it's a
-child of @npm/bar and only when @npm/bar is a child of @npm/baz:
              
+
              Keys can be nested to any arbitrary length.
+To override @npm/foo only when it's a child of @npm/bar and only when @npm/bar is a child of @npm/baz:
              
 
              {
   "overrides": {
     "@npm/baz": {
@@ -926,11 +808,8 @@ 
              overrides
              
   }
 }
 
              
-
              You may not set an override for a package that you directly depend on unless
-both the dependency and the override itself share the exact same spec. To make
-this limitation easier to deal with, overrides may also be defined as a
-reference to a spec for a direct dependency by prefixing the name of the
-package you wish the version to match with a $.
              
+
              You may not set an override for a package that you directly depend on unless both the dependency and the override itself share the exact same spec.
+To make this limitation easier to deal with, overrides may also be defined as a reference to a spec for a direct dependency by prefixing the name of the package you wish the version to match with a $.
              
 
              {
   "dependencies": {
     "@npm/foo": "^1.0.0"
@@ -955,23 +834,18 @@ 
              engines
              
   }
 }
 
              
-
              And, like with dependencies, if you don't specify the version (or if you
-specify "*" as the version), then any version of node will do.
              
-
              You can also use the "engines" field to specify which versions of npm are
-capable of properly installing your program.  For example:
              
+
              And, like with dependencies, if you don't specify the version (or if you specify "*" as the version), then any version of node will do.
              
+
              You can also use the "engines" field to specify which versions of npm are capable of properly installing your program.
+For example:
              
 
              {
   "engines": {
     "npm": "~1.0.20"
   }
 }
 
              
-
              Unless the user has set the
-engine-strict config flag, this field is
-advisory only and will only produce warnings when your package is installed as a
-dependency.
              
+
              Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.
              
 
              os
              
-
              You can specify which operating systems your
-module will run on:
              
+
              You can specify which operating systems your module will run on:
              
 
              {
   "os": [
     "darwin",
@@ -979,8 +853,7 @@ 
              os
              
   ]
 }
 
              
-
              You can also block instead of allowing operating systems, just prepend the
-blocked os with a '!':
              
+
              You can also block instead of allowing operating systems, just prepend the blocked os with a '!':
              
 
              {
   "os": [
     "!win32"
@@ -988,11 +861,9 @@ 
              os
              
 }
 
              
 
              The host operating system is determined by process.platform
              
-
              It is allowed to both block and allow an item, although there isn't any
-good reason to do this.
              
+
              It is allowed to both block and allow an item, although there isn't any good reason to do this.
              
 
              cpu
              
-
              If your code only runs on certain cpu architectures,
-you can specify which ones.
              
+
              If your code only runs on certain cpu architectures, you can specify which ones.
              
 
              {
   "cpu": [
     "x64",
@@ -1010,8 +881,8 @@ 
              cpu
              
 
              
 
              The host architecture is determined by process.arch
              
 
              libc
              
-
              If your code only runs or builds in certain versions of libc, you can
-specify which ones.  This field only applies if os is linux.
              
+
              If your code only runs or builds in certain versions of libc, you can specify which ones.
+This field only applies if os is linux.
              
 
              {
   "os": "linux",
   "libc": "glibc"
@@ -1021,10 +892,17 @@ 
              devEngines
              
 
              The devEngines field aids engineers working on a codebase to all be using the same tooling.
              
 
              You can specify a devEngines property in your package.json which will run before install, ci, and run commands.
              
 
              
-
              Note: engines and devEngines differ in object shape. They also function very differently. engines is designed to alert the user when a dependency uses a differening npm or node version that the project it's being used in, whereas devEngines is used to alert people interacting with the source code of a project.
              
+
              Note: engines and devEngines differ in object shape.
+They also function very differently.
+engines is designed to alert the user when a dependency uses a different npm or node version than the project it's being used in, whereas devEngines is used to alert people interacting with the source code of a project.
              
 
              
-
              The supported keys under the devEngines property are cpu, os, libc, runtime, and packageManager. Each property can be an object or an array of objects. Objects must contain name, and optionally can specify version, and onFail. onFail can be warn, error, or ignore, and if left undefined is of the same value as error. npm will assume that you're running with node.
-Here's an example of a project that will fail if the environment is not node and npm. If you set runtime.name or packageManager.name to any other string, it will fail within the npm CLI.
              
+
              The supported keys under the devEngines property are cpu, os, libc, runtime, and packageManager.
+Each property can be an object or an array of objects.
+Objects must contain name, and optionally can specify version, and onFail.
+onFail can be warn, error, or ignore, and if left undefined is of the same value as error.
+npm will assume that you're running with node.
+Here's an example of a project that will fail if the environment is not node and npm.
+If you set runtime.name or packageManager.name to any other string, it will fail within the npm CLI.
              
 
              {
   "devEngines": {
     "runtime": {
@@ -1039,31 +917,17 @@ 
              devEngines
              
 }
 
              
 
              private
              
-
              If you set "private": true in your package.json, then npm will refuse to
-publish it.
              
+
              If you set "private": true in your package.json, then npm will refuse to publish it.
              
 
              This is a way to prevent accidental publication of private repositories.
-If you would like to ensure that a given package is only ever published to
-a specific registry (for example, an internal registry), then use the
-publishConfig dictionary described below to override the registry
-config param at publish-time.
              
+If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the publishConfig dictionary described below to override the registry config param at publish-time.
              
 
              publishConfig
              
-
              This is a set of config values that will be used at publish-time. It's
-especially handy if you want to set the tag, registry or access, so that
-you can ensure that a given package is not tagged with "latest", published
-to the global public registry or that a scoped module is private by
-default.
              
-
              See config to see the list of config options that
-can be overridden.
              
+
              This is a set of config values that will be used at publish-time.
+It's especially handy if you want to set the tag, registry or access, so that you can ensure that a given package is not tagged with "latest", published to the global public registry or that a scoped module is private by default.
              
+
              See config to see the list of config options that can be overridden.
              
 
              workspaces
              
-
              The optional workspaces field is an array of file patterns that describes
-locations within the local file system that the install client should look
-up to find each workspace that needs to be
-symlinked to the top level node_modules folder.
              
-
              It can describe either the direct paths of the folders to be used as
-workspaces or it can define globs that will resolve to these same folders.
              
-
              In the following example, all folders located inside the folder
-./packages will be treated as workspaces as long as they have valid
-package.json files inside them:
              
+
              The optional workspaces field is an array of file patterns that describes locations within the local file system that the install client should look up to find each workspace that needs to be symlinked to the top level node_modules folder.
              
+
              It can describe either the direct paths of the folders to be used as workspaces or it can define globs that will resolve to these same folders.
              
+
              In the following example, all folders located inside the folder ./packages will be treated as workspaces as long as they have valid package.json files inside them:
              
 
              {
   "name": "workspace-example",
   "workspaces": [
@@ -1077,20 +941,16 @@ 
              DEFAULT VALUES
              
 
                
 
              • 
 
                "scripts": {"start": "node server.js"}
                
-
                If there is a server.js file in the root of your package, then npm will
-default the start command to node server.js.
                
+
                If there is a server.js file in the root of your package, then npm will default the start command to node server.js.
                
 
                • 
 
              • 
 
                "scripts":{"install": "node-gyp rebuild"}
                
-
                If there is a binding.gyp file in the root of your package and you have
-not defined an install or preinstall script, npm will default the
-install command to compile using node-gyp.
                
+
                If there is a binding.gyp file in the root of your package and you have not defined an install or preinstall script, npm will default the install command to compile using node-gyp.
                
 
                • 
 
              • 
 
                "contributors": [...]
                
-
                If there is an AUTHORS file in the root of your package, npm will treat
-each line as a Name <email> (url) format, where email and url are
-optional.  Lines which start with a # or are blank, will be ignored.
                
+
                If there is an AUTHORS file in the root of your package, npm will treat each line as a Name <email> (url) format, where email and url are optional.
+Lines which start with a # or are blank, will be ignored.
                
 
                • 
 
              
 
              SEE ALSO
              
diff --git a/deps/npm/docs/output/configuring-npm/package-lock-json.html b/deps/npm/docs/output/configuring-npm/package-lock-json.html
index fc5856d3141861..cfb5d95a827395 100644
--- a/deps/npm/docs/output/configuring-npm/package-lock-json.html
+++ b/deps/npm/docs/output/configuring-npm/package-lock-json.html
@@ -141,9 +141,9 @@
 
 
              
 
              
-
              
+
              
     package-lock.json
-    @11.6.1
+    @11.6.2
 
              
 A manifestation of the manifest
 
              
@@ -154,226 +154,162 @@ 
              Table of contents
              
 
              
 
 
              Description
              
-
              package-lock.json is automatically generated for any operations where npm
-modifies either the node_modules tree, or package.json. It describes the
-exact tree that was generated, such that subsequent installs are able to
-generate identical trees, regardless of intermediate dependency updates.
              
-
              This file is intended to be committed into source repositories, and serves
-various purposes:
              
+
              package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json.
+It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
              
+
              This file is intended to be committed into source repositories, and serves various purposes:
              
 
                
 
              • 
-
                Describe a single representation of a dependency tree such that
-teammates, deployments, and continuous integration are guaranteed to
-install exactly the same dependencies.
                
+
                Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
                
 
                • 
 
              • 
-
                Provide a facility for users to "time-travel" to previous states of
-node_modules without having to commit the directory itself.
                
+
                Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.
                
 
                • 
 
              • 
-
                Facilitate greater visibility of tree changes through readable source
-control diffs.
                
+
                Facilitate greater visibility of tree changes through readable source control diffs.
                
 
                • 
 
              • 
-
                Optimize the installation process by allowing npm to skip repeated
-metadata resolutions for previously-installed packages.
                
+
                Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
                
 
                • 
 
              • 
-
                As of npm v7, lockfiles include enough information to gain a complete
-picture of the package tree, reducing the need to read package.json
-files, and allowing for significant performance improvements.
                
+
                As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read package.json files, and allowing for significant performance improvements.
                
 
                • 
 
              
 
              When npm creates or updates package-lock.json, it will infer line endings and indentation from package.json so that the formatting of both files matches.
              
 
              package-lock.json vs npm-shrinkwrap.json
              
-
              Both of these files have the same format, and perform similar functions in
-the root of a project.
              
-
              The difference is that package-lock.json cannot be published, and it will
-be ignored if found in any place other than the root project.
              
-
              In contrast, npm-shrinkwrap.json allows
-publication, and defines the dependency tree from the point encountered.
-This is not recommended unless deploying a CLI tool or otherwise using the
-publication process for producing production packages.
              
-
              If both package-lock.json and npm-shrinkwrap.json are present in the
-root of a project, npm-shrinkwrap.json will take precedence and
-package-lock.json will be ignored.
              
+
              Both of these files have the same format, and perform similar functions in the root of a project.
              
+
              The difference is that package-lock.json cannot be published, and it will be ignored if found in any place other than the root project.
              
+
              In contrast, npm-shrinkwrap.json allows publication, and defines the dependency tree from the point encountered.
+This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.
              
+
              If both package-lock.json and npm-shrinkwrap.json are present in the root of a project, npm-shrinkwrap.json will take precedence and package-lock.json will be ignored.
              
 
              Hidden Lockfiles
              
-
              In order to avoid processing the node_modules folder repeatedly, npm as
-of v7 uses a "hidden" lockfile present in
-node_modules/.package-lock.json.  This contains information about the
-tree, and is used in lieu of reading the entire node_modules hierarchy
-provided that the following conditions are met:
              
+
              In order to avoid processing the node_modules folder repeatedly, npm as of v7 uses a "hidden" lockfile present in node_modules/.package-lock.json.
+This contains information about the tree, and is used in lieu of reading the entire node_modules hierarchy provided that the following conditions are met:
              
 
                
 
              • All package folders it references exist in the node_modules hierarchy.
                • 
-
              • No package folders exist in the node_modules hierarchy that are not
-listed in the lockfile.
                • 
-
              • The modified time of the file is at least as recent as all of the package
-folders it references.
                • 
+
              • No package folders exist in the node_modules hierarchy that are not listed in the lockfile.
                • 
+
              • The modified time of the file is at least as recent as all of the package folders it references.
                • 
 
              
-
              That is, the hidden lockfile will only be relevant if it was created as
-part of the most recent update to the package tree.  If another CLI mutates
-the tree in any way, this will be detected, and the hidden lockfile will be
-ignored.
              
-
              Note that it is possible to manually change the contents of a package
-in such a way that the modified time of the package folder is unaffected.
-For example, if you add a file to node_modules/foo/lib/bar.js, then the
-modified time on node_modules/foo will not reflect this change.  If you
-are manually editing files in node_modules, it is generally best to
-delete the file at node_modules/.package-lock.json.
              
-
              As the hidden lockfile is ignored by older npm versions, it does not
-contain the backwards compatibility affordances present in "normal"
-lockfiles.  That is, it is lockfileVersion: 3, rather than
-lockfileVersion: 2.
              
+
              That is, the hidden lockfile will only be relevant if it was created as part of the most recent update to the package tree.
+If another CLI mutates the tree in any way, this will be detected, and the hidden lockfile will be ignored.
              
+
              Note that it is possible to manually change the contents of a package in such a way that the modified time of the package folder is unaffected.
+For example, if you add a file to node_modules/foo/lib/bar.js, then the modified time on node_modules/foo will not reflect this change.
+If you are manually editing files in node_modules, it is generally best to delete the file at node_modules/.package-lock.json.
              
+
              As the hidden lockfile is ignored by older npm versions, it does not contain the backwards compatibility affordances present in "normal" lockfiles.
+That is, it is lockfileVersion: 3, rather than lockfileVersion: 2.
              
 
              Handling Old Lockfiles
              
-
              When npm detects a lockfile from npm v6 or before during the package
-installation process, it is automatically updated to fetch missing
-information from either the node_modules tree or (in the case of empty
-node_modules trees or very old lockfile formats) the npm registry.
              
+
              When npm detects a lockfile from npm v6 or before during the package installation process, it is automatically updated to fetch missing information from either the node_modules tree or (in the case of empty node_modules trees or very old lockfile formats) the npm registry.
              
 
              File Format
              
 
              name
              
-
              The name of the package this is a package-lock for. This will match what's
-in package.json.
              
+
              The name of the package this is a package-lock for.
+This will match what's in package.json.
              
 
              version
              
-
              The version of the package this is a package-lock for. This will match
-what's in package.json.
              
+
              The version of the package this is a package-lock for.
+This will match what's in package.json.
              
 
              lockfileVersion
              
-
              An integer version, starting at 1 with the version number of this
-document whose semantics were used when generating this
-package-lock.json.
              
-
              Note that the file format changed significantly in npm v7 to track
-information that would have otherwise required looking in node_modules or
-the npm registry.  Lockfiles generated by npm v7 will contain
-lockfileVersion: 2.
              
+
              An integer version, starting at 1 with the version number of this document whose semantics were used when generating this package-lock.json.
              
+
              Note that the file format changed significantly in npm v7 to track information that would have otherwise required looking in node_modules or the npm registry.
+Lockfiles generated by npm v7 will contain lockfileVersion: 2.
              
 
                
-
              • No version provided: an "ancient" shrinkwrap file from a version of npm
-prior to npm v5.
                • 
+
              • No version provided: an "ancient" shrinkwrap file from a version of npm prior to npm v5.
                • 
 
              • 1: The lockfile version used by npm v5 and v6.
                • 
-
              • 2: The lockfile version used by npm v7 and v8. Backwards compatible to v1
-lockfiles.
                • 
-
              • 3: The lockfile version used by npm v9 and above. Backwards compatible to npm v7.
                • 
+
              • 2: The lockfile version used by npm v7 and v8. Backwards compatible to v1 lockfiles.
                • 
+
              • 3: The lockfile version used by npm v9 and above.
+Backwards compatible to npm v7.
                • 
 
              
-
              npm will always attempt to get whatever data it can out of a lockfile, even
-if it is not a version that it was designed to support.
              
+
              npm will always attempt to get whatever data it can out of a lockfile, even if it is not a version that it was designed to support.
              
 
              packages
              
-
              This is an object that maps package locations to an object containing the
-information about that package.
              
-
              The root project is typically listed with a key of "", and all other
-packages are listed with their relative paths from the root project folder.
              
+
              This is an object that maps package locations to an object containing the information about that package.
              
+
              The root project is typically listed with a key of "", and all other packages are listed with their relative paths from the root project folder.
              
 
              Package descriptors have the following fields:
              
 
                
 
              • 
 
                version: The version found in package.json
                
 
                • 
 
              • 
-
                resolved: The place where the package was actually resolved from.  In
-the case of packages fetched from the registry, this will be a url to a
-tarball.  In the case of git dependencies, this will be the full git url
-with commit sha.  In the case of link dependencies, this will be the
-location of the link target. registry.npmjs.org is a magic value meaning
-"the currently configured registry".
                
+
                resolved: The place where the package was actually resolved from.
+In the case of packages fetched from the registry, this will be a url to a tarball.
+In the case of git dependencies, this will be the full git url with commit sha.
+In the case of link dependencies, this will be the location of the link target.
+registry.npmjs.org is a magic value meaning "the currently configured registry".
                
 
                • 
 
              • 
-
                integrity: A sha512 or sha1 Standard Subresource
-Integrity
-string for the artifact that was unpacked in this location.
                
+
                integrity: A sha512 or sha1 Standard Subresource Integrity string for the artifact that was unpacked in this location.
                
 
                • 
 
              • 
-
                link: A flag to indicate that this is a symbolic link.  If this is
-present, no other fields are specified, since the link target will also
-be included in the lockfile.
                
+
                link: A flag to indicate that this is a symbolic link.
+If this is present, no other fields are specified, since the link target will also be included in the lockfile.
                
 
                • 
 
              • 
 
                dev, optional, devOptional: If the package is strictly part of the
-devDependencies tree, then dev will be true.  If it is strictly part
-of the optionalDependencies tree, then optional will be set.  If it
-is both a dev dependency and an optional dependency of a non-dev
-dependency, then devOptional will be set.  (An optional dependency of
-a dev dependency will have both dev and optional set.)
                
+devDependencies tree, then dev will be true.
+If it is strictly part of the optionalDependencies tree, then optional will be set.
+If it is both a dev dependency and an optional dependency of a non-dev dependency, then devOptional will be set.
+(An optional dependency of a dev dependency will have both dev and optional set.)
                
 
                • 
 
              • 
 
                inBundle: A flag to indicate that the package is a bundled dependency.
                
 
                • 
 
              • 
-
                hasInstallScript: A flag to indicate that the package has a preinstall,
-install, or postinstall script.
                
+
                hasInstallScript: A flag to indicate that the package has a preinstall, install, or postinstall script.
                
 
                • 
 
              • 
-
                hasShrinkwrap: A flag to indicate that the package has an
-npm-shrinkwrap.json file.
                
+
                hasShrinkwrap: A flag to indicate that the package has an npm-shrinkwrap.json file.
                
 
                • 
 
              • 
-
                bin, license, engines, dependencies, optionalDependencies: fields from
-package.json
                
+
                bin, license, engines, dependencies, optionalDependencies: fields from package.json
                
 
                • 
 
              
 
              dependencies
              
 
              Legacy data for supporting versions of npm that use lockfileVersion: 1.
-This is a mapping of package names to dependency objects.  Because the
-object structure is strictly hierarchical, symbolic link dependencies are
-somewhat challenging to represent in some cases.
              
-
              npm v7 ignores this section entirely if a packages section is present,
-but does keep it up to date in order to support switching between npm v6
-and npm v7.
              
+This is a mapping of package names to dependency objects.
+Because the object structure is strictly hierarchical, symbolic link dependencies are somewhat challenging to represent in some cases.
              
+
              npm v7 ignores this section entirely if a packages section is present, but does keep it up to date in order to support switching between npm v6 and npm v7.
              
 
              Dependency objects have the following fields:
              
 
                
 
              • 
-
                version: a specifier that varies depending on the nature of the package,
-and is usable in fetching a new copy of it.
                
+
                version: a specifier that varies depending on the nature of the package, and is usable in fetching a new copy of it.
                
 
                  
-
                • bundled dependencies: Regardless of source, this is a version number
-that is purely for informational purposes.
                  • 
-
                • registry sources: This is a version number. (eg, 1.2.3)
                  • 
-
                • git sources: This is a git specifier with resolved committish. (eg,
-git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e)
                  • 
-
                • http tarball sources: This is the URL of the tarball. (eg,
-https://example.com/example-1.3.0.tgz)
                  • 
-
                • local tarball sources: This is the file URL of the tarball. (eg
-file:///opt/storage/example-1.3.0.tgz)
                  • 
-
                • local link sources: This is the file URL of the link. (eg
-file:libs/our-module)
                  • 
+
                • bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.
                  • 
+
                • registry sources: This is a version number.
+(eg, 1.2.3)
                  • 
+
                • git sources: This is a git specifier with resolved committish.
+(eg, git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e)
                  • 
+
                • http tarball sources: This is the URL of the tarball.
+(eg, https://example.com/example-1.3.0.tgz)
                  • 
+
                • local tarball sources: This is the file URL of the tarball.
+(eg file:///opt/storage/example-1.3.0.tgz)
                  • 
+
                • local link sources: This is the file URL of the link.
+(eg file:libs/our-module)
                  • 
 
                
 
                • 
 
              • 
-
                integrity: A sha512 or sha1 Standard Subresource
-Integrity
-string for the artifact that was unpacked in this location.  For git
-dependencies, this is the commit sha.
                
+
                integrity: A sha512 or sha1 Standard Subresource Integrity string for the artifact that was unpacked in this location.
+For git dependencies, this is the commit sha.
                
 
                • 
 
              • 
-
                resolved: For registry sources this is path of the tarball relative to
-the registry URL.  If the tarball URL isn't on the same server as the
-registry URL then this is a complete URL. registry.npmjs.org is a magic
-value meaning "the currently configured registry".
                
+
                resolved: For registry sources this is path of the tarball relative to the registry URL.
+If the tarball URL isn't on the same server as the registry URL then this is a complete URL.
+registry.npmjs.org is a magic value meaning "the currently configured registry".
                
 
                • 
 
              • 
-
                bundled:  If true, this is the bundled dependency and will be installed
-by the parent module.  When installing, this module will be extracted
-from the parent module during the extract phase, not installed as a
-separate dependency.
                
+
                bundled:  If true, this is the bundled dependency and will be installed by the parent module.
+When installing, this module will be extracted from the parent module during the extract phase, not installed as a separate dependency.
                
 
                • 
 
              • 
-
                dev: If true then this dependency is either a development dependency ONLY
-of the top level module or a transitive dependency of one.  This is false
-for dependencies that are both a development dependency of the top level
-and a transitive dependency of a non-development dependency of the top
-level.
                
+
                dev: If true then this dependency is either a development dependency ONLY of the top level module or a transitive dependency of one.
+This is false for dependencies that are both a development dependency of the top level and a transitive dependency of a non-development dependency of the top level.
                
 
                • 
 
              • 
-
                optional: If true then this dependency is either an optional dependency
-ONLY of the top level module or a transitive dependency of one.  This is
-false for dependencies that are both an optional dependency of the top
-level and a transitive dependency of a non-optional dependency of the top
-level.
                
+
                optional: If true then this dependency is either an optional dependency ONLY of the top level module or a transitive dependency of one.
+This is false for dependencies that are both an optional dependency of the top level and a transitive dependency of a non-optional dependency of the top level.
                
 
                • 
 
              • 
-
                requires: This is a mapping of module name to version.  This is a list of
-everything this module requires, regardless of where it will be
-installed.  The version should match via normal matching rules a
-dependency either in our dependencies or in a level higher than us.
                
+
                requires: This is a mapping of module name to version.
+This is a list of everything this module requires, regardless of where it will be installed.
+The version should match via normal matching rules a dependency either in our dependencies or in a level higher than us.
                
 
                • 
 
              • 
-
                dependencies: The dependencies of this dependency, exactly as at the top
-level.
                
+
                dependencies: The dependencies of this dependency, exactly as at the top level.
                
 
                • 
 
              
 
              See also
              
diff --git a/deps/npm/docs/output/using-npm/config.html b/deps/npm/docs/output/using-npm/config.html
index 76fbc521bf6603..1cffacc56efad2 100644
--- a/deps/npm/docs/output/using-npm/config.html
+++ b/deps/npm/docs/output/using-npm/config.html
@@ -141,9 +141,9 @@
 
 
              
 
              
-
              
+
              
     config
-    @11.6.1
+    @11.6.2
 
              
 More than you probably want to know about npm configuration
 
              
@@ -154,46 +154,34 @@ 
              Table of contents
              
 
              
 
 
              Description
              
-
              This article details npm configuration in general. To learn about the config command,
-see npm config.
              
+
              This article details npm configuration in general.
+To learn about the config command, see npm config.
              
 
              npm gets its configuration values from the following sources, sorted by priority:
              
 
              Command Line Flags
              
-
              Putting --foo bar on the command line sets the foo configuration
-parameter to "bar".  A -- argument tells the cli parser to stop
-reading flags.  Using --flag without specifying any value will set
-the value to true.
              
-
              Example: --flag1 --flag2 will set both configuration parameters
-to true, while --flag1 --flag2 bar will set flag1 to true,
-and flag2 to bar.  Finally, --flag1 --flag2 -- bar will set
-both configuration parameters to true, and the bar is taken
-as a command argument.
              
+
              Putting --foo bar on the command line sets the foo configuration parameter to "bar".
+A -- argument tells the cli parser to stop reading flags.
+Using --flag without specifying any value will set the value to true.
              
+
              Example: --flag1 --flag2 will set both configuration parameters to true, while --flag1 --flag2 bar will set flag1 to true, and flag2 to bar.
+Finally, --flag1 --flag2 -- bar will set both configuration parameters to true, and the bar is taken as a command argument.
              
 
              Environment Variables
              
-
              Any environment variables that start with npm_config_ will be
-interpreted as a configuration parameter.  For example, putting
-npm_config_foo=bar in your environment will set the foo
-configuration parameter to bar.  Any environment configurations that
-are not given a value will be given the value of true.  Config
-values are case-insensitive, so NPM_CONFIG_FOO=bar will work the
-same. However, please note that inside scripts
-npm will set its own environment variables and Node will prefer
-those lowercase versions over any uppercase ones that you might set.
+
              Any environment variables that start with npm_config_ will be interpreted as a configuration parameter.
+For example, putting npm_config_foo=bar in your environment will set the foo configuration parameter to bar.
+Any environment configurations that are not given a value will be given the value of true.
+Config values are case-insensitive, so NPM_CONFIG_FOO=bar will work the same.
+However, please note that inside scripts npm will set its own environment variables and Node will prefer those lowercase versions over any uppercase ones that you might set.
 For details see this issue.
              
-
              Notice that you need to use underscores instead of dashes, so --allow-same-version
-would become npm_config_allow_same_version=true.
              
+
              Notice that you need to use underscores instead of dashes, so --allow-same-version would become npm_config_allow_same_version=true.
              
 
              npmrc Files
              
 
              The four relevant files are:
              
 
                
 
              • per-project configuration file (/path/to/my/project/.npmrc)
                • 
-
              • per-user configuration file (defaults to $HOME/.npmrc; configurable via CLI
-option --userconfig or environment variable $NPM_CONFIG_USERCONFIG)
                • 
-
              • global configuration file (defaults to $PREFIX/etc/npmrc; configurable via
-CLI option --globalconfig or environment variable $NPM_CONFIG_GLOBALCONFIG)
                • 
+
              • per-user configuration file (defaults to $HOME/.npmrc; configurable via CLI option --userconfig or environment variable $NPM_CONFIG_USERCONFIG)
                • 
+
              • global configuration file (defaults to $PREFIX/etc/npmrc; configurable via CLI option --globalconfig or environment variable $NPM_CONFIG_GLOBALCONFIG)
                • 
 
              • npm's built-in configuration file (/path/to/npm/npmrc)
                • 
 
              
 
              See npmrc for more details.
              
 
              Default Configs
              
-
              Run npm config ls -l to see a set of configuration parameters that are
-internal to npm, and are defaults if nothing else is specified.
              
+
              Run npm config ls -l to see a set of configuration parameters that are internal to npm, and are defaults if nothing else is specified.
              
 
              Shorthands and Other CLI Niceties
              
 
              The following shorthands are parsed on the command-line:
              
 
                
@@ -238,17 +226,14 @@ 
                Shorthands and Other CLI Niceties
                --ws: --workspaces
 
              • -y: --yes
                • 
 
              
-
              If the specified configuration param resolves unambiguously to a known
-configuration parameter, then it is expanded to that configuration
-parameter.  For example:
              
+
              If the specified configuration param resolves unambiguously to a known configuration parameter, then it is expanded to that configuration parameter.
+For example:
              
 
              npm ls --par
 # same as:
 npm ls --parseable
 
              
-
              If multiple single-character shorthands are strung together, and the
-resulting combination is unambiguously not some other configuration
-param, then it is expanded to its various component pieces.  For
-example:
              
+
              If multiple single-character shorthands are strung together, and the resulting combination is unambiguously not some other configuration param, then it is expanded to its various component pieces.
+For example:
              
 
              npm ls -gpld
 # same as:
 npm ls --global --parseable --long --loglevel info
@@ -259,75 +244,77 @@ 
              _auth
              
 
            • Default: null
              • 
 
            • Type: null or String
              • 
 
            
-
            A basic-auth string to use when authenticating against the npm registry.
-This will ONLY be used to authenticate against the npm registry. For other
-registries you will need to scope it like "//other-registry.tld/:_auth"
            
-
            Warning: This should generally not be set via a command-line option. It is
-safer to use a registry-provided authentication bearer token stored in the
-~/.npmrc file by running npm login.
            
+
            A basic-auth string to use when authenticating against the npm
+registry. This will ONLY be used to authenticate against the npm
+registry. For other registries you will need to scope it like
+"//other-registry.tld/:_auth"
            
+
            Warning: This should generally not be set via a command-line option.
+It is safer to use a registry-provided authentication bearer token
+stored in the ~/.npmrc file by running npm login.
            
 
            access
            
 
              
-
            • Default: 'public' for new packages, existing packages it will not change the
-current level
              • 
+
            • Default: 'public' for new packages, existing packages it will not
+change the current level
              • 
 
            • Type: null, "restricted", or "public"
              • 
 
            
 
            If you do not want your scoped package to be publicly viewable (and
 installable) set --access=restricted.
            
-
            Unscoped packages can not be set to restricted.
            
-
            Note: This defaults to not changing the current access level for existing
-packages. Specifying a value of restricted or public during publish will
-change the access for an existing package the same way that npm access set status would.
            
+
            Unscoped packages cannot be set to restricted.
            
+
            Note: This defaults to not changing the current access level for
+existing packages. Specifying a value of restricted or public
+during publish will change the access for an existing package the
+same way that npm access set status would.
            
 
            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.
            
+
            When running npm outdated and npm ls, setting --all will show
+all outdated or installed packages, rather than only those directly
+depended upon by the current project.
            
 
            allow-same-version
            
 
              
 
            • Default: false
              • 
 
            • Type: Boolean
              • 
 
            
-
            Prevents throwing an error when npm version is used to set the new version
-to the same value as the current version.
            
+
            Prevents throwing an error when npm version is used to set the new
+version to the same value as the current version.
            
 
            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 for details on what is
-submitted.
            
+
            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 for details
+on what is submitted.
            
 
            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.
            
+
            The minimum level of vulnerability for npm audit to exit with a
+non-zero exit code.
            
 
            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.
            
+
            What authentication strategy to use with login. Note that if an
+otp config is given, this value will always be set to legacy.
            
 
            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.
            
+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.
            
 
 
              
 
            • Default: true
              • 
@@ -335,9 +322,9 @@ 
 
            
 
            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.
            
+
            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.
            
 
            browser
            
 
              
 
            • Default: macOS: "open", Windows: "start", Others: "xdg-open"
              • 
@@ -353,13 +340,13 @@ 
              ca
              
 
            • Type: null or String (can be set multiple times)
              • 
 
            
 
            The Certificate Authority signing certificate that is trusted for SSL
-connections to the registry. Values should be in PEM format (Windows calls
-it "Base-64 encoded X.509 (.CER)") with newlines replaced by the string
-"\n". For example:
            
+connections to the registry. Values should be in PEM format (Windows
+calls it "Base-64 encoded X.509 (.CER)") with newlines replaced by
+the string "\n". For example:
            
 
            ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
 
            
-
            Set to null to only allow "known" registrars, or to a specific CA cert to
-trust only that specific signing authority.
            
+
            Set to null to only allow "known" registrars, or to a specific CA
+cert to trust only that specific signing authority.
            
 
            Multiple CAs can be trusted by specifying an array of certificates:
            
 
            ca[]="..."
 ca[]="..."
@@ -376,16 +363,18 @@ 
            cafile
            
 
          • Default: null
            • 
 
          • Type: Path
            •
          -

          A path to a file containing one or multiple Certificate Authority signing -certificates. Similar to the ca setting, but allows for multiple CA's, as -well as for the CA information to be stored in a file on disk.

          +

          A path to a file containing one or multiple Certificate Authority +signing certificates. Similar to the ca setting, but allows for +multiple CA's, as well as for the CA information to be stored in a +file on disk.

          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.

          +

          Optional companion option for npm exec, npx that allows for +specifying a custom command to be run along with the installed +packages.

          npm exec --package yo --package generator-node --call "yo node"

          cidr

          @@ -393,15 +382,16 @@

          cidr

        • Default: null
        • Type: null or String (can be set multiple times)
        -

        This is a list of CIDR address to be used when configuring limited access -tokens with the npm token create command.

        +

        This is a list of CIDR address to be used when configuring limited +access tokens with the npm token create command.

        color

          -
        • Default: true unless the NO_COLOR environ is set to something other than '0'
          • +
        • Default: true unless the NO_COLOR environ is set to something other +than '0'
        • Type: "always" or Boolean
        -

        If false, never shows colors. If "always" then always shows colors. If -true, then only prints color codes for tty file descriptors.

        +

        If false, never shows colors. If "always" then always shows colors. +If true, then only prints color codes for tty file descriptors.

        commit-hooks

        • Default: true
          • @@ -413,16 +403,18 @@

          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.

        +

        Override CPU architecture of native modules to install. Acceptable +values are same as cpu field of package.json, which comes from +process.arch.

        depth

          -
        • Default: Infinity if --all is set, otherwise 0
          • +
        • 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.

        +

        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.

        description

        • Default: true
          • @@ -484,12 +476,13 @@

          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.

        +

        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.

        editor

        • Default: The EDITOR or VISUAL environment variables, or @@ -502,9 +495,9 @@

          engine-strict

        • Default: false
        • Type: Boolean
        -

        If set to true, then npm will stubbornly refuse to install (or even consider -installing) any package that claims to not be compatible with the current -Node.js version.

        +

        If set to true, then npm will stubbornly refuse to install (or even +consider installing) any package that claims to not be compatible +with the current Node.js version.

        This can be overridden by setting the --force flag.

        expect-result-count

          @@ -512,30 +505,31 @@

          expect-result-count

        • Type: null or Number

        Tells to expect a specific number of results from the command.

        -

        This config can not be used with: expect-results

        +

        This config cannot be used with: expect-results

        expect-results

        • Default: null
        • Type: null or Boolean
        -

        Tells npm whether or not to expect results from the command. Can be either -true (expect some results) or false (expect no results).

        -

        This config can not be used with: expect-result-count

        +

        Tells npm whether or not to expect results from the command. Can be +either true (expect some results) or false (expect no results).

        +

        This config cannot be used with: expect-result-count

        fetch-retries

        • Default: 2
        • Type: Number
        -

        The "retries" config for the retry module to use when fetching packages -from the registry.

        -

        npm will retry idempotent read requests to the registry in the case of -network failures or 5xx HTTP errors.

        +

        The "retries" config for the retry module to use when fetching +packages from the registry.

        +

        npm will retry idempotent read requests to the registry in the case +of network failures or 5xx HTTP errors.

        fetch-retry-factor

        • Default: 10
        • Type: Number
        -

        The "factor" config for the retry module to use when fetching packages.

        +

        The "factor" config for the retry module to use when fetching +packages.

        fetch-retry-maxtimeout

        • Default: 60000 (1 minute)
          • @@ -567,14 +561,16 @@

          force

        • 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 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.
          • +
        • 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).
          • @@ -583,54 +579,58 @@

          force

          recommended that you do not use this option!

          foreground-scripts

            -
          • Default: false unless when using npm pack or npm publish where it -defaults to true
            • +
          • 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.

          +

          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.

          format-package-lock

          • Default: true
          • Type: Boolean
          -

          Format package-lock.json or npm-shrinkwrap.json as a human readable -file.

          +

          Format package-lock.json or npm-shrinkwrap.json as a human +readable file.

          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 for details.

          +acknowledging the number of dependencies looking for funding. See +npm fund for details.

          git

          • Default: "git"
          • Type: String
          -

          The command to use for git commands. If git is installed on the computer, -but is not in the PATH, then set this to the full path to the git binary.

          +

          The command to use for git commands. If git is installed on the +computer, but is not in the PATH, then set this to the full path to +the git binary.

          git-tag-version

          • Default: true
          • Type: Boolean
          -

          Tag the commit when using the npm version command. Setting this to false -results in no commit being made at all.

          +

          Tag the commit when using the npm version command. Setting this to +false results in no commit being made at all.

          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 for more on the differences in behavior.

          +

          Operates in "global" mode, so that packages are installed into the +prefix folder instead of the current working directory. See +folders for more on the differences in +behavior.

            -
          • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
            • +
          • 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
          @@ -653,20 +653,20 @@

          https-proxy

        • Type: null or URL

        A proxy to use for outgoing https requests. If the HTTPS_PROXY or -https_proxy or HTTP_PROXY or http_proxy environment variables are set, -proxy settings will be honored by the underlying make-fetch-happen -library.

        +https_proxy or HTTP_PROXY or http_proxy environment variables +are set, proxy settings will be honored by the underlying +make-fetch-happen library.

        if-present

        • Default: false
        • Type: Boolean
        -

        If true, npm will not exit with an error code when run is invoked for a -script that isn't defined in the scripts section of package.json. This -option can be used when it's desirable to optionally run a script when it's -present and fail if the script fails. This is useful, for example, when -running scripts that may only apply for some builds in an otherwise generic -CI setup.

        +

        If true, npm will not exit with an error code when run is invoked +for a script that isn't defined in the scripts section of +package.json. This option can be used when it's desirable to +optionally run a script when it's present and fail if the script +fails. This is useful, for example, when running scripts that may +only apply for some builds in an otherwise generic CI setup.

        This value is not exported to the environment for child processes.

        ignore-scripts

          @@ -674,26 +674,28 @@

          ignore-scripts

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

        +

        Note that commands explicitly intended to run a particular script, +such as npm start, npm stop, npm restart, npm test, and npm run will still run their intended script if ignore-scripts is set, +but they will not run any pre- or post-scripts.

        include

        • Default:
          • -
        • Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
          • +
        • Type: "prod", "dev", "optional", or "peer" (can be set multiple +times)
        -

        Option that allows for defining which types of dependencies to install.

        +

        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.

        +

        Dependency types specified in --include will not be omitted, +regardless of the order in which omit/include are specified on the +command-line.

        include-staged

        • Default: false
        • Type: Boolean
        -

        Allow installing "staged" published packages, as defined by npm RFC PR -#92.

        +

        Allow installing "staged" published packages, as defined by npm RFC +PR #92.

        This is experimental, and not implemented by the npm public registry.

        include-workspace-root

          @@ -701,22 +703,25 @@

          include-workspace-root

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

        +

        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.

        init-author-email

        • Default: ""
        • Type: String
        -

        The value npm init should use by default for the package author's email.

        +

        The value npm init should use by default for the package author's +email.

        init-author-name

        • Default: ""
        • Type: String
        -

        The value npm init should use by default for the package author's name.

        +

        The value npm init should use by default for the package author's +name.

        init-author-url

        • Default: ""
          • @@ -737,47 +742,49 @@

          init-module

        A module that will be loaded by the npm init command. See the documentation for the -init-package-json module for -more information, or npm init.

        +init-package-json module +for more information, or npm init.

        init-private

        • Default: false
        • Type: Boolean
        -

        The value npm init should use by default for the package's private flag.

        +

        The value npm init should use by default for the package's private +flag.

        init-type

        • Default: "commonjs"
        • Type: String
        -

        The value that npm init should use by default for the package.json type -field.

        +

        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.

        +

        The value that npm init should use by default for the package +version number, if not already set in package.json.

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

        +

        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.

        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.

        +(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.

        json

        • Default: false
          • @@ -785,8 +792,8 @@

          json

        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.
          • +
        • 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.

        legacy-peer-deps

        @@ -794,77 +801,83 @@

        legacy-peer-deps

      • Default: false
      • Type: Boolean
      -

      Causes npm to completely ignore peerDependencies when building a package -tree, as in npm versions 3 through 6.

      -

      If a package cannot be installed because of overly strict peerDependencies -that collide, it provides a way to move forward resolving the situation.

      -

      This differs from --omit=peer, in that --omit=peer will avoid unpacking -peerDependencies on disk, but will still design a tree such that -peerDependencies could be unpacked in a correct place.

      -

      Use of legacy-peer-deps is not recommended, as it will not enforce the -peerDependencies contract that meta-dependencies may rely on.

      +

      Causes npm to completely ignore peerDependencies when building a +package tree, as in npm versions 3 through 6.

      +

      If a package cannot be installed because of overly strict +peerDependencies that collide, it provides a way to move forward +resolving the situation.

      +

      This differs from --omit=peer, in that --omit=peer will avoid +unpacking peerDependencies on disk, but will still design a tree +such that peerDependencies could be unpacked in a correct place.

      +

      Use of legacy-peer-deps is not recommended, as it will not enforce +the peerDependencies contract that meta-dependencies may rely on.

      libc

      • Default: null
      • Type: null or String
      -

      Override libc of native modules to install. Acceptable values are same as -libc field of package.json

      +

      Override libc of native modules to install. Acceptable values are +same as libc field of package.json

      • Default: false
      • Type: Boolean
      -

      Used with npm ls, limiting output to only those packages that are linked.

      +

      Used with npm ls, limiting output to only those packages that are +linked.

      local-address

      • Default: null
      • Type: IP Address
      -

      The IP address of the local interface to use when making connections to the -npm registry. Must be IPv4 in versions of Node prior to 0.12.

      +

      The IP address of the local interface to use when making connections +to the npm registry. Must be IPv4 in versions of Node prior to 0.12.

      location

        -
      • Default: "user" unless --global is passed, which will also set this value -to "global"
        • +
      • 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 for more on the differences in behavior.

      +

      When set to "global" mode, packages are installed into the prefix +folder instead of the current working directory. See +folders for more on the differences in +behavior.

        -
      • packages are installed into the {prefix}/lib/node_modules folder, instead -of the current working directory.
        • +
      • 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

      lockfile-version

        -
      • Default: Version 3 if no lockfile, auto-converting v1 lockfiles to v3, -otherwise maintain current lockfile version.
        • +
      • Default: Version 3 if no lockfile, auto-converting v1 lockfiles to +v3; otherwise, maintain current lockfile version.
      • Type: null, 1, 2, 3, "1", "2", or "3"

      Set the lockfile format version to be used in package-lock.json and npm-shrinkwrap-json files. Possible options are:

      -

      1: The lockfile version used by npm versions 5 and 6. Lacks some data that -is used during the install, resulting in slower and possibly less -deterministic installs. Prevents lockfile churn when interoperating with -older npm versions.

      -

      2: The default lockfile version used by npm version 7 and 8. Includes both -the version 1 lockfile data and version 3 lockfile data, for maximum -determinism and interoperability, at the expense of more bytes on disk.

      -

      3: Only the new lockfile information introduced in npm version 7. Smaller on -disk than lockfile version 2, but not interoperable with older npm versions. -Ideal if all users are on npm version 7 and higher.

      +

      1: The lockfile version used by npm versions 5 and 6. Lacks some data +that is used during the install, resulting in slower and possibly +less deterministic installs. Prevents lockfile churn when +interoperating with older npm versions.

      +

      2: The default lockfile version used by npm version 7 and 8. Includes +both the version 1 lockfile data and version 3 lockfile data, for +maximum determinism and interoperability, at the expense of more +bytes on disk.

      +

      3: Only the new lockfile information introduced in npm version 7. +Smaller on disk than lockfile version 2, but not interoperable with +older npm versions. Ideal if all users are on npm version 7 and +higher.

      loglevel

      • Default: "notice"
        • -
      • Type: "silent", "error", "warn", "notice", "http", "info", "verbose", or -"silly"
        • +
      • Type: "silent", "error", "warn", "notice", "http", "info", "verbose", +or "silly"
      -

      What level of logs to report. All logs are written to a debug log, with the -path to that file printed if the execution of a command fails.

      +

      What level of logs to report. All logs are written to a debug log, +with the path to that file printed if the execution of a command +fails.

      Any logs of a higher level than the setting are shown. The default is "notice".

      See also the foreground-scripts config.

      @@ -873,8 +886,7 @@

      logs-dir

    • Default: A directory named _logs inside the cache
    • Type: null or Path
    -

    The location of npm's log directory. See npm logging -for more information.

    +

    The location of npm's log directory. See npm logging for more information.

    logs-max

    • Default: 10
      • @@ -893,32 +905,33 @@

      maxsockets

    • Default: 15
    • Type: Number
    -

    The maximum number of connections to use per origin (protocol/host/port -combination).

    +

    The maximum number of connections to use per origin +(protocol/host/port combination).

    message

    • Default: "%s"
    • Type: String
    -

    Commit message which is used by npm version when creating version commit.

    +

    Commit message which is used by npm version when creating version +commit.

    Any "%s" in the message will be replaced with the version number.

    node-gyp

    • Default: The path to the node-gyp bin that ships with npm
    • Type: Path
    -

    This is the location of the "node-gyp" bin. By default it uses one that -ships with npm itself.

    -

    You can use this config to specify your own "node-gyp" to run when it is -required to build a package.

    +

    This is the location of the "node-gyp" bin. By default it uses one +that ships with npm itself.

    +

    You can use this config to specify your own "node-gyp" to run when it +is required to build a package.

    node-options

    • Default: null
    • Type: null or String

    Options to pass through to Node.js via the NODE_OPTIONS environment -variable. This does not impact how npm itself is executed but it does impact -how lifecycle scripts are called.

    +variable. This does not impact how npm itself is executed but it does +impact how lifecycle scripts are called.

    noproxy

    • Default: The value of the NO_PROXY environment variable
      • @@ -931,47 +944,49 @@

      offline

    • Default: false
    • Type: Boolean
    -

    Force offline mode: no network requests will be done during install. To -allow the CLI to fill in missing cache data, see --prefer-offline.

    +

    Force offline mode: no network requests will be done during install. +To allow the CLI to fill in missing cache data, see +--prefer-offline.

    omit

    • Default: 'dev' if the NODE_ENV environment variable is set to -'production', otherwise empty.
      • +'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.

    +

    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.

    omit-lockfile-registry-resolved

    • Default: false
    • Type: Boolean
    -

    This option causes npm to create lock files without a resolved key for -registry dependencies. Subsequent installs will need to resolve tarball -endpoints with the configured registry, likely resulting in a longer install -time.

    +

    This option causes npm to create lock files without a resolved key +for registry dependencies. Subsequent installs will need to resolve +tarball endpoints with the configured registry, likely resulting in a +longer install time.

    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.

    +

    Override OS of native modules to install. Acceptable values are same +as os field of package.json, which comes from process.platform.

    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.

    +

    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.

    pack-destination

    • Default: "."
      • @@ -989,103 +1004,107 @@

      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.

    +

    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.

    +

    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.

    +

    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.

    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.

    +

    Output parseable results from commands that write to standard output. +For npm search, this will be tab-separated table format.

    prefer-dedupe

    • Default: false
    • Type: Boolean
    -

    Prefer to deduplicate packages if possible, rather than choosing a newer -version of a dependency.

    +

    Prefer to deduplicate packages if possible, rather than choosing a +newer version of a dependency.

    prefer-offline

    • Default: false
    • Type: Boolean
    -

    If true, staleness checks for cached data will be bypassed, but missing data -will be requested from the server. To force full offline mode, use ---offline.

    +

    If true, staleness checks for cached data will be bypassed, but +missing data will be requested from the server. To force full offline +mode, use --offline.

    prefer-online

    • Default: false
    • Type: Boolean
    -

    If true, staleness checks for cached data will be forced, making the CLI -look for updates immediately even for fresh package data.

    +

    If true, staleness checks for cached data will be forced, making the +CLI look for updates immediately even for fresh package data.

    prefix

      -
    • Default: In global mode, the folder where the node executable is installed. -Otherwise, the nearest parent folder containing either a package.json file -or a node_modules folder.
      • +
    • Default: In global mode, the folder where the node executable is +installed. Otherwise, the nearest parent folder containing either a +package.json file or a node_modules folder.
    • Type: Path
    -

    The location to install global items. If set on the command line, then it -forces non-global commands to run in the specified folder.

    +

    The location to install global items. If set on the command line, +then it forces non-global commands to run in the specified folder.

    preid

    • Default: ""
    • Type: String
    -

    The "prerelease identifier" to use as a prefix for the "prerelease" part of -a semver. Like the rc in 1.2.0-rc.8.

    +

    The "prerelease identifier" to use as a prefix for the "prerelease" +part of a semver. Like the rc in 1.2.0-rc.8.

    progress

      -
    • Default: true when not in CI and both stderr and stdout are TTYs and not -in a dumb terminal
      • +
    • Default: true when not in CI and both stderr and stdout are TTYs +and not in a dumb terminal
    • Type: Boolean
    -

    When set to true, npm will display a progress bar during time intensive -operations, if process.stderr and process.stdout are a TTY.

    +

    When set to true, npm will display a progress bar during time +intensive operations, if process.stderr and process.stdout are a +TTY.

    Set to false to suppress the progress bar.

    provenance

    • Default: false
    • Type: Boolean
    -

    When publishing from a supported cloud CI/CD system, the package will be -publicly linked to where it was built and published from.

    -

    This config can not be used with: provenance-file

    +

    When publishing from a supported cloud CI/CD system, the package will +be publicly linked to where it was built and published from.

    +

    This config cannot be used with: provenance-file

    provenance-file

    • Default: null
    • Type: Path
    -

    When publishing, the provenance bundle at the given path will be used.

    -

    This config can not be used with: provenance

    +

    When publishing, the provenance bundle at the given path will be +used.

    +

    This config cannot be used with: provenance

    proxy

    • Default: null
    • Type: null, false, or URL

    A proxy to use for outgoing http requests. If the HTTP_PROXY or -http_proxy environment variables are set, proxy settings will be honored -by the underlying request library.

    +http_proxy environment variables are set, proxy settings will be +honored by the underlying request library.

    read-only

    • Default: false
    • Type: Boolean
    -

    This is used to mark a token as unable to publish when configuring limited -access tokens with the npm token create command.

    +

    This is used to mark a token as unable to publish when configuring +limited access tokens with the npm token create command.

    rebuild-bundle

    • Default: true
      • @@ -1103,16 +1122,17 @@

      replace-registry-host

    • Default: "npmjs"
    • Type: "npmjs", "never", "always", or String
    -

    Defines behavior for replacing the registry host in a lockfile with the -configured registry.

    +

    Defines behavior for replacing the registry host in a lockfile with +the configured registry.

    The default behavior is to replace package dist URLs from the default -registry (https://registry.npmjs.org) to the configured registry. If set to -"never", then use the registry value. If set to "always", then replace the -registry host with the configured host every time.

    +registry (https://registry.npmjs.org) to the configured registry. If +set to "never", then use the registry value. If set to "always", then +replace the registry host with the configured host every time.

    You may also specify a bare hostname (e.g., "registry.npmjs.org").

    save

      -
    • Default: true unless when using npm update where it defaults to false
      • +
    • Default: true unless when using npm update where it defaults to +false
    • Type: Boolean

    Save installed packages to a package.json file as dependencies.

    @@ -1127,56 +1147,63 @@

    save-bundle

    If a package would be saved at install time by the use of --save, --save-dev, or --save-optional, then also put it in the bundleDependencies list.

    -

    Ignored if --save-peer is set, since peerDependencies cannot be bundled.

    +

    Ignored if --save-peer is set, since peerDependencies cannot be +bundled.

    save-dev

    • Default: false
    • Type: Boolean

    Save installed packages to a package.json file as devDependencies.

    -

    This config can not be used with: save-optional, save-peer, save-prod

    +

    This config cannot be used with: save-optional, save-peer, +save-prod

    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.

    +

    Dependencies saved to package.json will be configured with an exact +version rather than using npm's default semver range operator.

    save-optional

    • Default: false
    • Type: Boolean
    -

    Save installed packages to a package.json file as optionalDependencies.

    -

    This config can not be used with: save-dev, save-peer, save-prod

    +

    Save installed packages to a package.json file as +optionalDependencies.

    +

    This config cannot be used with: save-dev, save-peer, save-prod

    save-peer

    • Default: false
    • Type: Boolean

    Save installed packages to a package.json file as peerDependencies

    -

    This config can not be used with: save-dev, save-optional, save-prod

    +

    This config cannot be used with: save-dev, save-optional, +save-prod

    save-prefix

    • Default: "^"
    • Type: String
    -

    Configure how versions of packages installed to a package.json file via ---save or --save-dev get prefixed.

    -

    For example if a package has version 1.2.3, by default its version is set -to ^1.2.3 which allows minor upgrades for that package, but after npm config set save-prefix='~' it would be set to ~1.2.3 which only allows -patch upgrades.

    +

    Configure how versions of packages installed to a package.json file +via --save or --save-dev get prefixed.

    +

    For example if a package has version 1.2.3, by default its version +is set to ^1.2.3 which allows minor upgrades for that package, but +after npm config set save-prefix='~' it would be set to ~1.2.3 +which only allows patch upgrades.

    save-prod

    • Default: false
    • Type: Boolean
    -

    Save installed packages into dependencies specifically. This is useful if -a package already exists in devDependencies or optionalDependencies, but -you want to move it to be a non-optional production dependency.

    -

    This is the default behavior if --save is true, and neither --save-dev -or --save-optional are true.

    -

    This config can not be used with: save-dev, save-optional, save-peer

    +

    Save installed packages into dependencies specifically. This is +useful if a package already exists in devDependencies or +optionalDependencies, but you want to move it to be a non-optional +production dependency.

    +

    This is the default behavior if --save is true, and neither +--save-dev or --save-optional are true.

    +

    This config cannot be used with: save-dev, save-optional, +save-peer

    sbom-format

    • Default: null
      • @@ -1188,9 +1215,9 @@

      sbom-type

    • Default: "library"
    • Type: "library", "application", or "framework"
    -

    The type of package described by the generated SBOM. For SPDX, this is the -value for the primaryPackagePurpose field. For CycloneDX, this is the -value for the type field.

    +

    The type of package described by the generated SBOM. For SPDX, this +is the value for the primaryPackagePurpose field. For CycloneDX, +this is the value for the type field.

    scope

    • Default: the scope of the current project, if any, or ""
      • @@ -1217,7 +1244,8 @@

      script-shell

    • Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
    • Type: null or String
    -

    The shell to use for scripts run with the npm exec, npm run and npm init <package-spec> commands.

    +

    The shell to use for scripts run with the npm exec, npm run and +npm init <package-spec> commands.

    searchexclude

    • Default: ""
      • @@ -1229,8 +1257,8 @@

      searchlimit

    • Default: 20
    • Type: Number
    -

    Number of items to limit search results to. Will not apply at all to legacy -searches.

    +

    Number of items to limit search results to. Will not apply at all to +legacy searches.

    searchopts

    • Default: ""
      • @@ -1242,12 +1270,12 @@

      searchstaleness

    • Default: 900
    • Type: Number
    -

    The age of the cache, in seconds, before another registry request is made if -using legacy search endpoint.

    +

    The age of the cache, in seconds, before another registry request is +made if using legacy search endpoint.

    shell

      -
    • Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" on -Windows
      • +
    • Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" +on Windows
    • Type: String

    The shell to run for the npm explore command.

    @@ -1256,108 +1284,111 @@

    sign-git-commit

  • Default: false
  • Type: Boolean
    • -

    If set to true, then the npm version command will commit the new package -version using -S to add a signature.

    -

    Note that git requires you to have set up GPG keys in your git configs for -this to work properly.

    +

    If set to true, then the npm version command will commit the new +package version using -S to add a signature.

    +

    Note that git requires you to have set up GPG keys in your git +configs for this to work properly.

    sign-git-tag

    • Default: false
    • Type: Boolean
    -

    If set to true, then the npm version command will tag the version using --s to add a signature.

    -

    Note that git requires you to have set up GPG keys in your git configs for -this to work properly.

    +

    If set to true, then the npm version command will tag the version +using -s to add a signature.

    +

    Note that git requires you to have set up GPG keys in your git +configs for this to work properly.

    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.

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

    strict-ssl

    • Default: true
    • Type: Boolean
    -

    Whether or not to do SSL key validation when making requests to the registry -via https.

    +

    Whether or not to do SSL key validation when making requests to the +registry via https.

    See also the ca config.

    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.

    +

    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.

    +

    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.

    tag-version-prefix

    • Default: "v"
    • Type: String
    -

    If set, alters the prefix used when tagging a new version when performing a -version increment using npm version. To remove the prefix altogether, set -it to the empty string: "".

    -

    Because other tools may rely on the convention that npm version tags look -like v1.0.0, only use this property if it is absolutely necessary. In -particular, use care when overriding this setting for public packages.

    +

    If set, alters the prefix used when tagging a new version when +performing a version increment using npm version. To remove the +prefix altogether, set it to the empty string: "".

    +

    Because other tools may rely on the convention that npm version tags +look like v1.0.0, only use this property if it is absolutely +necessary. In particular, use care when overriding this setting for +public packages.

    timing

    • Default: false
    • Type: Boolean
    -

    If true, writes timing information to a process specific json file in the -cache or logs-dir. The file name ends with -timing.json.

    -

    You can quickly view it with this json command line: -cat ~/.npm/_logs/*-timing.json | npm exec -- json -g.

    -

    Timing information will also be reported in the terminal. To suppress this -while still writing the timing file, use --silent.

    +

    If true, writes timing information to a process specific json file in +the cache or logs-dir. The file name ends with -timing.json.

    +

    You can quickly view it with this json command +line: cat ~/.npm/_logs/*-timing.json | npm exec -- json -g.

    +

    Timing information will also be reported in the terminal. To suppress +this while still writing the timing file, use --silent.

    umask

    • Default: 0
    • Type: Octal numeric string in range 0000..0777 (0..511)
    -

    The "umask" value to use when setting the file creation mode on files and -folders.

    -

    Folders and executables are given a mode which is 0o777 masked against -this value. Other files are given a mode which is 0o666 masked against -this value.

    -

    Note that the underlying system will also apply its own umask value to -files and folders that are created, and npm does not circumvent this, but -rather adds the --umask config to it.

    -

    Thus, the effective default umask value on most POSIX systems is 0o22, -meaning that folders and executables are created with a mode of 0o755 and -other files are created with a mode of 0o644.

    +

    The "umask" value to use when setting the file creation mode on files +and folders.

    +

    Folders and executables are given a mode which is 0o777 masked +against this value. Other files are given a mode which is 0o666 +masked against this value.

    +

    Note that the underlying system will also apply its own umask value +to files and folders that are created, and npm does not circumvent +this, but rather adds the --umask config to it.

    +

    Thus, the effective default umask value on most POSIX systems is +0o22, meaning that folders and executables are created with a mode of +0o755 and other files are created with a mode of 0o644.

    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.
      • +
    • 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.

    +

    When set to true, npm uses unicode characters in the tree output. +When false, it uses ascii characters instead of unicode glyphs.

    update-notifier

    • Default: true
    • Type: Boolean
    -

    Set to false to suppress the update notification when using an older version -of npm than the latest.

    +

    Set to false to suppress the update notification when using an older +version of npm than the latest.

    usage

    • Default: false
      • @@ -1370,17 +1401,17 @@

      user-agent

      workspaces/{workspaces} {ci}"
    • Type: String
    -

    Sets the User-Agent request header. The following fields are replaced with -their actual counterparts:

    +

    Sets the User-Agent request header. The following fields are replaced +with their actual counterparts:

    • {npm-version} - The npm version in use
    • {node-version} - The Node.js version in use
    • {platform} - The value of process.platform
    • {arch} - The value of process.arch
      • -
    • {workspaces} - Set to true if the workspaces or workspace options -are set.
      • -
    • {ci} - The value of the ci-name config, if set, prefixed with ci/, or -an empty string if ci-name is empty.
      • +
    • {workspaces} - Set to true if the workspaces or workspace +options are set.
      • +
    • {ci} - The value of the ci-name config, if set, prefixed with +ci/, or an empty string if ci-name is empty.

    userconfig

      @@ -1388,9 +1419,9 @@

      userconfig

    • Type: Path

    The location of user-level configuration settings.

    -

    This may be overridden by the npm_config_userconfig environment variable -or the --userconfig command line option, but may not be overridden by -settings in the globalconfig file.

    +

    This may be overridden by the npm_config_userconfig environment +variable or the --userconfig command line option, but may not be +overridden by settings in the globalconfig file.

    version

    • Default: false
      • @@ -1403,9 +1434,9 @@

      versions

    • Default: false
    • Type: Boolean
    -

    If true, output the npm version as well as node's process.versions map and -the version in the current working directory's package.json file if one -exists, and exit successfully.

    +

    If true, output the npm version as well as node's process.versions +map and the version in the current working directory's package.json +file if one exists, and exit successfully.

    Only relevant when specified explicitly on the command line.

    viewer

      @@ -1413,21 +1444,23 @@

      viewer

    • Type: String

    The program to use to view help content.

    -

    Set to "browser" to view html help content in the default web browser.

    +

    Set to "browser" to view html help content in the default web +browser.

    which

    • Default: null
    • Type: null or Number
    -

    If there are multiple funding sources, which 1-indexed source URL to open.

    +

    If there are multiple funding sources, which 1-indexed source URL to +open.

    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.

    +

    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
      • @@ -1435,9 +1468,9 @@

      workspace

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

    +

    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

      @@ -1446,13 +1479,14 @@

      workspaces

    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:

    +

    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.
      • +
    • 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

    @@ -1460,8 +1494,9 @@

    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.

    +

    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.

    yes

    • Default: null
      • @@ -1475,19 +1510,22 @@

      also

    • Type: null, "dev", or "development"
    • DEPRECATED: Please use --include=dev instead.
    -

    When set to dev or development, this is an alias for --include=dev.

    +

    When set to dev or development, this is an alias for +--include=dev.

    cache-max

    • Default: Infinity
    • Type: Number
      • -
    • DEPRECATED: This option has been deprecated in favor of --prefer-online
      • +
    • DEPRECATED: This option has been deprecated in favor of +--prefer-online

    --cache-max=0 is an alias for --prefer-online

    cache-min

    • Default: 0
    • Type: Number
      • -
    • DEPRECATED: This option has been deprecated in favor of --prefer-offline.
      • +
    • DEPRECATED: This option has been deprecated in favor of +--prefer-offline.

    --cache-min=9999 (or bigger) is an alias for --prefer-offline.

    cert

    @@ -1495,13 +1533,13 @@

    cert

  • Default: null
  • Type: null or String
  • DEPRECATED: key and cert are no longer used for most registry -operations. Use registry scoped keyfile and certfile instead. Example: -//other-registry.tld/:keyfile=/path/to/key.pem +operations. Use registry scoped keyfile and certfile instead. +Example: //other-registry.tld/:keyfile=/path/to/key.pem //other-registry.tld/:certfile=/path/to/cert.crt
    • -

    A client certificate to pass when accessing the registry. Values should be -in PEM format (Windows calls it "Base-64 encoded X.509 (.CER)") with -newlines replaced by the string "\n". For example:

    +

    A client certificate to pass when accessing the registry. Values +should be in PEM format (Windows calls it "Base-64 encoded X.509 +(.CER)") with newlines replaced by the string "\n". For example:

    cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"

    It is not the path to a certificate file, though you can set a @@ -1521,8 +1559,8 @@

    global-style

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

    +

    Only install direct dependencies in the top level node_modules, but +hoist on deeper dependencies. Sets --install-strategy=shallow.

    init.author.email

    • Default: ""
      • @@ -1570,16 +1608,17 @@

      key

    • Default: null
    • Type: null or String
    • DEPRECATED: key and cert are no longer used for most registry -operations. Use registry scoped keyfile and certfile instead. Example: -//other-registry.tld/:keyfile=/path/to/key.pem +operations. Use registry scoped keyfile and certfile instead. +Example: //other-registry.tld/:keyfile=/path/to/key.pem //other-registry.tld/:certfile=/path/to/cert.crt
    -

    A client key to pass when accessing the registry. Values should be in PEM -format with newlines replaced by the string "\n". For example:

    +

    A client key to pass when accessing the registry. Values should be in +PEM format with newlines replaced by the string "\n". For example:

    key="-----BEGIN PRIVATE KEY-----\nXXXX\nXXXX\n-----END PRIVATE KEY-----"
    -

    It is not the path to a key file, though you can set a registry-scoped -"keyfile" path like "//other-registry.tld/:keyfile=/path/to/key.pem".

    +

    It is not the path to a key file, though you can set a +registry-scoped "keyfile" path like +"//other-registry.tld/:keyfile=/path/to/key.pem".

    legacy-bundling

    • Default: false
      • @@ -1587,23 +1626,25 @@

      legacy-bundling

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

    +

    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.

    only

    • Default: null
    • Type: null, "prod", or "production"
      • -
    • DEPRECATED: Use --omit=dev to omit dev dependencies from the install.
      • +
    • DEPRECATED: Use --omit=dev to omit dev dependencies from the +install.
    -

    When set to prod or production, this is an alias for --omit=dev.

    +

    When set to prod or production, this is an alias for +--omit=dev.

    optional

    • Default: null
    • Type: null or Boolean
      • -
    • DEPRECATED: Use --omit=optional to exclude optional dependencies, or ---include=optional to include them.
      • +
    • DEPRECATED: Use --omit=optional to exclude optional dependencies, +or --include=optional to include them.

    Default value does install optional deps unless otherwise omitted.

    Alias for --include=optional or --omit=optional

    diff --git a/deps/npm/docs/output/using-npm/dependency-selectors.html b/deps/npm/docs/output/using-npm/dependency-selectors.html index b50c4c5d1a870f..67ea145085b0b6 100644 --- a/deps/npm/docs/output/using-npm/dependency-selectors.html +++ b/deps/npm/docs/output/using-npm/dependency-selectors.html @@ -141,9 +141,9 @@
    -

    +

    Dependency Selector Syntax & Querying - @11.6.1 + @11.6.2

    Dependency Selector Syntax & Querying
    @@ -159,12 +159,14 @@

    Table of contents

  • Standardizes the shape of, & querying of, dependency graphs with a robust object model, metadata & selector syntax
  • Leverages existing, known language syntax & operators from CSS to make disparate package information broadly accessible
  • Unlocks the ability to answer complex, multi-faceted questions about dependencies, their relationships & associative metadata
    • -
  • Consolidates redundant logic of similar query commands in npm (ex. npm fund, npm ls, npm outdated, npm audit ...)
    • +
  • Consolidates redundant logic of similar query commands in npm (ex. +npm fund, npm ls, npm outdated, npm audit ...)

    • Dependency Selector Syntax

    Overview:

      -
    • there is no "type" or "tag" selectors (ex. div, h1, a) as a dependency/target is the only type of Node that can be queried
      • +
    • there is no "type" or "tag" selectors (ex. +div, h1, a) as a dependency/target is the only type of Node that can be queried
    • the term "dependencies" is in reference to any Node found in a tree returned by Arborist

    Combinators

    @@ -213,13 +215,17 @@

    Pseudo Selectors

  • :vuln(<selector>) when a dependency has a known vulnerability
    • :semver(<spec>, [selector], [function])
    -

    The :semver() pseudo selector allows comparing fields from each node's package.json using semver methods. It accepts up to 3 parameters, all but the first of which are optional.

    +

    The :semver() pseudo selector allows comparing fields from each node's package.json using semver methods. +It accepts up to 3 parameters, all but the first of which are optional.

    • spec a semver version or range
    • selector an attribute selector for each node (default [version])
    • function a semver method to apply, one of: satisfies, intersects, subset, gt, gte, gtr, lt, lte, ltr, eq, neq or the special function infer (default infer)
    -

    When the special infer function is used the spec and the actual value from the node are compared. If both are versions, according to semver.valid(), eq is used. If both values are ranges, according to !semver.valid(), intersects is used. If the values are mixed types satisfies is used.

    +

    When the special infer function is used the spec and the actual value from the node are compared. +If both are versions, according to semver.valid(), eq is used. +If both values are ranges, according to !semver.valid(), intersects is used. +If the values are mixed types satisfies is used.

    Some examples:

    • :semver(^1.0.0) returns every node that has a version satisfied by the provided range ^1.0.0
      • @@ -227,7 +233,8 @@
      :semver(<spec>, [selector], [f
    • :semver(1.0.0, [version], lt) every node with a version less than 1.0.0
    :outdated(<type>)
    -

    The :outdated pseudo selector retrieves data from the registry and returns information about which of your dependencies are outdated. The type parameter may be one of the following:

    +

    The :outdated pseudo selector retrieves data from the registry and returns information about which of your dependencies are outdated. +The type parameter may be one of the following:

    • any (default) a version exists that is greater than the current one
    • in-range a version exists that is greater than the current one, and satisfies at least one if its parent's dependencies
      • @@ -236,11 +243,14 @@
      :outdated(<type>)
    • minor a version exists that is a semver minor greater than the current one
    • patch a version exists that is a semver patch greater than the current one
    -

    In addition to the filtering performed by the pseudo selector, some extra data is added to the resulting objects. The following data can be found under the queryContext property of each node.

    +

    In addition to the filtering performed by the pseudo selector, some extra data is added to the resulting objects. +The following data can be found under the queryContext property of each node.

    • versions an array of every available version of the given node
      • -
    • outdated.inRange an array of objects, each with a from and versions, where from is the on-disk location of the node that depends on the current node and versions is an array of all available versions that satisfies that dependency. This is only populated if :outdated(in-range) is used.
      • -
    • outdated.outOfRange an array of objects, identical in shape to inRange, but where the versions array is every available version that does not satisfy the dependency. This is only populated if :outdated(out-of-range) is used.
      • +
    • outdated.inRange an array of objects, each with a from and versions, where from is the on-disk location of the node that depends on the current node and versions is an array of all available versions that satisfies that dependency. +This is only populated if :outdated(in-range) is used.
      • +
    • outdated.outOfRange an array of objects, identical in shape to inRange, but where the versions array is every available version that does not satisfy the dependency. +This is only populated if :outdated(out-of-range) is used.

    Some examples:

      @@ -248,8 +258,12 @@
      :outdated(<type>)
    • .prod:outdated(in-range) returns production dependencies that have a new release that satisfies at least one of its parent's dependencies
    :vuln
    -

    The :vuln pseudo selector retrieves data from the registry and returns information about which if your dependencies has a known vulnerability. Only dependencies whose current version matches a vulnerability will be returned. For example if you have semver@7.6.0 in your tree, a vulnerability for semver which affects versions <=6.3.1 will not match.

    -

    You can also filter results by certain attributes in advisories. Currently that includes severity and cwe. Note that severity filtering is done per severity, it does not include severities "higher" or "lower" than the one specified.

    +

    The :vuln pseudo selector retrieves data from the registry and returns information about which if your dependencies has a known vulnerability. +Only dependencies whose current version matches a vulnerability will be returned. +For example if you have semver@7.6.0 in your tree, a vulnerability for semver which affects versions <=6.3.1 will not match.

    +

    You can also filter results by certain attributes in advisories. +Currently that includes severity and cwe. +Note that severity filtering is done per severity, it does not include severities "higher" or "lower" than the one specified.

    In addition to the filtering performed by the pseudo selector, info about each relevant advisory will be added to the queryContext attribute of each node under the advisories attribute.

    Some examples:

    -

    However, this behavior should not be relied on to keep all possible sensitive information redacted. If you are concerned about secrets in your log file or terminal output, you can use --loglevel=silent and --logs-max=0 to ensure no logs are written to your terminal or filesystem.

    +

    However, this behavior should not be relied on to keep all possible sensitive information redacted. +If you are concerned about secrets in your log file or terminal output, you can use --loglevel=silent and --logs-max=0 to ensure no logs are written to your terminal or filesystem.

    See also

    • config
      • diff --git a/deps/npm/docs/output/using-npm/orgs.html b/deps/npm/docs/output/using-npm/orgs.html index 01e3e29d006117..b998bb01581526 100644 --- a/deps/npm/docs/output/using-npm/orgs.html +++ b/deps/npm/docs/output/using-npm/orgs.html @@ -141,9 +141,9 @@
      -

      +

      orgs - @11.6.1 + @11.6.2

      Working with Teams & Orgs
      @@ -160,9 +160,13 @@

      Table of contents

    • Team admin, manages team membership & package access.
    • Developer, works on packages they are given access to.
      • -

      The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a developers team that all users are automatically added to.

      -

      The team admin is the person who manages team creation, team membership, and package access for teams. The team admin grants package access to teams, not individuals.

      -

      The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only.

      +

      The super admin is the only person who can add users to the org because it impacts the monthly bill. +The super admin will use the website to manage membership. +Every org has a developers team that all users are automatically added to.

      +

      The team admin is the person who manages team creation, team membership, and package access for teams. +The team admin grants package access to teams, not individuals.

      +

      The developer will be able to access packages based on the teams they are on. +Access is either read-write or read-only.

      There are two main commands:

      1. npm team see npm team for more details
        2. @@ -176,7 +180,8 @@

        Team Admins create teams
        • -

          Each org is automatically given a developers team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the access command.

          +

          Each org is automatically given a developers team, so you can see the whole list of team members in your org. +This team automatically gets read-write access to all packages, but you can change that with the access command.

        • Create a new team:

          @@ -210,17 +215,17 @@

          Monitor your package access

          • See what org packages a team member can access:
          -
          npm access ls-packages <org> <user>
+
          npm access list packages <org> <user>
 
          
 
            
 
          • See packages available to a specific team:
            • 
 
          
-
          npm access ls-packages <org:team>
+
          npm access list packages <org:team>
 
          
 
            
 
          • Check which teams are collaborating on a package:
            • 
 
          
-
          npm access ls-collaborators <pkg>
+
          npm access list collaborators <pkg>
 
          
 
          See also
          
 
            
diff --git a/deps/npm/docs/output/using-npm/package-spec.html b/deps/npm/docs/output/using-npm/package-spec.html
index 35835197f2470b..764a2ad3eb4291 100644
--- a/deps/npm/docs/output/using-npm/package-spec.html
+++ b/deps/npm/docs/output/using-npm/package-spec.html
@@ -141,9 +141,9 @@
 
 
            
 
            
-
            
+
            
     package-spec
-    @11.6.1
+    @11.6.2
 
            
 Package name specifier
 
            
@@ -154,12 +154,9 @@ 
            Table of contents
            
 
            
 
 
            Description
            
-
            Commands like npm install and the dependency sections in the
-package.json use a package name specifier.  This can be many different
-things that all refer to a "package".  Examples include a package name,
-git url, tarball, or local directory.  These will generally be referred
-to as <package-spec> in the help output for the npm commands that use
-this package name specifier.
            
+
            Commands like npm install and the dependency sections in the package.json use a package name specifier.
+This can be many different things that all refer to a "package".  Examples include a package name, git url, tarball, or local directory.
+These will generally be referred to as <package-spec> in the help output for the npm commands that use this package name specifier.
            
 
            Package name
            
 
              
 
            • [<@scope>/]<pkg>
              • 
@@ -167,10 +164,8 @@ 
              Package name
              
 
            • [<@scope>/]<pkg>@<version>
              • 
 
            • [<@scope>/]<pkg>@<version range>
              • 
 
            
-
            Refers to a package by name, with or without a scope, and optionally
-tag, version, or version range.  This is typically used in combination
-with the registry config to refer to a
-package in a registry.
            
+
            Refers to a package by name, with or without a scope, and optionally tag, version, or version range.
+This is typically used in combination with the registry config to refer to a package in a registry.
            
 
            Examples:
            
 
              
 
            • npm
              • 
@@ -183,14 +178,9 @@ 
              Aliases
              
 
                
 
              • <alias>@npm:<name>
                • 
 
              
-
              Primarily used by commands like npm install and in the dependency
-sections in the package.json, this refers to a package by an alias.
-The <alias> is the name of the package as it is reified in the
-node_modules folder, and the <name> refers to a package name as
-found in the configured registry.
              
-
              See Package name above for more info on referring to a package by
-name, and registry for configuring which
-registry is used when referring to a package by name.
              
+
              Primarily used by commands like npm install and in the dependency sections in the package.json, this refers to a package by an alias.
+The <alias> is the name of the package as it is reified in the node_modules folder, and the <name> refers to a package name as found in the configured registry.
              
+
              See Package name above for more info on referring to a package by name, and registry for configuring which registry is used when referring to a package by name.
              
 
              Examples:
              
 
                
 
              • semver:@npm:@npmcli/semver-with-patch
                • 
@@ -201,12 +191,10 @@ 
                Folders
                
 
                  
 
                • <folder>
                  • 
 
                
-
                This refers to a package on the local filesystem.  Specifically this is
-a folder with a package.json file in it.  This should always be
-prefixed with a / or ./ (or your OS equivalent) to reduce confusion.
-npm currently will parse a string with more than one / in it as a
-folder, but this is legacy behavior that may be removed in a future
-version.
                
+
                This refers to a package on the local filesystem.
+Specifically this is a folder with a package.json file in it.
+This should always be prefixed with a / or ./ (or your OS equivalent) to reduce confusion.
+npm currently will parse a string with more than one / in it as a folder, but this is legacy behavior that may be removed in a future version.
                
 
                Examples:
                
 
                  
 
                • ./my-package
                  • 
@@ -222,17 +210,16 @@ 
                  Tarballs
                  
 
                • ./my-package.tgz
                  • 
 
                • https://registry.npmjs.org/semver/-/semver-1.0.0.tgz
                  • 
 
                
-
                Refers to a package in a tarball format, either on the local filesystem
-or remotely via url.  This is the format that packages exist in when
-uploaded to a registry.
                
+
                Refers to a package in a tarball format, either on the local filesystem or remotely via url.
+This is the format that packages exist in when uploaded to a registry.
                
 
                git urls
                
 
                  
 
                • <git:// url>
                  • 
 
                • <github username>/<github project>
                  • 
 
                
-
                Refers to a package in a git repo.  This can be a full git url, git
-shorthand, or a username/package on GitHub.  You can specify a
-git tag, branch, or other git ref by appending #ref.
                
+
                Refers to a package in a git repo.
+This can be a full git url, git shorthand, or a username/package on GitHub.
+You can specify a git tag, branch, or other git ref by appending #ref.
                
 
                Examples:
                
 
                  
 
                • https://github.com/npm/cli.git
                  • 
diff --git a/deps/npm/docs/output/using-npm/registry.html b/deps/npm/docs/output/using-npm/registry.html
index 822686fa486055..95fe69d0f0e1fb 100644
--- a/deps/npm/docs/output/using-npm/registry.html
+++ b/deps/npm/docs/output/using-npm/registry.html
@@ -141,9 +141,9 @@
 
 
                  
 
                  
-
                  
+
                  
     registry
-    @11.6.1
+    @11.6.2
 
                  
 The JavaScript Package Registry
 
                  
@@ -154,56 +154,34 @@ 
                  Table of contents
                  
 
                  
 
 
                  Description
                  
-
                  To resolve packages by name and version, npm talks to a registry website
-that implements the CommonJS Package Registry specification for reading
-package info.
                  
+
                  To resolve packages by name and version, npm talks to a registry website that implements the CommonJS Package Registry specification for reading package info.
                  
 
                  npm is configured to use the npm public registry at
-https://registry.npmjs.org by default. Use of the npm public registry is
-subject to terms of use available at https://docs.npmjs.com/policies/terms.
                  
-
                  You can configure npm to use any compatible registry you like, and even run
-your own registry. Use of someone else's registry may be governed by their
-terms of use.
                  
-
                  npm's package registry implementation supports several
-write APIs as well, to allow for publishing packages and managing user
-account information.
                  
-
                  The registry URL used is determined by the scope of the package (see
-scope. If no scope is specified, the default registry is
-used, which is supplied by the registry config
-parameter.  See npm config,
-npmrc, and config for more on
-managing npm's configuration.
-Authentication configuration such as auth tokens and certificates are configured
-specifically scoped to an individual registry. See
-Auth Related Configuration
                  
-
                  When the default registry is used in a package-lock or shrinkwrap it has the
-special meaning of "the currently configured registry". If you create a lock
-file while using the default registry you can switch to another registry and
-npm will install packages from the new registry, but if you create a lock
-file while using a custom registry packages will be installed from that
-registry even after you change to another registry.
                  
+https://registry.npmjs.org by default.
+Use of the npm public registry is subject to terms of use available at https://docs.npmjs.com/policies/terms.
                  
+
                  You can configure npm to use any compatible registry you like, and even run your own registry.
+Use of someone else's registry may be governed by their terms of use.
                  
+
                  npm's package registry implementation supports several write APIs as well, to allow for publishing packages and managing user account information.
                  
+
                  The registry URL used is determined by the scope of the package (see scope.
+If no scope is specified, the default registry is used, which is supplied by the registry config parameter.
+See npm config, npmrc, and config for more on managing npm's configuration.
+Authentication configuration such as auth tokens and certificates are configured specifically scoped to an individual registry.
+See Auth Related Configuration
                  
+
                  When the default registry is used in a package-lock or shrinkwrap it has the special meaning of "the currently configured registry". If you create a lock file while using the default registry you can switch to another registry and npm will install packages from the new registry, but if you create a lock file while using a custom registry packages will be installed from that registry even after you change to another registry.
                  
 
                  Does npm send any information about me back to the registry?
                  
 
                  Yes.
                  
-
                  When making requests of the registry npm adds two headers with information
-about your environment:
                  
+
                  When making requests of the registry npm adds two headers with information about your environment:
                  
 
                    
-
                  • Npm-Scope – If your project is scoped, this header will contain its
-scope. In the future npm hopes to build registry features that use this
-information to allow you to customize your experience for your
-organization.
                    • 
-
                  • Npm-In-CI – Set to "true" if npm believes this install is running in a
-continuous integration environment, "false" otherwise. This is detected by
-looking for the following environment variables: CI, TDDIUM,
-JENKINS_URL, bamboo.buildKey. If you'd like to learn more you may find
-the original PR
-interesting.
-This is used to gather better metrics on how npm is used by humans, versus
-build farms.
                    • 
+
                  • Npm-Scope – If your project is scoped, this header will contain its scope.
+In the future npm hopes to build registry features that use this information to allow you to customize your experience for your organization.
                    • 
+
                  • Npm-In-CI – Set to "true" if npm believes this install is running in a continuous integration environment, "false" otherwise.
+This is detected by looking for the following environment variables: CI, TDDIUM,
+JENKINS_URL, bamboo.buildKey.
+If you'd like to learn more you may find the original PR interesting.
+This is used to gather better metrics on how npm is used by humans, versus build farms.
                    • 
 
                  
-
                  The npm registry does not try to correlate the information in these headers
-with any authenticated accounts that may be used in the same requests.
                  
+
                  The npm registry does not try to correlate the information in these headers with any authenticated accounts that may be used in the same requests.
                  
 
                  How can I prevent my package from being published in the official registry?
                  
-
                  Set "private": true in your package.json to prevent it from being
-published at all, or
+
                  Set "private": true in your package.json to prevent it from being published at all, or
 "publishConfig":{"registry":"http://my-internal-registry.local"}
 to force it to be published only to your internal/private registry.
                  
 
                  See package.json for more info on what goes in the package.json file.
                  
diff --git a/deps/npm/docs/output/using-npm/removal.html b/deps/npm/docs/output/using-npm/removal.html
index d52141e1c67485..23db6a16ca78d5 100644
--- a/deps/npm/docs/output/using-npm/removal.html
+++ b/deps/npm/docs/output/using-npm/removal.html
@@ -141,9 +141,9 @@
 
 
                  
 
                  
-
                  
+
                  
     removal
-    @11.6.1
+    @11.6.2
 
                  
 Cleaning the Slate
 
                  
@@ -159,29 +159,24 @@ 
                  Table of contents
                  
 
          
 
          Or, if that fails, please proceed to more severe uninstalling methods.
          
 
          More Severe Uninstalling
          
-
          Usually, the above instructions are sufficient.  That will remove
-npm, but leave behind anything you've installed.
          
-
          If that doesn't work, or if you require more drastic measures,
-continue reading.
          
-
          Note that this is only necessary for globally-installed packages.  Local
-installs are completely contained within a project's node_modules
-folder.  Delete that folder, and everything is gone unless a package's
-install script is particularly ill-behaved.
          
-
          This assumes that you installed node and npm in the default place.  If
-you configured node with a different --prefix, or installed npm with a
-different prefix setting, then adjust the paths accordingly, replacing
+
          Usually, the above instructions are sufficient.
+That will remove npm, but leave behind anything you've installed.
          
+
          If that doesn't work, or if you require more drastic measures, continue reading.
          
+
          Note that this is only necessary for globally-installed packages.
+Local installs are completely contained within a project's node_modules folder.
+Delete that folder, and everything is gone unless a package's install script is particularly ill-behaved.
          
+
          This assumes that you installed node and npm in the default place.
+If you configured node with a different --prefix, or installed npm with a different prefix setting, then adjust the paths accordingly, replacing
 /usr/local with your install prefix.
          
 
          To remove everything npm-related manually:
          
 
          rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
 
          
-
          If you installed things with npm, then your best bet is to uninstall
-them with npm first, and then install them again once you have a
-proper install.  This can help find any symlinks that are lying
-around:
          
+
          If you installed things with npm, then your best bet is to uninstall them with npm first, and then install them again once you have a proper install.
+This can help find any symlinks that are lying around:
          
 
          ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
 
          
-
          Prior to version 0.3, npm used shim files for executables and node
-modules.  To track those down, you can do the following:
          
+
          Prior to version 0.3, npm used shim files for executables and node modules.
+To track those down, you can do the following:
          
 
          find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;
 
          
 
          See also
          
diff --git a/deps/npm/docs/output/using-npm/scope.html b/deps/npm/docs/output/using-npm/scope.html
index 821e7980f9241e..a2ff83d6221a24 100644
--- a/deps/npm/docs/output/using-npm/scope.html
+++ b/deps/npm/docs/output/using-npm/scope.html
@@ -141,9 +141,9 @@
 
 
          
 
          
-
          
+
          
     scope
-    @11.6.1
+    @11.6.2
 
          
 Scoped packages
 
          
@@ -154,28 +154,22 @@ 
          Table of contents
          
 
          
 
 
          Description
          
-
          All npm packages have a name. Some package names also have a scope. A scope
-follows the usual rules for package names (URL-safe characters, no leading dots
-or underscores). When used in package names, scopes are preceded by an @ symbol
-and followed by a slash, e.g.
          
+
          All npm packages have a name.
+Some package names also have a scope.
+A scope follows the usual rules for package names (URL-safe characters, no leading dots or underscores).
+When used in package names, scopes are preceded by an @ symbol and followed by a slash, e.g.
          
 
          @somescope/somepackagename
 
          
-
          Scopes are a way of grouping related packages together, and also affect a few
-things about the way npm treats the package.
          
-
          Each npm user/organization has their own scope, and only you can add packages
-in your scope. This means you don't have to worry about someone taking your
-package name ahead of you. Thus it is also a good way to signal official packages
-for organizations.
          
-
          Scoped packages can be published and installed as of npm@2 and are supported
-by the primary npm registry. Unscoped packages can depend on scoped packages and
-vice versa. The npm client is backwards-compatible with unscoped registries,
-so it can be used to work with scoped and unscoped registries at the same time.
          
+
          Scopes are a way of grouping related packages together, and also affect a few things about the way npm treats the package.
          
+
          Each npm user/organization has their own scope, and only you can add packages in your scope.
+This means you don't have to worry about someone taking your package name ahead of you.
+Thus it is also a good way to signal official packages for organizations.
          
+
          Scoped packages can be published and installed as of npm@2 and are supported by the primary npm registry.
+Unscoped packages can depend on scoped packages and vice versa.
+The npm client is backwards-compatible with unscoped registries, so it can be used to work with scoped and unscoped registries at the same time.
          
 
          Installing scoped packages
          
-
          Scoped packages are installed to a sub-folder of the regular installation
-folder, e.g. if your other packages are installed in node_modules/packagename,
-scoped modules will be installed in node_modules/@myorg/packagename. The scope
-folder (@myorg) is simply the name of the scope preceded by an @ symbol, and can
-contain any number of scoped packages.
          
+
          Scoped packages are installed to a sub-folder of the regular installation folder, e.g. if your other packages are installed in node_modules/packagename, scoped modules will be installed in node_modules/@myorg/packagename.
+The scope folder (@myorg) is simply the name of the scope preceded by an @ symbol, and can contain any number of scoped packages.
          
 
          A scoped package is installed by referencing it by name, preceded by an
 @ symbol, in npm install:
          
 
          npm install @myorg/mypackage
@@ -185,19 +179,15 @@ 
          Installing scoped packages
          
   "@myorg/mypackage": "^1.3.0"
 }
 
          
-
          Note that if the @ symbol is omitted, in either case, npm will instead attempt to
-install from GitHub; see npm install.
          
+
          Note that if the @ symbol is omitted, in either case, npm will instead attempt to install from GitHub; see npm install.
          
 
          Requiring scoped packages
          
-
          Because scoped packages are installed into a scope folder, you have to
-include the name of the scope when requiring them in your code, e.g.
          
+
          Because scoped packages are installed into a scope folder, you have to include the name of the scope when requiring them in your code, e.g.
          
 
          require('@myorg/mypackage')
 
          
-
          There is nothing special about the way Node treats scope folders. This
-simply requires the mypackage module in the folder named @myorg.
          
+
          There is nothing special about the way Node treats scope folders.
+This simply requires the mypackage module in the folder named @myorg.
          
 
          Publishing scoped packages
          
-
          Scoped packages can be published from the CLI as of npm@2 and can be
-published to any registry that supports them, including the primary npm
-registry.
          
+
          Scoped packages can be published from the CLI as of npm@2 and can be published to any registry that supports them, including the primary npm registry.
          
 
          (As of 2015-04-19, and with npm 2.0 or better, the primary npm registry
 does support scoped packages.)
          
 
          If you wish, you may associate a scope with a registry; see below.
          
@@ -207,39 +197,29 @@ 
          Publishin
 
        • Publishing to your user scope (example: @username/module)
          • 
 
        • Publishing to an organization scope (example: @org/module)
          •
        -

        If publishing a public module to an organization scope, you must -first either create an organization with the name of the scope -that you'd like to publish to or be added to an existing organization -with the appropriate permissions. For example, if you'd like to -publish to @org, you would need to create the org organization -on npmjs.com prior to trying to publish.

        -

        Scoped packages are not public by default. You will need to specify ---access public with the initial npm publish command. This will publish -the package and set access to public as if you had run npm access public -after publishing. You do not need to do this when publishing new versions of -an existing scoped package.

        +

        If publishing a public module to an organization scope, you must first either create an organization with the name of the scope that you'd like to publish to or be added to an existing organization with the appropriate permissions. +For example, if you'd like to publish to @org, you would need to create the org organization on npmjs.com prior to trying to publish.

        +

        Scoped packages are not public by default. +You will need to specify +--access public with the initial npm publish command. +This will publish the package and set access to public as if you had run npm access public after publishing. +You do not need to do this when publishing new versions of an existing scoped package.

        Publishing private scoped packages to the npm registry

        -

        To publish a private scoped package to the npm registry, you must have -an npm Private Modules -account.

        -

        You can then publish the module with npm publish or npm publish --access restricted, and it will be present in the npm registry, with -restricted access. You can then change the access permissions, if -desired, with npm access or on the npmjs.com website.

        +

        To publish a private scoped package to the npm registry, you must have an npm Private Modules account.

        +

        You can then publish the module with npm publish or npm publish --access restricted, and it will be present in the npm registry, with restricted access. +You can then change the access permissions, if desired, with npm access or on the npmjs.com website.

        Associating a scope with a registry

        -

        Scopes can be associated with a separate registry. This allows you to -seamlessly use a mix of packages from the primary npm registry and one or more -private registries, such as GitHub Packages or the open source Verdaccio -project.

        +

        Scopes can be associated with a separate registry. +This allows you to seamlessly use a mix of packages from the primary npm registry and one or more private registries, such as GitHub Packages or the open source Verdaccio project.

        You can associate a scope with a registry at login, e.g.

        npm login --registry=http://reg.example.com --scope=@myco
        -

        Scopes have a many-to-one relationship with registries: one registry can -host multiple scopes, but a scope only ever points to one registry.

        +

        Scopes have a many-to-one relationship with registries: one registry can host multiple scopes, but a scope only ever points to one registry.

        You can also associate a scope with a registry using npm config:

        npm config set @myco:registry=http://reg.example.com
        -

        Once a scope is associated with a registry, any npm install for a package -with that scope will request packages from that registry instead. Any +

        Once a scope is associated with a registry, any npm install for a package with that scope will request packages from that registry instead. +Any npm publish for a package name that contains the scope will be published to that registry instead.

        See also

        diff --git a/deps/npm/docs/output/using-npm/scripts.html b/deps/npm/docs/output/using-npm/scripts.html index a1da523c2577c4..1e76b658763907 100644 --- a/deps/npm/docs/output/using-npm/scripts.html +++ b/deps/npm/docs/output/using-npm/scripts.html @@ -141,9 +141,9 @@
        -

        +

        scripts - @11.6.1 + @11.6.2

        How npm handles the "scripts" field
        @@ -154,13 +154,12 @@

        Table of contents

        Description

        -

        The "scripts" property of your package.json file supports a number -of built-in scripts and their preset life cycle events as well as -arbitrary scripts. These all can be executed by running -npm run <stage>. Pre and post -commands with matching names will be run for those as well (e.g. premyscript, -myscript, postmyscript). Scripts from dependencies can be run with -npm explore <pkg> -- npm run <stage>.

        +

        The "scripts" property of your package.json file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. +These all can be executed by running npm run <stage>. +Pre and post commands with matching names will be run for those as well (e.g. +premyscript, +myscript, postmyscript). +Scripts from dependencies can be run with npm explore <pkg> -- npm run <stage>.

        Pre & Post Scripts

        To create "pre" or "post" scripts for any scripts defined in the "scripts" section of the package.json, simply create another script @@ -173,11 +172,10 @@

        Pre & Post Scripts

        } }         -

        In this example npm run compress would execute these scripts as -described.

        +

        In this example npm run compress would execute these scripts as described.

        Life Cycle Scripts

        -

        There are some special life cycle scripts that happen only in certain -situations. These scripts happen in addition to the pre<event>, post<event>, and +

        There are some special life cycle scripts that happen only in certain situations. +These scripts happen in addition to the pre<event>, post<event>, and <event> scripts.

        • prepare, prepublish, prepublishOnly, prepack, postpack, dependencies
          • @@ -185,8 +183,8 @@

          Life Cycle Scripts

          prepare (since npm@4.0.0)

          • -

            Runs BEFORE the package is packed, i.e. during npm publish -and npm pack

            +

            Runs BEFORE the package is packed, i.e. +during npm publish and npm pack

          • Runs on local npm install without any arguments

            @@ -198,10 +196,7 @@

            Life Cycle Scripts

            Runs for a package if it's being installed as a link through npm install <folder>

          • -

            NOTE: If a package being installed through git 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.

            +

            NOTE: If a package being installed through git 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.

          • As of npm@7 these scripts run in the background. @@ -210,8 +205,8 @@

            Life Cycle Scripts

          prepublish (DEPRECATED)

            -
          • Does not run during npm publish, but does run during npm ci -and npm install. See below for more info.
            • +
          • Does not run during npm publish, but does run during npm ci and npm install. +See below for more info.

          prepublishOnly

            @@ -220,7 +215,7 @@

            Life Cycle Scripts

            prepack

            • Runs BEFORE a tarball is packed (on "npm pack", "npm publish", and when installing a git dependency).
              • -
            • NOTE: "npm run pack" is NOT the same as "npm pack". "npm run pack" is an arbitrary user defined script name, where as, "npm pack" is a CLI defined command.
              • +
            • NOTE: "npm run pack" is NOT the same as "npm pack". "npm run pack" is an arbitrary user defined script name, whereas, "npm pack" is a CLI defined command.

            postpack

              @@ -233,26 +228,29 @@

              Life Cycle Scripts

            Prepare and Prepublish

            Deprecation Note: prepublish

            -

            Since npm@1.1.71, the npm CLI has run the prepublish script for both npm publish and npm install, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, very confusing. As of npm@4.0.0, a new event has been introduced, prepare, that preserves this existing behavior. A new event, prepublishOnly has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on npm publish (for instance, running the tests one last time to ensure they're in good shape).

            +

            Since npm@1.1.71, the npm CLI has run the prepublish script for both npm publish and npm install, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). +It has also turned out to be, in practice, very confusing. +As of npm@4.0.0, a new event has been introduced, prepare, that preserves this existing behavior. +A new event, prepublishOnly has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on npm publish (for instance, running the tests one last time to ensure they're in good shape).

            See https://github.com/npm/npm/issues/10074 for a much lengthier justification, with further reading, for this change.

            Use Cases

            -

            If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a prepublish script. This includes tasks such as:

            +

            If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a prepublish script. +This includes tasks such as:

            • Compiling CoffeeScript source code into JavaScript.
            • Creating minified versions of JavaScript source code.
            • Fetching remote resources that your package will use.
            -

            The advantage of doing these things at prepublish time is that they can be done once, in a single place, thus reducing complexity and variability. Additionally, this means that:

            +

            The advantage of doing these things at prepublish time is that they can be done once, in a single place, thus reducing complexity and variability. +Additionally, this means that:

              -
            • You can depend on coffee-script as a devDependency, and thus -your users don't need to have it installed.
              • -
            • You don't need to include minifiers in your package, reducing -the size for your users.
              • -
            • You don't need to rely on your users having curl or wget or -other system tools on the target machines.
              • +
            • You can depend on coffee-script as a devDependency, and thus your users don't need to have it installed.
              • +
            • You don't need to include minifiers in your package, reducing the size for your users.
              • +
            • You don't need to rely on your users having curl or wget or other system tools on the target machines.

            Dependencies

            -

            The dependencies script is run any time an npm command causes changes to the node_modules directory. It is run AFTER the changes have been applied and the package.json and package-lock.json files have been updated.

            +

            The dependencies script is run any time an npm command causes changes to the node_modules directory. +It is run AFTER the changes have been applied and the package.json and package-lock.json files have been updated.

            Life Cycle Operation Order

            npm cache add

            -

            If there is a binding.gyp file in the root of your package and you -haven't defined your own install or preinstall scripts, npm will -default the install command to compile using node-gyp via node-gyp rebuild

            +

            If there is a binding.gyp file in the root of your package and you haven't defined your own install or preinstall scripts, npm will default the install command to compile using node-gyp via node-gyp rebuild

            These are run from the scripts of <pkg-name>

            npm pack

            -

            prepare is only run if the current directory is a symlink (e.g. with -linked packages)

            +

            prepare is only run if the current directory is a symlink (e.g. +with linked packages)

            npm restart

            -

            If there is a restart script defined, these events are run, otherwise -stop and start are both run if present, including their pre and -post iterations)

            +

            If there is a restart script defined, these events are run; otherwise, +stop and start are both run if present, including their pre and post iterations)

            -

            If there is a server.js file in the root of your package, then npm -will default the start command to node server.js. prestart and -poststart will still run in this case.

            +

            If there is a server.js file in the root of your package, then npm will default the start command to node server.js. +prestart and poststart will still run in this case.

            npm stop

            A Note on a lack of npm uninstall scripts

            -

            While npm v6 had uninstall lifecycle scripts, npm v7 does not. Removal of a package can happen for a wide variety of reasons, and there's no clear way to currently give the script enough context to be useful.

            +

            While npm v6 had uninstall lifecycle scripts, npm v7 does not. +Removal of a package can happen for a wide variety of reasons, and there's no clear way to currently give the script enough context to be useful.

            Reasons for a package removal include:

            • a user directly uninstalled this package
              • -
            • a user uninstalled a dependant package and so this dependency is being uninstalled
              • -
            • a user uninstalled a dependant package but another package also depends on this version
              • +
            • a user uninstalled a dependent package and so this dependency is being uninstalled
              • +
            • a user uninstalled a dependent package but another package also depends on this version
            • this version has been merged as a duplicate with another version
            • etc.

            Due to the lack of necessary context, uninstall lifecycle scripts are not implemented and will not function.

            Working Directory for Scripts

            -

            Scripts are always run from the root of the package folder, regardless of what the current working directory is when npm is invoked. This means your scripts can reliably assume they are running in the package root.

            +

            Scripts are always run from the root of the package folder, regardless of what the current working directory is when npm is invoked. +This means your scripts can reliably assume they are running in the package root.

            If you want your script to behave differently based on the directory you were in when you ran npm, you can use the INIT_CWD environment variable, which holds the full path you were in when you ran npm run.

            Historical Behavior in Older npm Versions

            -

            For npm v6 and earlier, scripts were generally run from the root of the package, but there were rare cases and bugs in older versions where this was not guaranteed. If your package must support very old npm versions, you may wish to add a safeguard in your scripts (for example, by checking process.cwd()).

            +

            For npm v6 and earlier, scripts were generally run from the root of the package, but there were rare cases and bugs in older versions where this was not guaranteed. +If your package must support very old npm versions, you may wish to add a safeguard in your scripts (for example, by checking process.cwd()).

            For more details, see:

            User

            -

            When npm is run as root, scripts are always run with the effective uid -and gid of the working directory owner.

            +

            When npm is run as root, scripts are always run with the effective uid and gid of the working directory owner.

            Environment

            -

            Package scripts run in an environment where many pieces of information -are made available regarding the setup of npm and the current state of -the process.

            +

            Package scripts run in an environment where many pieces of information are made available regarding the setup of npm and the current state of the process.

            path

            -

            If you depend on modules that define executable scripts, like test -suites, then those executables will be added to the PATH for -executing the scripts. So, if your package.json has this:

            +

            If you depend on modules that define executable scripts, like test suites, then those executables will be added to the PATH for executing the scripts. +So, if your package.json has this:

            {
   "name" : "foo",
   "dependencies" : {
@@ -397,25 +390,16 @@ 
            path
            
   }
 }
            -

            then you could run npm start to execute the bar script, which is -exported into the node_modules/.bin directory on npm install.

            +

            then you could run npm start to execute the bar script, which is exported into the node_modules/.bin directory on npm install.

            package.json vars

            -

            The package.json fields are tacked onto the npm_package_ prefix. So, -for instance, if you had {"name":"foo", "version":"1.2.5"} in your -package.json file, then your package scripts would have the -npm_package_name environment variable set to "foo", and the -npm_package_version set to "1.2.5". You can access these variables -in your code with process.env.npm_package_name and -process.env.npm_package_version, and so on for other fields.

            +

            The package.json fields are tacked onto the npm_package_ prefix. +So, for instance, if you had {"name":"foo", "version":"1.2.5"} in your package.json file, then your package scripts would have the npm_package_name environment variable set to "foo", and the npm_package_version set to "1.2.5". You can access these variables in your code with process.env.npm_package_name and process.env.npm_package_version, and so on for other fields.

            See package.json for more on package configs.

            current lifecycle event

            -

            Lastly, the npm_lifecycle_event environment variable is set to -whichever stage of the cycle is being executed. So, you could have a -single script used for different parts of the process which switches -based on what's currently happening.

            +

            Lastly, the npm_lifecycle_event environment variable is set to whichever stage of the cycle is being executed. +So, you could have a single script used for different parts of the process which switches based on what's currently happening.

            Objects are flattened following this format, so if you had -{"scripts":{"install":"foo.js"}} in your package.json, then you'd -see this in the script:

            +{"scripts":{"install":"foo.js"}} in your package.json, then you'd see this in the script:

            process.env.npm_package_scripts_install === "foo.js"

            Examples

            @@ -427,12 +411,11 @@

            Examples

            } }             -

            then scripts/install.js will be called for the install and post-install -stages of the lifecycle. Since scripts/install.js is running for two -different phases, it would be wise in this case to look at the +

            then scripts/install.js will be called for the install and post-install stages of the lifecycle. +Since scripts/install.js is running for two different phases, it would be wise in this case to look at the npm_lifecycle_event environment variable.

            -

            If you want to run a make command, you can do so. This works just -fine:

            +

            If you want to run a make command, you can do so. +This works just fine:

            {
   "scripts" : {
     "preinstall" : "./configure",
@@ -442,33 +425,27 @@ 
            Examples
            
 }

            Exiting

            -

            Scripts are run by passing the line as a script argument to /bin/sh on POSIX systems or cmd.exe on Windows. You can control which shell is used by setting the script-shell configuration option.

            -

            If the script exits with a code other than 0, then this will abort the -process.

            -

            Note that these script files don't have to be Node.js or even -JavaScript programs. They just have to be some kind of executable -file.

            +

            Scripts are run by passing the line as a script argument to /bin/sh on POSIX systems or cmd.exe on Windows. +You can control which shell is used by setting the script-shell configuration option.

            +

            If the script exits with a code other than 0, then this will abort the process.

            +

            Note that these script files don't have to be Node.js or even JavaScript programs. +They just have to be some kind of executable file.

            Best Practices

            • Don't exit with a non-zero error code unless you really mean it. -If the failure is minor or only will prevent some optional features, then -it's better to just print a warning and exit successfully.
              • -
            • Try not to use scripts to do what npm can do for you. Read through -package.json to see all the things that you can specify and enable -by simply describing your package appropriately. In general, this -will lead to a more robust and consistent state.
              • -
            • Inspect the env to determine where to put things. For instance, if -the npm_config_binroot environment variable is set to /home/user/bin, then -don't try to install executables into /usr/local/bin. The user -probably set it up that way for a reason.
              • -
            • Don't prefix your script commands with "sudo". If root permissions -are required for some reason, then it'll fail with that error, and -the user will sudo the npm command in question.
              • -
            • Don't use install. Use a .gyp file for compilation, and prepare -for anything else. You should almost never have to explicitly set a -preinstall or install script. If you are doing this, please consider if -there is another option. The only valid use of install or preinstall -scripts is for compilation which must be done on the target architecture.
              • +If the failure is minor or only will prevent some optional features, then it's better to just print a warning and exit successfully. +
            • Try not to use scripts to do what npm can do for you. +Read through package.json to see all the things that you can specify and enable by simply describing your package appropriately. +In general, this will lead to a more robust and consistent state.
              • +
            • Inspect the env to determine where to put things. +For instance, if the npm_config_binroot environment variable is set to /home/user/bin, then don't try to install executables into /usr/local/bin. +The user probably set it up that way for a reason.
              • +
            • Don't prefix your script commands with "sudo". If root permissions are required for some reason, then it'll fail with that error, and the user will sudo the npm command in question.
              • +
            • Don't use install. +Use a .gyp file for compilation, and prepare for anything else. +You should almost never have to explicitly set a preinstall or install script. +If you are doing this, please consider if there is another option. +The only valid use of install or preinstall scripts is for compilation which must be done on the target architecture.

            See Also

              diff --git a/deps/npm/docs/output/using-npm/workspaces.html b/deps/npm/docs/output/using-npm/workspaces.html index 072a3a1fdd8ec0..f1062e2d28399f 100644 --- a/deps/npm/docs/output/using-npm/workspaces.html +++ b/deps/npm/docs/output/using-npm/workspaces.html @@ -141,9 +141,9 @@
              -

              +

              workspaces - @11.6.1 + @11.6.2

              Working with workspaces
              @@ -154,21 +154,13 @@

              Table of contents

              Description

              -

              Workspaces is a generic term that refers to the set of features in the -npm cli that provides support for managing multiple packages from your local -file system from within a singular top-level, root package.

              -

              This set of features makes up for a much more streamlined workflow handling -linked packages from the local file system. It automates the linking process -as part of npm install and removes the need to manually use npm link in -order to add references to packages that should be symlinked into the current -node_modules folder.

              -

              We also refer to these packages being auto-symlinked during npm install as a -single workspace, meaning it's a nested package within the current local -file system that is explicitly defined in the package.json +

              Workspaces is a generic term that refers to the set of features in the npm cli that provides support for managing multiple packages from your local file system from within a singular top-level, root package.

              +

              This set of features makes up for a much more streamlined workflow handling linked packages from the local file system. +It automates the linking process as part of npm install and removes the need to manually use npm link in order to add references to packages that should be symlinked into the current node_modules folder.

              +

              We also refer to these packages being auto-symlinked during npm install as a single workspace, meaning it's a nested package within the current local file system that is explicitly defined in the package.json workspaces configuration.

              Defining workspaces

              -

              Workspaces are usually defined via the workspaces property of the -package.json file, e.g:

              +

              Workspaces are usually defined via the workspaces property of the package.json file, e.g:

              {
   "name": "my-workspaces-powered-project",
   "workspaces": [
@@ -176,20 +168,15 @@ 
              Defining workspaces
              
   ]
 }
              -

              Given the above package.json example living at a current working -directory . that contains a folder named packages/a that itself contains -a package.json inside it, defining a Node.js package, e.g:

              +

              Given the above package.json example living at a current working directory . that contains a folder named packages/a that itself contains a package.json inside it, defining a Node.js package, e.g:

              .
 +-- package.json
 `-- packages
    +-- a
    |   `-- package.json
              -

              The expected result once running npm install in this current working -directory . is that the folder packages/a will get symlinked to the -node_modules folder of the current working dir.

              -

              Below is a post npm install example, given that same previous example -structure of files and folders:

              +

              The expected result once running npm install in this current working directory . is that the folder packages/a will get symlinked to the node_modules folder of the current working dir.

              +

              Below is a post npm install example, given that same previous example structure of files and folders:

              .
 +-- node_modules
 |  `-- a -> ../packages/a
@@ -200,17 +187,14 @@ 
              Defining workspaces
              
    |   `-- package.json

              Getting started with workspaces

              -

              You may automate the required steps to define a new workspace using -npm init. For example in a project that already has a -package.json defined you can run:

              +

              You may automate the required steps to define a new workspace using npm init. +For example in a project that already has a package.json defined you can run:

              npm init -w ./packages/a
              -

              This command will create the missing folders and a new package.json -file (if needed) while also making sure to properly configure the +

              This command will create the missing folders and a new package.json file (if needed) while also making sure to properly configure the "workspaces" property of your root project package.json.

              Adding dependencies to a workspace

              -

              It's possible to directly add/remove/update dependencies of your workspaces -using the workspace config.

              +

              It's possible to directly add/remove/update dependencies of your workspaces using the workspace config.

              For example, assuming the following structure:

              .
 +-- package.json
@@ -220,19 +204,13 @@ 
              Adding dependencies to a workspace
              -

              If you want to add a dependency named abbrev from the registry as a -dependency of your workspace a, you may use the workspace config to tell -the npm installer that package should be added as a dependency of the provided -workspace:

              +

              If you want to add a dependency named abbrev from the registry as a dependency of your workspace a, you may use the workspace config to tell the npm installer that package should be added as a dependency of the provided workspace:

              npm install abbrev -w a
              -

              Note: other installing commands such as uninstall, ci, etc will also -respect the provided workspace configuration.

              +

              Note: other installing commands such as uninstall, ci, etc will also respect the provided workspace configuration.

              Using workspaces

              -

              Given the specifics of how Node.js handles module resolution it's possible to consume any defined workspace -by its declared package.json name. Continuing from the example defined -above, let's also create a Node.js script that will require the workspace a -example module, e.g:

              +

              Given the specifics of how Node.js handles module resolution it's possible to consume any defined workspace by its declared package.json name. +Continuing from the example defined above, let's also create a Node.js script that will require the workspace a example module, e.g:

              // ./packages/a/index.js
 module.exports = 'a'
 
@@ -243,16 +221,12 @@ 
              Using workspaces
              
 
              When running it with:
              
 
              node lib/index.js
              
 
              This demonstrates how the nature of node_modules resolution allows for
-workspaces to enable a portable workflow for requiring each workspace
-in such a way that is also easy to publish these
-nested workspaces to be consumed elsewhere.
              
+workspaces to enable a portable workflow for requiring each workspace in such a way that is also easy to publish these nested workspaces to be consumed elsewhere.
              
 
              Running commands in the context of workspaces
              
-
              You can use the workspace configuration option to run commands in the context
-of a configured workspace.
-Additionally, if your current directory is in a workspace, the workspace
-configuration is implicitly set, and prefix is set to the root workspace.
              
-
              Following is a quick example on how to use the npm run command in the context
-of nested workspaces. For a project containing multiple workspaces, e.g:
              
+
              You can use the workspace configuration option to run commands in the context of a configured workspace.
+Additionally, if your current directory is in a workspace, the workspace configuration is implicitly set, and prefix is set to the root workspace.
              
+
              Following is a quick example on how to use the npm run command in the context of nested workspaces.
+For a project containing multiple workspaces, e.g:
              
 
              .
 +-- package.json
 `-- packages
@@ -261,8 +235,8 @@ 
              Running commands in the c
    `-- b
        `-- package.json
 
              
-
              By running a command using the workspace option, it's possible to run the
-given command in the context of that specific workspace. e.g:
              
+
              By running a command using the workspace option, it's possible to run the given command in the context of that specific workspace.
+e.g:
              
 
              npm run test --workspace=a
 
              
 
              You could also run the command within the workspace.
              
@@ -270,16 +244,14 @@ 
              Running commands in the c

              Either will run the test script defined within the ./packages/a/package.json file.

              -

              Please note that you can also specify this argument multiple times in the -command-line in order to target multiple workspaces, e.g:

              +

              Please note that you can also specify this argument multiple times in the command-line in order to target multiple workspaces, e.g:

              npm run test --workspace=a --workspace=b

              Or run the command for each workspace within the 'packages' folder:

              npm run test --workspace=packages
              -

              It's also possible to use the workspaces (plural) configuration option to -enable the same behavior but running that command in the context of all -configured workspaces. e.g:

              +

              It's also possible to use the workspaces (plural) configuration option to enable the same behavior but running that command in the context of all configured workspaces. +e.g:

              npm run test --workspaces

              Will run the test script in both ./packages/a and ./packages/b.

              diff --git a/deps/npm/lib/base-cmd.js b/deps/npm/lib/base-cmd.js index dcbad88a8b35e1..3e6c4758cbd587 100644 --- a/deps/npm/lib/base-cmd.js +++ b/deps/npm/lib/base-cmd.js @@ -84,7 +84,7 @@ class BaseCommand { } if (config.get('workspaces') === false && config.get('workspace').length) { - throw new Error('Can not use --no-workspaces and --workspace at the same time') + throw new Error('Cannot use --no-workspaces and --workspace at the same time') } } diff --git a/deps/npm/lib/cli/entry.js b/deps/npm/lib/cli/entry.js index dd9b39973f8a1f..a068d22c55cbf1 100644 --- a/deps/npm/lib/cli/entry.js +++ b/deps/npm/lib/cli/entry.js @@ -20,7 +20,7 @@ module.exports = async (process, validateEngines) => { log.info('using', 'npm@%s', npm.version) log.info('using', 'node@%s', process.version) - // At this point we've required a few files and can be pretty sure we dont contain invalid syntax for this version of node. It's possible a lazy require would, but that's unlikely enough that it's not worth catching anymore and we attach the more important exit handlers. + // At this point we've required a few files and can be pretty sure we don't contain invalid syntax for this version of node. It's possible a lazy require would, but that's unlikely enough that it's not worth catching anymore and we attach the more important exit handlers. validateEngines.off() exitHandler.registerUncaughtHandlers() @@ -57,7 +57,7 @@ module.exports = async (process, validateEngines) => { const execPromise = npm.exec(command, args) - // this is async but we dont await it, since its ok if it doesnt + // this is async but we don't await it, since its ok if it doesnt // finish before the command finishes running. it uses command and argv // so it must be initiated here, after the command name is set const updateNotifier = require('./update-notifier.js') diff --git a/deps/npm/lib/cli/exit-handler.js b/deps/npm/lib/cli/exit-handler.js index e76b08c80a635b..f4fbcd9d834f16 100644 --- a/deps/npm/lib/cli/exit-handler.js +++ b/deps/npm/lib/cli/exit-handler.js @@ -37,7 +37,7 @@ class ExitHandler { constructor ({ process }) { this.#process = process - this.#process.on('exit', this.#handleProcesExitAndReset) + this.#process.on('exit', this.#handleProcessExitAndReset) } registerUncaughtHandlers () { @@ -49,12 +49,12 @@ class ExitHandler { this.#handleExit(err) } - #handleProcesExitAndReset = (code) => { + #handleProcessExitAndReset = (code) => { this.#handleProcessExit(code) // Reset all the state. This is only relevant for tests since // in reality the process fully exits here. - this.#process.off('exit', this.#handleProcesExitAndReset) + this.#process.off('exit', this.#handleProcessExitAndReset) this.#process.off('uncaughtException', this.#handleExit) this.#process.off('unhandledRejection', this.#handleExit) if (this.#loaded) { @@ -158,7 +158,7 @@ class ExitHandler { this.#exitErrorMessage = err?.suppressError === true ? false : !!err // Prefer the exit code of the error, then the current process exit code, - // then set it to 1 if we still have an error. Otherwise we call process.exit + // then set it to 1 if we still have an error. Otherwise, we call process.exit // with undefined so that it can determine the final exit code const exitCode = err?.exitCode ?? this.#process.exitCode ?? (err ? 1 : undefined) diff --git a/deps/npm/lib/cli/update-notifier.js b/deps/npm/lib/cli/update-notifier.js index ffe51af1feea69..20a22900268934 100644 --- a/deps/npm/lib/cli/update-notifier.js +++ b/deps/npm/lib/cli/update-notifier.js @@ -102,7 +102,6 @@ const updateNotifier = async (npm, spec = '*') => { return updateCheck(npm, spec, version, current) } -// only update the notification timeout if we actually finished checking module.exports = npm => { if ( // opted out diff --git a/deps/npm/lib/commands/audit.js b/deps/npm/lib/commands/audit.js index 486bef1bb5dc11..97d0729da9618d 100644 --- a/deps/npm/lib/commands/audit.js +++ b/deps/npm/lib/commands/audit.js @@ -53,7 +53,7 @@ class Audit extends ArboristWorkspaceCmd { async auditAdvisories (args) { const fix = args[0] === 'fix' if (this.npm.config.get('package-lock') === false && fix) { - throw this.usageError('fix can not be used without a package-lock') + throw this.usageError('fix cannot be used without a package-lock') } const reporter = this.npm.config.get('json') ? 'json' : 'detail' const Arborist = require('@npmcli/arborist') diff --git a/deps/npm/lib/commands/completion.js b/deps/npm/lib/commands/completion.js index f8c2e00c6baee7..1a1cb901ee5a0d 100644 --- a/deps/npm/lib/commands/completion.js +++ b/deps/npm/lib/commands/completion.js @@ -4,7 +4,7 @@ // zsh or bash when calling a function for completion, based on the cursor // position and the command line thus far. These are: // COMP_CWORD: the index of the "word" in the command line being completed -// COMP_LINE: the full command line thusfar as a string +// COMP_LINE: the full command line thus far as a string // COMP_POINT: the cursor index at the point of triggering completion // // We parse the command line with nopt, like npm does, and then create an diff --git a/deps/npm/lib/commands/config.js b/deps/npm/lib/commands/config.js index 31dbc074a83726..b657029b2d2fe5 100644 --- a/deps/npm/lib/commands/config.js +++ b/deps/npm/lib/commands/config.js @@ -15,7 +15,7 @@ const { redact } = require('@npmcli/redact') // validate valid configs during "npm config set", and folks may have old // invalid entries lying around in a config file that we still want to protect // when running "npm config list" -// This is a more general list of values to consider protected. You can not +// This is a more general list of values to consider protected. You cannot // "npm config get" them, and they will not display during "npm config list" const protected = [ 'auth', @@ -176,7 +176,7 @@ class Config extends BaseCommand { const deprecated = this.npm.config.definitions[baseKey]?.deprecated if (deprecated) { throw new Error( - `The \`${baseKey}\` option is deprecated, and can not be set in this way${deprecated}` + `The \`${baseKey}\` option is deprecated, and cannot be set in this way${deprecated}` ) } @@ -203,7 +203,7 @@ class Config extends BaseCommand { for (const key of keys) { const val = this.npm.config.get(key) if (isPrivate(key, val)) { - throw new Error(`The ${key} option is protected, and can not be retrieved in this way`) + throw new Error(`The ${key} option is protected, and cannot be retrieved in this way`) } const pref = keys.length > 1 ? `${key}=` : '' diff --git a/deps/npm/lib/commands/diff.js b/deps/npm/lib/commands/diff.js index 0ab7f6fccc9c6a..f2a43c135c0e19 100644 --- a/deps/npm/lib/commands/diff.js +++ b/deps/npm/lib/commands/diff.js @@ -181,8 +181,8 @@ class Diff extends BaseCommand { const aSpec = `file:${node.realpath}` - // finds what version of the package to compare against, if a exact - // version or tag was passed than it should use that, otherwise + // finds what version of the package to compare against, if an exact + // version or tag was passed than it should use that; otherwise, // work from the top of the arborist tree to find the original semver // range declared in the package that depends on the package. let bSpec diff --git a/deps/npm/lib/commands/dist-tag.js b/deps/npm/lib/commands/dist-tag.js index 3fdecd926a564e..655ec0d17539ef 100644 --- a/deps/npm/lib/commands/dist-tag.js +++ b/deps/npm/lib/commands/dist-tag.js @@ -77,7 +77,7 @@ class DistTag extends BaseCommand { } // anything else is just a regular dist-tag command - // so we fallback to the non-workspaces implementation + // so we fall back to the non-workspaces implementation log.warn('dist-tag', 'Ignoring workspaces for specified package') return this.exec([cmdName, pkg, tag]) } diff --git a/deps/npm/lib/commands/exec.js b/deps/npm/lib/commands/exec.js index 57ee8efe2c98fe..c91222ffe3230d 100644 --- a/deps/npm/lib/commands/exec.js +++ b/deps/npm/lib/commands/exec.js @@ -82,7 +82,7 @@ class Exec extends BaseCommand { // when we try to install a missing package, we won't actually install it packageLockOnly: false, // what the user asked to run args[0] is run by default - args: [...args], // copy args so they dont get mutated + args: [...args], // copy args so they don't get mutated // specify a custom command to be run instead of args[0] call, chalk, diff --git a/deps/npm/lib/commands/help-search.js b/deps/npm/lib/commands/help-search.js index 72dd03ac7406ec..f5f6ec05cfa593 100644 --- a/deps/npm/lib/commands/help-search.js +++ b/deps/npm/lib/commands/help-search.js @@ -163,18 +163,18 @@ class HelpSearch extends BaseCommand { return } - const hilitLine = [] + const highlightLine = [] for (const arg of args) { const finder = line.toLowerCase().split(arg.toLowerCase()) let p = 0 for (const f of finder) { - hilitLine.push(line.slice(p, p + f.length)) + highlightLine.push(line.slice(p, p + f.length)) const word = line.slice(p + f.length, p + f.length + arg.length) - hilitLine.push(this.npm.chalk.blue(word)) + highlightLine.push(this.npm.chalk.blue(word)) p += f.length + arg.length } } - out.push(hilitLine.join('') + '\n') + out.push(highlightLine.join('') + '\n') }) return out.join('') diff --git a/deps/npm/lib/commands/help.js b/deps/npm/lib/commands/help.js index 057090da0036c5..6eca85b4b0fe00 100644 --- a/deps/npm/lib/commands/help.js +++ b/deps/npm/lib/commands/help.js @@ -13,7 +13,7 @@ const globify = pattern => pattern.split('\\').join('/') // We don't currently compress our man pages but if we ever did this would // seamlessly continue supporting it const manNumberRegex = /\.(\d+)(\.[^/\\]*)?$/ -// hardcoded names for mansections +// hardcoded names for man sections // XXX: these are used in the docs workspace and should be exported // from npm so section names can changed more easily const manSectionNames = { diff --git a/deps/npm/lib/commands/outdated.js b/deps/npm/lib/commands/outdated.js index 5421b1ddaab894..6c2d4cdcd9581d 100644 --- a/deps/npm/lib/commands/outdated.js +++ b/deps/npm/lib/commands/outdated.js @@ -278,7 +278,7 @@ class Outdated extends ArboristWorkspaceCmd { dependedByLocation: d.dependedByLocation } : {}, } acc[d.name] = acc[d.name] - // If this item alread has an outdated dep then we turn it into an array + // If this item already has an outdated dep then we turn it into an array ? (Array.isArray(acc[d.name]) ? acc[d.name] : [acc[d.name]]).concat(dep) : dep return acc diff --git a/deps/npm/lib/commands/publish.js b/deps/npm/lib/commands/publish.js index 6586e652c7b810..162e3d65ba5ce9 100644 --- a/deps/npm/lib/commands/publish.js +++ b/deps/npm/lib/commands/publish.js @@ -188,7 +188,7 @@ class Publish extends BaseCommand { await otplease(this.npm, opts, o => libpub(manifest, tarballData, o)) } - // In json mode we dont log until the publish has completed as this will + // In json mode we don't log until the publish has completed as this will // add it to the output only if completes successfully if (json) { logPkg() diff --git a/deps/npm/lib/npm.js b/deps/npm/lib/npm.js index 9a7103f135d5df..c635f3e05a7b3a 100644 --- a/deps/npm/lib/npm.js +++ b/deps/npm/lib/npm.js @@ -130,7 +130,7 @@ class Npm { process.env.COLOR = this.color ? '1' : '0' // npm -v - // return from here early so we dont create any caches/logfiles/timers etc + // return from here early so we don't create any caches/logfiles/timers etc if (this.config.get('version', 'cli')) { output.standard(this.version) return { exec: false } diff --git a/deps/npm/lib/utils/display.js b/deps/npm/lib/utils/display.js index 67a3b98c0417a0..01ad55d4ce30c3 100644 --- a/deps/npm/lib/utils/display.js +++ b/deps/npm/lib/utils/display.js @@ -75,11 +75,9 @@ const setBlocking = (stream) => { return stream } -// These are important // This is the key that is returned to the user for errors const ERROR_KEY = 'error' -// This is the key producers use to indicate that there -// is a json error that should be merged into the finished output +// This is the key producers use to indicate that there is a json error that should be merged into the finished output const JSON_ERROR_KEY = 'jsonError' const isPlainObject = (v) => v && typeof v === 'object' && !Array.isArray(v) @@ -120,15 +118,12 @@ const getJsonBuffer = ({ [JSON_ERROR_KEY]: metaError }, buffer) => { const res = getArrayOrObject(items) - // This skips any error checking since we can only set an error property - // on an object that can be stringified + // This skips any error checking since we can only set an error property on an object that can be stringified // XXX(BREAKING_CHANGE): remove this in favor of always returning an object with result and error keys if (isPlainObject(res) && errors.length) { - // This is not ideal. JSON output has always been keyed at the root with an `error` - // key, so we cant change that without it being a breaking change. At the same time - // some commands output arbitrary keys at the top level of the output, such as package - // names. So the output could already have the same key. The choice here is to overwrite - // it with our error since that is (probably?) more important. + // This is not ideal. + // JSON output has always been keyed at the root with an `error` key, so we cant change that without it being a breaking change. At the same time some commands output arbitrary keys at the top level of the output, such as package names. + // So the output could already have the same key. The choice here is to overwrite it with our error since that is (probably?) more important. // XXX(BREAKING_CHANGE): all json output should be keyed under well known keys, eg `result` and `error` if (res[ERROR_KEY]) { log.warn('', `overwriting existing ${ERROR_KEY} on json output`) @@ -221,15 +216,11 @@ class Display { timing, unicode, }) { - // get createSupportsColor from chalk directly if this lands - // https://github.com/chalk/chalk/pull/600 const [{ Chalk }, { createSupportsColor }] = await Promise.all([ import('chalk'), import('supports-color'), ]) - // we get the chalk level based on a null stream meaning chalk will only use - // what it knows about the environment to get color support since we already - // determined in our definitions that we want to show colors. + // We get the chalk level based on a null stream, meaning chalk will only use what it knows about the environment to get color support since we already determined in our definitions that we want to show colors. const level = Math.max(createSupportsColor(null).level, 1) this.#noColorChalk = new Chalk({ level: 0 }) this.#stdoutColor = stdoutColor @@ -265,8 +256,7 @@ class Display { // HANDLERS - // Arrow function assigned to a private class field so it can be passed - // directly as a listener and still reference "this" + // Arrow function assigned to a private class field so it can be passed directly as a listener and still reference "this" #logHandler = withMeta((level, meta, ...args) => { switch (level) { case log.KEYS.resume: @@ -289,8 +279,7 @@ class Display { } }) - // Arrow function assigned to a private class field so it can be passed - // directly as a listener and still reference "this" + // Arrow function assigned to a private class field so it can be passed directly as a listener and still reference "this" #outputHandler = withMeta((level, meta, ...args) => { this.#json = typeof meta.json === 'boolean' ? meta.json : this.#json switch (level) { @@ -316,18 +305,14 @@ class Display { if (this.#outputState.buffering) { this.#outputState.buffer.push([level, meta, ...args]) } else { - // HACK: Check if the argument looks like a run-script banner. This can be - // replaced with proc-log.META in @npmcli/run-script + // XXX: Check if the argument looks like a run-script banner. This should be replaced with proc-log.META in @npmcli/run-script if (typeof args[0] === 'string' && args[0].startsWith('\n> ') && args[0].endsWith('\n')) { if (this.#silent || ['exec', 'explore'].includes(this.#command)) { // Silent mode and some specific commands always hide run script banners break } else if (this.#json) { - // In json mode, change output to stderr since we dont want to break json - // parsing on stdout if the user is piping to jq or something. - // XXX: in a future (breaking?) change it might make sense for run-script to - // always output these banners with proc-log.output.error if we think they - // align closer with "logging" instead of "output" + // In json mode, change output to stderr since we don't want to break json parsing on stdout if the user is piping to jq or something. + // XXX: in a future (breaking?) change it might make sense for run-script to always output these banners with proc-log.output.error if we think they align closer with "logging" instead of "output". level = output.KEYS.error } } @@ -352,14 +337,12 @@ class Display { break case input.KEYS.read: { - // The convention when calling input.read is to pass in a single fn that returns - // the promise to await. resolve and reject are provided by proc-log + // The convention when calling input.read is to pass in a single fn that returns the promise to await. resolve and reject are provided by proc-log. const [res, rej, p] = args return input.start(() => p() .then(res) .catch(rej) - // Any call to procLog.input.read will render a prompt to the user, so we always - // add a single newline of output to stdout to move the cursor to the next line + // Any call to procLog.input.read will render a prompt to the user, so we always add a single newline of output to stdout to move the cursor to the next line. .finally(() => output.standard(''))) } } @@ -370,11 +353,11 @@ class Display { #writeOutput (level, meta, ...args) { switch (level) { case output.KEYS.standard: - this.#write(this.#stdout, {}, ...args) + this.#write(this.#stdout, meta, ...args) break case output.KEYS.error: - this.#write(this.#stderr, {}, ...args) + this.#write(this.#stderr, meta, ...args) break } } @@ -383,10 +366,7 @@ class Display { #tryWriteLog (level, meta, ...args) { try { - // Also (and this is a really inexcusable kludge), we patch the - // log.warn() method so that when we see a peerDep override - // explanation from Arborist, we can replace the object with a - // highly abbreviated explanation of what's being overridden. + // Also (and this is a really inexcusable kludge), we patch the log.warn() method so that when we see a peerDep override explanation from Arborist, we can replace the object with a highly abbreviated explanation of what's being overridden. // TODO: this could probably be moved to arborist now that display is refactored const [heading, message, expl] = args if (level === log.KEYS.warn && heading === 'ERESOLVE' && expl && typeof expl === 'object') { @@ -400,8 +380,7 @@ class Display { // if it crashed once, it might again! this.#writeLog(log.KEYS.verbose, meta, '', `attempt to log crashed`, ...args, ex) } catch (ex2) { - // This happens if the object has an inspect method that crashes so just console.error - // with the errors but don't do anything else that might error again. + // This happens if the object has an inspect method that crashes so just console.error with the errors but don't do anything else that might error again. // eslint-disable-next-line no-console console.error(`attempt to log crashed`, ex, ex2) } @@ -421,7 +400,12 @@ class Display { this.#logColors[level](level), title ? this.#logColors.title(title) : null, ] - this.#write(this.#stderr, { prefix }, ...args) + const writeOpts = { prefix } + // notice logs typically come from `npm-notice` headers in responses. Some of them have 2fa login links so we skip redaction. + if (level === 'notice') { + writeOpts.redact = false + } + this.#write(this.#stderr, writeOpts, ...args) } } } @@ -433,16 +417,17 @@ class Progress { static dots = { duration: 80, frames: ['⠋', '⠙', '⠹', '⠸', '⠼', '⠴', '⠦', '⠧', '⠇', '⠏'] } static lines = { duration: 130, frames: ['-', '\\', '|', '/'] } - #stream - #spinner #enabled = false - #frameIndex = 0 - #lastUpdate = 0 #interval + #lastUpdate = 0 + #spinner + #stream + // Initial timeout to wait to start rendering #timeout + #rendered = false - // We are rendering is enabled option is set and we are not waiting for the render timeout + // We are rendering if enabled option is set and we are not waiting for the render timeout get #rendering () { return this.#enabled && !this.#timeout } @@ -459,8 +444,13 @@ class Progress { load ({ enabled, unicode }) { this.#enabled = enabled this.#spinner = unicode ? Progress.dots : Progress.lines - // Dont render the spinner for short durations - this.#render(200) + // Wait 200 ms so we don't render the spinner for short durations + this.#timeout = setTimeout(() => { + this.#timeout = null + this.#render() + }, 200) + // Make sure this timeout does not keep the process open + this.#timeout.unref() } off () { @@ -477,12 +467,11 @@ class Progress { } resume () { - this.#render() + this.#render(true) } - // If we are currenting rendering the spinner we clear it - // before writing our line and then re-render the spinner after. - // If not then all we need to do is write the line + // If we are currently rendering the spinner we clear it before writing our line and then re-render the spinner after. + // If not then all we need to do is write the line. write (write) { if (this.#spinning) { this.#clearSpinner() @@ -493,31 +482,21 @@ class Progress { } } - #render (ms) { - if (ms) { - this.#timeout = setTimeout(() => { - this.#timeout = null - this.#renderSpinner() - }, ms) - // Make sure this timeout does not keep the process open - this.#timeout.unref() - } else { - this.#renderSpinner() - } - } - - #renderSpinner () { + #render (resuming) { if (!this.#rendering) { return } - // We always attempt to render immediately but we only request to move to the next - // frame if it has been longer than our spinner frame duration since our last update - this.#renderFrame(Date.now() - this.#lastUpdate >= this.#spinner.duration) - clearInterval(this.#interval) - this.#interval = setInterval(() => this.#renderFrame(true), this.#spinner.duration) + // We always attempt to render immediately but we only request to move to the next frame if it has been longer than our spinner frame duration since our last update + this.#renderFrame(Date.now() - this.#lastUpdate >= this.#spinner.duration, resuming) + if (!this.#interval) { + this.#interval = setInterval(() => this.#renderFrame(true), this.#spinner.duration) + // Make sure this timeout does not keep the process open + this.#interval.unref() + } + this.#interval.refresh() } - #renderFrame (next) { + #renderFrame (next, resuming) { if (next) { this.#lastUpdate = Date.now() this.#frameIndex++ @@ -525,14 +504,21 @@ class Progress { this.#frameIndex = 0 } } - this.#clearSpinner() + if (!resuming) { + this.#clearSpinner() + } this.#stream.write(this.#spinner.frames[this.#frameIndex]) + this.#rendered = true } #clearSpinner () { + if (!this.#rendered) { + return + } // Move to the start of the line and clear the rest of the line this.#stream.cursorTo(0) this.#stream.clearLine(1) + this.#rendered = false } } diff --git a/deps/npm/lib/utils/format.js b/deps/npm/lib/utils/format.js index 9216c7918678ac..3161abd7ea4de1 100644 --- a/deps/npm/lib/utils/format.js +++ b/deps/npm/lib/utils/format.js @@ -41,9 +41,12 @@ function STRIP_C01 (str) { return result } -const formatWithOptions = ({ prefix: prefixes = [], eol = '\n', ...options }, ...args) => { +const formatWithOptions = ({ prefix: prefixes = [], eol = '\n', redact = true, ...options }, ...args) => { const prefix = prefixes.filter(p => p != null).join(' ') - const formatted = redactLog(STRIP_C01(baseFormatWithOptions(options, ...args))) + let formatted = STRIP_C01(baseFormatWithOptions(options, ...args)) + if (redact) { + formatted = redactLog(formatted) + } // Splitting could be changed to only `\n` once we are sure we only emit unix newlines. // The eol param to this function will put the correct newlines in place for the returned string. const lines = formatted.split(/\r?\n/) diff --git a/deps/npm/lib/utils/log-file.js b/deps/npm/lib/utils/log-file.js index 6c9bcd7ff8d86b..c7c1d754009a3c 100644 --- a/deps/npm/lib/utils/log-file.js +++ b/deps/npm/lib/utils/log-file.js @@ -118,7 +118,7 @@ class LogFiles { } if (this.#isBuffered) { - // Cant do anything but buffer the output if we dont + // Cant do anything but buffer the output if we don't // have a file stream yet this.#logStream.push([level, ...args]) return diff --git a/deps/npm/lib/utils/open-url.js b/deps/npm/lib/utils/open-url.js index 632dcc79949d66..9aa04b13822776 100644 --- a/deps/npm/lib/utils/open-url.js +++ b/deps/npm/lib/utils/open-url.js @@ -1,5 +1,5 @@ const { open } = require('@npmcli/promise-spawn') -const { output, input } = require('proc-log') +const { output, input, META } = require('proc-log') const { URL } = require('node:url') const readline = require('node:readline/promises') const { once } = require('node:events') @@ -18,7 +18,8 @@ const outputMsg = (json, title, url) => { if (json) { output.buffer({ title, url }) } else { - output.standard(`${title}:\n${url}`) + // These urls are sometimes specifically login urls so we have to turn off redaction to standard output + output.standard(`${title}:\n${url}`, { [META]: true, redact: false }) } } diff --git a/deps/npm/lib/utils/queryable.js b/deps/npm/lib/utils/queryable.js index a5fb25a845eafc..7e51194eaf1fc7 100644 --- a/deps/npm/lib/utils/queryable.js +++ b/deps/npm/lib/utils/queryable.js @@ -101,7 +101,7 @@ const getter = ({ data, key }, { unwrapSingleItemArrays = true } = {}) => { // extra logic to take into account printing array, along with its // special syntax in which using a dot-sep property name after an - // arry will expand it's results, e.g: + // array will expand it's results, e.g: // arr.name -> arr[0].name=value, arr[1].name=value, ... const maybeIndex = Number(k) if (Array.isArray(_data) && !Number.isInteger(maybeIndex)) { @@ -206,7 +206,7 @@ const setter = ({ data, key, value, force }) => { } // sets items from the parsed array of keys as objects, recurses to - // setKeys in case there are still items to be handled, otherwise it + // setKeys in case there are still items to be handled; otherwise, it // just sets the original value set by the user if (keys.length) { _data[_key] = setKeys(next(), keys.shift()) @@ -270,7 +270,7 @@ class Queryable { } } - // return the value for a single query if found, otherwise returns undefined + // return the value for a single query if found; otherwise, returns undefined get (query) { const obj = this.query(query) if (obj) { diff --git a/deps/npm/lib/utils/sbom-cyclonedx.js b/deps/npm/lib/utils/sbom-cyclonedx.js index e09d2486e21c40..0cd170fbbcbee0 100644 --- a/deps/npm/lib/utils/sbom-cyclonedx.js +++ b/deps/npm/lib/utils/sbom-cyclonedx.js @@ -1,6 +1,6 @@ const crypto = require('node:crypto') -const normalizeData = require('normalize-package-data') const parseLicense = require('spdx-expression-parse') +const PackageJson = require('@npmcli/package-json') const npa = require('npm-package-arg') const ssri = require('ssri') @@ -79,7 +79,9 @@ const toCyclonedxItem = (node, { packageType }) => { const purl = npa.toPurl(spec) + (isGitNode(node) ? `?vcs_url=${node.resolved}` : '') if (node.package) { - normalizeData(node.package) + const toNormalize = new PackageJson() + toNormalize.fromContent(node.package).normalize({ steps: ['normalizeData'] }) + node.package = toNormalize.content } let parsedLicense diff --git a/deps/npm/lib/utils/sbom-spdx.js b/deps/npm/lib/utils/sbom-spdx.js index 7f6ce0580ed41f..074a6f57f98bf0 100644 --- a/deps/npm/lib/utils/sbom-spdx.js +++ b/deps/npm/lib/utils/sbom-spdx.js @@ -1,6 +1,6 @@ const crypto = require('node:crypto') -const normalizeData = require('normalize-package-data') +const PackageJson = require('@npmcli/package-json') const npa = require('npm-package-arg') const ssri = require('ssri') @@ -90,7 +90,9 @@ const spdxOutput = ({ npm, nodes, packageType }) => { } const toSpdxItem = (node, { packageType }) => { - normalizeData(node.package) + const toNormalize = new PackageJson() + toNormalize.fromContent(node.package).normalize({ steps: ['normalizeData'] }) + node.package = toNormalize.content // Calculate purl from package spec let spec = npa(node.pkgid) diff --git a/deps/npm/lib/utils/verify-signatures.js b/deps/npm/lib/utils/verify-signatures.js index cf9fafd17745da..baadb2b1227d94 100644 --- a/deps/npm/lib/utils/verify-signatures.js +++ b/deps/npm/lib/utils/verify-signatures.js @@ -190,7 +190,7 @@ class VerifySignatures { } }) - // If keys not found in Sigstore TUF repo, fallback to registry keys API + // If keys not found in Sigstore TUF repo, fall back to registry keys API if (!keys) { log.warn(`Fetching verification keys using TUF failed. Fetching directly from ${registry}.`) keys = await npmFetch.json('/-/npm/v1/keys', { @@ -264,7 +264,7 @@ class VerifySignatures { const { version } = node.package || {} if (node.isWorkspace || // Skip local workspaces packages - !version || // Skip packages that don't have a installed version, e.g. optonal dependencies + !version || // Skip packages that don't have an installed version, e.g. optional dependencies !spec.registry) { // Skip if not from registry, e.g. git package return } diff --git a/deps/npm/man/man1/npm-access.1 b/deps/npm/man/man1/npm-access.1 index 2af0e1e7485be0..8165aa386bd0d9 100644 --- a/deps/npm/man/man1/npm-access.1 +++ b/deps/npm/man/man1/npm-access.1 @@ -1,4 +1,4 @@ -.TH "NPM-ACCESS" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-ACCESS" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-access\fR - Set access level on published packages .SS "Synopsis" @@ -23,17 +23,7 @@ Used to set access controls on private packages. For all of the subcommands, \fBnpm access\fR will perform actions on the packages in the current working directory if no package name is passed to the subcommand. .RS 0 .IP \(bu 4 -public / restricted (deprecated): Set a package to be either publicly accessible or restricted. -.IP \(bu 4 -grant / revoke (deprecated): Add or remove the ability of users and teams to have read-only or read-write access to a package. -.IP \(bu 4 -2fa-required / 2fa-not-required (deprecated): Configure whether a package requires that anyone publishing it have two-factor authentication enabled on their account. -.IP \(bu 4 -ls-packages (deprecated): Show all of the packages a user or a team is able to access, along with the access level, except for read-only public packages (it won't print the whole registry listing) -.IP \(bu 4 -ls-collaborators (deprecated): Show all of the access privileges for a package. Will only show permissions for packages to which you have at least read access. If \fB\fR is passed in, the list is filtered only to teams \fIthat\fR user happens to belong to. -.IP \(bu 4 -edit (not implemented) +grant / revoke: Add or remove the ability of users and teams to have read-only or read-write access to a package. .RE 0 .SS "Details" @@ -42,7 +32,7 @@ edit (not implemented) .P Unscoped packages are \fIalways public\fR. .P -Scoped packages \fIdefault to restricted\fR, but you can either publish them as public using \fBnpm publish --access=public\fR, or set their access as public using \fBnpm access public\fR after the initial publish. +Scoped packages \fIdefault to restricted\fR, but you can either publish them as public using \fBnpm publish --access=public\fR, or set their access as public using \fBnpm access set status=public\fR after the initial publish. .P You must have privileges to set the access of a package: .RS 0 @@ -87,7 +77,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "\fBregistry\fR" diff --git a/deps/npm/man/man1/npm-adduser.1 b/deps/npm/man/man1/npm-adduser.1 index 17e282982d2918..9435eb6f819788 100644 --- a/deps/npm/man/man1/npm-adduser.1 +++ b/deps/npm/man/man1/npm-adduser.1 @@ -1,4 +1,4 @@ -.TH "NPM-ADDUSER" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-ADDUSER" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-adduser\fR - Add a registry user account .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-audit.1 b/deps/npm/man/man1/npm-audit.1 index 176cf77d2707b3..70e8b778937a12 100644 --- a/deps/npm/man/man1/npm-audit.1 +++ b/deps/npm/man/man1/npm-audit.1 @@ -1,4 +1,4 @@ -.TH "NPM-AUDIT" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-AUDIT" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-audit\fR - Run a security audit .SS "Synopsis" @@ -14,8 +14,7 @@ The audit command submits a description of the dependencies configured in your p .P The command will exit with a 0 exit code if no vulnerabilities were found. .P -Note that some vulnerabilities cannot be fixed automatically and will require manual intervention or review. Also note that since \fBnpm audit -fix\fR runs a full-fledged \fBnpm install\fR under the hood, all configs that apply to the installer will also apply to \fBnpm install\fR -- so things like \fBnpm audit fix --package-lock-only\fR will work as expected. +Note that some vulnerabilities cannot be fixed automatically and will require manual intervention or review. Also note that since \fBnpm audit fix\fR runs a full-fledged \fBnpm install\fR under the hood, all configs that apply to the installer will also apply to \fBnpm install\fR -- so things like \fBnpm audit fix --package-lock-only\fR will work as expected. .P 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 \fB--audit-level\fR 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. .SS "Package lock" @@ -82,7 +81,7 @@ Keys response: .IP \(bu 4 \fBexpires\fR: null or a simplified extended \fBISO 8601 format\fR \fI\(lahttps://en.wikipedia.org/wiki/ISO_8601\(ra\fR: \fBYYYY-MM-DDTHH:mm:ss.sssZ\fR .IP \(bu 4 -\fBkeydid\fR: sha256 fingerprint of the public key +\fBkeyid\fR: sha256 fingerprint of the public key .IP \(bu 4 \fBkeytype\fR: only \fBecdsa-sha2-nistp256\fR is currently supported by the npm CLI .IP \(bu 4 @@ -140,8 +139,7 @@ This scrubbing has been removed from npm as of version 7. .P npm uses the \fB\[rs]fB@npmcli/metavuln-calculator\[rs]fR\fR \fI\(lahttp://npm.im/@npmcli/metavuln-calculator\(ra\fR 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. .P -For example, if the package \fBfoo\fR is vulnerable in the range \fB>=1.0.2 -<2.0.0\fR, and the package \fBbar\fR depends on \fBfoo@^1.1.0\fR, then that version of \fBbar\fR can only be installed by installing a vulnerable version of \fBfoo\fR. In this case, \fBbar\fR is a "metavulnerability". +For example, if the package \fBfoo\fR is vulnerable in the range \fB>=1.0.2 <2.0.0\fR, and the package \fBbar\fR depends on \fBfoo@^1.1.0\fR, then that version of \fBbar\fR can only be installed by installing a vulnerable version of \fBfoo\fR. In this case, \fBbar\fR is a "metavulnerability". .P Once metavulnerabilities for a given package are calculated, they are cached in the \fB~/.npm\fR 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). .P @@ -320,7 +318,7 @@ If set to false, then ignore \fBpackage-lock.json\fR files when installing. This .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -370,7 +368,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBworkspace\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-bugs.1 b/deps/npm/man/man1/npm-bugs.1 index a0f37645f76b9b..72053050d6e14f 100644 --- a/deps/npm/man/man1/npm-bugs.1 +++ b/deps/npm/man/man1/npm-bugs.1 @@ -1,4 +1,4 @@ -.TH "NPM-BUGS" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-BUGS" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-bugs\fR - Report bugs for a package in a web browser .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-cache.1 b/deps/npm/man/man1/npm-cache.1 index 449a2749b8639d..41a41ba928e1ed 100644 --- a/deps/npm/man/man1/npm-cache.1 +++ b/deps/npm/man/man1/npm-cache.1 @@ -1,4 +1,4 @@ -.TH "NPM-CACHE" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-CACHE" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-cache\fR - Manipulates packages cache .SS "Synopsis" @@ -54,8 +54,7 @@ npm will not remove data by itself: the cache will grow as new packages are inst .P 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. .P -To run an offline verification of existing cache contents, use \fBnpm cache -verify\fR. +To run an offline verification of existing cache contents, use \fBnpm cache verify\fR. .SS "Configuration" .SS "\fBcache\fR" .RS 0 diff --git a/deps/npm/man/man1/npm-ci.1 b/deps/npm/man/man1/npm-ci.1 index 90451e5d524357..87ae6170434e39 100644 --- a/deps/npm/man/man1/npm-ci.1 +++ b/deps/npm/man/man1/npm-ci.1 @@ -1,4 +1,4 @@ -.TH "NPM-CI" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-CI" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-ci\fR - Clean install a project .SS "Synopsis" @@ -103,7 +103,7 @@ Only install direct dependencies in the top level \fBnode_modules\fR, but hoist .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -167,7 +167,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBaudit\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-completion.1 b/deps/npm/man/man1/npm-completion.1 index 9dca8e7e82bf90..06e58655c486d5 100644 --- a/deps/npm/man/man1/npm-completion.1 +++ b/deps/npm/man/man1/npm-completion.1 @@ -1,4 +1,4 @@ -.TH "NPM-COMPLETION" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-COMPLETION" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-completion\fR - Tab Completion for npm .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-config.1 b/deps/npm/man/man1/npm-config.1 index 929f8a0c529721..17f27ea10b5f71 100644 --- a/deps/npm/man/man1/npm-config.1 +++ b/deps/npm/man/man1/npm-config.1 @@ -1,4 +1,4 @@ -.TH "NPM-CONFIG" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-CONFIG" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-config\fR - Manage the npm configuration files .SS "Synopsis" @@ -56,8 +56,7 @@ Echo the config value(s) to stdout. .P If multiple keys are provided, then the values will be prefixed with the key names. .P -If no keys are provided, then this command behaves the same as \fBnpm config -list\fR. +If no keys are provided, then this command behaves the same as \fBnpm config list\fR. .SS "list" .P .RS 2 diff --git a/deps/npm/man/man1/npm-dedupe.1 b/deps/npm/man/man1/npm-dedupe.1 index c3195f309ae31f..10472a8aa93446 100644 --- a/deps/npm/man/man1/npm-dedupe.1 +++ b/deps/npm/man/man1/npm-dedupe.1 @@ -1,4 +1,4 @@ -.TH "NPM-DEDUPE" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-DEDUPE" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-dedupe\fR - Reduce duplication in the package tree .SS "Synopsis" @@ -126,7 +126,7 @@ If set to false, then ignore \fBpackage-lock.json\fR files when installing. This .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -164,7 +164,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBaudit\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-deprecate.1 b/deps/npm/man/man1/npm-deprecate.1 index 653113fc5ce40a..871577b872385f 100644 --- a/deps/npm/man/man1/npm-deprecate.1 +++ b/deps/npm/man/man1/npm-deprecate.1 @@ -1,4 +1,4 @@ -.TH "NPM-DEPRECATE" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-DEPRECATE" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-deprecate\fR - Deprecate a version of a package .SS "Synopsis" @@ -55,7 +55,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "\fBdry-run\fR" diff --git a/deps/npm/man/man1/npm-diff.1 b/deps/npm/man/man1/npm-diff.1 index 2ccd6f6524bcb4..a1f2b5f2e38c78 100644 --- a/deps/npm/man/man1/npm-diff.1 +++ b/deps/npm/man/man1/npm-diff.1 @@ -1,4 +1,4 @@ -.TH "NPM-DIFF" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-DIFF" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-diff\fR - The registry diff command .SS "Synopsis" @@ -233,8 +233,8 @@ Type: String .P If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag. .P -It is the tag added to the package@version specified in the \fBnpm dist-tag -add\fR command, if no explicit tag is given. +It is the tag added to the package@version specified in the \fBnpm +dist-tag add\fR command, if no explicit tag is given. .P When used by the \fBnpm diff\fR command, this is the tag used to fetch the tarball that will be compared with the local files by default. .P diff --git a/deps/npm/man/man1/npm-dist-tag.1 b/deps/npm/man/man1/npm-dist-tag.1 index 517d90e473aa00..6defc97bdfe2af 100644 --- a/deps/npm/man/man1/npm-dist-tag.1 +++ b/deps/npm/man/man1/npm-dist-tag.1 @@ -1,4 +1,4 @@ -.TH "NPM-DIST-TAG" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-DIST-TAG" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-dist-tag\fR - Modify package distribution tags .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-docs.1 b/deps/npm/man/man1/npm-docs.1 index 391743cc879ede..602888e1d713f1 100644 --- a/deps/npm/man/man1/npm-docs.1 +++ b/deps/npm/man/man1/npm-docs.1 @@ -1,4 +1,4 @@ -.TH "NPM-DOCS" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-DOCS" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-docs\fR - Open documentation for a package in a web browser .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-doctor.1 b/deps/npm/man/man1/npm-doctor.1 index 8dd6c503306355..1f5f653bbf5ad5 100644 --- a/deps/npm/man/man1/npm-doctor.1 +++ b/deps/npm/man/man1/npm-doctor.1 @@ -1,4 +1,4 @@ -.TH "NPM-DOCTOR" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-DOCTOR" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-doctor\fR - Check the health of your npm environment .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-edit.1 b/deps/npm/man/man1/npm-edit.1 index 0093b97726b33a..19d5c537d889f6 100644 --- a/deps/npm/man/man1/npm-edit.1 +++ b/deps/npm/man/man1/npm-edit.1 @@ -1,4 +1,4 @@ -.TH "NPM-EDIT" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-EDIT" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-edit\fR - Edit an installed package .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-exec.1 b/deps/npm/man/man1/npm-exec.1 index 1825fd519529be..d6b3d384eae666 100644 --- a/deps/npm/man/man1/npm-exec.1 +++ b/deps/npm/man/man1/npm-exec.1 @@ -1,4 +1,4 @@ -.TH "NPM-EXEC" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-EXEC" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-exec\fR - Run a command from a local or remote npm package .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-explain.1 b/deps/npm/man/man1/npm-explain.1 index 7ed14c2321bcff..88f209f5ddc1b5 100644 --- a/deps/npm/man/man1/npm-explain.1 +++ b/deps/npm/man/man1/npm-explain.1 @@ -1,4 +1,4 @@ -.TH "NPM-EXPLAIN" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-EXPLAIN" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-explain\fR - Explain installed packages .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-explore.1 b/deps/npm/man/man1/npm-explore.1 index 7245ea91537d1b..b91eb6dbee5cc9 100644 --- a/deps/npm/man/man1/npm-explore.1 +++ b/deps/npm/man/man1/npm-explore.1 @@ -1,4 +1,4 @@ -.TH "NPM-EXPLORE" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-EXPLORE" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-explore\fR - Browse an installed package .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-find-dupes.1 b/deps/npm/man/man1/npm-find-dupes.1 index b7516a025ebcf8..2373a842661e3e 100644 --- a/deps/npm/man/man1/npm-find-dupes.1 +++ b/deps/npm/man/man1/npm-find-dupes.1 @@ -1,4 +1,4 @@ -.TH "NPM-FIND-DUPES" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-FIND-DUPES" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-find-dupes\fR - Find duplication in the package tree .SS "Synopsis" @@ -73,7 +73,7 @@ If set to false, then ignore \fBpackage-lock.json\fR files when installing. This .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -111,7 +111,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBaudit\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-fund.1 b/deps/npm/man/man1/npm-fund.1 index c5a1446feba01a..58eb3cd3577615 100644 --- a/deps/npm/man/man1/npm-fund.1 +++ b/deps/npm/man/man1/npm-fund.1 @@ -1,4 +1,4 @@ -.TH "NPM-FUND" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-FUND" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-fund\fR - Retrieve funding information .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-help-search.1 b/deps/npm/man/man1/npm-help-search.1 index 12e4ed3c5b5ffa..94c7dc9e7b8b2a 100644 --- a/deps/npm/man/man1/npm-help-search.1 +++ b/deps/npm/man/man1/npm-help-search.1 @@ -1,4 +1,4 @@ -.TH "NPM-HELP-SEARCH" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-HELP-SEARCH" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-help-search\fR - Search npm help documentation .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-help.1 b/deps/npm/man/man1/npm-help.1 index 23908a792935d0..0f07f5a9582fd1 100644 --- a/deps/npm/man/man1/npm-help.1 +++ b/deps/npm/man/man1/npm-help.1 @@ -1,4 +1,4 @@ -.TH "NPM-HELP" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-HELP" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-help\fR - Get help on npm .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-init.1 b/deps/npm/man/man1/npm-init.1 index bb7822a0097518..322cd28ccbb29f 100644 --- a/deps/npm/man/man1/npm-init.1 +++ b/deps/npm/man/man1/npm-init.1 @@ -1,4 +1,4 @@ -.TH "NPM-INIT" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-INIT" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-init\fR - Create a package.json file .SS "Synopsis" @@ -44,8 +44,7 @@ If the initializer is omitted (by just calling \fBnpm init\fR), init will fall b .SS "Forwarding additional options" .P -Any additional options will be passed directly to the command, so \fBnpm init -foo -- --hello\fR will map to \fBnpm exec -- create-foo --hello\fR. +Any additional options will be passed directly to the command, so \fBnpm init foo -- --hello\fR will map to \fBnpm exec -- create-foo --hello\fR. .P To better illustrate how options are forwarded, here's a more evolved example showing options passed to both the \fBnpm cli\fR and a create package, both following commands are equivalent: .RS 0 diff --git a/deps/npm/man/man1/npm-install-ci-test.1 b/deps/npm/man/man1/npm-install-ci-test.1 index f133901ca74c0d..035b5c073523de 100644 --- a/deps/npm/man/man1/npm-install-ci-test.1 +++ b/deps/npm/man/man1/npm-install-ci-test.1 @@ -1,4 +1,4 @@ -.TH "NPM-INSTALL-CI-TEST" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-INSTALL-CI-TEST" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-install-ci-test\fR - Install a project with a clean slate and run tests .SS "Synopsis" @@ -51,7 +51,7 @@ Only install direct dependencies in the top level \fBnode_modules\fR, but hoist .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -115,7 +115,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBaudit\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-install-test.1 b/deps/npm/man/man1/npm-install-test.1 index 0d26b55e26c441..fe6ae37b386184 100644 --- a/deps/npm/man/man1/npm-install-test.1 +++ b/deps/npm/man/man1/npm-install-test.1 @@ -1,4 +1,4 @@ -.TH "NPM-INSTALL-TEST" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-INSTALL-TEST" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-install-test\fR - Install package(s) and run tests .SS "Synopsis" @@ -94,7 +94,7 @@ Only install direct dependencies in the top level \fBnode_modules\fR, but hoist .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -192,7 +192,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBaudit\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-install.1 b/deps/npm/man/man1/npm-install.1 index 05ec564d08d81e..b90459ae8ce71a 100644 --- a/deps/npm/man/man1/npm-install.1 +++ b/deps/npm/man/man1/npm-install.1 @@ -1,4 +1,4 @@ -.TH "NPM-INSTALL" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-INSTALL" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-install\fR - Install a package .SS "Synopsis" @@ -89,8 +89,7 @@ Tarball requirements: .IP \(bu 4 The filename \fImust\fR use \fB.tar\fR, \fB.tar.gz\fR, or \fB.tgz\fR as the extension. .IP \(bu 4 -The package contents should reside in a subfolder inside the tarball (usually it is called \fBpackage/\fR). npm strips one directory layer when installing the package (an equivalent of \fBtar x ---strip-components=1\fR is run). +The package contents should reside in a subfolder inside the tarball (usually it is called \fBpackage/\fR). npm strips one directory layer when installing the package (an equivalent of \fBtar x --strip-components=1\fR is run). .IP \(bu 4 The package must contain a \fBpackage.json\fR file with \fBname\fR and \fBversion\fR properties. .RE 0 @@ -456,7 +455,7 @@ Only install direct dependencies in the top level \fBnode_modules\fR, but hoist .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -554,7 +553,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBaudit\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-link.1 b/deps/npm/man/man1/npm-link.1 index 6c9bac33fd2815..9850cd544a93d8 100644 --- a/deps/npm/man/man1/npm-link.1 +++ b/deps/npm/man/man1/npm-link.1 @@ -1,4 +1,4 @@ -.TH "NPM-LINK" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-LINK" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-link\fR - Symlink a package folder .SS "Synopsis" @@ -185,7 +185,7 @@ If set to false, then ignore \fBpackage-lock.json\fR files when installing. This .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -223,7 +223,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBaudit\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-login.1 b/deps/npm/man/man1/npm-login.1 index 80645f0e792742..de24dae466d3ac 100644 --- a/deps/npm/man/man1/npm-login.1 +++ b/deps/npm/man/man1/npm-login.1 @@ -1,4 +1,4 @@ -.TH "NPM-LOGIN" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-LOGIN" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-login\fR - Login to a registry user account .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-logout.1 b/deps/npm/man/man1/npm-logout.1 index 632ec468098d15..7d7624bbea3f25 100644 --- a/deps/npm/man/man1/npm-logout.1 +++ b/deps/npm/man/man1/npm-logout.1 @@ -1,4 +1,4 @@ -.TH "NPM-LOGOUT" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-LOGOUT" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-logout\fR - Log out of the registry .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-ls.1 b/deps/npm/man/man1/npm-ls.1 index 557f26281c0a71..88858109203301 100644 --- a/deps/npm/man/man1/npm-ls.1 +++ b/deps/npm/man/man1/npm-ls.1 @@ -1,4 +1,4 @@ -.TH "NPM-LS" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-LS" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-ls\fR - List installed packages .SS "Synopsis" @@ -20,7 +20,7 @@ Positional arguments are \fBname@version-range\fR identifiers, which will limit .P .RS 2 .nf -npm@11.6.1 /path/to/npm +npm@11.6.2 /path/to/npm └─┬ init-package-json@0.0.4 └── promzard@0.1.5 .fi @@ -103,7 +103,7 @@ man pages are linked to \fB{prefix}/share/man\fR .SS "\fBdepth\fR" .RS 0 .IP \(bu 4 -Default: \fBInfinity\fR if \fB--all\fR is set, otherwise \fB0\fR +Default: \fBInfinity\fR if \fB--all\fR is set; otherwise, \fB0\fR .IP \(bu 4 Type: null or Number .RE 0 @@ -115,7 +115,7 @@ If not set, \fBnpm ls\fR will show only the immediate dependencies of the root p .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 diff --git a/deps/npm/man/man1/npm-org.1 b/deps/npm/man/man1/npm-org.1 index 431c0de3d6cadf..56f6f269509a97 100644 --- a/deps/npm/man/man1/npm-org.1 +++ b/deps/npm/man/man1/npm-org.1 @@ -1,4 +1,4 @@ -.TH "NPM-ORG" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-ORG" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-org\fR - Manage orgs .SS "Synopsis" @@ -86,7 +86,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "\fBjson\fR" diff --git a/deps/npm/man/man1/npm-outdated.1 b/deps/npm/man/man1/npm-outdated.1 index 1c56d51ef64b7f..5e715d6bf25b34 100644 --- a/deps/npm/man/man1/npm-outdated.1 +++ b/deps/npm/man/man1/npm-outdated.1 @@ -1,4 +1,4 @@ -.TH "NPM-OUTDATED" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-OUTDATED" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-outdated\fR - Check for outdated packages .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-owner.1 b/deps/npm/man/man1/npm-owner.1 index 1dda6adfdfabc9..0e51922629f3ce 100644 --- a/deps/npm/man/man1/npm-owner.1 +++ b/deps/npm/man/man1/npm-owner.1 @@ -1,4 +1,4 @@ -.TH "NPM-OWNER" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-OWNER" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-owner\fR - Manage package owners .SS "Synopsis" @@ -48,7 +48,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "\fBworkspace\fR" diff --git a/deps/npm/man/man1/npm-pack.1 b/deps/npm/man/man1/npm-pack.1 index 03b1824a6179b5..52d7feb68d94d5 100644 --- a/deps/npm/man/man1/npm-pack.1 +++ b/deps/npm/man/man1/npm-pack.1 @@ -1,4 +1,4 @@ -.TH "NPM-PACK" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-PACK" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-pack\fR - Create a tarball from a package .SS "Synopsis" @@ -117,7 +117,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "Description" .P For anything that's installable (that is, a package folder, tarball, tarball url, git url, name@tag, name@version, name, or scoped name), this command will fetch it to the cache, copy the tarball to the current working directory as \fB-.tgz\fR, and then write the filenames out to stdout. diff --git a/deps/npm/man/man1/npm-ping.1 b/deps/npm/man/man1/npm-ping.1 index af027e7dc3ed1d..7a686e9fff0539 100644 --- a/deps/npm/man/man1/npm-ping.1 +++ b/deps/npm/man/man1/npm-ping.1 @@ -1,4 +1,4 @@ -.TH "NPM-PING" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-PING" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-ping\fR - Ping npm registry .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-pkg.1 b/deps/npm/man/man1/npm-pkg.1 index bee53e1f798344..4940be8a413210 100644 --- a/deps/npm/man/man1/npm-pkg.1 +++ b/deps/npm/man/man1/npm-pkg.1 @@ -1,4 +1,4 @@ -.TH "NPM-PKG" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-PKG" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-pkg\fR - Manages your package.json .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-prefix.1 b/deps/npm/man/man1/npm-prefix.1 index ebc2b9ce98bb7b..b0c93b019644fd 100644 --- a/deps/npm/man/man1/npm-prefix.1 +++ b/deps/npm/man/man1/npm-prefix.1 @@ -1,4 +1,4 @@ -.TH "NPM-PREFIX" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-PREFIX" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-prefix\fR - Display prefix .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-profile.1 b/deps/npm/man/man1/npm-profile.1 index 6abf67a7b5b36c..0e53039daf0625 100644 --- a/deps/npm/man/man1/npm-profile.1 +++ b/deps/npm/man/man1/npm-profile.1 @@ -1,4 +1,4 @@ -.TH "NPM-PROFILE" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-PROFILE" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-profile\fR - Change settings on your registry profile .SS "Synopsis" @@ -104,7 +104,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "See Also" diff --git a/deps/npm/man/man1/npm-prune.1 b/deps/npm/man/man1/npm-prune.1 index 47a281ae786433..8f139fd2f4df9c 100644 --- a/deps/npm/man/man1/npm-prune.1 +++ b/deps/npm/man/man1/npm-prune.1 @@ -1,4 +1,4 @@ -.TH "NPM-PRUNE" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-PRUNE" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-prune\fR - Remove extraneous packages .SS "Synopsis" @@ -25,7 +25,7 @@ In normal operation, extraneous modules are pruned automatically, so you'll only .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -104,7 +104,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBworkspace\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-publish.1 b/deps/npm/man/man1/npm-publish.1 index 53d1e835d91f4a..96be016f9fdacf 100644 --- a/deps/npm/man/man1/npm-publish.1 +++ b/deps/npm/man/man1/npm-publish.1 @@ -1,4 +1,4 @@ -.TH "NPM-PUBLISH" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-PUBLISH" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-publish\fR - Publish a package .SS "Synopsis" @@ -74,8 +74,8 @@ Type: String .P If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag. .P -It is the tag added to the package@version specified in the \fBnpm dist-tag -add\fR command, if no explicit tag is given. +It is the tag added to the package@version specified in the \fBnpm +dist-tag add\fR command, if no explicit tag is given. .P When used by the \fBnpm diff\fR command, this is the tag used to fetch the tarball that will be compared with the local files by default. .P @@ -91,10 +91,9 @@ Type: null, "restricted", or "public" .P If you do not want your scoped package to be publicly viewable (and installable) set \fB--access=restricted\fR. .P -Unscoped packages can not be set to \fBrestricted\fR. +Unscoped packages cannot be set to \fBrestricted\fR. .P -Note: This defaults to not changing the current access level for existing packages. Specifying a value of \fBrestricted\fR or \fBpublic\fR during publish will change the access for an existing package the same way that \fBnpm access set -status\fR would. +Note: This defaults to not changing the current access level for existing packages. Specifying a value of \fBrestricted\fR or \fBpublic\fR during publish will change the access for an existing package the same way that \fBnpm access set status\fR would. .SS "\fBdry-run\fR" .RS 0 .IP \(bu 4 @@ -116,7 +115,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "\fBworkspace\fR" @@ -188,7 +188,7 @@ Type: Boolean .P When publishing from a supported cloud CI/CD system, the package will be publicly linked to where it was built and published from. .P -This config can not be used with: \fBprovenance-file\fR +This config cannot be used with: \fBprovenance-file\fR .SS "\fBprovenance-file\fR" .RS 0 .IP \(bu 4 @@ -200,7 +200,7 @@ Type: Path .P When publishing, the provenance bundle at the given path will be used. .P -This config can not be used with: \fBprovenance\fR +This config cannot be used with: \fBprovenance\fR .SS "See Also" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-query.1 b/deps/npm/man/man1/npm-query.1 index 2a7979abdf1262..7e626c7f1d4a6a 100644 --- a/deps/npm/man/man1/npm-query.1 +++ b/deps/npm/man/man1/npm-query.1 @@ -1,4 +1,4 @@ -.TH "NPM-QUERY" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-QUERY" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-query\fR - Dependency selector query .SS "Synopsis" @@ -261,7 +261,7 @@ Type: null or Boolean .P Tells npm whether or not to expect results from the command. Can be either true (expect some results) or false (expect no results). .P -This config can not be used with: \fBexpect-result-count\fR +This config cannot be used with: \fBexpect-result-count\fR .SS "\fBexpect-result-count\fR" .RS 0 .IP \(bu 4 @@ -273,7 +273,7 @@ Type: null or Number .P Tells to expect a specific number of results from the command. .P -This config can not be used with: \fBexpect-results\fR +This config cannot be used with: \fBexpect-results\fR .SH "SEE ALSO" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-rebuild.1 b/deps/npm/man/man1/npm-rebuild.1 index 37118ff5eff873..dcd4dfb91210d9 100644 --- a/deps/npm/man/man1/npm-rebuild.1 +++ b/deps/npm/man/man1/npm-rebuild.1 @@ -1,4 +1,4 @@ -.TH "NPM-REBUILD" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-REBUILD" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-rebuild\fR - Rebuild a package .SS "Synopsis" @@ -100,7 +100,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBworkspace\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-repo.1 b/deps/npm/man/man1/npm-repo.1 index ea769172fcfc45..634e6358838e0c 100644 --- a/deps/npm/man/man1/npm-repo.1 +++ b/deps/npm/man/man1/npm-repo.1 @@ -1,4 +1,4 @@ -.TH "NPM-REPO" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-REPO" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-repo\fR - Open package repository page in the browser .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-restart.1 b/deps/npm/man/man1/npm-restart.1 index 6276579767f68d..837fffcfd05d92 100644 --- a/deps/npm/man/man1/npm-restart.1 +++ b/deps/npm/man/man1/npm-restart.1 @@ -1,4 +1,4 @@ -.TH "NPM-RESTART" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-RESTART" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-restart\fR - Restart a package .SS "Synopsis" @@ -10,8 +10,7 @@ npm restart \[lB]-- \[rB] .RE .SS "Description" .P -This restarts a project. It is equivalent to running \fBnpm run -restart\fR. +This restarts a project. It is equivalent to running \fBnpm run restart\fR. .P If the current project has a \fB"restart"\fR script specified in \fBpackage.json\fR, then the following scripts will be run: .RS 0 @@ -56,7 +55,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBscript-shell\fR" .RS 0 .IP \(bu 4 @@ -66,8 +66,7 @@ Type: null or String .RE 0 .P -The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm -init \fR commands. +The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm init \fR commands. .SS "See Also" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-root.1 b/deps/npm/man/man1/npm-root.1 index 22f05c83006733..97d5c3f868dc06 100644 --- a/deps/npm/man/man1/npm-root.1 +++ b/deps/npm/man/man1/npm-root.1 @@ -1,4 +1,4 @@ -.TH "NPM-ROOT" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-ROOT" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-root\fR - Display npm root .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-run.1 b/deps/npm/man/man1/npm-run.1 index 37f2b94db90ae3..a1834d3d2bc2df 100644 --- a/deps/npm/man/man1/npm-run.1 +++ b/deps/npm/man/man1/npm-run.1 @@ -1,4 +1,4 @@ -.TH "NPM-RUN" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-RUN" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-run\fR - Run arbitrary package scripts .SS "Synopsis" @@ -191,7 +191,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBforeground-scripts\fR" .RS 0 .IP \(bu 4 @@ -213,8 +214,7 @@ Type: null or String .RE 0 .P -The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm -init \fR commands. +The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm init \fR commands. .SS "See Also" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-sbom.1 b/deps/npm/man/man1/npm-sbom.1 index 99895e597a9034..11212d9653b5b0 100644 --- a/deps/npm/man/man1/npm-sbom.1 +++ b/deps/npm/man/man1/npm-sbom.1 @@ -1,4 +1,4 @@ -.TH "NPM-SBOM" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-SBOM" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-sbom\fR - Generate a Software Bill of Materials (SBOM) .SS "Synopsis" @@ -210,7 +210,7 @@ If package-lock-only is enabled, only the information in the package lock (or sh .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 diff --git a/deps/npm/man/man1/npm-search.1 b/deps/npm/man/man1/npm-search.1 index c7701b19518960..0fb57fafd4512e 100644 --- a/deps/npm/man/man1/npm-search.1 +++ b/deps/npm/man/man1/npm-search.1 @@ -1,4 +1,4 @@ -.TH "NPM-SEARCH" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-SEARCH" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-search\fR - Search for packages .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-shrinkwrap.1 b/deps/npm/man/man1/npm-shrinkwrap.1 index 216e4df5036ff6..c47c6b76bc0e8a 100644 --- a/deps/npm/man/man1/npm-shrinkwrap.1 +++ b/deps/npm/man/man1/npm-shrinkwrap.1 @@ -1,4 +1,4 @@ -.TH "NPM-SHRINKWRAP" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-SHRINKWRAP" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-shrinkwrap\fR - Lock down dependency versions for publication .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-star.1 b/deps/npm/man/man1/npm-star.1 index 09f8bde7e337ee..2f137195aa92c7 100644 --- a/deps/npm/man/man1/npm-star.1 +++ b/deps/npm/man/man1/npm-star.1 @@ -1,4 +1,4 @@ -.TH "NPM-STAR" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-STAR" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-star\fR - Mark your favorite packages .SS "Synopsis" @@ -56,7 +56,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "See Also" diff --git a/deps/npm/man/man1/npm-stars.1 b/deps/npm/man/man1/npm-stars.1 index 8c69445640801b..8c0533aadfb997 100644 --- a/deps/npm/man/man1/npm-stars.1 +++ b/deps/npm/man/man1/npm-stars.1 @@ -1,4 +1,4 @@ -.TH "NPM-STARS" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-STARS" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-stars\fR - View packages marked as favorites .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-start.1 b/deps/npm/man/man1/npm-start.1 index eb91c8177e3f68..c9c55e4ec6ee3c 100644 --- a/deps/npm/man/man1/npm-start.1 +++ b/deps/npm/man/man1/npm-start.1 @@ -1,4 +1,4 @@ -.TH "NPM-START" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-START" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-start\fR - Start a package .SS "Synopsis" @@ -52,7 +52,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBscript-shell\fR" .RS 0 .IP \(bu 4 @@ -62,8 +63,7 @@ Type: null or String .RE 0 .P -The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm -init \fR commands. +The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm init \fR commands. .SS "See Also" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-stop.1 b/deps/npm/man/man1/npm-stop.1 index dbc1f1f16d5d52..da49dd07de80a6 100644 --- a/deps/npm/man/man1/npm-stop.1 +++ b/deps/npm/man/man1/npm-stop.1 @@ -1,4 +1,4 @@ -.TH "NPM-STOP" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-STOP" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-stop\fR - Stop a package .SS "Synopsis" @@ -48,7 +48,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBscript-shell\fR" .RS 0 .IP \(bu 4 @@ -58,8 +59,7 @@ Type: null or String .RE 0 .P -The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm -init \fR commands. +The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm init \fR commands. .SS "See Also" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-team.1 b/deps/npm/man/man1/npm-team.1 index 88f0205530afd5..e4c885229a41d7 100644 --- a/deps/npm/man/man1/npm-team.1 +++ b/deps/npm/man/man1/npm-team.1 @@ -1,4 +1,4 @@ -.TH "NPM-TEAM" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-TEAM" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-team\fR - Manage organization teams and team memberships .SS "Synopsis" @@ -107,7 +107,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "\fBparseable\fR" diff --git a/deps/npm/man/man1/npm-test.1 b/deps/npm/man/man1/npm-test.1 index 6c820c26e24b5b..d233bd2c54ccd8 100644 --- a/deps/npm/man/man1/npm-test.1 +++ b/deps/npm/man/man1/npm-test.1 @@ -1,4 +1,4 @@ -.TH "NPM-TEST" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-TEST" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-test\fR - Test a package .SS "Synopsis" @@ -46,7 +46,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBscript-shell\fR" .RS 0 .IP \(bu 4 @@ -56,8 +57,7 @@ Type: null or String .RE 0 .P -The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm -init \fR commands. +The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm init \fR commands. .SS "See Also" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-token.1 b/deps/npm/man/man1/npm-token.1 index e54db32f19f7ae..e1005725bdcf74 100644 --- a/deps/npm/man/man1/npm-token.1 +++ b/deps/npm/man/man1/npm-token.1 @@ -1,4 +1,4 @@ -.TH "NPM-TOKEN" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-TOKEN" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-token\fR - Manage your authentication tokens .SS "Synopsis" @@ -36,7 +36,7 @@ Publish token npm_… with id e0cf92 created 2017-10-02 .IP \(bu 4 \fBnpm token create \[lB]--read-only\[rB] \[lB]--cidr=\[rB]\fR: Create a new authentication token. It can be \fB--read-only\fR, or accept a list of \fBCIDR\fR \fI\(lahttps://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing\(ra\fR ranges with which to limit use of this token. This will prompt you for your password, and, if you have two-factor authentication enabled, an otp. .P -Currently, the cli can not generate automation tokens. Please refer to the \fBdocs website\fR \fI\(lahttps://docs.npmjs.com/creating-and-viewing-access-tokens\(ra\fR for more information on generating automation tokens. +Currently, the cli cannot generate automation tokens. Please refer to the \fBdocs website\fR \fI\(lahttps://docs.npmjs.com/creating-and-viewing-access-tokens\(ra\fR for more information on generating automation tokens. .RE 0 .P @@ -90,7 +90,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "See Also" diff --git a/deps/npm/man/man1/npm-undeprecate.1 b/deps/npm/man/man1/npm-undeprecate.1 index a7f221f3ba62a6..2593ba2bb3adf9 100644 --- a/deps/npm/man/man1/npm-undeprecate.1 +++ b/deps/npm/man/man1/npm-undeprecate.1 @@ -1,4 +1,4 @@ -.TH "NPM-UNDEPRECATE" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-UNDEPRECATE" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-undeprecate\fR - Undeprecate a version of a package .SS "Synopsis" @@ -35,7 +35,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "\fBdry-run\fR" diff --git a/deps/npm/man/man1/npm-uninstall.1 b/deps/npm/man/man1/npm-uninstall.1 index 7d9883a5ec60cd..9a3713bba4051e 100644 --- a/deps/npm/man/man1/npm-uninstall.1 +++ b/deps/npm/man/man1/npm-uninstall.1 @@ -1,4 +1,4 @@ -.TH "NPM-UNINSTALL" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-UNINSTALL" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-uninstall\fR - Remove a package .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-unpublish.1 b/deps/npm/man/man1/npm-unpublish.1 index c6b18f4b8f0e6a..eb8073bf3575d7 100644 --- a/deps/npm/man/man1/npm-unpublish.1 +++ b/deps/npm/man/man1/npm-unpublish.1 @@ -1,4 +1,4 @@ -.TH "NPM-UNPUBLISH" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-UNPUBLISH" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-unpublish\fR - Remove a package from the registry .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-unstar.1 b/deps/npm/man/man1/npm-unstar.1 index 5a51910e491f14..3c0fd6a17d546d 100644 --- a/deps/npm/man/man1/npm-unstar.1 +++ b/deps/npm/man/man1/npm-unstar.1 @@ -1,4 +1,4 @@ -.TH "NPM-UNSTAR" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-UNSTAR" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-unstar\fR - Remove an item from your favorite packages .SS "Synopsis" @@ -52,7 +52,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "See Also" diff --git a/deps/npm/man/man1/npm-update.1 b/deps/npm/man/man1/npm-update.1 index 603efc2c223453..50eaa09ef1a2de 100644 --- a/deps/npm/man/man1/npm-update.1 +++ b/deps/npm/man/man1/npm-update.1 @@ -1,4 +1,4 @@ -.TH "NPM-UPDATE" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-UPDATE" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-update\fR - Update packages .SS "Synopsis" @@ -202,7 +202,7 @@ Only install direct dependencies in the top level \fBnode_modules\fR, but hoist .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -276,7 +276,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBaudit\fR" .RS 0 .IP \(bu 4 diff --git a/deps/npm/man/man1/npm-version.1 b/deps/npm/man/man1/npm-version.1 index 0556b29f56cf59..4d467c1682102b 100644 --- a/deps/npm/man/man1/npm-version.1 +++ b/deps/npm/man/man1/npm-version.1 @@ -1,4 +1,4 @@ -.TH "NPM-VERSION" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-VERSION" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-version\fR - Bump a package version .SS "Synopsis" @@ -171,16 +171,14 @@ If the \fB\[rs]fBsign-git-tag\[rs]fR config\fR \fI\(la/using-npm/config#sign-git $ npm config set sign-git-tag true $ npm version patch -You need a passphrase to unlock the secret key for -user: "isaacs (http://blog.izs.me/) " +You need a passphrase to unlock the secret key for user: "isaacs (http://blog.izs.me/) " 2048-bit RSA key, ID 6C481CF6, created 2010-08-31 Enter passphrase: .fi .RE .P -If \fBpreversion\fR, \fBversion\fR, or \fBpostversion\fR are in the \fBscripts\fR property of the package.json, they will be executed as part of running \fBnpm -version\fR. +If \fBpreversion\fR, \fBversion\fR, or \fBpostversion\fR are in the \fBscripts\fR property of the package.json, they will be executed as part of running \fBnpm version\fR. .P The exact order of execution is as follows: .RS 0 diff --git a/deps/npm/man/man1/npm-view.1 b/deps/npm/man/man1/npm-view.1 index f4b889423f1297..63c57ffa7156bc 100644 --- a/deps/npm/man/man1/npm-view.1 +++ b/deps/npm/man/man1/npm-view.1 @@ -1,4 +1,4 @@ -.TH "NPM-VIEW" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-VIEW" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-view\fR - View registry info .SS "Synopsis" diff --git a/deps/npm/man/man1/npm-whoami.1 b/deps/npm/man/man1/npm-whoami.1 index e936ae88762316..0a316e3a3fc72f 100644 --- a/deps/npm/man/man1/npm-whoami.1 +++ b/deps/npm/man/man1/npm-whoami.1 @@ -1,4 +1,4 @@ -.TH "NPM-WHOAMI" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM-WHOAMI" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-whoami\fR - Display npm username .SS "Synopsis" diff --git a/deps/npm/man/man1/npm.1 b/deps/npm/man/man1/npm.1 index 41c965a58b04d8..cda18c5f71c59c 100644 --- a/deps/npm/man/man1/npm.1 +++ b/deps/npm/man/man1/npm.1 @@ -1,4 +1,4 @@ -.TH "NPM" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPM" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm\fR - javascript package manager .SS "Synopsis" @@ -12,7 +12,7 @@ npm Note: This command is unaware of workspaces. .SS "Version" .P -11.6.1 +11.6.2 .SS "Description" .P npm is the package manager for the Node JavaScript platform. It puts modules in place so that node can find them, and manages dependency conflicts intelligently. @@ -86,7 +86,7 @@ Defaults: npm's default configuration options are defined in \fBlib/utils/config .RE 0 .P -See npm help config for much much more information. +See npm help config for much, much, more information. .SS "Contributions" .P Patches welcome! diff --git a/deps/npm/man/man1/npx.1 b/deps/npm/man/man1/npx.1 index 2aee2877364272..a862e5d6e8b2b6 100644 --- a/deps/npm/man/man1/npx.1 +++ b/deps/npm/man/man1/npx.1 @@ -1,4 +1,4 @@ -.TH "NPX" "1" "September 2025" "NPM@11.6.1" "" +.TH "NPX" "1" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpx\fR - Run a command from a local or remote npm package .SS "Synopsis" diff --git a/deps/npm/man/man5/folders.5 b/deps/npm/man/man5/folders.5 index 7f060a08694192..e6b255cef3eda8 100644 --- a/deps/npm/man/man5/folders.5 +++ b/deps/npm/man/man5/folders.5 @@ -1,4 +1,4 @@ -.TH "FOLDERS" "5" "September 2025" "NPM@11.6.1" "" +.TH "FOLDERS" "5" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBfolders\fR - Folder Structures Used by npm .SS "Description" diff --git a/deps/npm/man/man5/install.5 b/deps/npm/man/man5/install.5 index 1f8e1fcbc6de70..2864350ce80d94 100644 --- a/deps/npm/man/man5/install.5 +++ b/deps/npm/man/man5/install.5 @@ -1,4 +1,4 @@ -.TH "INSTALL" "5" "September 2025" "NPM@11.6.1" "" +.TH "INSTALL" "5" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBinstall\fR - Download and install node and npm .SS "Description" diff --git a/deps/npm/man/man5/npm-global.5 b/deps/npm/man/man5/npm-global.5 index 7f060a08694192..e6b255cef3eda8 100644 --- a/deps/npm/man/man5/npm-global.5 +++ b/deps/npm/man/man5/npm-global.5 @@ -1,4 +1,4 @@ -.TH "FOLDERS" "5" "September 2025" "NPM@11.6.1" "" +.TH "FOLDERS" "5" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBfolders\fR - Folder Structures Used by npm .SS "Description" diff --git a/deps/npm/man/man5/npm-json.5 b/deps/npm/man/man5/npm-json.5 index e0c8caa855aa9b..c12aa8fe3b1b31 100644 --- a/deps/npm/man/man5/npm-json.5 +++ b/deps/npm/man/man5/npm-json.5 @@ -1,4 +1,4 @@ -.TH "PACKAGE.JSON" "5" "September 2025" "NPM@11.6.1" "" +.TH "PACKAGE.JSON" "5" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBpackage.json\fR - Specifics of npm's package.json handling .SS "Description" @@ -341,7 +341,7 @@ Most of these ignored files can be included specifically if included in the \fBf .RE 0 .P -These can not be included. +These cannot be included. .SS "exports" .P The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package. For more details see the \fBnode.js documentation on package entry points\fR \fI\(lahttps://nodejs.org/api/packages.html#package-entry-points\(ra\fR @@ -403,7 +403,7 @@ would be the same as this: .fi .RE .P -Please make sure that your file(s) referenced in \fBbin\fR starts with \fB#!/usr/bin/env node\fR, otherwise the scripts are started without the node executable! +Please make sure that your file(s) referenced in \fBbin\fR starts with \fB#!/usr/bin/env node\fR; otherwise, the scripts are started without the node executable! .P Note that you can also set the executable files using \fI(directories.bin)\fR. .P @@ -426,8 +426,7 @@ If only a single file is provided, then it's installed such that it is the resul .fi .RE .P -would link the \fB./man/doc.1\fR file in such that it is the target for \fBman -foo\fR +would link the \fB./man/doc.1\fR file in such that it is the target for \fBman foo\fR .P If the filename doesn't start with the package name, then it's prefixed. So, this: .P @@ -689,8 +688,7 @@ As of version 1.1.65, you can refer to GitHub URLs as just "foo": "user/foo-proj .RE .SS "Local Paths" .P -As of version 2.0.0 you can provide a path to a local directory that contains a package. Local paths can be saved using \fBnpm install -S\fR or \fBnpm -install --save\fR, using any of these forms: +As of version 2.0.0 you can provide a path to a local directory that contains a package. Local paths can be saved using \fBnpm install -S\fR or \fBnpm install --save\fR, using any of these forms: .P .RS 2 .nf @@ -765,8 +763,7 @@ For example: .fi .RE .P -This ensures your package \fB@npm/tea-latte\fR can be installed \fIalong\fR with the second major version of the host package \fB@npm/tea\fR only. \fBnpm install -tea-latte\fR could possibly yield the following dependency graph: +This ensures your package \fB@npm/tea-latte\fR can be installed \fIalong\fR with the second major version of the host package \fB@npm/tea\fR only. \fBnpm install tea-latte\fR could possibly yield the following dependency graph: .P .RS 2 .nf @@ -826,16 +823,14 @@ If we define a package.json like this: .fi .RE .P -we can obtain \fB@npm/awesome-web-framework-1.0.0.tgz\fR file by running \fBnpm pack\fR. This file contains the dependencies \fB@npm/renderized\fR and \fB@npm/super-streams\fR which can be installed in a new project by executing \fBnpm install -awesome-web-framework-1.0.0.tgz\fR. Note that the package names do not include any versions, as that information is specified in \fBdependencies\fR. +we can obtain \fB@npm/awesome-web-framework-1.0.0.tgz\fR file by running \fBnpm pack\fR. This file contains the dependencies \fB@npm/renderized\fR and \fB@npm/super-streams\fR which can be installed in a new project by executing \fBnpm install awesome-web-framework-1.0.0.tgz\fR. Note that the package names do not include any versions, as that information is specified in \fBdependencies\fR. .P If this is spelled \fB"bundledDependencies"\fR, then that is also honored. .P Alternatively, \fB"bundleDependencies"\fR can be defined as a boolean value. A value of \fBtrue\fR will bundle all dependencies, a value of \fBfalse\fR will bundle none. .SS "optionalDependencies" .P -If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the \fBoptionalDependencies\fR object. This is a map of package name to version or URL, just like the \fBdependencies\fR object. The difference is that build failures do not cause installation to fail. Running \fBnpm install ---omit=optional\fR will prevent these dependencies from being installed. +If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the \fBoptionalDependencies\fR object. This is a map of package name to version or URL, just like the \fBdependencies\fR object. The difference is that build failures do not cause installation to fail. Running \fBnpm install --omit=optional\fR will prevent these dependencies from being installed. .P It is still your program's responsibility to handle the lack of the dependency. For example, something like this: .P @@ -1067,7 +1062,7 @@ The \fBdevEngines\fR field aids engineers working on a codebase to all be using You can specify a \fBdevEngines\fR property in your \fBpackage.json\fR which will run before \fBinstall\fR, \fBci\fR, and \fBrun\fR commands. .RS 0 .P -Note: \fBengines\fR and \fBdevEngines\fR differ in object shape. They also function very differently. \fBengines\fR is designed to alert the user when a dependency uses a differening npm or node version that the project it's being used in, whereas \fBdevEngines\fR is used to alert people interacting with the source code of a project. +Note: \fBengines\fR and \fBdevEngines\fR differ in object shape. They also function very differently. \fBengines\fR is designed to alert the user when a dependency uses a different npm or node version than the project it's being used in, whereas \fBdevEngines\fR is used to alert people interacting with the source code of a project. .RE 0 .P diff --git a/deps/npm/man/man5/npm-shrinkwrap-json.5 b/deps/npm/man/man5/npm-shrinkwrap-json.5 index 88276bd45cd8a3..b4b8cee1b390f5 100644 --- a/deps/npm/man/man5/npm-shrinkwrap-json.5 +++ b/deps/npm/man/man5/npm-shrinkwrap-json.5 @@ -1,4 +1,4 @@ -.TH "NPM-SHRINKWRAP.JSON" "5" "September 2025" "NPM@11.6.1" "" +.TH "NPM-SHRINKWRAP.JSON" "5" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpm-shrinkwrap.json\fR - A publishable lockfile .SS "Description" diff --git a/deps/npm/man/man5/npmrc.5 b/deps/npm/man/man5/npmrc.5 index 7f37d076b964a2..1d50198b83e0ab 100644 --- a/deps/npm/man/man5/npmrc.5 +++ b/deps/npm/man/man5/npmrc.5 @@ -1,4 +1,4 @@ -.TH "NPMRC" "5" "September 2025" "NPM@11.6.1" "" +.TH "NPMRC" "5" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBnpmrc\fR - The npm config files .SS "Description" diff --git a/deps/npm/man/man5/package-json.5 b/deps/npm/man/man5/package-json.5 index e0c8caa855aa9b..c12aa8fe3b1b31 100644 --- a/deps/npm/man/man5/package-json.5 +++ b/deps/npm/man/man5/package-json.5 @@ -1,4 +1,4 @@ -.TH "PACKAGE.JSON" "5" "September 2025" "NPM@11.6.1" "" +.TH "PACKAGE.JSON" "5" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBpackage.json\fR - Specifics of npm's package.json handling .SS "Description" @@ -341,7 +341,7 @@ Most of these ignored files can be included specifically if included in the \fBf .RE 0 .P -These can not be included. +These cannot be included. .SS "exports" .P The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package. For more details see the \fBnode.js documentation on package entry points\fR \fI\(lahttps://nodejs.org/api/packages.html#package-entry-points\(ra\fR @@ -403,7 +403,7 @@ would be the same as this: .fi .RE .P -Please make sure that your file(s) referenced in \fBbin\fR starts with \fB#!/usr/bin/env node\fR, otherwise the scripts are started without the node executable! +Please make sure that your file(s) referenced in \fBbin\fR starts with \fB#!/usr/bin/env node\fR; otherwise, the scripts are started without the node executable! .P Note that you can also set the executable files using \fI(directories.bin)\fR. .P @@ -426,8 +426,7 @@ If only a single file is provided, then it's installed such that it is the resul .fi .RE .P -would link the \fB./man/doc.1\fR file in such that it is the target for \fBman -foo\fR +would link the \fB./man/doc.1\fR file in such that it is the target for \fBman foo\fR .P If the filename doesn't start with the package name, then it's prefixed. So, this: .P @@ -689,8 +688,7 @@ As of version 1.1.65, you can refer to GitHub URLs as just "foo": "user/foo-proj .RE .SS "Local Paths" .P -As of version 2.0.0 you can provide a path to a local directory that contains a package. Local paths can be saved using \fBnpm install -S\fR or \fBnpm -install --save\fR, using any of these forms: +As of version 2.0.0 you can provide a path to a local directory that contains a package. Local paths can be saved using \fBnpm install -S\fR or \fBnpm install --save\fR, using any of these forms: .P .RS 2 .nf @@ -765,8 +763,7 @@ For example: .fi .RE .P -This ensures your package \fB@npm/tea-latte\fR can be installed \fIalong\fR with the second major version of the host package \fB@npm/tea\fR only. \fBnpm install -tea-latte\fR could possibly yield the following dependency graph: +This ensures your package \fB@npm/tea-latte\fR can be installed \fIalong\fR with the second major version of the host package \fB@npm/tea\fR only. \fBnpm install tea-latte\fR could possibly yield the following dependency graph: .P .RS 2 .nf @@ -826,16 +823,14 @@ If we define a package.json like this: .fi .RE .P -we can obtain \fB@npm/awesome-web-framework-1.0.0.tgz\fR file by running \fBnpm pack\fR. This file contains the dependencies \fB@npm/renderized\fR and \fB@npm/super-streams\fR which can be installed in a new project by executing \fBnpm install -awesome-web-framework-1.0.0.tgz\fR. Note that the package names do not include any versions, as that information is specified in \fBdependencies\fR. +we can obtain \fB@npm/awesome-web-framework-1.0.0.tgz\fR file by running \fBnpm pack\fR. This file contains the dependencies \fB@npm/renderized\fR and \fB@npm/super-streams\fR which can be installed in a new project by executing \fBnpm install awesome-web-framework-1.0.0.tgz\fR. Note that the package names do not include any versions, as that information is specified in \fBdependencies\fR. .P If this is spelled \fB"bundledDependencies"\fR, then that is also honored. .P Alternatively, \fB"bundleDependencies"\fR can be defined as a boolean value. A value of \fBtrue\fR will bundle all dependencies, a value of \fBfalse\fR will bundle none. .SS "optionalDependencies" .P -If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the \fBoptionalDependencies\fR object. This is a map of package name to version or URL, just like the \fBdependencies\fR object. The difference is that build failures do not cause installation to fail. Running \fBnpm install ---omit=optional\fR will prevent these dependencies from being installed. +If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the \fBoptionalDependencies\fR object. This is a map of package name to version or URL, just like the \fBdependencies\fR object. The difference is that build failures do not cause installation to fail. Running \fBnpm install --omit=optional\fR will prevent these dependencies from being installed. .P It is still your program's responsibility to handle the lack of the dependency. For example, something like this: .P @@ -1067,7 +1062,7 @@ The \fBdevEngines\fR field aids engineers working on a codebase to all be using You can specify a \fBdevEngines\fR property in your \fBpackage.json\fR which will run before \fBinstall\fR, \fBci\fR, and \fBrun\fR commands. .RS 0 .P -Note: \fBengines\fR and \fBdevEngines\fR differ in object shape. They also function very differently. \fBengines\fR is designed to alert the user when a dependency uses a differening npm or node version that the project it's being used in, whereas \fBdevEngines\fR is used to alert people interacting with the source code of a project. +Note: \fBengines\fR and \fBdevEngines\fR differ in object shape. They also function very differently. \fBengines\fR is designed to alert the user when a dependency uses a different npm or node version than the project it's being used in, whereas \fBdevEngines\fR is used to alert people interacting with the source code of a project. .RE 0 .P diff --git a/deps/npm/man/man5/package-lock-json.5 b/deps/npm/man/man5/package-lock-json.5 index b726375c1509e6..3bbf561cce657e 100644 --- a/deps/npm/man/man5/package-lock-json.5 +++ b/deps/npm/man/man5/package-lock-json.5 @@ -1,4 +1,4 @@ -.TH "PACKAGE-LOCK.JSON" "5" "September 2025" "NPM@11.6.1" "" +.TH "PACKAGE-LOCK.JSON" "5" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBpackage-lock.json\fR - A manifestation of the manifest .SS "Description" diff --git a/deps/npm/man/man7/config.7 b/deps/npm/man/man7/config.7 index 5419ab1b750532..3703e0634686b9 100644 --- a/deps/npm/man/man7/config.7 +++ b/deps/npm/man/man7/config.7 @@ -1,4 +1,4 @@ -.TH "CONFIG" "7" "September 2025" "NPM@11.6.1" "" +.TH "CONFIG" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBconfig\fR - More than you probably want to know about npm configuration .SS "Description" @@ -165,10 +165,9 @@ Type: null, "restricted", or "public" .P If you do not want your scoped package to be publicly viewable (and installable) set \fB--access=restricted\fR. .P -Unscoped packages can not be set to \fBrestricted\fR. +Unscoped packages cannot be set to \fBrestricted\fR. .P -Note: This defaults to not changing the current access level for existing packages. Specifying a value of \fBrestricted\fR or \fBpublic\fR during publish will change the access for an existing package the same way that \fBnpm access set -status\fR would. +Note: This defaults to not changing the current access level for existing packages. Specifying a value of \fBrestricted\fR or \fBpublic\fR during publish will change the access for an existing package the same way that \fBnpm access set status\fR would. .SS "\fBall\fR" .RS 0 .IP \(bu 4 @@ -365,7 +364,7 @@ Override CPU architecture of native modules to install. Acceptable values are sa .SS "\fBdepth\fR" .RS 0 .IP \(bu 4 -Default: \fBInfinity\fR if \fB--all\fR is set, otherwise \fB0\fR +Default: \fBInfinity\fR if \fB--all\fR is set; otherwise, \fB0\fR .IP \(bu 4 Type: null or Number .RE 0 @@ -511,7 +510,7 @@ Type: null or Number .P Tells to expect a specific number of results from the command. .P -This config can not be used with: \fBexpect-results\fR +This config cannot be used with: \fBexpect-results\fR .SS "\fBexpect-results\fR" .RS 0 .IP \(bu 4 @@ -523,7 +522,7 @@ Type: null or Boolean .P Tells npm whether or not to expect results from the command. Can be either true (expect some results) or false (expect no results). .P -This config can not be used with: \fBexpect-result-count\fR +This config cannot be used with: \fBexpect-result-count\fR .SS "\fBfetch-retries\fR" .RS 0 .IP \(bu 4 @@ -737,7 +736,8 @@ Type: Boolean .P If true, npm does not run scripts specified in package.json files. .P -Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. +Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm +run\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts. .SS "\fBinclude\fR" .RS 0 .IP \(bu 4 @@ -965,7 +965,7 @@ man pages are linked to \fB{prefix}/share/man\fR .SS "\fBlockfile-version\fR" .RS 0 .IP \(bu 4 -Default: Version 3 if no lockfile, auto-converting v1 lockfiles to v3, otherwise maintain current lockfile version. +Default: Version 3 if no lockfile, auto-converting v1 lockfiles to v3; otherwise, maintain current lockfile version. .IP \(bu 4 Type: null, 1, 2, 3, "1", "2", or "3" .RE 0 @@ -1093,7 +1093,7 @@ Force offline mode: no network requests will be done during install. To allow th .SS "\fBomit\fR" .RS 0 .IP \(bu 4 -Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty. +Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production'; otherwise, empty. .IP \(bu 4 Type: "dev", "optional", or "peer" (can be set multiple times) .RE 0 @@ -1135,7 +1135,8 @@ Type: null or String .RE 0 .P -This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR. +This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm +access\fR. .P 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. .SS "\fBpack-destination\fR" @@ -1265,7 +1266,7 @@ Type: Boolean .P When publishing from a supported cloud CI/CD system, the package will be publicly linked to where it was built and published from. .P -This config can not be used with: \fBprovenance-file\fR +This config cannot be used with: \fBprovenance-file\fR .SS "\fBprovenance-file\fR" .RS 0 .IP \(bu 4 @@ -1277,7 +1278,7 @@ Type: Path .P When publishing, the provenance bundle at the given path will be used. .P -This config can not be used with: \fBprovenance\fR +This config cannot be used with: \fBprovenance\fR .SS "\fBproxy\fR" .RS 0 .IP \(bu 4 @@ -1369,7 +1370,7 @@ Type: Boolean .P Save installed packages to a package.json file as \fBdevDependencies\fR. .P -This config can not be used with: \fBsave-optional\fR, \fBsave-peer\fR, \fBsave-prod\fR +This config cannot be used with: \fBsave-optional\fR, \fBsave-peer\fR, \fBsave-prod\fR .SS "\fBsave-exact\fR" .RS 0 .IP \(bu 4 @@ -1391,7 +1392,7 @@ Type: Boolean .P Save installed packages to a package.json file as \fBoptionalDependencies\fR. .P -This config can not be used with: \fBsave-dev\fR, \fBsave-peer\fR, \fBsave-prod\fR +This config cannot be used with: \fBsave-dev\fR, \fBsave-peer\fR, \fBsave-prod\fR .SS "\fBsave-peer\fR" .RS 0 .IP \(bu 4 @@ -1403,7 +1404,7 @@ Type: Boolean .P Save installed packages to a package.json file as \fBpeerDependencies\fR .P -This config can not be used with: \fBsave-dev\fR, \fBsave-optional\fR, \fBsave-prod\fR +This config cannot be used with: \fBsave-dev\fR, \fBsave-optional\fR, \fBsave-prod\fR .SS "\fBsave-prefix\fR" .RS 0 .IP \(bu 4 @@ -1415,8 +1416,7 @@ Type: String .P Configure how versions of packages installed to a package.json file via \fB--save\fR or \fB--save-dev\fR get prefixed. .P -For example if a package has version \fB1.2.3\fR, by default its version is set to \fB^1.2.3\fR which allows minor upgrades for that package, but after \fBnpm -config set save-prefix='~'\fR it would be set to \fB~1.2.3\fR which only allows patch upgrades. +For example if a package has version \fB1.2.3\fR, by default its version is set to \fB^1.2.3\fR which allows minor upgrades for that package, but after \fBnpm config set save-prefix='~'\fR it would be set to \fB~1.2.3\fR which only allows patch upgrades. .SS "\fBsave-prod\fR" .RS 0 .IP \(bu 4 @@ -1430,7 +1430,7 @@ Save installed packages into \fBdependencies\fR specifically. This is useful if .P This is the default behavior if \fB--save\fR is true, and neither \fB--save-dev\fR or \fB--save-optional\fR are true. .P -This config can not be used with: \fBsave-dev\fR, \fBsave-optional\fR, \fBsave-peer\fR +This config cannot be used with: \fBsave-dev\fR, \fBsave-optional\fR, \fBsave-peer\fR .SS "\fBsbom-format\fR" .RS 0 .IP \(bu 4 @@ -1494,8 +1494,7 @@ Type: null or String .RE 0 .P -The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm -init \fR commands. +The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm init \fR commands. .SS "\fBsearchexclude\fR" .RS 0 .IP \(bu 4 @@ -1607,8 +1606,8 @@ Type: String .P If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag. .P -It is the tag added to the package@version specified in the \fBnpm dist-tag -add\fR command, if no explicit tag is given. +It is the tag added to the package@version specified in the \fBnpm +dist-tag add\fR command, if no explicit tag is given. .P When used by the \fBnpm diff\fR command, this is the tag used to fetch the tarball that will be compared with the local files by default. .P diff --git a/deps/npm/man/man7/dependency-selectors.7 b/deps/npm/man/man7/dependency-selectors.7 index 165f0e21051382..eed3d6c769106f 100644 --- a/deps/npm/man/man7/dependency-selectors.7 +++ b/deps/npm/man/man7/dependency-selectors.7 @@ -1,4 +1,4 @@ -.TH "QUERYING" "7" "September 2025" "NPM@11.6.1" "" +.TH "QUERYING" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBQuerying\fR - Dependency Selector Syntax & Querying .SS "Description" @@ -226,7 +226,7 @@ Nested objects are expressed as sequential arguments to \fB:attr()\fR. .P .RS 2 .nf -/* return dependencies that have a testling config for opera browsers */ +/* return dependencies that have a \[lB]testling config\[rB](https://ci.testling.com/guide/advanced_configuration) for opera browsers */ *:attr(testling, browsers, \[lB]~=opera\[rB]) .fi .RE diff --git a/deps/npm/man/man7/developers.7 b/deps/npm/man/man7/developers.7 index 833e4a3e2ba3a3..a65327f7813f1d 100644 --- a/deps/npm/man/man7/developers.7 +++ b/deps/npm/man/man7/developers.7 @@ -1,4 +1,4 @@ -.TH "DEVELOPERS" "7" "September 2025" "NPM@11.6.1" "" +.TH "DEVELOPERS" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBdevelopers\fR - Developer Guide .SS "Description" @@ -152,7 +152,7 @@ More info at npm help link. .P \fBThis is important.\fR .P -If you can not install it locally, you'll have problems trying to publish it. Or, worse yet, you'll be able to publish it, but you'll be publishing a broken or pointless package. So don't do that. +If you cannot install it locally, you'll have problems trying to publish it. Or, worse yet, you'll be able to publish it, but you'll be publishing a broken or pointless package. So don't do that. .P In the root of your package, do this: .P diff --git a/deps/npm/man/man7/logging.7 b/deps/npm/man/man7/logging.7 index 07c651836ab0e0..fcdcfcec66c5aa 100644 --- a/deps/npm/man/man7/logging.7 +++ b/deps/npm/man/man7/logging.7 @@ -1,4 +1,4 @@ -.TH "LOGGING" "7" "September 2025" "NPM@11.6.1" "" +.TH "LOGGING" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBLogging\fR - Why, What & How We Log .SS "Description" diff --git a/deps/npm/man/man7/orgs.7 b/deps/npm/man/man7/orgs.7 index 781781aab5d61f..e68241ff36fe19 100644 --- a/deps/npm/man/man7/orgs.7 +++ b/deps/npm/man/man7/orgs.7 @@ -1,4 +1,4 @@ -.TH "ORGS" "7" "September 2025" "NPM@11.6.1" "" +.TH "ORGS" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBorgs\fR - Working with Teams & Orgs .SS "Description" @@ -109,7 +109,7 @@ See what org packages a team member can access: .P .RS 2 .nf -npm access ls-packages +npm access list packages .fi .RE .RS 0 @@ -120,7 +120,7 @@ See packages available to a specific team: .P .RS 2 .nf -npm access ls-packages +npm access list packages .fi .RE .RS 0 @@ -131,7 +131,7 @@ Check which teams are collaborating on a package: .P .RS 2 .nf -npm access ls-collaborators +npm access list collaborators .fi .RE .SS "See also" diff --git a/deps/npm/man/man7/package-spec.7 b/deps/npm/man/man7/package-spec.7 index a2f7d0167ab3f3..c70815de103705 100644 --- a/deps/npm/man/man7/package-spec.7 +++ b/deps/npm/man/man7/package-spec.7 @@ -1,4 +1,4 @@ -.TH "PACKAGE-SPEC" "7" "September 2025" "NPM@11.6.1" "" +.TH "PACKAGE-SPEC" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBpackage-spec\fR - Package name specifier .SS "Description" diff --git a/deps/npm/man/man7/registry.7 b/deps/npm/man/man7/registry.7 index 9aa42d0ab63b44..1c0b0bf111a2e6 100644 --- a/deps/npm/man/man7/registry.7 +++ b/deps/npm/man/man7/registry.7 @@ -1,4 +1,4 @@ -.TH "REGISTRY" "7" "September 2025" "NPM@11.6.1" "" +.TH "REGISTRY" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBregistry\fR - The JavaScript Package Registry .SS "Description" diff --git a/deps/npm/man/man7/removal.7 b/deps/npm/man/man7/removal.7 index dd1ca3b69cc8a8..750f5a0b35ed84 100644 --- a/deps/npm/man/man7/removal.7 +++ b/deps/npm/man/man7/removal.7 @@ -1,4 +1,4 @@ -.TH "REMOVAL" "7" "September 2025" "NPM@11.6.1" "" +.TH "REMOVAL" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBremoval\fR - Cleaning the Slate .SS "Synopsis" diff --git a/deps/npm/man/man7/scope.7 b/deps/npm/man/man7/scope.7 index c52ad525b4d8e7..c12c8360f3f076 100644 --- a/deps/npm/man/man7/scope.7 +++ b/deps/npm/man/man7/scope.7 @@ -1,4 +1,4 @@ -.TH "SCOPE" "7" "September 2025" "NPM@11.6.1" "" +.TH "SCOPE" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBscope\fR - Scoped packages .SS "Description" diff --git a/deps/npm/man/man7/scripts.7 b/deps/npm/man/man7/scripts.7 index 9e7611a43f87ff..cbef73ef64ad2d 100644 --- a/deps/npm/man/man7/scripts.7 +++ b/deps/npm/man/man7/scripts.7 @@ -1,4 +1,4 @@ -.TH "SCRIPTS" "7" "September 2025" "NPM@11.6.1" "" +.TH "SCRIPTS" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBscripts\fR - How npm handles the "scripts" field .SS "Description" @@ -66,7 +66,7 @@ Runs BEFORE the package is prepared and packed, ONLY on \fBnpm publish\fR. .IP \(bu 4 Runs BEFORE a tarball is packed (on "\fBnpm pack\fR", "\fBnpm publish\fR", and when installing a git dependency). .IP \(bu 4 -NOTE: "\fBnpm run pack\fR" is NOT the same as "\fBnpm pack\fR". "\fBnpm run pack\fR" is an arbitrary user defined script name, where as, "\fBnpm pack\fR" is a CLI defined command. +NOTE: "\fBnpm run pack\fR" is NOT the same as "\fBnpm pack\fR". "\fBnpm run pack\fR" is an arbitrary user defined script name, whereas, "\fBnpm pack\fR" is a CLI defined command. .RE 0 .P @@ -173,8 +173,7 @@ These also run when you run \fBnpm install -g \fR .RE 0 .P -If there is a \fBbinding.gyp\fR file in the root of your package and you haven't defined your own \fBinstall\fR or \fBpreinstall\fR scripts, npm will default the \fBinstall\fR command to compile using node-gyp via \fBnode-gyp -rebuild\fR +If there is a \fBbinding.gyp\fR file in the root of your package and you haven't defined your own \fBinstall\fR or \fBpreinstall\fR scripts, npm will default the \fBinstall\fR command to compile using node-gyp via \fBnode-gyp rebuild\fR .P These are run from the scripts of \fB\fR .SS "npm help pack" @@ -219,7 +218,7 @@ These are run from the scripts of \fB\fR \fBprepare\fR is only run if the current directory is a symlink (e.g. with linked packages) .SS "npm help restart" .P -If there is a \fBrestart\fR script defined, these events are run, otherwise \fBstop\fR and \fBstart\fR are both run if present, including their \fBpre\fR and \fBpost\fR iterations) +If there is a \fBrestart\fR script defined, these events are run; otherwise, \fBstop\fR and \fBstart\fR are both run if present, including their \fBpre\fR and \fBpost\fR iterations) .RS 0 .IP \(bu 4 \fBprerestart\fR @@ -290,9 +289,9 @@ Reasons for a package removal include: .IP \(bu 4 a user directly uninstalled this package .IP \(bu 4 -a user uninstalled a dependant package and so this dependency is being uninstalled +a user uninstalled a dependent package and so this dependency is being uninstalled .IP \(bu 4 -a user uninstalled a dependant package but another package also depends on this version +a user uninstalled a dependent package but another package also depends on this version .IP \(bu 4 this version has been merged as a duplicate with another version .IP \(bu 4 diff --git a/deps/npm/man/man7/workspaces.7 b/deps/npm/man/man7/workspaces.7 index 536cae66ce09ba..74a291685b8b29 100644 --- a/deps/npm/man/man7/workspaces.7 +++ b/deps/npm/man/man7/workspaces.7 @@ -1,4 +1,4 @@ -.TH "WORKSPACES" "7" "September 2025" "NPM@11.6.1" "" +.TH "WORKSPACES" "7" "October 2025" "NPM@11.6.2" "" .SH "NAME" \fBworkspaces\fR - Working with workspaces .SS "Description" diff --git a/deps/npm/node_modules/@npmcli/arborist/README.md b/deps/npm/node_modules/@npmcli/arborist/README.md index 8a111f3c70fe26..bdffaf4041ab68 100644 --- a/deps/npm/node_modules/@npmcli/arborist/README.md +++ b/deps/npm/node_modules/@npmcli/arborist/README.md @@ -6,7 +6,7 @@ Inspect and manage `node_modules` trees. -![a tree with the word ARBORIST superimposed on it](https://raw.githubusercontent.com/npm/arborist/main/docs/logo.svg?sanitize=true) +![a tree with the word ARBORIST superimposed on it](https://raw.githubusercontent.com/npm/cli/latest/workspaces/arborist/docs/logo.svg?sanitize=true) There's more documentation [in the docs folder](https://github.com/npm/cli/tree/latest/workspaces/arborist/docs). diff --git a/deps/npm/node_modules/@npmcli/arborist/bin/index.js b/deps/npm/node_modules/@npmcli/arborist/bin/index.js index 7c5d45f1f1fc94..0b559687ac06af 100755 --- a/deps/npm/node_modules/@npmcli/arborist/bin/index.js +++ b/deps/npm/node_modules/@npmcli/arborist/bin/index.js @@ -37,7 +37,7 @@ ${message && '\n' + message + '\n'} Additionally: - * --loglevel=warn|--quiet will supppress the printing of package trees + * --loglevel=warn|--quiet will suppress the printing of package trees * --logfile will output logs to a file * --timing will show timing information * Instead of 'npm install ', use 'arborist reify --add='. diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js index 9eff905ffa39c0..3a066d9b6d336f 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js @@ -192,7 +192,7 @@ module.exports = cls => class IdealTreeBuilder extends cls { } async #checkEngineAndPlatform () { - const { engineStrict, npmVersion, nodeVersion, omit = [] } = this.options + const { engineStrict, npmVersion, nodeVersion, omit = [], cpu, os, libc } = this.options const omitSet = new Set(omit) for (const node of this.idealTree.inventory.values()) { @@ -214,6 +214,19 @@ module.exports = cls => class IdealTreeBuilder extends cls { } checkPlatform(node.package, this.options.force) } + if (node.optional && !node.inert) { + // Mark any optional packages we can't install as inert. + // We ignore the --force and --engine-strict flags. + try { + checkEngine(node.package, npmVersion, nodeVersion, false) + checkPlatform(node.package, false, { cpu, os, libc }) + } catch (error) { + const set = optionalSet(node) + for (const node of set) { + node.inert = true + } + } + } } } @@ -324,7 +337,7 @@ module.exports = cls => class IdealTreeBuilder extends cls { }) .then(tree => { - // search the virtual tree for invalid edges, if any are found add their source to + // search the virtual tree for missing/invalid edges, if any are found add their source to // the depsQueue so that we'll fix it later depth({ tree, @@ -338,7 +351,7 @@ module.exports = cls => class IdealTreeBuilder extends cls { filter: node => node, visit: node => { for (const edge of node.edgesOut.values()) { - if (!edge.valid) { + if (!edge.to || !edge.valid) { this.#depsQueue.push(node) break // no need to continue the loop after the first hit } @@ -811,7 +824,7 @@ This is a one-time fix-up, please be patient... node !== this.idealTree && node.resolved && (hasBundle || hasShrinkwrap) && - !node.ideallyInert + !node.inert if (crackOpen) { const Arborist = this.constructor const opt = { ...this.options } @@ -1011,7 +1024,7 @@ This is a one-time fix-up, please be patient... } // pre-fetch any problem edges, since we'll need these soon - // if it fails at this point, though, dont' worry because it + // if it fails at this point, though, don't worry because it // may well be an optional dep that has gone missing. it'll // fail later anyway. for (const e of this.#problemEdges(placed)) { @@ -1067,7 +1080,7 @@ This is a one-time fix-up, please be patient... ? await this.#nodeFromSpec(edge.name, spec2, parent, secondEdge) : null - // pick the second one if they're both happy with that, otherwise first + // pick the second one if they're both happy with that; otherwise, first const node = second && edge.valid ? second : first // ensure the one we want is the one that's placed node.parent = parent @@ -1274,7 +1287,7 @@ This is a one-time fix-up, please be patient... // failed to load the spec, either because of enotarget or // fetch failure of some other sort. save it so we can verify - // later that it's optional, otherwise the error is fatal. + // later that it's optional; otherwise, the error is fatal. const n = new Node({ name, parent, @@ -1431,7 +1444,7 @@ This is a one-time fix-up, please be patient... // - if a path under an existing node, then assign that as the fsParent, // and add it to the _depsQueue // - // call buildDepStep if anything was added to the queue, otherwise we're done + // call buildDepStep if anything was added to the queue; otherwise, we're done #resolveLinks () { for (const link of this.#linkNodes) { this.#linkNodes.delete(link) @@ -1561,7 +1574,7 @@ This is a one-time fix-up, please be patient... const set = optionalSet(node) for (const node of set) { - node.ideallyInert = true + node.inert = true } } } @@ -1582,7 +1595,7 @@ This is a one-time fix-up, please be patient... node.parent !== null && !node.isProjectRoot && !excludeNodes.has(node) - && !node.ideallyInert + && !node.inert ) { this[_addNodeToTrashList](node) } diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/isolated-reifier.js b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/isolated-reifier.js index a9a31dbf2e00ae..16210296b5a141 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/isolated-reifier.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/isolated-reifier.js @@ -81,7 +81,7 @@ module.exports = cls => class IsolatedReifier extends cls { } queue.push(e.to) }) - if (!next.isProjectRoot && !next.isWorkspace && !next.ideallyInert) { + if (!next.isProjectRoot && !next.isWorkspace && !next.inert) { root.external.push(await this.externalProxyMemo(next)) } } @@ -140,15 +140,15 @@ module.exports = cls => class IsolatedReifier extends cls { async assignCommonProperties (node, result) { function validEdgesOut (node) { - return [...node.edgesOut.values()].filter(e => e.to && e.to.target && !(node.package.bundledDepenedencies || node.package.bundleDependencies || []).includes(e.to.name)) + return [...node.edgesOut.values()].filter(e => e.to && e.to.target && !(node.package.bundledDependencies || node.package.bundleDependencies || []).includes(e.to.name)) } const edges = validEdgesOut(node) const optionalDeps = edges.filter(e => e.optional).map(e => e.to.target) const nonOptionalDeps = edges.filter(e => !e.optional).map(e => e.to.target) result.localDependencies = await Promise.all(nonOptionalDeps.filter(n => n.isWorkspace).map(this.workspaceProxyMemo)) - result.externalDependencies = await Promise.all(nonOptionalDeps.filter(n => !n.isWorkspace && !n.ideallyInert).map(this.externalProxyMemo)) - result.externalOptionalDependencies = await Promise.all(optionalDeps.filter(n => !n.ideallyInert).map(this.externalProxyMemo)) + result.externalDependencies = await Promise.all(nonOptionalDeps.filter(n => !n.isWorkspace && !n.inert).map(this.externalProxyMemo)) + result.externalOptionalDependencies = await Promise.all(optionalDeps.filter(n => !n.inert).map(this.externalProxyMemo)) result.dependencies = [ ...result.externalDependencies, ...result.localDependencies, diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/load-actual.js b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/load-actual.js index 02914a8861bc56..3be44780e01aee 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/load-actual.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/load-actual.js @@ -36,7 +36,7 @@ module.exports = cls => class ActualLoader extends cls { // We don't do fsParent as a magic getter/setter, because it'd be too costly // to keep up to date along the walk. // And, we know that it can ONLY be relevant when the node is a target of a - // link, otherwise it'd be in a node_modules folder, so take advantage of + // link; otherwise, it'd be in a node_modules folder, so take advantage of // that to limit the scans later. #topNodes = new Set() #transplantFilter diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/load-virtual.js b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/load-virtual.js index fb0e5e8c60c6f9..ba1b7478bd510f 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/load-virtual.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/load-virtual.js @@ -168,7 +168,7 @@ module.exports = cls => class VirtualLoader extends cls { } } - // separate out link metadatas, and create Node objects for nodes + // separate out link metadata, and create Node objects for nodes #resolveNodes (s, root) { const links = new Map() const nodes = new Map([['', root]]) @@ -269,7 +269,6 @@ To fix: integrity: sw.integrity, resolved: consistentResolve(sw.resolved, this.path, path), pkg: sw, - ideallyInert: sw.ideallyInert, hasShrinkwrap: sw.hasShrinkwrap, dev, optional, diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/reify.js b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/reify.js index 8591e0b0db96e3..70d4d9796d2e72 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/arborist/reify.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/arborist/reify.js @@ -7,7 +7,6 @@ const pacote = require('pacote') const promiseAllRejectLate = require('promise-all-reject-late') const runScript = require('@npmcli/run-script') const { callLimit: promiseCallLimit } = require('promise-call-limit') -const { checkEngine, checkPlatform } = require('npm-install-checks') const { depth: dfwalk } = require('treeverse') const { dirname, resolve, relative, join } = require('node:path') const { log, time } = require('proc-log') @@ -74,7 +73,6 @@ module.exports = cls => class Reifier extends cls { #dryRun #nmValidated = new Set() #omit - #omitted #retiredPaths = {} #retiredUnchanged = {} #savePrefix @@ -99,7 +97,6 @@ module.exports = cls => class Reifier extends cls { } this.#omit = new Set(options.omit) - this.#omitted = new Set() // start tracker block this.addTracker('reify') @@ -132,15 +129,17 @@ module.exports = cls => class Reifier extends cls { this.idealTree = oldTree } await this[_saveIdealTree](options) - // clean omitted - for (const node of this.#omitted) { - node.parent = null + // clean inert + for (const node of this.idealTree.inventory.values()) { + if (node.inert) { + node.parent = null + } } // clean up any trash that is still in the tree for (const path of this[_trashList]) { const loc = relpath(this.idealTree.realpath, path) const node = this.idealTree.inventory.get(loc) - if (node && node.root === this.idealTree && !node.ideallyInert) { + if (node && node.root === this.idealTree) { node.parent = null } } @@ -228,18 +227,6 @@ module.exports = cls => class Reifier extends cls { this.idealTree.meta.hiddenLockfile = true this.idealTree.meta.lockfileVersion = defaultLockfileVersion - // Preserve inertness for failed stuff. - if (this.actualTree) { - for (const [loc, actual] of this.actualTree.inventory.entries()) { - if (actual.ideallyInert) { - const ideal = this.idealTree.inventory.get(loc) - if (ideal) { - ideal.ideallyInert = true - } - } - } - } - this.actualTree = this.idealTree this.idealTree = null @@ -465,7 +452,6 @@ module.exports = cls => class Reifier extends cls { // and ideal trees. this.diff = Diff.calculate({ omit: this.#omit, - omitted: this.#omitted, shrinkwrapInflated: this.#shrinkwrapInflated, filterNodes, actual: this.actualTree, @@ -566,9 +552,6 @@ module.exports = cls => class Reifier extends cls { // retire the same path at the same time. const dirsChecked = new Set() return promiseAllRejectLate(leaves.map(async node => { - if (node.ideallyInert) { - return - } for (const d of walkUp(node.path)) { if (d === node.top.path) { break @@ -662,18 +645,7 @@ module.exports = cls => class Reifier extends cls { const timeEnd = time.start(`reifyNode:${node.location}`) this.addTracker('reify', node.name, node.location) - const { npmVersion, nodeVersion, cpu, os, libc } = this.options const p = Promise.resolve().then(async () => { - // when we reify an optional node, check the engine and platform - // first. be sure to ignore the --force and --engine-strict flags, - // since we always want to skip any optional packages we can't install. - // these checks throwing will result in a rollback and removal - // of the mismatches - // eslint-disable-next-line promise/always-return - if (node.optional) { - checkEngine(node.package, npmVersion, nodeVersion, false) - checkPlatform(node.package, false, { cpu, os, libc }) - } await this[_checkBins](node) await this.#extractOrLink(node) const { _id, deprecated } = node.package @@ -707,10 +679,6 @@ module.exports = cls => class Reifier extends cls { } async #extractOrLink (node) { - if (node.ideallyInert) { - return - } - const nm = resolve(node.parent.path, 'node_modules') await this.#validateNodeModules(nm) @@ -791,9 +759,9 @@ module.exports = cls => class Reifier extends cls { [_handleOptionalFailure] (node, p) { return (node.optional ? p.catch(() => { const set = optionalSet(node) - for (node of set) { + for (const node of set) { log.verbose('reify', 'failed optional dependency', node.path) - node.ideallyInert = true + node.inert = true this[_addNodeToTrashList](node) } }) : p).then(() => node) @@ -1165,9 +1133,6 @@ module.exports = cls => class Reifier extends cls { this.#retiredUnchanged[retireFolder] = [] return promiseAllRejectLate(diff.unchanged.map(node => { - if (node.ideallyInert) { - return - } // no need to roll back links, since we'll just delete them anyway if (node.isLink) { return mkdir(dirname(node.path), { recursive: true, force: true }) @@ -1247,7 +1212,7 @@ module.exports = cls => class Reifier extends cls { // skip links that only live within node_modules as they are most // likely managed by packages we installed, we only want to rebuild // unchanged links we directly manage - const linkedFromRoot = (node.parent === tree && !node.ideallyInert) || node.target.fsTop === tree + const linkedFromRoot = (node.parent === tree && !node.inert) || node.target.fsTop === tree if (node.isLink && linkedFromRoot) { nodes.push(node) } @@ -1358,7 +1323,7 @@ module.exports = cls => class Reifier extends cls { const alias = name !== pname newSpec = alias ? `npm:${pname}@${range}` : range } else if (req.hosted) { - // save the git+https url if it has auth, otherwise shortcut + // save the git+https url if it has auth; otherwise, shortcut const h = req.hosted const opt = { noCommittish: false } if (h.https && h.auth) { @@ -1427,7 +1392,7 @@ module.exports = cls => class Reifier extends cls { // Returns true if any of the edges from this node has a semver // range definition that is an exact match to the version installed - // e.g: should return true if for a given an installed version 1.0.0, + // e.g: should return true if for a given and installed version 1.0.0, // range is either =1.0.0 or 1.0.0 const exactVersion = node => { for (const edge of node.edgesIn) { diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/diff.js b/deps/npm/node_modules/@npmcli/arborist/lib/diff.js index 9f2d5aed47d073..465657cc624222 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/diff.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/diff.js @@ -11,9 +11,8 @@ const { existsSync } = require('node:fs') const ssri = require('ssri') class Diff { - constructor ({ actual, ideal, filterSet, shrinkwrapInflated, omit, omitted }) { + constructor ({ actual, ideal, filterSet, shrinkwrapInflated, omit }) { this.omit = omit - this.omitted = omitted this.filterSet = filterSet this.shrinkwrapInflated = shrinkwrapInflated this.children = [] @@ -39,7 +38,6 @@ class Diff { filterNodes = [], shrinkwrapInflated = new Set(), omit = new Set(), - omitted = new Set(), }) { // if there's a filterNode, then: // - get the path from the root to the filterNode. The root or @@ -98,28 +96,18 @@ class Diff { } return depth({ - tree: new Diff({ actual, ideal, filterSet, shrinkwrapInflated, omit, omitted }), + tree: new Diff({ actual, ideal, filterSet, shrinkwrapInflated, omit }), getChildren, leave, }) } } -const getAction = ({ actual, ideal, omit, omitted }) => { +const getAction = ({ actual, ideal }) => { if (!ideal) { return 'REMOVE' } - if (ideal.shouldOmit?.(omit)) { - omitted.add(ideal) - - if (actual) { - return 'REMOVE' - } - - return null - } - // bundled meta-deps are copied over to the ideal tree when we visit it, // so they'll appear to be missing here. There's no need to handle them // in the diff, though, because they'll be replaced at reify time anyway @@ -199,7 +187,6 @@ const getChildren = diff => { filterSet, shrinkwrapInflated, omit, - omitted, } = diff // Note: we DON'T diff fsChildren themselves, because they are either @@ -231,7 +218,6 @@ const getChildren = diff => { filterSet, shrinkwrapInflated, omit, - omitted, }) } @@ -251,13 +237,24 @@ const diffNode = ({ filterSet, shrinkwrapInflated, omit, - omitted, }) => { if (filterSet.size && !(filterSet.has(ideal) || filterSet.has(actual))) { return } - const action = getAction({ actual, ideal, omit, omitted }) + if (ideal?.shouldOmit?.(omit)) { + ideal.inert = true + } + + // Treat inert nodes as undefined for the purposes of diffing. + if (ideal?.inert) { + ideal = undefined + } + if (!actual && !ideal) { + return + } + + const action = getAction({ actual, ideal }) // if it's a match, then get its children // otherwise, this is the child diff node @@ -265,7 +262,7 @@ const diffNode = ({ if (action === 'REMOVE') { removed.push(actual) } - children.push(new Diff({ actual, ideal, filterSet, shrinkwrapInflated, omit, omitted })) + children.push(new Diff({ actual, ideal, filterSet, shrinkwrapInflated, omit })) } else { unchanged.push(ideal) // !*! Weird dirty hack warning !*! @@ -306,7 +303,6 @@ const diffNode = ({ filterSet, shrinkwrapInflated, omit, - omitted, })) } } diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/gather-dep-set.js b/deps/npm/node_modules/@npmcli/arborist/lib/gather-dep-set.js index 2c85a640fddfb1..39180de38db4a9 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/gather-dep-set.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/gather-dep-set.js @@ -20,7 +20,7 @@ const gatherDepSet = (set, edgeFilter) => { } } - // now remove all nodes in the set that have a dependant outside the set + // now remove all nodes in the set that have a dependent outside the set // if any change is made, then re-check // continue until no changes made, or deps set evaporates fully. let changed = true diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/node.js b/deps/npm/node_modules/@npmcli/arborist/lib/node.js index 1b75e606609276..41871756c221cc 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/node.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/node.js @@ -101,7 +101,7 @@ class Node { global = false, dummy = false, sourceReference = null, - ideallyInert = false, + inert = false, } = options // this object gives querySelectorAll somewhere to stash context about a node // while processing a query @@ -207,7 +207,7 @@ class Node { this.extraneous = false } - this.ideallyInert = ideallyInert + this.inert = inert this.edgesIn = new Set() this.edgesOut = new CaseInsensitiveMap() @@ -248,7 +248,7 @@ class Node { this.fsParent = fsParent || null // see parent/root setters below. - // root is set to parent's root if we have a parent, otherwise if it's + // root is set to parent's root if we have a parent; otherwise, if it's // null, then it's set to the node itself. if (!parent && !fsParent) { this.root = root || null @@ -832,7 +832,7 @@ class Node { edge.reload() } } - // reload all edgesOut where root doens't match, or is missing, since + // reload all edgesOut where root doesn't match, or is missing, since // it might not be missing in the new tree for (const edge of this.edgesOut.values()) { if (!edge.to || edge.to.root !== root) { @@ -1268,7 +1268,7 @@ class Node { // with another by the same name (eg, to update or dedupe). // This does a couple of walks out on the node_modules tree, recursing // into child nodes. However, as setting the parent is typically done - // with nodes that don't have have many children, and (deduped) package + // with nodes that don't have many children, and (deduped) package // trees tend to be broad rather than deep, it's not that bad. // The only walk that starts from the parent rather than this node is // limited by edge name. @@ -1412,7 +1412,7 @@ class Node { } recalculateOutEdgesOverrides () { - // For each edge out propogate the new overrides through. + // For each edge out propagate the new overrides through. for (const edge of this.edgesOut.values()) { edge.reload(true) if (edge.to) { diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/optional-set.js b/deps/npm/node_modules/@npmcli/arborist/lib/optional-set.js index 9f5184ea024420..76d557c0e52c55 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/optional-set.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/optional-set.js @@ -29,10 +29,8 @@ const optionalSet = node => { } // now that we've hit the boundary, gather the rest of the nodes in - // the optional section. that's the set of dependencies that are only - // depended upon by other nodes within the set, or optional dependencies - // from outside the set. - return gatherDepSet(set, edge => !edge.optional) + // the optional section that don't have dependents outside the set. + return gatherDepSet(set, edge => !set.has(edge.to)) } module.exports = optionalSet diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/packument-cache.js b/deps/npm/node_modules/@npmcli/arborist/lib/packument-cache.js index 26e463eb9d334d..d8e163ba23ba1e 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/packument-cache.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/packument-cache.js @@ -30,7 +30,7 @@ class PackumentCache extends LRUCache { maxSize, maxEntrySize, sizeCalculation: (p) => { - // Don't cache if we dont know the size + // Don't cache if we don't know the size // Some versions of pacote set this to `0`, newer versions set it to `null` if (!p[sizeKey]) { return maxEntrySize + 1 diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/place-dep.js b/deps/npm/node_modules/@npmcli/arborist/lib/place-dep.js index 532b529b28b418..c7b3e10d408d0b 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/place-dep.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/place-dep.js @@ -203,7 +203,7 @@ class PlaceDep { this.warnPeerConflict() } - // if we get a KEEP in a update scenario, then we MAY have something + // if we get a KEEP in an update scenario, then we MAY have something // already duplicating this unnecessarily! For example: // ``` // root (dep: y@1) @@ -317,7 +317,7 @@ class PlaceDep { force: this.force, installLinks: this.installLinks, installStrategy: this.installStrategy, - legacyPeerDeps: this.legaycPeerDeps, + legacyPeerDeps: this.legacyPeerDeps, preferDedupe: this.preferDedupe, strictPeerDeps: this.strictPeerDeps, updateNames: this.updateName, @@ -421,7 +421,7 @@ class PlaceDep { // prune all the nodes in a branch of the tree that can be safely removed // This is only the most basic duplication detection; it finds if there // is another satisfying node further up the tree, and if so, dedupes. - // Even in installStategy is nested, we do this amount of deduplication. + // Even if installStrategy is nested, we do this amount of deduplication. pruneDedupable (node, descend = true) { if (node.canDedupe(this.preferDedupe, this.explicitRequest)) { // gather up all deps that have no valid edges in from outside diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/query-selector-all.js b/deps/npm/node_modules/@npmcli/arborist/lib/query-selector-all.js index c2cd00d0a2e2ee..db0d8ea2edb113 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/query-selector-all.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/query-selector-all.js @@ -785,7 +785,7 @@ const hasParent = (node, compareNodes) => { compareNode = compareNode.target } - // follows logical parent for link anscestors + // follows logical parent for link ancestors if (node.isTop && (node.resolveParent === compareNode)) { return true } diff --git a/deps/npm/node_modules/@npmcli/arborist/lib/shrinkwrap.js b/deps/npm/node_modules/@npmcli/arborist/lib/shrinkwrap.js index e4b159c568250c..8313e05d61c376 100644 --- a/deps/npm/node_modules/@npmcli/arborist/lib/shrinkwrap.js +++ b/deps/npm/node_modules/@npmcli/arborist/lib/shrinkwrap.js @@ -109,7 +109,6 @@ const nodeMetaKeys = [ 'inBundle', 'hasShrinkwrap', 'hasInstallScript', - 'ideallyInert', ] const metaFieldFromPkg = (pkg, key) => { @@ -136,10 +135,6 @@ const assertNoNewer = async (path, data, lockTime, dir, seen) => { const parent = isParent ? dir : resolve(dir, 'node_modules') const rel = relpath(path, dir) - const inert = data.packages[rel]?.ideallyInert - if (inert) { - return - } seen.add(rel) let entries if (dir === path) { @@ -178,7 +173,7 @@ const assertNoNewer = async (path, data, lockTime, dir, seen) => { // assert that all the entries in the lockfile were seen for (const loc in data.packages) { - if (!seen.has(loc) && !data.packages[loc].ideallyInert) { + if (!seen.has(loc)) { throw new Error(`missing from node_modules: ${loc}`) } } @@ -436,7 +431,7 @@ class Shrinkwrap { const [sw, lock, yarn] = await this.loadFiles data = sw || lock || '{}' - // use shrinkwrap only for deps, otherwise prefer package-lock + // use shrinkwrap only for deps; otherwise, prefer package-lock // and ignore npm-shrinkwrap if both are present. // TODO: emit a warning here or something if both are present. if (this.hiddenLockfile) { @@ -788,10 +783,6 @@ class Shrinkwrap { // ok, I did my best! good luck! } - if (lock.ideallyInert) { - meta.ideallyInert = true - } - if (lock.bundled) { meta.inBundle = true } @@ -962,12 +953,6 @@ class Shrinkwrap { this.#buildLegacyLockfile(this.tree, this.data) } - if (!this.hiddenLockfile) { - for (const node of Object.values(this.data.packages)) { - delete node.ideallyInert - } - } - // lf version 1 = dependencies only // lf version 2 = dependencies and packages // lf version 3 = packages only @@ -993,7 +978,7 @@ class Shrinkwrap { // npm v6 and before tracked 'from', meaning "the request that led // to this package being installed". However, that's inherently - // racey and non-deterministic in a world where deps are deduped + // racy and non-deterministic in a world where deps are deduped // ahead of fetch time. In order to maintain backwards compatibility // with v6 in the lockfile, we do this trick where we pick a valid // dep link out of the edgesIn set. Choose the edge with the fewest diff --git a/deps/npm/node_modules/@npmcli/arborist/package.json b/deps/npm/node_modules/@npmcli/arborist/package.json index c462e026af7f12..ed00181eceaec0 100644 --- a/deps/npm/node_modules/@npmcli/arborist/package.json +++ b/deps/npm/node_modules/@npmcli/arborist/package.json @@ -1,6 +1,6 @@ { "name": "@npmcli/arborist", - "version": "9.1.5", + "version": "9.1.6", "description": "Manage node_modules trees", "dependencies": { "@isaacs/string-locale-compare": "^1.1.0", diff --git a/deps/npm/node_modules/@npmcli/config/README.md b/deps/npm/node_modules/@npmcli/config/README.md index 12a5e23331d3ae..6a948d9b11a912 100644 --- a/deps/npm/node_modules/@npmcli/config/README.md +++ b/deps/npm/node_modules/@npmcli/config/README.md @@ -2,53 +2,42 @@ Configuration management for the npm cli. -This module is the spiritual descendant of -[`npmconf`](http://npm.im/npmconf), and the code that once lived in npm's +This module is the spiritual descendant of [`npmconf`](http://npm.im/npmconf), and the code that once lived in npm's `lib/config/` folder. -It does the management of configuration files that npm uses, but -importantly, does _not_ define all the configuration defaults or types, as -those parts make more sense to live within the npm CLI itself. +It does the management of configuration files that npm uses, but importantly, does _not_ define all the configuration defaults or types, as those parts make more sense to live within the npm CLI itself. The only exceptions: -- The `prefix` config value has some special semantics, setting the local - prefix if specified on the CLI options and not in global mode, or the - global prefix otherwise. -- The `project` config file is loaded based on the local prefix (which can - only be set by the CLI config options, and otherwise defaults to a walk - up the folder tree to the first parent containing a `node_modules` - folder, `package.json` file, or `package-lock.json` file.) +- The `prefix` config value has some special semantics, setting the local prefix if specified on the CLI options and not in global mode, or the global prefix otherwise. +- The `project` config file is loaded based on the local prefix (which can only be set by the CLI config options, and otherwise defaults to a walk up the folder tree to the first parent containing a `node_modules` folder, `package.json` file, or `package-lock.json` file.) - The `userconfig` value, as set by the environment and CLI (defaulting to `~/.npmrc`, is used to load user configs. - The `globalconfig` value, as set by the environment, CLI, and - `userconfig` file (defaulting to `$PREFIX/etc/npmrc`) is used to load - global configs. -- A `builtin` config, read from a `npmrc` file in the root of the npm - project itself, overrides all defaults. + `userconfig` file (defaulting to `$PREFIX/etc/npmrc`) is used to load global configs. +- A `builtin` config, read from a `npmrc` file in the root of the npm project itself, overrides all defaults. The resulting hierarchy of configs: -- CLI switches. eg `--some-key=some-value` on the command line. These are - parsed by [`nopt`](http://npm.im/nopt), which is not a great choice, but - it's the one that npm has used forever, and changing it will be - difficult. -- Environment variables. eg `npm_config_some_key=some_value` in the - environment. There is no way at this time to modify this prefix. -- INI-formatted project configs. eg `some-key = some-value` in the - `localPrefix` folder (ie, the `cwd`, or its nearest parent that contains - either a `node_modules` folder or `package.json` file.) -- INI-formatted userconfig file. eg `some-key = some-value` in `~/.npmrc`. +- CLI switches. + eg `--some-key=some-value` on the command line. + These are parsed by [`nopt`](http://npm.im/nopt), which is not a great choice, but it's the one that npm has used forever, and changing it will be difficult. +- Environment variables. + eg `npm_config_some_key=some_value` in the environment. + There is no way at this time to modify this prefix. +- INI-formatted project configs. + eg `some-key = some-value` in the + `localPrefix` folder (ie, the `cwd`, or its nearest parent that contains either a `node_modules` folder or `package.json` file.) +- INI-formatted userconfig file. + eg `some-key = some-value` in `~/.npmrc`. The `userconfig` config value can be overridden by the `cli`, `env`, or `project` configs to change this value. -- INI-formatted globalconfig file. eg `some-key = some-value` in - the `globalPrefix` folder, which is inferred by looking at the location - of the node executable, or the `prefix` setting in the `cli`, `env`, - `project`, or `userconfig`. The `globalconfig` value at any of those - levels can override this. -- INI-formatted builtin config file. eg `some-key = some-value` in - `/usr/local/lib/node_modules/npm/npmrc`. This is not configurable, and - is determined by looking in the `npmPath` folder. +- INI-formatted globalconfig file. + eg `some-key = some-value` in the `globalPrefix` folder, which is inferred by looking at the location of the node executable, or the `prefix` setting in the `cli`, `env`, `project`, or `userconfig`. + The `globalconfig` value at any of those levels can override this. +- INI-formatted builtin config file. + eg `some-key = some-value` in `/usr/local/lib/node_modules/npm/npmrc`. + This is not configurable, and is determined by looking in the `npmPath` folder. - Default values (passed in by npm when it loads this module). ## USAGE @@ -65,7 +54,7 @@ const conf = new Config({ flatten, // optional, defaults to process.argv // argv: [] <- if you are using this package in your own cli - // and dont want to have colliding argv + // and don't want to have colliding argv argv: process.argv, // optional, defaults to process.env env: process.env, @@ -103,57 +92,50 @@ const Config = require('@npmcli/config') ### static `Config.typeDefs` -The type definitions passed to `nopt` for CLI option parsing and known -configuration validation. +The type definitions passed to `nopt` for CLI option parsing and known configuration validation. ### constructor `new Config(options)` Options: -- `types` Types of all known config values. Note that some are effectively - given semantic value in the config loading process itself. -- `shorthands` An object mapping a shorthand value to an array of CLI - arguments that replace it. +- `types` Types of all known config values. +Note that some are effectively given semantic value in the config loading process itself. +- `shorthands` An object mapping a shorthand value to an array of CLI arguments that replace it. - `defaults` Default values for each of the known configuration keys. These should be defined for all configs given a type, and must be valid. -- `npmPath` The path to the `npm` module, for loading the `builtin` config - file. +- `npmPath` The path to the `npm` module, for loading the `builtin` config file. - `cwd` Optional, defaults to `process.cwd()`, used for inferring the `localPrefix` and loading the `project` config. -- `platform` Optional, defaults to `process.platform`. Used when inferring - the `globalPrefix` from the `execPath`, since this is done diferently on - Windows. -- `execPath` Optional, defaults to `process.execPath`. Used to infer the +- `platform` Optional, defaults to `process.platform`. +Used when inferring the `globalPrefix` from the `execPath`, since this is done differently on Windows. +- `execPath` Optional, defaults to `process.execPath`. +Used to infer the `globalPrefix`. -- `env` Optional, defaults to `process.env`. Source of the environment - variables for configuration. -- `argv` Optional, defaults to `process.argv`. Source of the CLI options - used for configuration. +- `env` Optional, defaults to `process.env`. +Source of the environment variables for configuration. +- `argv` Optional, defaults to `process.argv`. +Source of the CLI options used for configuration. Returns a `config` object, which is not yet loaded. Fields: -- `config.globalPrefix` The prefix for `global` operations. Set by the +- `config.globalPrefix` The prefix for `global` operations. +Set by the `prefix` config value, or defaults based on the location of the `execPath` option. -- `config.localPrefix` The prefix for `local` operations. Set by the - `prefix` config value on the CLI only, or defaults to either the `cwd` or - its nearest ancestor containing a `node_modules` folder or `package.json` - file. -- `config.sources` A read-only `Map` of the file (or a comment, if no file - found, or relevant) to the config level loaded from that source. -- `config.data` A `Map` of config level to `ConfigData` objects. These - objects should not be modified directly under any circumstances. +- `config.localPrefix` The prefix for `local` operations. +Set by the + `prefix` config value on the CLI only, or defaults to either the `cwd` or its nearest ancestor containing a `node_modules` folder or `package.json` file. +- `config.sources` A read-only `Map` of the file (or a comment, if no file found, or relevant) to the config level loaded from that source. +- `config.data` A `Map` of config level to `ConfigData` objects. +These objects should not be modified directly under any circumstances. - `source` The source where this data was loaded from. - - `raw` The raw data used to generate this config data, as it was parsed - initially from the environment, config file, or CLI options. - - `data` The data object reflecting the inheritance of configs up to this - point in the chain. - - `loadError` Any errors encountered that prevented the loading of this - config data. -- `config.list` A list sorted in priority of all the config data objects in - the prototype chain. `config.list[0]` is the `cli` level, + - `raw` The raw data used to generate this config data, as it was parsed initially from the environment, config file, or CLI options. + - `data` The data object reflecting the inheritance of configs up to this point in the chain. + - `loadError` Any errors encountered that prevented the loading of this config data. +- `config.list` A list sorted in priority of all the config data objects in the prototype chain. +`config.list[0]` is the `cli` level, `config.list[1]` is the `env` level, and so on. - `cwd` The `cwd` param - `env` The `env` param @@ -166,21 +148,17 @@ Fields: - `npmPath` The `npmPath` param - `globalPrefix` The effective `globalPrefix` - `localPrefix` The effective `localPrefix` -- `prefix` If `config.get('global')` is true, then `globalPrefix`, - otherwise `localPrefix` -- `home` The user's home directory, found by looking at `env.HOME` or - calling `os.homedir()`. +- `prefix` If `config.get('global')` is true, then `globalPrefix`, otherwise `localPrefix` +- `home` The user's home directory, found by looking at `env.HOME` or calling `os.homedir()`. - `loaded` A boolean indicating whether or not configs are loaded - `valid` A getter that returns `true` if all the config objects are valid. - Any data objects that have been modified with `config.set(...)` will be - re-evaluated when `config.valid` is read. + Any data objects that have been modified with `config.set(...)` will be re-evaluated when `config.valid` is read. ### `config.load()` Load configuration from the various sources of information. -Returns a `Promise` that resolves when configuration is loaded, and fails -if a fatal error is encountered. +Returns a `Promise` that resolves when configuration is loaded, and fails if a fatal error is encountered. ### `config.find(key)` @@ -196,8 +174,7 @@ Load the given key from the config stack. ### `config.set(key, value, where = 'cli')` -Set the key to the specified value, at the specified level in the config -stack. +Set the key to the specified value, at the specified level in the config stack. ### `config.delete(key, where = 'cli')` @@ -205,12 +182,9 @@ Delete the configuration key from the specified level in the config stack. ### `config.validate(where)` -Verify that all known configuration options are set to valid values, and -log a warning if they are invalid. +Verify that all known configuration options are set to valid values, and log a warning if they are invalid. -Invalid auth options will cause this method to throw an error with a `code` -property of `ERR_INVALID_AUTH`, and a `problems` property listing the specific -concerns with the current configuration. +Invalid auth options will cause this method to throw an error with a `code` property of `ERR_INVALID_AUTH`, and a `problems` property listing the specific concerns with the current configuration. If `where` is not set, then all config objects are validated. @@ -222,30 +196,24 @@ Note that it's usually enough (and more efficient) to just check ### `config.repair(problems)` -Accept an optional array of problems (as thrown by `config.validate()`) and -perform the necessary steps to resolve them. If no problems are provided, -this method will call `config.validate()` internally to retrieve them. +Accept an optional array of problems (as thrown by `config.validate()`) and perform the necessary steps to resolve them. +If no problems are provided, this method will call `config.validate()` internally to retrieve them. Note that you must `await config.save('user')` in order to persist the changes. ### `config.isDefault(key)` -Returns `true` if the value is coming directly from the -default definitions, if the current value for the key config is -coming from any other source, returns `false`. +Returns `true` if the value is coming directly from the default definitions, if the current value for the key config is coming from any other source, returns `false`. This method can be used for avoiding or tweaking default values, e.g: -> Given a global default definition of foo='foo' it's possible to read that -> value such as: +> Given a global default definition of foo='foo' it's possible to read that value such as: > > ```js > const save = config.get('foo') > ``` > -> Now in a different place of your app it's possible to avoid using the `foo` -> default value, by checking to see if the current config value is currently -> one that was defined by the default definitions: +> Now in a different place of your app it's possible to avoid using the `foo` default value, by checking to see if the current config value is currently one that was defined by the default definitions: > > ```js > const save = config.isDefault('foo') ? 'bar' : config.get('foo') @@ -253,5 +221,6 @@ This method can be used for avoiding or tweaking default values, e.g: ### `config.save(where)` -Save the config file specified by the `where` param. Must be one of +Save the config file specified by the `where` param. +Must be one of `project`, `user`, `global`, `builtin`. diff --git a/deps/npm/node_modules/@npmcli/config/lib/definitions/definition.js b/deps/npm/node_modules/@npmcli/config/lib/definitions/definition.js index 333a91928526ed..26ba0c0bc14b9a 100644 --- a/deps/npm/node_modules/@npmcli/config/lib/definitions/definition.js +++ b/deps/npm/node_modules/@npmcli/config/lib/definitions/definition.js @@ -34,7 +34,7 @@ const { class Definition { constructor (key, def) { this.key = key - // if it's set falsey, don't export it, otherwise we do by default + // if it's set falsey, don't export it; otherwise, we do by default this.envExport = true Object.assign(this, def) this.validate() @@ -83,7 +83,7 @@ This value is not exported to the environment for child processes. ` const deprecated = !this.deprecated ? '' : `* DEPRECATED: ${unindent(this.deprecated)}\n` /* eslint-disable-next-line max-len */ - const exclusive = !this.exclusive ? '' : `\nThis config can not be used with: \`${this.exclusive.join('`, `')}\`` + const exclusive = !this.exclusive ? '' : `\nThis config cannot be used with: \`${this.exclusive.join('`, `')}\`` return wrapAll(`#### \`${this.key}\` * Default: ${unindent(this.defaultDescription)} diff --git a/deps/npm/node_modules/@npmcli/config/lib/definitions/definitions.js b/deps/npm/node_modules/@npmcli/config/lib/definitions/definitions.js index cb5c4e41fd6e9e..739428508d2fe9 100644 --- a/deps/npm/node_modules/@npmcli/config/lib/definitions/definitions.js +++ b/deps/npm/node_modules/@npmcli/config/lib/definitions/definitions.js @@ -158,7 +158,7 @@ const definitions = { If you do not want your scoped package to be publicly viewable (and installable) set \`--access=restricted\`. - Unscoped packages can not be set to \`restricted\`. + Unscoped packages cannot be set to \`restricted\`. Note: This defaults to not changing the current access level for existing packages. Specifying a value of \`restricted\` or \`public\` during @@ -462,7 +462,7 @@ const definitions = { depth: new Definition('depth', { default: null, defaultDescription: ` - \`Infinity\` if \`--all\` is set, otherwise \`0\` + \`Infinity\` if \`--all\` is set; otherwise, \`0\` `, type: [null, Number], description: ` @@ -1205,7 +1205,7 @@ const definitions = { default: null, type: [null, 1, 2, 3, '1', '2', '3'], defaultDescription: ` - Version 3 if no lockfile, auto-converting v1 lockfiles to v3, otherwise + Version 3 if no lockfile, auto-converting v1 lockfiles to v3; otherwise, maintain current lockfile version.`, description: ` Set the lockfile format version to be used in package-lock.json and @@ -1304,7 +1304,13 @@ const definitions = { flatten, }), 'node-gyp': new Definition('node-gyp', { - default: require.resolve('node-gyp/bin/node-gyp.js'), + default: (() => { + try { + return require.resolve('node-gyp/bin/node-gyp.js') + } catch { + return '' + } + })(), defaultDescription: ` The path to the node-gyp bin that ships with npm `, @@ -1356,8 +1362,8 @@ const definitions = { omit: new Definition('omit', { default: process.env.NODE_ENV === 'production' ? ['dev'] : [], defaultDescription: ` - 'dev' if the \`NODE_ENV\` environment variable is set to 'production', - otherwise empty. + 'dev' if the \`NODE_ENV\` environment variable is set to 'production'; + otherwise, empty. `, type: [Array, 'dev', 'optional', 'peer'], description: ` diff --git a/deps/npm/node_modules/@npmcli/config/lib/index.js b/deps/npm/node_modules/@npmcli/config/lib/index.js index 9c1fad0c59f620..b56c461991c5c0 100644 --- a/deps/npm/node_modules/@npmcli/config/lib/index.js +++ b/deps/npm/node_modules/@npmcli/config/lib/index.js @@ -281,7 +281,7 @@ class Config { } try { - // This does not have an actual definition because this is not user defineable + // This does not have an actual definition because this is not user definable defaultsObject['npm-version'] = require(join(this.npmPath, 'package.json')).version } catch { // in some weird state where the passed in npmPath does not have a package.json @@ -589,7 +589,7 @@ class Config { if (this.definitions[key]?.exclusive) { for (const exclusive of this.definitions[key].exclusive) { if (!this.isDefault(exclusive)) { - throw new TypeError(`--${key} can not be provided when using --${exclusive}`) + throw new TypeError(`--${key} cannot be provided when using --${exclusive}`) } } } @@ -672,7 +672,7 @@ class Config { // if we're in the ~ directory, and there happens to be a node_modules // folder (which is not TOO uncommon, it turns out), then we can end // up loading the "project" config where the "userconfig" will be, - // which causes some calamaties. So, we only load project config if + // which causes some calamities. So, we only load project config if // it doesn't match what the userconfig will be. if (projectFile !== this.#get('userconfig')) { return this.#loadFile(projectFile, 'project') diff --git a/deps/npm/node_modules/@npmcli/config/lib/set-envs.js b/deps/npm/node_modules/@npmcli/config/lib/set-envs.js index 30e175dae867f2..12719b56478363 100644 --- a/deps/npm/node_modules/@npmcli/config/lib/set-envs.js +++ b/deps/npm/node_modules/@npmcli/config/lib/set-envs.js @@ -97,7 +97,7 @@ const setEnvs = (config) => { env.EDITOR = cliConf.editor } - // note: this doesn't afect the *current* node process, of course, since + // note: this doesn't affect the *current* node process, of course, since // it's already started, but it does affect the options passed to scripts. if (cliConf['node-options']) { env.NODE_OPTIONS = cliConf['node-options'] diff --git a/deps/npm/node_modules/@npmcli/config/package.json b/deps/npm/node_modules/@npmcli/config/package.json index 71d56eb8379d03..651e2135893f48 100644 --- a/deps/npm/node_modules/@npmcli/config/package.json +++ b/deps/npm/node_modules/@npmcli/config/package.json @@ -1,6 +1,6 @@ { "name": "@npmcli/config", - "version": "10.4.1", + "version": "10.4.2", "files": [ "bin/", "lib/" diff --git a/deps/npm/node_modules/@sigstore/sign/dist/util/oidc.js b/deps/npm/node_modules/@sigstore/sign/dist/util/oidc.js index 37c5b168ee12e6..a9a3b10d3f61ad 100644 --- a/deps/npm/node_modules/@sigstore/sign/dist/util/oidc.js +++ b/deps/npm/node_modules/@sigstore/sign/dist/util/oidc.js @@ -20,11 +20,16 @@ const core_1 = require("@sigstore/core"); function extractJWTSubject(jwt) { const parts = jwt.split('.', 3); const payload = JSON.parse(core_1.encoding.base64Decode(parts[1])); - switch (payload.iss) { - case 'https://accounts.google.com': - case 'https://oauth2.sigstore.dev/auth': - return payload.email; - default: - return payload.sub; + if (payload.email) { + if (!payload.email_verified) { + throw new Error('JWT email not verified by issuer'); + } + return payload.email; + } + if (payload.sub) { + return payload.sub; + } + else { + throw new Error('JWT subject not found'); } } diff --git a/deps/npm/node_modules/@sigstore/sign/package.json b/deps/npm/node_modules/@sigstore/sign/package.json index 4059997ced341b..a24f8e87ff3494 100644 --- a/deps/npm/node_modules/@sigstore/sign/package.json +++ b/deps/npm/node_modules/@sigstore/sign/package.json @@ -1,6 +1,6 @@ { "name": "@sigstore/sign", - "version": "4.0.0", + "version": "4.0.1", "description": "Sigstore signing library", "main": "dist/index.js", "types": "dist/index.d.ts", @@ -36,7 +36,7 @@ "@sigstore/bundle": "^4.0.0", "@sigstore/core": "^3.0.0", "@sigstore/protobuf-specs": "^0.5.0", - "make-fetch-happen": "^15.0.0", + "make-fetch-happen": "^15.0.2", "proc-log": "^5.0.0", "promise-retry": "^2.0.1" }, diff --git a/deps/npm/node_modules/ci-info/index.js b/deps/npm/node_modules/ci-info/index.js index 75695253adb477..38056d9aa8772a 100644 --- a/deps/npm/node_modules/ci-info/index.js +++ b/deps/npm/node_modules/ci-info/index.js @@ -15,22 +15,24 @@ exports.name = null exports.isPR = null exports.id = null -vendors.forEach(function (vendor) { - const envs = Array.isArray(vendor.env) ? vendor.env : [vendor.env] - const isCI = envs.every(function (obj) { - return checkEnv(obj) - }) +if (env.CI !== 'false') { + vendors.forEach(function (vendor) { + const envs = Array.isArray(vendor.env) ? vendor.env : [vendor.env] + const isCI = envs.every(function (obj) { + return checkEnv(obj) + }) - exports[vendor.constant] = isCI + exports[vendor.constant] = isCI - if (!isCI) { - return - } + if (!isCI) { + return + } - exports.name = vendor.name - exports.isPR = checkPR(vendor) - exports.id = vendor.constant -}) + exports.name = vendor.name + exports.isPR = checkPR(vendor) + exports.id = vendor.constant + }) +} exports.isCI = !!( env.CI !== 'false' && // Bypass all checks if CI env is explicitly set to 'false' diff --git a/deps/npm/node_modules/ci-info/package.json b/deps/npm/node_modules/ci-info/package.json index 8ce80ae1ee8473..1e47fe0092d3a0 100644 --- a/deps/npm/node_modules/ci-info/package.json +++ b/deps/npm/node_modules/ci-info/package.json @@ -1,6 +1,6 @@ { "name": "ci-info", - "version": "4.3.0", + "version": "4.3.1", "description": "Get details about the current Continuous Integration environment", "main": "index.js", "typings": "index.d.ts", diff --git a/deps/npm/node_modules/cidr-regex/package.json b/deps/npm/node_modules/cidr-regex/package.json index 7e8cf3e044a2d2..662f89261b01c6 100644 --- a/deps/npm/node_modules/cidr-regex/package.json +++ b/deps/npm/node_modules/cidr-regex/package.json @@ -1,6 +1,6 @@ { "name": "cidr-regex", - "version": "5.0.0", + "version": "5.0.1", "description": "Regular expression for matching IP addresses in CIDR notation", "author": "silverwind ", "contributors": [ @@ -20,18 +20,18 @@ "node": ">=20" }, "dependencies": { - "ip-regex": "^5.0.0" + "ip-regex": "5.0.0" }, "devDependencies": { - "@types/node": "24.1.0", - "eslint": "8.57.0", - "eslint-config-silverwind": "101.4.1", - "typescript": "5.8.3", - "typescript-config-silverwind": "9.0.8", - "updates": "16.5.2", - "versions": "13.1.1", - "vite": "7.0.6", - "vite-config-silverwind": "5.4.0", + "@types/node": "24.5.2", + "eslint": "9.36.0", + "eslint-config-silverwind": "105.1.0", + "typescript": "5.9.2", + "typescript-config-silverwind": "10.0.1", + "updates": "16.7.2", + "versions": "13.1.2", + "vite": "7.1.7", + "vite-config-silverwind": "6.0.2", "vitest": "3.2.4", "vitest-config-silverwind": "10.2.0" } diff --git a/deps/npm/node_modules/hosted-git-info/lib/hosts.js b/deps/npm/node_modules/hosted-git-info/lib/hosts.js index 2a88e95927772a..6e7c123dbff8b4 100644 --- a/deps/npm/node_modules/hosted-git-info/lib/hosts.js +++ b/deps/npm/node_modules/hosted-git-info/lib/hosts.js @@ -109,8 +109,6 @@ hosts.gitlab = { treepath: 'tree', blobpath: 'tree', editpath: '-/edit', - httpstemplate: ({ auth, domain, user, project, committish }) => - `git+https://${maybeJoin(auth, '@')}${domain}/${user}/${project}.git${maybeJoin('#', committish)}`, tarballtemplate: ({ domain, user, project, committish }) => `https://${domain}/${user}/${project}/repository/archive.tar.gz?ref=${maybeEncode(committish || 'HEAD')}`, extract: (url) => { diff --git a/deps/npm/node_modules/hosted-git-info/lib/parse-url.js b/deps/npm/node_modules/hosted-git-info/lib/parse-url.js index 7d5489c008ab4a..bfd54b9140c116 100644 --- a/deps/npm/node_modules/hosted-git-info/lib/parse-url.js +++ b/deps/npm/node_modules/hosted-git-info/lib/parse-url.js @@ -21,20 +21,23 @@ const correctProtocol = (arg, protocols) => { return arg } + if (arg.substr(firstColon, 3) === '://') { + // If arg is given as ://, then this is already a valid URL. + return arg + } + const firstAt = arg.indexOf('@') if (firstAt > -1) { if (firstAt > firstColon) { + // URL has the form of :@. Assume this is a git+ssh URL. return `git+ssh://${arg}` } else { + // URL has the form 'git@github.com:npm/hosted-git-info.git'. return arg } } - const doubleSlash = arg.indexOf('//') - if (doubleSlash === firstColon + 1) { - return arg - } - + // Correct : to :// return `${arg.slice(0, firstColon + 1)}//${arg.slice(firstColon + 1)}` } diff --git a/deps/npm/node_modules/hosted-git-info/package.json b/deps/npm/node_modules/hosted-git-info/package.json index 5883a7d308d794..1e74eda1656d78 100644 --- a/deps/npm/node_modules/hosted-git-info/package.json +++ b/deps/npm/node_modules/hosted-git-info/package.json @@ -1,6 +1,6 @@ { "name": "hosted-git-info", - "version": "9.0.0", + "version": "9.0.2", "description": "Provides metadata and conversions from repository urls for GitHub, Bitbucket and GitLab", "main": "./lib/index.js", "repository": { @@ -35,7 +35,7 @@ }, "devDependencies": { "@npmcli/eslint-config": "^5.0.0", - "@npmcli/template-oss": "4.25.0", + "@npmcli/template-oss": "4.25.1", "tap": "^16.0.1" }, "files": [ @@ -55,7 +55,7 @@ }, "templateOSS": { "//@npmcli/template-oss": "This file is partially managed by @npmcli/template-oss. Edits may be overwritten.", - "version": "4.25.0", + "version": "4.25.1", "publish": "true" } } diff --git a/deps/npm/node_modules/is-cidr/package.json b/deps/npm/node_modules/is-cidr/package.json index 267af3c20fc5b3..3a8a966578478a 100644 --- a/deps/npm/node_modules/is-cidr/package.json +++ b/deps/npm/node_modules/is-cidr/package.json @@ -1,6 +1,6 @@ { "name": "is-cidr", - "version": "6.0.0", + "version": "6.0.1", "description": "Check if a string is an IP address in CIDR notation", "author": "silverwind ", "contributors": [ @@ -20,18 +20,18 @@ "node": ">=20" }, "dependencies": { - "cidr-regex": "^5.0.0" + "cidr-regex": "5.0.1" }, "devDependencies": { - "@types/node": "24.1.0", - "eslint": "8.57.0", - "eslint-config-silverwind": "101.4.1", - "typescript": "5.8.3", - "typescript-config-silverwind": "9.0.8", - "updates": "16.5.2", - "versions": "13.1.1", - "vite": "7.0.6", - "vite-config-silverwind": "5.4.0", + "@types/node": "24.5.2", + "eslint": "9.36.0", + "eslint-config-silverwind": "105.1.0", + "typescript": "5.9.2", + "typescript-config-silverwind": "10.0.1", + "updates": "16.7.2", + "versions": "13.1.2", + "vite": "7.1.7", + "vite-config-silverwind": "6.0.2", "vitest": "3.2.4", "vitest-config-silverwind": "10.2.0" } diff --git a/deps/npm/node_modules/libnpmaccess/README.md b/deps/npm/node_modules/libnpmaccess/README.md index 8580ba9ec1c4f7..233b61e65ea1ad 100644 --- a/deps/npm/node_modules/libnpmaccess/README.md +++ b/deps/npm/node_modules/libnpmaccess/README.md @@ -81,7 +81,7 @@ cannot be used to publish. - `automation`: mfa is required to publish this package, automation tokens may also be used for publishing from continuous integration workflows. -#### access.setPermissions(team, spec, permssions, opts) -> Promise` +#### access.setPermissions(team, spec, permissions, opts) -> Promise` Sets permissions levels for a given team to a package. diff --git a/deps/npm/node_modules/libnpmaccess/lib/index.js b/deps/npm/node_modules/libnpmaccess/lib/index.js index fca0e47279bfb9..71ba6ea352acd1 100644 --- a/deps/npm/node_modules/libnpmaccess/lib/index.js +++ b/deps/npm/node_modules/libnpmaccess/lib/index.js @@ -73,7 +73,7 @@ const setMfa = async (pkg, level, opts) => { body.publish_requires_tfa = false break case 'publish': - // tfa is required, automation tokens can not override tfa + // tfa is required, automation tokens cannot override tfa body.publish_requires_tfa = true body.automation_token_overrides_tfa = false break diff --git a/deps/npm/node_modules/libnpmaccess/package.json b/deps/npm/node_modules/libnpmaccess/package.json index 365b02d10464c2..b9ef72d8384606 100644 --- a/deps/npm/node_modules/libnpmaccess/package.json +++ b/deps/npm/node_modules/libnpmaccess/package.json @@ -1,6 +1,6 @@ { "name": "libnpmaccess", - "version": "10.0.2", + "version": "10.0.3", "description": "programmatic library for `npm access` commands", "author": "GitHub Inc.", "license": "ISC", diff --git a/deps/npm/node_modules/libnpmdiff/README.md b/deps/npm/node_modules/libnpmdiff/README.md index 0f8205c7004400..68fcd88af2d791 100644 --- a/deps/npm/node_modules/libnpmdiff/README.md +++ b/deps/npm/node_modules/libnpmdiff/README.md @@ -52,15 +52,11 @@ index v1.1.0..v1.1.1 100644 ### Contributing The npm team enthusiastically welcomes contributions and project participation! -There's a bunch of things you can do if you want to contribute! The -[Contributor Guide](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md) -outlines the process for community interaction and contribution. Please don't -hesitate to jump in if you'd like to, or even ask us questions if something -isn't clear. +There's a bunch of things you can do if you want to contribute! +The [Contributor Guide](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md) outlines the process for community interaction and contribution. +Please don't hesitate to jump in if you'd like to, or even ask us questions if something isn't clear. -All participants and maintainers in this project are expected to follow the -[npm Code of Conduct](https://docs.npmjs.com/policies/conduct), and just -generally be excellent to each other. +All participants and maintainers in this project are expected to follow the [npm Code of Conduct](https://docs.npmjs.com/policies/conduct), and just generally be excellent to each other. Please refer to the [Changelog](CHANGELOG.md) for project history details, too. @@ -70,23 +66,34 @@ Happy hacking! #### `> libnpmdif([ a, b ], [opts]) -> Promise` -Fetches the registry tarballs and compare files between a spec `a` and spec `b`. **npm** spec types are usually described in `@` form but multiple other types are alsos supported, for more info on valid specs take a look at [`npm-package-arg`](https://github.com/npm/npm-package-arg). +Fetches the registry tarballs and compare files between a spec `a` and spec `b`. +**npm** spec types are usually described in `@` form but multiple other types are also supported, for more info on valid specs take a look at [`npm-package-arg`](https://github.com/npm/npm-package-arg). **Options**: -- `color `: Should add ANSI colors to string output? Defaults to `false`. -- `tagVersionPrefix `: What prefix should be used to define version numbers. Defaults to `v` -- `diffUnified `: How many lines of code to print before/after each diff. Defaults to `3`. -- `diffFiles >`: If set only prints patches for the files listed in this array (also accepts globs). Defaults to `undefined`. -- `diffIgnoreAllSpace `: Whether or not should ignore changes in whitespace (very useful to avoid indentation changes extra diff lines). Defaults to `false`. -- `diffNameOnly `: Prints only file names and no patch diffs. Defaults to `false`. -- `diffNoPrefix `: If true then skips printing any prefixes in filenames. Defaults to `false`. -- `diffSrcPrefix `: Prefix to be used in the filenames from `a`. Defaults to `a/`. -- `diffDstPrefix `: Prefix to be used in the filenames from `b`. Defaults to `b/`. -- `diffText `: Should treat all files as text and try to print diff for binary files. Defaults to `false`. +- `color `: Should add ANSI colors to string output? + Defaults to `false`. +- `tagVersionPrefix `: What prefix should be used to define version numbers. + Defaults to `v` +- `diffUnified `: How many lines of code to print before/after each diff. + Defaults to `3`. +- `diffFiles >`: If set only prints patches for the files listed in this array (also accepts globs). + Defaults to `undefined`. +- `diffIgnoreAllSpace `: Whether or not should ignore changes in whitespace (very useful to avoid indentation changes extra diff lines). + Defaults to `false`. +- `diffNameOnly `: Prints only file names and no patch diffs. + Defaults to `false`. +- `diffNoPrefix `: If true then skips printing any prefixes in filenames. + Defaults to `false`. +- `diffSrcPrefix `: Prefix to be used in the filenames from `a`. + Defaults to `a/`. +- `diffDstPrefix `: Prefix to be used in the filenames from `b`. + Defaults to `b/`. +- `diffText `: Should treat all files as text and try to print diff for binary files. + Defaults to `false`. - ...`cache`, `registry`, `where` and other common options accepted by [pacote](https://github.com/npm/pacote#options) -Returns a `Promise` that fullfils with a `String` containing the resulting patch diffs. +Returns a `Promise` that fulfills with a `String` containing the resulting patch diffs. Throws an error if either `a` or `b` are missing or if trying to diff more than two specs. diff --git a/deps/npm/node_modules/libnpmdiff/package.json b/deps/npm/node_modules/libnpmdiff/package.json index cd72fea7a2bc89..ff894976468dbc 100644 --- a/deps/npm/node_modules/libnpmdiff/package.json +++ b/deps/npm/node_modules/libnpmdiff/package.json @@ -1,6 +1,6 @@ { "name": "libnpmdiff", - "version": "8.0.8", + "version": "8.0.9", "description": "The registry diff", "repository": { "type": "git", @@ -47,7 +47,7 @@ "tap": "^16.3.8" }, "dependencies": { - "@npmcli/arborist": "^9.1.5", + "@npmcli/arborist": "^9.1.6", "@npmcli/installed-package-contents": "^3.0.0", "binary-extensions": "^3.0.0", "diff": "^8.0.2", diff --git a/deps/npm/node_modules/libnpmexec/README.md b/deps/npm/node_modules/libnpmexec/README.md index acd037c110b4ba..84512ac590498a 100644 --- a/deps/npm/node_modules/libnpmexec/README.md +++ b/deps/npm/node_modules/libnpmexec/README.md @@ -40,7 +40,7 @@ await libexec({ - `runPath`: Location to where to execute the script **String**, defaults to `.` - `scriptShell`: Default shell to be used **String**, defaults to `sh` on POSIX systems, `process.env.ComSpec` OR `cmd` on Windows - `yes`: Should skip download confirmation prompt when fetching missing packages from the registry? **Boolean** - - `registry`, `cache`, and more options that are forwarded to [@npmcli/arborist](https://github.com/npm/arborist/) and [pacote](https://github.com/npm/pacote/#options) **Object** + - `registry`, `cache`, and more options that are forwarded to [@npmcli/arborist](https://github.com/npm/cli/blob/latest/workspaces/arborist/README.md) and [pacote](https://github.com/npm/pacote/#options) **Object** ## LICENSE diff --git a/deps/npm/node_modules/libnpmexec/lib/get-bin-from-manifest.js b/deps/npm/node_modules/libnpmexec/lib/get-bin-from-manifest.js index 8ebc0e7a18bd25..cede563c96a0de 100644 --- a/deps/npm/node_modules/libnpmexec/lib/get-bin-from-manifest.js +++ b/deps/npm/node_modules/libnpmexec/lib/get-bin-from-manifest.js @@ -1,7 +1,7 @@ const getBinFromManifest = (mani) => { // if we have a bin matching (unscoped portion of) packagename, use that // otherwise if there's 1 bin or all bin value is the same (alias), use - // that, otherwise fail + // that; otherwise, fail const bin = mani.bin || {} if (new Set(Object.values(bin)).size === 1) { return Object.keys(bin)[0] diff --git a/deps/npm/node_modules/libnpmexec/package.json b/deps/npm/node_modules/libnpmexec/package.json index ab04163704c0f1..d06081ce21a609 100644 --- a/deps/npm/node_modules/libnpmexec/package.json +++ b/deps/npm/node_modules/libnpmexec/package.json @@ -1,6 +1,6 @@ { "name": "libnpmexec", - "version": "10.1.7", + "version": "10.1.8", "files": [ "bin/", "lib/" @@ -60,7 +60,7 @@ "tap": "^16.3.8" }, "dependencies": { - "@npmcli/arborist": "^9.1.5", + "@npmcli/arborist": "^9.1.6", "@npmcli/package-json": "^7.0.0", "@npmcli/run-script": "^10.0.0", "ci-info": "^4.0.0", diff --git a/deps/npm/node_modules/libnpmfund/README.md b/deps/npm/node_modules/libnpmfund/README.md index 6072b11d9dee7d..2b5b283014c861 100644 --- a/deps/npm/node_modules/libnpmfund/README.md +++ b/deps/npm/node_modules/libnpmfund/README.md @@ -75,14 +75,14 @@ things such as printing a `6 packages are looking for funding` msg. - `workspaces`: `Array` List of workspaces names to filter for, the result will only include a subset of the resulting tree that includes only the nodes that are children of the listed workspaces names. -- `path`, `registry` and more [Arborist](https://github.com/npm/arborist/) options. +- `path`, `registry` and more [Arborist options](https://github.com/npm/cli/blob/latest/workspaces/arborist/README.md#usage). ##### `> fund.readTree(tree, [opts]) -> Promise` Reads **funding** info from a given install tree and returns a tree object that only contains packages in which funding info is defined. -- `tree`: An [`arborist`](https://github.com/npm/arborist) tree to be used, e.g: +- `tree`: An [`arborist`](https://github.com/npm/cli/blob/latest/workspaces/arborist/README.md) tree to be used, e.g: ```js const Arborist = require('@npmcli/arborist') diff --git a/deps/npm/node_modules/libnpmfund/package.json b/deps/npm/node_modules/libnpmfund/package.json index 6f18b9969d96b2..7b9bf8e703a5f5 100644 --- a/deps/npm/node_modules/libnpmfund/package.json +++ b/deps/npm/node_modules/libnpmfund/package.json @@ -1,6 +1,6 @@ { "name": "libnpmfund", - "version": "7.0.8", + "version": "7.0.9", "main": "lib/index.js", "files": [ "bin/", @@ -46,7 +46,7 @@ "tap": "^16.3.8" }, "dependencies": { - "@npmcli/arborist": "^9.1.5" + "@npmcli/arborist": "^9.1.6" }, "engines": { "node": "^20.17.0 || >=22.9.0" diff --git a/deps/npm/node_modules/libnpmpack/package.json b/deps/npm/node_modules/libnpmpack/package.json index 740a9bc3a44c81..dc4def4651723c 100644 --- a/deps/npm/node_modules/libnpmpack/package.json +++ b/deps/npm/node_modules/libnpmpack/package.json @@ -1,6 +1,6 @@ { "name": "libnpmpack", - "version": "9.0.8", + "version": "9.0.9", "description": "Programmatic API for the bits behind npm pack", "author": "GitHub Inc.", "main": "lib/index.js", @@ -37,7 +37,7 @@ "bugs": "https://github.com/npm/libnpmpack/issues", "homepage": "https://npmjs.com/package/libnpmpack", "dependencies": { - "@npmcli/arborist": "^9.1.5", + "@npmcli/arborist": "^9.1.6", "@npmcli/run-script": "^10.0.0", "npm-package-arg": "^13.0.0", "pacote": "^21.0.2" diff --git a/deps/npm/node_modules/libnpmpublish/package.json b/deps/npm/node_modules/libnpmpublish/package.json index d316bcdfcaa1e4..d9f00aaffac6c5 100644 --- a/deps/npm/node_modules/libnpmpublish/package.json +++ b/deps/npm/node_modules/libnpmpublish/package.json @@ -1,6 +1,6 @@ { "name": "libnpmpublish", - "version": "11.1.1", + "version": "11.1.2", "description": "Programmatic API for the bits behind npm publish and unpublish", "author": "GitHub Inc.", "main": "lib/index.js", diff --git a/deps/npm/node_modules/libnpmversion/README.md b/deps/npm/node_modules/libnpmversion/README.md index 857c4d52dc1831..b81a231d05ce04 100644 --- a/deps/npm/node_modules/libnpmversion/README.md +++ b/deps/npm/node_modules/libnpmversion/README.md @@ -15,8 +15,8 @@ const npmVersion = require('libnpmversion') // - any semver version string (set to that exact version) // - 'major', 'minor', 'patch', 'pre{major,minor,patch}' (increment at // that value) -// - 'from-git' (set to the latest semver-lookin git tag - this skips -// gitTagVersion, but will still sign if asked) +// - 'from-git' (set to the latest tag in git that looks like semver - +// this skips gitTagVersion, but will still sign if asked) npmVersion(arg, { path: '/path/to/my/pkg', // defaults to cwd @@ -114,7 +114,7 @@ all is well, or rejects if any errors are encountered. #### `path` String -The path to the package being versionified. Defaults to process.cwd(). +The path to the package being versioned. Defaults to process.cwd(). #### `allowSameVersion` Boolean diff --git a/deps/npm/node_modules/lru-cache/dist/commonjs/index.js b/deps/npm/node_modules/lru-cache/dist/commonjs/index.js index 13c1f604679017..71e5f56c375459 100644 --- a/deps/npm/node_modules/lru-cache/dist/commonjs/index.js +++ b/deps/npm/node_modules/lru-cache/dist/commonjs/index.js @@ -1170,7 +1170,11 @@ class LRUCache { } // either we didn't abort, and are still here, or we did, and ignored const bf = p; - if (this.#valList[index] === p) { + // if nothing else has been written there but we're set to update the + // cache and ignore the abort, or if it's still pending on this specific + // background request, then write it to the cache. + const vl = this.#valList[index]; + if (vl === p || ignoreAbort && updateCache && vl === undefined) { if (v === undefined) { if (bf.__staleWhileFetching !== undefined) { this.#valList[index] = bf.__staleWhileFetching; diff --git a/deps/npm/node_modules/lru-cache/dist/commonjs/index.min.js b/deps/npm/node_modules/lru-cache/dist/commonjs/index.min.js index ef5027b91650d9..be835d75ffb542 100644 --- a/deps/npm/node_modules/lru-cache/dist/commonjs/index.min.js +++ b/deps/npm/node_modules/lru-cache/dist/commonjs/index.min.js @@ -1,2 +1,2 @@ -"use strict";Object.defineProperty(exports,"__esModule",{value:!0});exports.LRUCache=void 0;var M=typeof performance=="object"&&performance&&typeof performance.now=="function"?performance:Date,x=new Set,R=typeof process=="object"&&process?process:{},U=(a,t,e,i)=>{typeof R.emitWarning=="function"?R.emitWarning(a,t,e,i):console.error(`[${e}] ${t}: ${a}`)},C=globalThis.AbortController,L=globalThis.AbortSignal;if(typeof C>"u"){L=class{onabort;_onabort=[];reason;aborted=!1;addEventListener(i,s){this._onabort.push(s)}},C=class{constructor(){t()}signal=new L;abort(i){if(!this.signal.aborted){this.signal.reason=i,this.signal.aborted=!0;for(let s of this.signal._onabort)s(i);this.signal.onabort?.(i)}}};let a=R.env?.LRU_CACHE_IGNORE_AC_WARNING!=="1",t=()=>{a&&(a=!1,U("AbortController is not defined. If using lru-cache in node 14, load an AbortController polyfill from the `node-abort-controller` package. A minimal polyfill is provided for use by LRUCache.fetch(), but it should not be relied upon in other contexts (eg, passing it to other APIs that use AbortController/AbortSignal might have undesirable effects). You may disable this with LRU_CACHE_IGNORE_AC_WARNING=1 in the env.","NO_ABORT_CONTROLLER","ENOTSUP",t))}}var G=a=>!x.has(a),H=Symbol("type"),y=a=>a&&a===Math.floor(a)&&a>0&&isFinite(a),I=a=>y(a)?a<=Math.pow(2,8)?Uint8Array:a<=Math.pow(2,16)?Uint16Array:a<=Math.pow(2,32)?Uint32Array:a<=Number.MAX_SAFE_INTEGER?E:null:null,E=class extends Array{constructor(t){super(t),this.fill(0)}},W=class a{heap;length;static#l=!1;static create(t){let e=I(t);if(!e)return[];a.#l=!0;let i=new a(t,e);return a.#l=!1,i}constructor(t,e){if(!a.#l)throw new TypeError("instantiate Stack using Stack.create(n)");this.heap=new e(t),this.length=0}push(t){this.heap[this.length++]=t}pop(){return this.heap[--this.length]}},D=class a{#l;#c;#p;#v;#w;#D;#L;#S;get perf(){return this.#S}ttl;ttlResolution;ttlAutopurge;updateAgeOnGet;updateAgeOnHas;allowStale;noDisposeOnSet;noUpdateTTL;maxEntrySize;sizeCalculation;noDeleteOnFetchRejection;noDeleteOnStaleGet;allowStaleOnFetchAbort;allowStaleOnFetchRejection;ignoreFetchAbort;#n;#_;#s;#i;#t;#a;#u;#o;#h;#m;#r;#b;#y;#d;#A;#z;#f;#x;static unsafeExposeInternals(t){return{starts:t.#y,ttls:t.#d,sizes:t.#b,keyMap:t.#s,keyList:t.#i,valList:t.#t,next:t.#a,prev:t.#u,get head(){return t.#o},get tail(){return t.#h},free:t.#m,isBackgroundFetch:e=>t.#e(e),backgroundFetch:(e,i,s,n)=>t.#M(e,i,s,n),moveToTail:e=>t.#W(e),indexes:e=>t.#F(e),rindexes:e=>t.#T(e),isStale:e=>t.#g(e)}}get max(){return this.#l}get maxSize(){return this.#c}get calculatedSize(){return this.#_}get size(){return this.#n}get fetchMethod(){return this.#D}get memoMethod(){return this.#L}get dispose(){return this.#p}get onInsert(){return this.#v}get disposeAfter(){return this.#w}constructor(t){let{max:e=0,ttl:i,ttlResolution:s=1,ttlAutopurge:n,updateAgeOnGet:h,updateAgeOnHas:o,allowStale:r,dispose:g,onInsert:_,disposeAfter:f,noDisposeOnSet:c,noUpdateTTL:u,maxSize:A=0,maxEntrySize:d=0,sizeCalculation:m,fetchMethod:l,memoMethod:w,noDeleteOnFetchRejection:b,noDeleteOnStaleGet:p,allowStaleOnFetchRejection:S,allowStaleOnFetchAbort:z,ignoreFetchAbort:F,perf:v}=t;if(v!==void 0&&typeof v?.now!="function")throw new TypeError("perf option must have a now() method if specified");if(this.#S=v??M,e!==0&&!y(e))throw new TypeError("max option must be a nonnegative integer");let T=e?I(e):Array;if(!T)throw new Error("invalid max value: "+e);if(this.#l=e,this.#c=A,this.maxEntrySize=d||this.#c,this.sizeCalculation=m,this.sizeCalculation){if(!this.#c&&!this.maxEntrySize)throw new TypeError("cannot set sizeCalculation without setting maxSize or maxEntrySize");if(typeof this.sizeCalculation!="function")throw new TypeError("sizeCalculation set to non-function")}if(w!==void 0&&typeof w!="function")throw new TypeError("memoMethod must be a function if defined");if(this.#L=w,l!==void 0&&typeof l!="function")throw new TypeError("fetchMethod must be a function if specified");if(this.#D=l,this.#z=!!l,this.#s=new Map,this.#i=new Array(e).fill(void 0),this.#t=new Array(e).fill(void 0),this.#a=new T(e),this.#u=new T(e),this.#o=0,this.#h=0,this.#m=W.create(e),this.#n=0,this.#_=0,typeof g=="function"&&(this.#p=g),typeof _=="function"&&(this.#v=_),typeof f=="function"?(this.#w=f,this.#r=[]):(this.#w=void 0,this.#r=void 0),this.#A=!!this.#p,this.#x=!!this.#v,this.#f=!!this.#w,this.noDisposeOnSet=!!c,this.noUpdateTTL=!!u,this.noDeleteOnFetchRejection=!!b,this.allowStaleOnFetchRejection=!!S,this.allowStaleOnFetchAbort=!!z,this.ignoreFetchAbort=!!F,this.maxEntrySize!==0){if(this.#c!==0&&!y(this.#c))throw new TypeError("maxSize must be a positive integer if specified");if(!y(this.maxEntrySize))throw new TypeError("maxEntrySize must be a positive integer if specified");this.#V()}if(this.allowStale=!!r,this.noDeleteOnStaleGet=!!p,this.updateAgeOnGet=!!h,this.updateAgeOnHas=!!o,this.ttlResolution=y(s)||s===0?s:1,this.ttlAutopurge=!!n,this.ttl=i||0,this.ttl){if(!y(this.ttl))throw new TypeError("ttl must be a positive integer if specified");this.#G()}if(this.#l===0&&this.ttl===0&&this.#c===0)throw new TypeError("At least one of max, maxSize, or ttl is required");if(!this.ttlAutopurge&&!this.#l&&!this.#c){let O="LRU_CACHE_UNBOUNDED";G(O)&&(x.add(O),U("TTL caching without ttlAutopurge, max, or maxSize can result in unbounded memory consumption.","UnboundedCacheWarning",O,a))}}getRemainingTTL(t){return this.#s.has(t)?1/0:0}#G(){let t=new E(this.#l),e=new E(this.#l);this.#d=t,this.#y=e,this.#j=(n,h,o=this.#S.now())=>{if(e[n]=h!==0?o:0,t[n]=h,h!==0&&this.ttlAutopurge){let r=setTimeout(()=>{this.#g(n)&&this.#O(this.#i[n],"expire")},h+1);r.unref&&r.unref()}},this.#C=n=>{e[n]=t[n]!==0?this.#S.now():0},this.#E=(n,h)=>{if(t[h]){let o=t[h],r=e[h];if(!o||!r)return;n.ttl=o,n.start=r,n.now=i||s();let g=n.now-r;n.remainingTTL=o-g}};let i=0,s=()=>{let n=this.#S.now();if(this.ttlResolution>0){i=n;let h=setTimeout(()=>i=0,this.ttlResolution);h.unref&&h.unref()}return n};this.getRemainingTTL=n=>{let h=this.#s.get(n);if(h===void 0)return 0;let o=t[h],r=e[h];if(!o||!r)return 1/0;let g=(i||s())-r;return o-g},this.#g=n=>{let h=e[n],o=t[n];return!!o&&!!h&&(i||s())-h>o}}#C=()=>{};#E=()=>{};#j=()=>{};#g=()=>!1;#V(){let t=new E(this.#l);this.#_=0,this.#b=t,this.#R=e=>{this.#_-=t[e],t[e]=0},this.#N=(e,i,s,n)=>{if(this.#e(i))return 0;if(!y(s))if(n){if(typeof n!="function")throw new TypeError("sizeCalculation must be a function");if(s=n(i,e),!y(s))throw new TypeError("sizeCalculation return invalid (expect positive integer)")}else throw new TypeError("invalid size value (must be positive integer). When maxSize or maxEntrySize is used, sizeCalculation or size must be set.");return s},this.#U=(e,i,s)=>{if(t[e]=i,this.#c){let n=this.#c-t[e];for(;this.#_>n;)this.#I(!0)}this.#_+=t[e],s&&(s.entrySize=i,s.totalCalculatedSize=this.#_)}}#R=t=>{};#U=(t,e,i)=>{};#N=(t,e,i,s)=>{if(i||s)throw new TypeError("cannot set size without setting maxSize or maxEntrySize on cache");return 0};*#F({allowStale:t=this.allowStale}={}){if(this.#n)for(let e=this.#h;!(!this.#P(e)||((t||!this.#g(e))&&(yield e),e===this.#o));)e=this.#u[e]}*#T({allowStale:t=this.allowStale}={}){if(this.#n)for(let e=this.#o;!(!this.#P(e)||((t||!this.#g(e))&&(yield e),e===this.#h));)e=this.#a[e]}#P(t){return t!==void 0&&this.#s.get(this.#i[t])===t}*entries(){for(let t of this.#F())this.#t[t]!==void 0&&this.#i[t]!==void 0&&!this.#e(this.#t[t])&&(yield[this.#i[t],this.#t[t]])}*rentries(){for(let t of this.#T())this.#t[t]!==void 0&&this.#i[t]!==void 0&&!this.#e(this.#t[t])&&(yield[this.#i[t],this.#t[t]])}*keys(){for(let t of this.#F()){let e=this.#i[t];e!==void 0&&!this.#e(this.#t[t])&&(yield e)}}*rkeys(){for(let t of this.#T()){let e=this.#i[t];e!==void 0&&!this.#e(this.#t[t])&&(yield e)}}*values(){for(let t of this.#F())this.#t[t]!==void 0&&!this.#e(this.#t[t])&&(yield this.#t[t])}*rvalues(){for(let t of this.#T())this.#t[t]!==void 0&&!this.#e(this.#t[t])&&(yield this.#t[t])}[Symbol.iterator](){return this.entries()}[Symbol.toStringTag]="LRUCache";find(t,e={}){for(let i of this.#F()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;if(n!==void 0&&t(n,this.#i[i],this))return this.get(this.#i[i],e)}}forEach(t,e=this){for(let i of this.#F()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;n!==void 0&&t.call(e,n,this.#i[i],this)}}rforEach(t,e=this){for(let i of this.#T()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;n!==void 0&&t.call(e,n,this.#i[i],this)}}purgeStale(){let t=!1;for(let e of this.#T({allowStale:!0}))this.#g(e)&&(this.#O(this.#i[e],"expire"),t=!0);return t}info(t){let e=this.#s.get(t);if(e===void 0)return;let i=this.#t[e],s=this.#e(i)?i.__staleWhileFetching:i;if(s===void 0)return;let n={value:s};if(this.#d&&this.#y){let h=this.#d[e],o=this.#y[e];if(h&&o){let r=h-(this.#S.now()-o);n.ttl=r,n.start=Date.now()}}return this.#b&&(n.size=this.#b[e]),n}dump(){let t=[];for(let e of this.#F({allowStale:!0})){let i=this.#i[e],s=this.#t[e],n=this.#e(s)?s.__staleWhileFetching:s;if(n===void 0||i===void 0)continue;let h={value:n};if(this.#d&&this.#y){h.ttl=this.#d[e];let o=this.#S.now()-this.#y[e];h.start=Math.floor(Date.now()-o)}this.#b&&(h.size=this.#b[e]),t.unshift([i,h])}return t}load(t){this.clear();for(let[e,i]of t){if(i.start){let s=Date.now()-i.start;i.start=this.#S.now()-s}this.set(e,i.value,i)}}set(t,e,i={}){if(e===void 0)return this.delete(t),this;let{ttl:s=this.ttl,start:n,noDisposeOnSet:h=this.noDisposeOnSet,sizeCalculation:o=this.sizeCalculation,status:r}=i,{noUpdateTTL:g=this.noUpdateTTL}=i,_=this.#N(t,e,i.size||0,o);if(this.maxEntrySize&&_>this.maxEntrySize)return r&&(r.set="miss",r.maxEntrySizeExceeded=!0),this.#O(t,"set"),this;let f=this.#n===0?void 0:this.#s.get(t);if(f===void 0)f=this.#n===0?this.#h:this.#m.length!==0?this.#m.pop():this.#n===this.#l?this.#I(!1):this.#n,this.#i[f]=t,this.#t[f]=e,this.#s.set(t,f),this.#a[this.#h]=f,this.#u[f]=this.#h,this.#h=f,this.#n++,this.#U(f,_,r),r&&(r.set="add"),g=!1,this.#x&&this.#v?.(e,t,"add");else{this.#W(f);let c=this.#t[f];if(e!==c){if(this.#z&&this.#e(c)){c.__abortController.abort(new Error("replaced"));let{__staleWhileFetching:u}=c;u!==void 0&&!h&&(this.#A&&this.#p?.(u,t,"set"),this.#f&&this.#r?.push([u,t,"set"]))}else h||(this.#A&&this.#p?.(c,t,"set"),this.#f&&this.#r?.push([c,t,"set"]));if(this.#R(f),this.#U(f,_,r),this.#t[f]=e,r){r.set="replace";let u=c&&this.#e(c)?c.__staleWhileFetching:c;u!==void 0&&(r.oldValue=u)}}else r&&(r.set="update");this.#x&&this.onInsert?.(e,t,e===c?"update":"replace")}if(s!==0&&!this.#d&&this.#G(),this.#d&&(g||this.#j(f,s,n),r&&this.#E(r,f)),!h&&this.#f&&this.#r){let c=this.#r,u;for(;u=c?.shift();)this.#w?.(...u)}return this}pop(){try{for(;this.#n;){let t=this.#t[this.#o];if(this.#I(!0),this.#e(t)){if(t.__staleWhileFetching)return t.__staleWhileFetching}else if(t!==void 0)return t}}finally{if(this.#f&&this.#r){let t=this.#r,e;for(;e=t?.shift();)this.#w?.(...e)}}}#I(t){let e=this.#o,i=this.#i[e],s=this.#t[e];return this.#z&&this.#e(s)?s.__abortController.abort(new Error("evicted")):(this.#A||this.#f)&&(this.#A&&this.#p?.(s,i,"evict"),this.#f&&this.#r?.push([s,i,"evict"])),this.#R(e),t&&(this.#i[e]=void 0,this.#t[e]=void 0,this.#m.push(e)),this.#n===1?(this.#o=this.#h=0,this.#m.length=0):this.#o=this.#a[e],this.#s.delete(i),this.#n--,e}has(t,e={}){let{updateAgeOnHas:i=this.updateAgeOnHas,status:s}=e,n=this.#s.get(t);if(n!==void 0){let h=this.#t[n];if(this.#e(h)&&h.__staleWhileFetching===void 0)return!1;if(this.#g(n))s&&(s.has="stale",this.#E(s,n));else return i&&this.#C(n),s&&(s.has="hit",this.#E(s,n)),!0}else s&&(s.has="miss");return!1}peek(t,e={}){let{allowStale:i=this.allowStale}=e,s=this.#s.get(t);if(s===void 0||!i&&this.#g(s))return;let n=this.#t[s];return this.#e(n)?n.__staleWhileFetching:n}#M(t,e,i,s){let n=e===void 0?void 0:this.#t[e];if(this.#e(n))return n;let h=new C,{signal:o}=i;o?.addEventListener("abort",()=>h.abort(o.reason),{signal:h.signal});let r={signal:h.signal,options:i,context:s},g=(d,m=!1)=>{let{aborted:l}=h.signal,w=i.ignoreFetchAbort&&d!==void 0;if(i.status&&(l&&!m?(i.status.fetchAborted=!0,i.status.fetchError=h.signal.reason,w&&(i.status.fetchAbortIgnored=!0)):i.status.fetchResolved=!0),l&&!w&&!m)return f(h.signal.reason);let b=u;return this.#t[e]===u&&(d===void 0?b.__staleWhileFetching!==void 0?this.#t[e]=b.__staleWhileFetching:this.#O(t,"fetch"):(i.status&&(i.status.fetchUpdated=!0),this.set(t,d,r.options))),d},_=d=>(i.status&&(i.status.fetchRejected=!0,i.status.fetchError=d),f(d)),f=d=>{let{aborted:m}=h.signal,l=m&&i.allowStaleOnFetchAbort,w=l||i.allowStaleOnFetchRejection,b=w||i.noDeleteOnFetchRejection,p=u;if(this.#t[e]===u&&(!b||p.__staleWhileFetching===void 0?this.#O(t,"fetch"):l||(this.#t[e]=p.__staleWhileFetching)),w)return i.status&&p.__staleWhileFetching!==void 0&&(i.status.returnedStale=!0),p.__staleWhileFetching;if(p.__returned===p)throw d},c=(d,m)=>{let l=this.#D?.(t,n,r);l&&l instanceof Promise&&l.then(w=>d(w===void 0?void 0:w),m),h.signal.addEventListener("abort",()=>{(!i.ignoreFetchAbort||i.allowStaleOnFetchAbort)&&(d(void 0),i.allowStaleOnFetchAbort&&(d=w=>g(w,!0)))})};i.status&&(i.status.fetchDispatched=!0);let u=new Promise(c).then(g,_),A=Object.assign(u,{__abortController:h,__staleWhileFetching:n,__returned:void 0});return e===void 0?(this.set(t,A,{...r.options,status:void 0}),e=this.#s.get(t)):this.#t[e]=A,A}#e(t){if(!this.#z)return!1;let e=t;return!!e&&e instanceof Promise&&e.hasOwnProperty("__staleWhileFetching")&&e.__abortController instanceof C}async fetch(t,e={}){let{allowStale:i=this.allowStale,updateAgeOnGet:s=this.updateAgeOnGet,noDeleteOnStaleGet:n=this.noDeleteOnStaleGet,ttl:h=this.ttl,noDisposeOnSet:o=this.noDisposeOnSet,size:r=0,sizeCalculation:g=this.sizeCalculation,noUpdateTTL:_=this.noUpdateTTL,noDeleteOnFetchRejection:f=this.noDeleteOnFetchRejection,allowStaleOnFetchRejection:c=this.allowStaleOnFetchRejection,ignoreFetchAbort:u=this.ignoreFetchAbort,allowStaleOnFetchAbort:A=this.allowStaleOnFetchAbort,context:d,forceRefresh:m=!1,status:l,signal:w}=e;if(!this.#z)return l&&(l.fetch="get"),this.get(t,{allowStale:i,updateAgeOnGet:s,noDeleteOnStaleGet:n,status:l});let b={allowStale:i,updateAgeOnGet:s,noDeleteOnStaleGet:n,ttl:h,noDisposeOnSet:o,size:r,sizeCalculation:g,noUpdateTTL:_,noDeleteOnFetchRejection:f,allowStaleOnFetchRejection:c,allowStaleOnFetchAbort:A,ignoreFetchAbort:u,status:l,signal:w},p=this.#s.get(t);if(p===void 0){l&&(l.fetch="miss");let S=this.#M(t,p,b,d);return S.__returned=S}else{let S=this.#t[p];if(this.#e(S)){let O=i&&S.__staleWhileFetching!==void 0;return l&&(l.fetch="inflight",O&&(l.returnedStale=!0)),O?S.__staleWhileFetching:S.__returned=S}let z=this.#g(p);if(!m&&!z)return l&&(l.fetch="hit"),this.#W(p),s&&this.#C(p),l&&this.#E(l,p),S;let F=this.#M(t,p,b,d),T=F.__staleWhileFetching!==void 0&&i;return l&&(l.fetch=z?"stale":"refresh",T&&z&&(l.returnedStale=!0)),T?F.__staleWhileFetching:F.__returned=F}}async forceFetch(t,e={}){let i=await this.fetch(t,e);if(i===void 0)throw new Error("fetch() returned undefined");return i}memo(t,e={}){let i=this.#L;if(!i)throw new Error("no memoMethod provided to constructor");let{context:s,forceRefresh:n,...h}=e,o=this.get(t,h);if(!n&&o!==void 0)return o;let r=i(t,o,{options:h,context:s});return this.set(t,r,h),r}get(t,e={}){let{allowStale:i=this.allowStale,updateAgeOnGet:s=this.updateAgeOnGet,noDeleteOnStaleGet:n=this.noDeleteOnStaleGet,status:h}=e,o=this.#s.get(t);if(o!==void 0){let r=this.#t[o],g=this.#e(r);return h&&this.#E(h,o),this.#g(o)?(h&&(h.get="stale"),g?(h&&i&&r.__staleWhileFetching!==void 0&&(h.returnedStale=!0),i?r.__staleWhileFetching:void 0):(n||this.#O(t,"expire"),h&&i&&(h.returnedStale=!0),i?r:void 0)):(h&&(h.get="hit"),g?r.__staleWhileFetching:(this.#W(o),s&&this.#C(o),r))}else h&&(h.get="miss")}#H(t,e){this.#u[e]=t,this.#a[t]=e}#W(t){t!==this.#h&&(t===this.#o?this.#o=this.#a[t]:this.#H(this.#u[t],this.#a[t]),this.#H(this.#h,t),this.#h=t)}delete(t){return this.#O(t,"delete")}#O(t,e){let i=!1;if(this.#n!==0){let s=this.#s.get(t);if(s!==void 0)if(i=!0,this.#n===1)this.#k(e);else{this.#R(s);let n=this.#t[s];if(this.#e(n)?n.__abortController.abort(new Error("deleted")):(this.#A||this.#f)&&(this.#A&&this.#p?.(n,t,e),this.#f&&this.#r?.push([n,t,e])),this.#s.delete(t),this.#i[s]=void 0,this.#t[s]=void 0,s===this.#h)this.#h=this.#u[s];else if(s===this.#o)this.#o=this.#a[s];else{let h=this.#u[s];this.#a[h]=this.#a[s];let o=this.#a[s];this.#u[o]=this.#u[s]}this.#n--,this.#m.push(s)}}if(this.#f&&this.#r?.length){let s=this.#r,n;for(;n=s?.shift();)this.#w?.(...n)}return i}clear(){return this.#k("delete")}#k(t){for(let e of this.#T({allowStale:!0})){let i=this.#t[e];if(this.#e(i))i.__abortController.abort(new Error("deleted"));else{let s=this.#i[e];this.#A&&this.#p?.(i,s,t),this.#f&&this.#r?.push([i,s,t])}}if(this.#s.clear(),this.#t.fill(void 0),this.#i.fill(void 0),this.#d&&this.#y&&(this.#d.fill(0),this.#y.fill(0)),this.#b&&this.#b.fill(0),this.#o=0,this.#h=0,this.#m.length=0,this.#_=0,this.#n=0,this.#f&&this.#r){let e=this.#r,i;for(;i=e?.shift();)this.#w?.(...i)}}};exports.LRUCache=D; +"use strict";Object.defineProperty(exports,"__esModule",{value:!0});exports.LRUCache=void 0;var M=typeof performance=="object"&&performance&&typeof performance.now=="function"?performance:Date,x=new Set,R=typeof process=="object"&&process?process:{},U=(a,t,e,i)=>{typeof R.emitWarning=="function"?R.emitWarning(a,t,e,i):console.error(`[${e}] ${t}: ${a}`)},C=globalThis.AbortController,L=globalThis.AbortSignal;if(typeof C>"u"){L=class{onabort;_onabort=[];reason;aborted=!1;addEventListener(i,s){this._onabort.push(s)}},C=class{constructor(){t()}signal=new L;abort(i){if(!this.signal.aborted){this.signal.reason=i,this.signal.aborted=!0;for(let s of this.signal._onabort)s(i);this.signal.onabort?.(i)}}};let a=R.env?.LRU_CACHE_IGNORE_AC_WARNING!=="1",t=()=>{a&&(a=!1,U("AbortController is not defined. If using lru-cache in node 14, load an AbortController polyfill from the `node-abort-controller` package. A minimal polyfill is provided for use by LRUCache.fetch(), but it should not be relied upon in other contexts (eg, passing it to other APIs that use AbortController/AbortSignal might have undesirable effects). You may disable this with LRU_CACHE_IGNORE_AC_WARNING=1 in the env.","NO_ABORT_CONTROLLER","ENOTSUP",t))}}var G=a=>!x.has(a),H=Symbol("type"),y=a=>a&&a===Math.floor(a)&&a>0&&isFinite(a),I=a=>y(a)?a<=Math.pow(2,8)?Uint8Array:a<=Math.pow(2,16)?Uint16Array:a<=Math.pow(2,32)?Uint32Array:a<=Number.MAX_SAFE_INTEGER?E:null:null,E=class extends Array{constructor(t){super(t),this.fill(0)}},W=class a{heap;length;static#l=!1;static create(t){let e=I(t);if(!e)return[];a.#l=!0;let i=new a(t,e);return a.#l=!1,i}constructor(t,e){if(!a.#l)throw new TypeError("instantiate Stack using Stack.create(n)");this.heap=new e(t),this.length=0}push(t){this.heap[this.length++]=t}pop(){return this.heap[--this.length]}},D=class a{#l;#c;#p;#z;#w;#D;#L;#S;get perf(){return this.#S}ttl;ttlResolution;ttlAutopurge;updateAgeOnGet;updateAgeOnHas;allowStale;noDisposeOnSet;noUpdateTTL;maxEntrySize;sizeCalculation;noDeleteOnFetchRejection;noDeleteOnStaleGet;allowStaleOnFetchAbort;allowStaleOnFetchRejection;ignoreFetchAbort;#n;#_;#s;#i;#t;#a;#u;#o;#h;#m;#r;#b;#y;#d;#A;#v;#f;#x;static unsafeExposeInternals(t){return{starts:t.#y,ttls:t.#d,sizes:t.#b,keyMap:t.#s,keyList:t.#i,valList:t.#t,next:t.#a,prev:t.#u,get head(){return t.#o},get tail(){return t.#h},free:t.#m,isBackgroundFetch:e=>t.#e(e),backgroundFetch:(e,i,s,n)=>t.#M(e,i,s,n),moveToTail:e=>t.#W(e),indexes:e=>t.#F(e),rindexes:e=>t.#T(e),isStale:e=>t.#g(e)}}get max(){return this.#l}get maxSize(){return this.#c}get calculatedSize(){return this.#_}get size(){return this.#n}get fetchMethod(){return this.#D}get memoMethod(){return this.#L}get dispose(){return this.#p}get onInsert(){return this.#z}get disposeAfter(){return this.#w}constructor(t){let{max:e=0,ttl:i,ttlResolution:s=1,ttlAutopurge:n,updateAgeOnGet:h,updateAgeOnHas:o,allowStale:r,dispose:p,onInsert:m,disposeAfter:f,noDisposeOnSet:u,noUpdateTTL:d,maxSize:A=0,maxEntrySize:g=0,sizeCalculation:_,fetchMethod:l,memoMethod:w,noDeleteOnFetchRejection:b,noDeleteOnStaleGet:c,allowStaleOnFetchRejection:S,allowStaleOnFetchAbort:v,ignoreFetchAbort:F,perf:z}=t;if(z!==void 0&&typeof z?.now!="function")throw new TypeError("perf option must have a now() method if specified");if(this.#S=z??M,e!==0&&!y(e))throw new TypeError("max option must be a nonnegative integer");let T=e?I(e):Array;if(!T)throw new Error("invalid max value: "+e);if(this.#l=e,this.#c=A,this.maxEntrySize=g||this.#c,this.sizeCalculation=_,this.sizeCalculation){if(!this.#c&&!this.maxEntrySize)throw new TypeError("cannot set sizeCalculation without setting maxSize or maxEntrySize");if(typeof this.sizeCalculation!="function")throw new TypeError("sizeCalculation set to non-function")}if(w!==void 0&&typeof w!="function")throw new TypeError("memoMethod must be a function if defined");if(this.#L=w,l!==void 0&&typeof l!="function")throw new TypeError("fetchMethod must be a function if specified");if(this.#D=l,this.#v=!!l,this.#s=new Map,this.#i=new Array(e).fill(void 0),this.#t=new Array(e).fill(void 0),this.#a=new T(e),this.#u=new T(e),this.#o=0,this.#h=0,this.#m=W.create(e),this.#n=0,this.#_=0,typeof p=="function"&&(this.#p=p),typeof m=="function"&&(this.#z=m),typeof f=="function"?(this.#w=f,this.#r=[]):(this.#w=void 0,this.#r=void 0),this.#A=!!this.#p,this.#x=!!this.#z,this.#f=!!this.#w,this.noDisposeOnSet=!!u,this.noUpdateTTL=!!d,this.noDeleteOnFetchRejection=!!b,this.allowStaleOnFetchRejection=!!S,this.allowStaleOnFetchAbort=!!v,this.ignoreFetchAbort=!!F,this.maxEntrySize!==0){if(this.#c!==0&&!y(this.#c))throw new TypeError("maxSize must be a positive integer if specified");if(!y(this.maxEntrySize))throw new TypeError("maxEntrySize must be a positive integer if specified");this.#V()}if(this.allowStale=!!r,this.noDeleteOnStaleGet=!!c,this.updateAgeOnGet=!!h,this.updateAgeOnHas=!!o,this.ttlResolution=y(s)||s===0?s:1,this.ttlAutopurge=!!n,this.ttl=i||0,this.ttl){if(!y(this.ttl))throw new TypeError("ttl must be a positive integer if specified");this.#G()}if(this.#l===0&&this.ttl===0&&this.#c===0)throw new TypeError("At least one of max, maxSize, or ttl is required");if(!this.ttlAutopurge&&!this.#l&&!this.#c){let O="LRU_CACHE_UNBOUNDED";G(O)&&(x.add(O),U("TTL caching without ttlAutopurge, max, or maxSize can result in unbounded memory consumption.","UnboundedCacheWarning",O,a))}}getRemainingTTL(t){return this.#s.has(t)?1/0:0}#G(){let t=new E(this.#l),e=new E(this.#l);this.#d=t,this.#y=e,this.#j=(n,h,o=this.#S.now())=>{if(e[n]=h!==0?o:0,t[n]=h,h!==0&&this.ttlAutopurge){let r=setTimeout(()=>{this.#g(n)&&this.#O(this.#i[n],"expire")},h+1);r.unref&&r.unref()}},this.#C=n=>{e[n]=t[n]!==0?this.#S.now():0},this.#E=(n,h)=>{if(t[h]){let o=t[h],r=e[h];if(!o||!r)return;n.ttl=o,n.start=r,n.now=i||s();let p=n.now-r;n.remainingTTL=o-p}};let i=0,s=()=>{let n=this.#S.now();if(this.ttlResolution>0){i=n;let h=setTimeout(()=>i=0,this.ttlResolution);h.unref&&h.unref()}return n};this.getRemainingTTL=n=>{let h=this.#s.get(n);if(h===void 0)return 0;let o=t[h],r=e[h];if(!o||!r)return 1/0;let p=(i||s())-r;return o-p},this.#g=n=>{let h=e[n],o=t[n];return!!o&&!!h&&(i||s())-h>o}}#C=()=>{};#E=()=>{};#j=()=>{};#g=()=>!1;#V(){let t=new E(this.#l);this.#_=0,this.#b=t,this.#R=e=>{this.#_-=t[e],t[e]=0},this.#N=(e,i,s,n)=>{if(this.#e(i))return 0;if(!y(s))if(n){if(typeof n!="function")throw new TypeError("sizeCalculation must be a function");if(s=n(i,e),!y(s))throw new TypeError("sizeCalculation return invalid (expect positive integer)")}else throw new TypeError("invalid size value (must be positive integer). When maxSize or maxEntrySize is used, sizeCalculation or size must be set.");return s},this.#U=(e,i,s)=>{if(t[e]=i,this.#c){let n=this.#c-t[e];for(;this.#_>n;)this.#I(!0)}this.#_+=t[e],s&&(s.entrySize=i,s.totalCalculatedSize=this.#_)}}#R=t=>{};#U=(t,e,i)=>{};#N=(t,e,i,s)=>{if(i||s)throw new TypeError("cannot set size without setting maxSize or maxEntrySize on cache");return 0};*#F({allowStale:t=this.allowStale}={}){if(this.#n)for(let e=this.#h;!(!this.#P(e)||((t||!this.#g(e))&&(yield e),e===this.#o));)e=this.#u[e]}*#T({allowStale:t=this.allowStale}={}){if(this.#n)for(let e=this.#o;!(!this.#P(e)||((t||!this.#g(e))&&(yield e),e===this.#h));)e=this.#a[e]}#P(t){return t!==void 0&&this.#s.get(this.#i[t])===t}*entries(){for(let t of this.#F())this.#t[t]!==void 0&&this.#i[t]!==void 0&&!this.#e(this.#t[t])&&(yield[this.#i[t],this.#t[t]])}*rentries(){for(let t of this.#T())this.#t[t]!==void 0&&this.#i[t]!==void 0&&!this.#e(this.#t[t])&&(yield[this.#i[t],this.#t[t]])}*keys(){for(let t of this.#F()){let e=this.#i[t];e!==void 0&&!this.#e(this.#t[t])&&(yield e)}}*rkeys(){for(let t of this.#T()){let e=this.#i[t];e!==void 0&&!this.#e(this.#t[t])&&(yield e)}}*values(){for(let t of this.#F())this.#t[t]!==void 0&&!this.#e(this.#t[t])&&(yield this.#t[t])}*rvalues(){for(let t of this.#T())this.#t[t]!==void 0&&!this.#e(this.#t[t])&&(yield this.#t[t])}[Symbol.iterator](){return this.entries()}[Symbol.toStringTag]="LRUCache";find(t,e={}){for(let i of this.#F()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;if(n!==void 0&&t(n,this.#i[i],this))return this.get(this.#i[i],e)}}forEach(t,e=this){for(let i of this.#F()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;n!==void 0&&t.call(e,n,this.#i[i],this)}}rforEach(t,e=this){for(let i of this.#T()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;n!==void 0&&t.call(e,n,this.#i[i],this)}}purgeStale(){let t=!1;for(let e of this.#T({allowStale:!0}))this.#g(e)&&(this.#O(this.#i[e],"expire"),t=!0);return t}info(t){let e=this.#s.get(t);if(e===void 0)return;let i=this.#t[e],s=this.#e(i)?i.__staleWhileFetching:i;if(s===void 0)return;let n={value:s};if(this.#d&&this.#y){let h=this.#d[e],o=this.#y[e];if(h&&o){let r=h-(this.#S.now()-o);n.ttl=r,n.start=Date.now()}}return this.#b&&(n.size=this.#b[e]),n}dump(){let t=[];for(let e of this.#F({allowStale:!0})){let i=this.#i[e],s=this.#t[e],n=this.#e(s)?s.__staleWhileFetching:s;if(n===void 0||i===void 0)continue;let h={value:n};if(this.#d&&this.#y){h.ttl=this.#d[e];let o=this.#S.now()-this.#y[e];h.start=Math.floor(Date.now()-o)}this.#b&&(h.size=this.#b[e]),t.unshift([i,h])}return t}load(t){this.clear();for(let[e,i]of t){if(i.start){let s=Date.now()-i.start;i.start=this.#S.now()-s}this.set(e,i.value,i)}}set(t,e,i={}){if(e===void 0)return this.delete(t),this;let{ttl:s=this.ttl,start:n,noDisposeOnSet:h=this.noDisposeOnSet,sizeCalculation:o=this.sizeCalculation,status:r}=i,{noUpdateTTL:p=this.noUpdateTTL}=i,m=this.#N(t,e,i.size||0,o);if(this.maxEntrySize&&m>this.maxEntrySize)return r&&(r.set="miss",r.maxEntrySizeExceeded=!0),this.#O(t,"set"),this;let f=this.#n===0?void 0:this.#s.get(t);if(f===void 0)f=this.#n===0?this.#h:this.#m.length!==0?this.#m.pop():this.#n===this.#l?this.#I(!1):this.#n,this.#i[f]=t,this.#t[f]=e,this.#s.set(t,f),this.#a[this.#h]=f,this.#u[f]=this.#h,this.#h=f,this.#n++,this.#U(f,m,r),r&&(r.set="add"),p=!1,this.#x&&this.#z?.(e,t,"add");else{this.#W(f);let u=this.#t[f];if(e!==u){if(this.#v&&this.#e(u)){u.__abortController.abort(new Error("replaced"));let{__staleWhileFetching:d}=u;d!==void 0&&!h&&(this.#A&&this.#p?.(d,t,"set"),this.#f&&this.#r?.push([d,t,"set"]))}else h||(this.#A&&this.#p?.(u,t,"set"),this.#f&&this.#r?.push([u,t,"set"]));if(this.#R(f),this.#U(f,m,r),this.#t[f]=e,r){r.set="replace";let d=u&&this.#e(u)?u.__staleWhileFetching:u;d!==void 0&&(r.oldValue=d)}}else r&&(r.set="update");this.#x&&this.onInsert?.(e,t,e===u?"update":"replace")}if(s!==0&&!this.#d&&this.#G(),this.#d&&(p||this.#j(f,s,n),r&&this.#E(r,f)),!h&&this.#f&&this.#r){let u=this.#r,d;for(;d=u?.shift();)this.#w?.(...d)}return this}pop(){try{for(;this.#n;){let t=this.#t[this.#o];if(this.#I(!0),this.#e(t)){if(t.__staleWhileFetching)return t.__staleWhileFetching}else if(t!==void 0)return t}}finally{if(this.#f&&this.#r){let t=this.#r,e;for(;e=t?.shift();)this.#w?.(...e)}}}#I(t){let e=this.#o,i=this.#i[e],s=this.#t[e];return this.#v&&this.#e(s)?s.__abortController.abort(new Error("evicted")):(this.#A||this.#f)&&(this.#A&&this.#p?.(s,i,"evict"),this.#f&&this.#r?.push([s,i,"evict"])),this.#R(e),t&&(this.#i[e]=void 0,this.#t[e]=void 0,this.#m.push(e)),this.#n===1?(this.#o=this.#h=0,this.#m.length=0):this.#o=this.#a[e],this.#s.delete(i),this.#n--,e}has(t,e={}){let{updateAgeOnHas:i=this.updateAgeOnHas,status:s}=e,n=this.#s.get(t);if(n!==void 0){let h=this.#t[n];if(this.#e(h)&&h.__staleWhileFetching===void 0)return!1;if(this.#g(n))s&&(s.has="stale",this.#E(s,n));else return i&&this.#C(n),s&&(s.has="hit",this.#E(s,n)),!0}else s&&(s.has="miss");return!1}peek(t,e={}){let{allowStale:i=this.allowStale}=e,s=this.#s.get(t);if(s===void 0||!i&&this.#g(s))return;let n=this.#t[s];return this.#e(n)?n.__staleWhileFetching:n}#M(t,e,i,s){let n=e===void 0?void 0:this.#t[e];if(this.#e(n))return n;let h=new C,{signal:o}=i;o?.addEventListener("abort",()=>h.abort(o.reason),{signal:h.signal});let r={signal:h.signal,options:i,context:s},p=(g,_=!1)=>{let{aborted:l}=h.signal,w=i.ignoreFetchAbort&&g!==void 0;if(i.status&&(l&&!_?(i.status.fetchAborted=!0,i.status.fetchError=h.signal.reason,w&&(i.status.fetchAbortIgnored=!0)):i.status.fetchResolved=!0),l&&!w&&!_)return f(h.signal.reason);let b=d,c=this.#t[e];return(c===d||w&&_&&c===void 0)&&(g===void 0?b.__staleWhileFetching!==void 0?this.#t[e]=b.__staleWhileFetching:this.#O(t,"fetch"):(i.status&&(i.status.fetchUpdated=!0),this.set(t,g,r.options))),g},m=g=>(i.status&&(i.status.fetchRejected=!0,i.status.fetchError=g),f(g)),f=g=>{let{aborted:_}=h.signal,l=_&&i.allowStaleOnFetchAbort,w=l||i.allowStaleOnFetchRejection,b=w||i.noDeleteOnFetchRejection,c=d;if(this.#t[e]===d&&(!b||c.__staleWhileFetching===void 0?this.#O(t,"fetch"):l||(this.#t[e]=c.__staleWhileFetching)),w)return i.status&&c.__staleWhileFetching!==void 0&&(i.status.returnedStale=!0),c.__staleWhileFetching;if(c.__returned===c)throw g},u=(g,_)=>{let l=this.#D?.(t,n,r);l&&l instanceof Promise&&l.then(w=>g(w===void 0?void 0:w),_),h.signal.addEventListener("abort",()=>{(!i.ignoreFetchAbort||i.allowStaleOnFetchAbort)&&(g(void 0),i.allowStaleOnFetchAbort&&(g=w=>p(w,!0)))})};i.status&&(i.status.fetchDispatched=!0);let d=new Promise(u).then(p,m),A=Object.assign(d,{__abortController:h,__staleWhileFetching:n,__returned:void 0});return e===void 0?(this.set(t,A,{...r.options,status:void 0}),e=this.#s.get(t)):this.#t[e]=A,A}#e(t){if(!this.#v)return!1;let e=t;return!!e&&e instanceof Promise&&e.hasOwnProperty("__staleWhileFetching")&&e.__abortController instanceof C}async fetch(t,e={}){let{allowStale:i=this.allowStale,updateAgeOnGet:s=this.updateAgeOnGet,noDeleteOnStaleGet:n=this.noDeleteOnStaleGet,ttl:h=this.ttl,noDisposeOnSet:o=this.noDisposeOnSet,size:r=0,sizeCalculation:p=this.sizeCalculation,noUpdateTTL:m=this.noUpdateTTL,noDeleteOnFetchRejection:f=this.noDeleteOnFetchRejection,allowStaleOnFetchRejection:u=this.allowStaleOnFetchRejection,ignoreFetchAbort:d=this.ignoreFetchAbort,allowStaleOnFetchAbort:A=this.allowStaleOnFetchAbort,context:g,forceRefresh:_=!1,status:l,signal:w}=e;if(!this.#v)return l&&(l.fetch="get"),this.get(t,{allowStale:i,updateAgeOnGet:s,noDeleteOnStaleGet:n,status:l});let b={allowStale:i,updateAgeOnGet:s,noDeleteOnStaleGet:n,ttl:h,noDisposeOnSet:o,size:r,sizeCalculation:p,noUpdateTTL:m,noDeleteOnFetchRejection:f,allowStaleOnFetchRejection:u,allowStaleOnFetchAbort:A,ignoreFetchAbort:d,status:l,signal:w},c=this.#s.get(t);if(c===void 0){l&&(l.fetch="miss");let S=this.#M(t,c,b,g);return S.__returned=S}else{let S=this.#t[c];if(this.#e(S)){let O=i&&S.__staleWhileFetching!==void 0;return l&&(l.fetch="inflight",O&&(l.returnedStale=!0)),O?S.__staleWhileFetching:S.__returned=S}let v=this.#g(c);if(!_&&!v)return l&&(l.fetch="hit"),this.#W(c),s&&this.#C(c),l&&this.#E(l,c),S;let F=this.#M(t,c,b,g),T=F.__staleWhileFetching!==void 0&&i;return l&&(l.fetch=v?"stale":"refresh",T&&v&&(l.returnedStale=!0)),T?F.__staleWhileFetching:F.__returned=F}}async forceFetch(t,e={}){let i=await this.fetch(t,e);if(i===void 0)throw new Error("fetch() returned undefined");return i}memo(t,e={}){let i=this.#L;if(!i)throw new Error("no memoMethod provided to constructor");let{context:s,forceRefresh:n,...h}=e,o=this.get(t,h);if(!n&&o!==void 0)return o;let r=i(t,o,{options:h,context:s});return this.set(t,r,h),r}get(t,e={}){let{allowStale:i=this.allowStale,updateAgeOnGet:s=this.updateAgeOnGet,noDeleteOnStaleGet:n=this.noDeleteOnStaleGet,status:h}=e,o=this.#s.get(t);if(o!==void 0){let r=this.#t[o],p=this.#e(r);return h&&this.#E(h,o),this.#g(o)?(h&&(h.get="stale"),p?(h&&i&&r.__staleWhileFetching!==void 0&&(h.returnedStale=!0),i?r.__staleWhileFetching:void 0):(n||this.#O(t,"expire"),h&&i&&(h.returnedStale=!0),i?r:void 0)):(h&&(h.get="hit"),p?r.__staleWhileFetching:(this.#W(o),s&&this.#C(o),r))}else h&&(h.get="miss")}#H(t,e){this.#u[e]=t,this.#a[t]=e}#W(t){t!==this.#h&&(t===this.#o?this.#o=this.#a[t]:this.#H(this.#u[t],this.#a[t]),this.#H(this.#h,t),this.#h=t)}delete(t){return this.#O(t,"delete")}#O(t,e){let i=!1;if(this.#n!==0){let s=this.#s.get(t);if(s!==void 0)if(i=!0,this.#n===1)this.#k(e);else{this.#R(s);let n=this.#t[s];if(this.#e(n)?n.__abortController.abort(new Error("deleted")):(this.#A||this.#f)&&(this.#A&&this.#p?.(n,t,e),this.#f&&this.#r?.push([n,t,e])),this.#s.delete(t),this.#i[s]=void 0,this.#t[s]=void 0,s===this.#h)this.#h=this.#u[s];else if(s===this.#o)this.#o=this.#a[s];else{let h=this.#u[s];this.#a[h]=this.#a[s];let o=this.#a[s];this.#u[o]=this.#u[s]}this.#n--,this.#m.push(s)}}if(this.#f&&this.#r?.length){let s=this.#r,n;for(;n=s?.shift();)this.#w?.(...n)}return i}clear(){return this.#k("delete")}#k(t){for(let e of this.#T({allowStale:!0})){let i=this.#t[e];if(this.#e(i))i.__abortController.abort(new Error("deleted"));else{let s=this.#i[e];this.#A&&this.#p?.(i,s,t),this.#f&&this.#r?.push([i,s,t])}}if(this.#s.clear(),this.#t.fill(void 0),this.#i.fill(void 0),this.#d&&this.#y&&(this.#d.fill(0),this.#y.fill(0)),this.#b&&this.#b.fill(0),this.#o=0,this.#h=0,this.#m.length=0,this.#_=0,this.#n=0,this.#f&&this.#r){let e=this.#r,i;for(;i=e?.shift();)this.#w?.(...i)}}};exports.LRUCache=D; //# sourceMappingURL=index.min.js.map diff --git a/deps/npm/node_modules/lru-cache/dist/esm/index.js b/deps/npm/node_modules/lru-cache/dist/esm/index.js index 28f463811f065e..a9182b36d78e2b 100644 --- a/deps/npm/node_modules/lru-cache/dist/esm/index.js +++ b/deps/npm/node_modules/lru-cache/dist/esm/index.js @@ -1167,7 +1167,11 @@ export class LRUCache { } // either we didn't abort, and are still here, or we did, and ignored const bf = p; - if (this.#valList[index] === p) { + // if nothing else has been written there but we're set to update the + // cache and ignore the abort, or if it's still pending on this specific + // background request, then write it to the cache. + const vl = this.#valList[index]; + if (vl === p || ignoreAbort && updateCache && vl === undefined) { if (v === undefined) { if (bf.__staleWhileFetching !== undefined) { this.#valList[index] = bf.__staleWhileFetching; diff --git a/deps/npm/node_modules/lru-cache/dist/esm/index.min.js b/deps/npm/node_modules/lru-cache/dist/esm/index.min.js index 07dd8fc3c59d8d..8ad29b768ed9ea 100644 --- a/deps/npm/node_modules/lru-cache/dist/esm/index.min.js +++ b/deps/npm/node_modules/lru-cache/dist/esm/index.min.js @@ -1,2 +1,2 @@ -var M=typeof performance=="object"&&performance&&typeof performance.now=="function"?performance:Date,x=new Set,R=typeof process=="object"&&process?process:{},I=(a,t,e,i)=>{typeof R.emitWarning=="function"?R.emitWarning(a,t,e,i):console.error(`[${e}] ${t}: ${a}`)},C=globalThis.AbortController,D=globalThis.AbortSignal;if(typeof C>"u"){D=class{onabort;_onabort=[];reason;aborted=!1;addEventListener(i,s){this._onabort.push(s)}},C=class{constructor(){t()}signal=new D;abort(i){if(!this.signal.aborted){this.signal.reason=i,this.signal.aborted=!0;for(let s of this.signal._onabort)s(i);this.signal.onabort?.(i)}}};let a=R.env?.LRU_CACHE_IGNORE_AC_WARNING!=="1",t=()=>{a&&(a=!1,I("AbortController is not defined. If using lru-cache in node 14, load an AbortController polyfill from the `node-abort-controller` package. A minimal polyfill is provided for use by LRUCache.fetch(), but it should not be relied upon in other contexts (eg, passing it to other APIs that use AbortController/AbortSignal might have undesirable effects). You may disable this with LRU_CACHE_IGNORE_AC_WARNING=1 in the env.","NO_ABORT_CONTROLLER","ENOTSUP",t))}}var G=a=>!x.has(a),H=Symbol("type"),y=a=>a&&a===Math.floor(a)&&a>0&&isFinite(a),U=a=>y(a)?a<=Math.pow(2,8)?Uint8Array:a<=Math.pow(2,16)?Uint16Array:a<=Math.pow(2,32)?Uint32Array:a<=Number.MAX_SAFE_INTEGER?O:null:null,O=class extends Array{constructor(t){super(t),this.fill(0)}},W=class a{heap;length;static#l=!1;static create(t){let e=U(t);if(!e)return[];a.#l=!0;let i=new a(t,e);return a.#l=!1,i}constructor(t,e){if(!a.#l)throw new TypeError("instantiate Stack using Stack.create(n)");this.heap=new e(t),this.length=0}push(t){this.heap[this.length++]=t}pop(){return this.heap[--this.length]}},L=class a{#l;#c;#p;#v;#w;#D;#L;#S;get perf(){return this.#S}ttl;ttlResolution;ttlAutopurge;updateAgeOnGet;updateAgeOnHas;allowStale;noDisposeOnSet;noUpdateTTL;maxEntrySize;sizeCalculation;noDeleteOnFetchRejection;noDeleteOnStaleGet;allowStaleOnFetchAbort;allowStaleOnFetchRejection;ignoreFetchAbort;#n;#_;#s;#i;#t;#a;#u;#o;#h;#m;#r;#b;#y;#d;#A;#z;#f;#x;static unsafeExposeInternals(t){return{starts:t.#y,ttls:t.#d,sizes:t.#b,keyMap:t.#s,keyList:t.#i,valList:t.#t,next:t.#a,prev:t.#u,get head(){return t.#o},get tail(){return t.#h},free:t.#m,isBackgroundFetch:e=>t.#e(e),backgroundFetch:(e,i,s,n)=>t.#M(e,i,s,n),moveToTail:e=>t.#W(e),indexes:e=>t.#F(e),rindexes:e=>t.#T(e),isStale:e=>t.#g(e)}}get max(){return this.#l}get maxSize(){return this.#c}get calculatedSize(){return this.#_}get size(){return this.#n}get fetchMethod(){return this.#D}get memoMethod(){return this.#L}get dispose(){return this.#p}get onInsert(){return this.#v}get disposeAfter(){return this.#w}constructor(t){let{max:e=0,ttl:i,ttlResolution:s=1,ttlAutopurge:n,updateAgeOnGet:h,updateAgeOnHas:o,allowStale:r,dispose:g,onInsert:_,disposeAfter:f,noDisposeOnSet:c,noUpdateTTL:u,maxSize:A=0,maxEntrySize:d=0,sizeCalculation:m,fetchMethod:l,memoMethod:w,noDeleteOnFetchRejection:b,noDeleteOnStaleGet:p,allowStaleOnFetchRejection:S,allowStaleOnFetchAbort:z,ignoreFetchAbort:F,perf:v}=t;if(v!==void 0&&typeof v?.now!="function")throw new TypeError("perf option must have a now() method if specified");if(this.#S=v??M,e!==0&&!y(e))throw new TypeError("max option must be a nonnegative integer");let T=e?U(e):Array;if(!T)throw new Error("invalid max value: "+e);if(this.#l=e,this.#c=A,this.maxEntrySize=d||this.#c,this.sizeCalculation=m,this.sizeCalculation){if(!this.#c&&!this.maxEntrySize)throw new TypeError("cannot set sizeCalculation without setting maxSize or maxEntrySize");if(typeof this.sizeCalculation!="function")throw new TypeError("sizeCalculation set to non-function")}if(w!==void 0&&typeof w!="function")throw new TypeError("memoMethod must be a function if defined");if(this.#L=w,l!==void 0&&typeof l!="function")throw new TypeError("fetchMethod must be a function if specified");if(this.#D=l,this.#z=!!l,this.#s=new Map,this.#i=new Array(e).fill(void 0),this.#t=new Array(e).fill(void 0),this.#a=new T(e),this.#u=new T(e),this.#o=0,this.#h=0,this.#m=W.create(e),this.#n=0,this.#_=0,typeof g=="function"&&(this.#p=g),typeof _=="function"&&(this.#v=_),typeof f=="function"?(this.#w=f,this.#r=[]):(this.#w=void 0,this.#r=void 0),this.#A=!!this.#p,this.#x=!!this.#v,this.#f=!!this.#w,this.noDisposeOnSet=!!c,this.noUpdateTTL=!!u,this.noDeleteOnFetchRejection=!!b,this.allowStaleOnFetchRejection=!!S,this.allowStaleOnFetchAbort=!!z,this.ignoreFetchAbort=!!F,this.maxEntrySize!==0){if(this.#c!==0&&!y(this.#c))throw new TypeError("maxSize must be a positive integer if specified");if(!y(this.maxEntrySize))throw new TypeError("maxEntrySize must be a positive integer if specified");this.#V()}if(this.allowStale=!!r,this.noDeleteOnStaleGet=!!p,this.updateAgeOnGet=!!h,this.updateAgeOnHas=!!o,this.ttlResolution=y(s)||s===0?s:1,this.ttlAutopurge=!!n,this.ttl=i||0,this.ttl){if(!y(this.ttl))throw new TypeError("ttl must be a positive integer if specified");this.#G()}if(this.#l===0&&this.ttl===0&&this.#c===0)throw new TypeError("At least one of max, maxSize, or ttl is required");if(!this.ttlAutopurge&&!this.#l&&!this.#c){let E="LRU_CACHE_UNBOUNDED";G(E)&&(x.add(E),I("TTL caching without ttlAutopurge, max, or maxSize can result in unbounded memory consumption.","UnboundedCacheWarning",E,a))}}getRemainingTTL(t){return this.#s.has(t)?1/0:0}#G(){let t=new O(this.#l),e=new O(this.#l);this.#d=t,this.#y=e,this.#j=(n,h,o=this.#S.now())=>{if(e[n]=h!==0?o:0,t[n]=h,h!==0&&this.ttlAutopurge){let r=setTimeout(()=>{this.#g(n)&&this.#E(this.#i[n],"expire")},h+1);r.unref&&r.unref()}},this.#C=n=>{e[n]=t[n]!==0?this.#S.now():0},this.#O=(n,h)=>{if(t[h]){let o=t[h],r=e[h];if(!o||!r)return;n.ttl=o,n.start=r,n.now=i||s();let g=n.now-r;n.remainingTTL=o-g}};let i=0,s=()=>{let n=this.#S.now();if(this.ttlResolution>0){i=n;let h=setTimeout(()=>i=0,this.ttlResolution);h.unref&&h.unref()}return n};this.getRemainingTTL=n=>{let h=this.#s.get(n);if(h===void 0)return 0;let o=t[h],r=e[h];if(!o||!r)return 1/0;let g=(i||s())-r;return o-g},this.#g=n=>{let h=e[n],o=t[n];return!!o&&!!h&&(i||s())-h>o}}#C=()=>{};#O=()=>{};#j=()=>{};#g=()=>!1;#V(){let t=new O(this.#l);this.#_=0,this.#b=t,this.#R=e=>{this.#_-=t[e],t[e]=0},this.#N=(e,i,s,n)=>{if(this.#e(i))return 0;if(!y(s))if(n){if(typeof n!="function")throw new TypeError("sizeCalculation must be a function");if(s=n(i,e),!y(s))throw new TypeError("sizeCalculation return invalid (expect positive integer)")}else throw new TypeError("invalid size value (must be positive integer). When maxSize or maxEntrySize is used, sizeCalculation or size must be set.");return s},this.#I=(e,i,s)=>{if(t[e]=i,this.#c){let n=this.#c-t[e];for(;this.#_>n;)this.#U(!0)}this.#_+=t[e],s&&(s.entrySize=i,s.totalCalculatedSize=this.#_)}}#R=t=>{};#I=(t,e,i)=>{};#N=(t,e,i,s)=>{if(i||s)throw new TypeError("cannot set size without setting maxSize or maxEntrySize on cache");return 0};*#F({allowStale:t=this.allowStale}={}){if(this.#n)for(let e=this.#h;!(!this.#P(e)||((t||!this.#g(e))&&(yield e),e===this.#o));)e=this.#u[e]}*#T({allowStale:t=this.allowStale}={}){if(this.#n)for(let e=this.#o;!(!this.#P(e)||((t||!this.#g(e))&&(yield e),e===this.#h));)e=this.#a[e]}#P(t){return t!==void 0&&this.#s.get(this.#i[t])===t}*entries(){for(let t of this.#F())this.#t[t]!==void 0&&this.#i[t]!==void 0&&!this.#e(this.#t[t])&&(yield[this.#i[t],this.#t[t]])}*rentries(){for(let t of this.#T())this.#t[t]!==void 0&&this.#i[t]!==void 0&&!this.#e(this.#t[t])&&(yield[this.#i[t],this.#t[t]])}*keys(){for(let t of this.#F()){let e=this.#i[t];e!==void 0&&!this.#e(this.#t[t])&&(yield e)}}*rkeys(){for(let t of this.#T()){let e=this.#i[t];e!==void 0&&!this.#e(this.#t[t])&&(yield e)}}*values(){for(let t of this.#F())this.#t[t]!==void 0&&!this.#e(this.#t[t])&&(yield this.#t[t])}*rvalues(){for(let t of this.#T())this.#t[t]!==void 0&&!this.#e(this.#t[t])&&(yield this.#t[t])}[Symbol.iterator](){return this.entries()}[Symbol.toStringTag]="LRUCache";find(t,e={}){for(let i of this.#F()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;if(n!==void 0&&t(n,this.#i[i],this))return this.get(this.#i[i],e)}}forEach(t,e=this){for(let i of this.#F()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;n!==void 0&&t.call(e,n,this.#i[i],this)}}rforEach(t,e=this){for(let i of this.#T()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;n!==void 0&&t.call(e,n,this.#i[i],this)}}purgeStale(){let t=!1;for(let e of this.#T({allowStale:!0}))this.#g(e)&&(this.#E(this.#i[e],"expire"),t=!0);return t}info(t){let e=this.#s.get(t);if(e===void 0)return;let i=this.#t[e],s=this.#e(i)?i.__staleWhileFetching:i;if(s===void 0)return;let n={value:s};if(this.#d&&this.#y){let h=this.#d[e],o=this.#y[e];if(h&&o){let r=h-(this.#S.now()-o);n.ttl=r,n.start=Date.now()}}return this.#b&&(n.size=this.#b[e]),n}dump(){let t=[];for(let e of this.#F({allowStale:!0})){let i=this.#i[e],s=this.#t[e],n=this.#e(s)?s.__staleWhileFetching:s;if(n===void 0||i===void 0)continue;let h={value:n};if(this.#d&&this.#y){h.ttl=this.#d[e];let o=this.#S.now()-this.#y[e];h.start=Math.floor(Date.now()-o)}this.#b&&(h.size=this.#b[e]),t.unshift([i,h])}return t}load(t){this.clear();for(let[e,i]of t){if(i.start){let s=Date.now()-i.start;i.start=this.#S.now()-s}this.set(e,i.value,i)}}set(t,e,i={}){if(e===void 0)return this.delete(t),this;let{ttl:s=this.ttl,start:n,noDisposeOnSet:h=this.noDisposeOnSet,sizeCalculation:o=this.sizeCalculation,status:r}=i,{noUpdateTTL:g=this.noUpdateTTL}=i,_=this.#N(t,e,i.size||0,o);if(this.maxEntrySize&&_>this.maxEntrySize)return r&&(r.set="miss",r.maxEntrySizeExceeded=!0),this.#E(t,"set"),this;let f=this.#n===0?void 0:this.#s.get(t);if(f===void 0)f=this.#n===0?this.#h:this.#m.length!==0?this.#m.pop():this.#n===this.#l?this.#U(!1):this.#n,this.#i[f]=t,this.#t[f]=e,this.#s.set(t,f),this.#a[this.#h]=f,this.#u[f]=this.#h,this.#h=f,this.#n++,this.#I(f,_,r),r&&(r.set="add"),g=!1,this.#x&&this.#v?.(e,t,"add");else{this.#W(f);let c=this.#t[f];if(e!==c){if(this.#z&&this.#e(c)){c.__abortController.abort(new Error("replaced"));let{__staleWhileFetching:u}=c;u!==void 0&&!h&&(this.#A&&this.#p?.(u,t,"set"),this.#f&&this.#r?.push([u,t,"set"]))}else h||(this.#A&&this.#p?.(c,t,"set"),this.#f&&this.#r?.push([c,t,"set"]));if(this.#R(f),this.#I(f,_,r),this.#t[f]=e,r){r.set="replace";let u=c&&this.#e(c)?c.__staleWhileFetching:c;u!==void 0&&(r.oldValue=u)}}else r&&(r.set="update");this.#x&&this.onInsert?.(e,t,e===c?"update":"replace")}if(s!==0&&!this.#d&&this.#G(),this.#d&&(g||this.#j(f,s,n),r&&this.#O(r,f)),!h&&this.#f&&this.#r){let c=this.#r,u;for(;u=c?.shift();)this.#w?.(...u)}return this}pop(){try{for(;this.#n;){let t=this.#t[this.#o];if(this.#U(!0),this.#e(t)){if(t.__staleWhileFetching)return t.__staleWhileFetching}else if(t!==void 0)return t}}finally{if(this.#f&&this.#r){let t=this.#r,e;for(;e=t?.shift();)this.#w?.(...e)}}}#U(t){let e=this.#o,i=this.#i[e],s=this.#t[e];return this.#z&&this.#e(s)?s.__abortController.abort(new Error("evicted")):(this.#A||this.#f)&&(this.#A&&this.#p?.(s,i,"evict"),this.#f&&this.#r?.push([s,i,"evict"])),this.#R(e),t&&(this.#i[e]=void 0,this.#t[e]=void 0,this.#m.push(e)),this.#n===1?(this.#o=this.#h=0,this.#m.length=0):this.#o=this.#a[e],this.#s.delete(i),this.#n--,e}has(t,e={}){let{updateAgeOnHas:i=this.updateAgeOnHas,status:s}=e,n=this.#s.get(t);if(n!==void 0){let h=this.#t[n];if(this.#e(h)&&h.__staleWhileFetching===void 0)return!1;if(this.#g(n))s&&(s.has="stale",this.#O(s,n));else return i&&this.#C(n),s&&(s.has="hit",this.#O(s,n)),!0}else s&&(s.has="miss");return!1}peek(t,e={}){let{allowStale:i=this.allowStale}=e,s=this.#s.get(t);if(s===void 0||!i&&this.#g(s))return;let n=this.#t[s];return this.#e(n)?n.__staleWhileFetching:n}#M(t,e,i,s){let n=e===void 0?void 0:this.#t[e];if(this.#e(n))return n;let h=new C,{signal:o}=i;o?.addEventListener("abort",()=>h.abort(o.reason),{signal:h.signal});let r={signal:h.signal,options:i,context:s},g=(d,m=!1)=>{let{aborted:l}=h.signal,w=i.ignoreFetchAbort&&d!==void 0;if(i.status&&(l&&!m?(i.status.fetchAborted=!0,i.status.fetchError=h.signal.reason,w&&(i.status.fetchAbortIgnored=!0)):i.status.fetchResolved=!0),l&&!w&&!m)return f(h.signal.reason);let b=u;return this.#t[e]===u&&(d===void 0?b.__staleWhileFetching!==void 0?this.#t[e]=b.__staleWhileFetching:this.#E(t,"fetch"):(i.status&&(i.status.fetchUpdated=!0),this.set(t,d,r.options))),d},_=d=>(i.status&&(i.status.fetchRejected=!0,i.status.fetchError=d),f(d)),f=d=>{let{aborted:m}=h.signal,l=m&&i.allowStaleOnFetchAbort,w=l||i.allowStaleOnFetchRejection,b=w||i.noDeleteOnFetchRejection,p=u;if(this.#t[e]===u&&(!b||p.__staleWhileFetching===void 0?this.#E(t,"fetch"):l||(this.#t[e]=p.__staleWhileFetching)),w)return i.status&&p.__staleWhileFetching!==void 0&&(i.status.returnedStale=!0),p.__staleWhileFetching;if(p.__returned===p)throw d},c=(d,m)=>{let l=this.#D?.(t,n,r);l&&l instanceof Promise&&l.then(w=>d(w===void 0?void 0:w),m),h.signal.addEventListener("abort",()=>{(!i.ignoreFetchAbort||i.allowStaleOnFetchAbort)&&(d(void 0),i.allowStaleOnFetchAbort&&(d=w=>g(w,!0)))})};i.status&&(i.status.fetchDispatched=!0);let u=new Promise(c).then(g,_),A=Object.assign(u,{__abortController:h,__staleWhileFetching:n,__returned:void 0});return e===void 0?(this.set(t,A,{...r.options,status:void 0}),e=this.#s.get(t)):this.#t[e]=A,A}#e(t){if(!this.#z)return!1;let e=t;return!!e&&e instanceof Promise&&e.hasOwnProperty("__staleWhileFetching")&&e.__abortController instanceof C}async fetch(t,e={}){let{allowStale:i=this.allowStale,updateAgeOnGet:s=this.updateAgeOnGet,noDeleteOnStaleGet:n=this.noDeleteOnStaleGet,ttl:h=this.ttl,noDisposeOnSet:o=this.noDisposeOnSet,size:r=0,sizeCalculation:g=this.sizeCalculation,noUpdateTTL:_=this.noUpdateTTL,noDeleteOnFetchRejection:f=this.noDeleteOnFetchRejection,allowStaleOnFetchRejection:c=this.allowStaleOnFetchRejection,ignoreFetchAbort:u=this.ignoreFetchAbort,allowStaleOnFetchAbort:A=this.allowStaleOnFetchAbort,context:d,forceRefresh:m=!1,status:l,signal:w}=e;if(!this.#z)return l&&(l.fetch="get"),this.get(t,{allowStale:i,updateAgeOnGet:s,noDeleteOnStaleGet:n,status:l});let b={allowStale:i,updateAgeOnGet:s,noDeleteOnStaleGet:n,ttl:h,noDisposeOnSet:o,size:r,sizeCalculation:g,noUpdateTTL:_,noDeleteOnFetchRejection:f,allowStaleOnFetchRejection:c,allowStaleOnFetchAbort:A,ignoreFetchAbort:u,status:l,signal:w},p=this.#s.get(t);if(p===void 0){l&&(l.fetch="miss");let S=this.#M(t,p,b,d);return S.__returned=S}else{let S=this.#t[p];if(this.#e(S)){let E=i&&S.__staleWhileFetching!==void 0;return l&&(l.fetch="inflight",E&&(l.returnedStale=!0)),E?S.__staleWhileFetching:S.__returned=S}let z=this.#g(p);if(!m&&!z)return l&&(l.fetch="hit"),this.#W(p),s&&this.#C(p),l&&this.#O(l,p),S;let F=this.#M(t,p,b,d),T=F.__staleWhileFetching!==void 0&&i;return l&&(l.fetch=z?"stale":"refresh",T&&z&&(l.returnedStale=!0)),T?F.__staleWhileFetching:F.__returned=F}}async forceFetch(t,e={}){let i=await this.fetch(t,e);if(i===void 0)throw new Error("fetch() returned undefined");return i}memo(t,e={}){let i=this.#L;if(!i)throw new Error("no memoMethod provided to constructor");let{context:s,forceRefresh:n,...h}=e,o=this.get(t,h);if(!n&&o!==void 0)return o;let r=i(t,o,{options:h,context:s});return this.set(t,r,h),r}get(t,e={}){let{allowStale:i=this.allowStale,updateAgeOnGet:s=this.updateAgeOnGet,noDeleteOnStaleGet:n=this.noDeleteOnStaleGet,status:h}=e,o=this.#s.get(t);if(o!==void 0){let r=this.#t[o],g=this.#e(r);return h&&this.#O(h,o),this.#g(o)?(h&&(h.get="stale"),g?(h&&i&&r.__staleWhileFetching!==void 0&&(h.returnedStale=!0),i?r.__staleWhileFetching:void 0):(n||this.#E(t,"expire"),h&&i&&(h.returnedStale=!0),i?r:void 0)):(h&&(h.get="hit"),g?r.__staleWhileFetching:(this.#W(o),s&&this.#C(o),r))}else h&&(h.get="miss")}#H(t,e){this.#u[e]=t,this.#a[t]=e}#W(t){t!==this.#h&&(t===this.#o?this.#o=this.#a[t]:this.#H(this.#u[t],this.#a[t]),this.#H(this.#h,t),this.#h=t)}delete(t){return this.#E(t,"delete")}#E(t,e){let i=!1;if(this.#n!==0){let s=this.#s.get(t);if(s!==void 0)if(i=!0,this.#n===1)this.#k(e);else{this.#R(s);let n=this.#t[s];if(this.#e(n)?n.__abortController.abort(new Error("deleted")):(this.#A||this.#f)&&(this.#A&&this.#p?.(n,t,e),this.#f&&this.#r?.push([n,t,e])),this.#s.delete(t),this.#i[s]=void 0,this.#t[s]=void 0,s===this.#h)this.#h=this.#u[s];else if(s===this.#o)this.#o=this.#a[s];else{let h=this.#u[s];this.#a[h]=this.#a[s];let o=this.#a[s];this.#u[o]=this.#u[s]}this.#n--,this.#m.push(s)}}if(this.#f&&this.#r?.length){let s=this.#r,n;for(;n=s?.shift();)this.#w?.(...n)}return i}clear(){return this.#k("delete")}#k(t){for(let e of this.#T({allowStale:!0})){let i=this.#t[e];if(this.#e(i))i.__abortController.abort(new Error("deleted"));else{let s=this.#i[e];this.#A&&this.#p?.(i,s,t),this.#f&&this.#r?.push([i,s,t])}}if(this.#s.clear(),this.#t.fill(void 0),this.#i.fill(void 0),this.#d&&this.#y&&(this.#d.fill(0),this.#y.fill(0)),this.#b&&this.#b.fill(0),this.#o=0,this.#h=0,this.#m.length=0,this.#_=0,this.#n=0,this.#f&&this.#r){let e=this.#r,i;for(;i=e?.shift();)this.#w?.(...i)}}};export{L as LRUCache}; +var M=typeof performance=="object"&&performance&&typeof performance.now=="function"?performance:Date,x=new Set,R=typeof process=="object"&&process?process:{},I=(a,t,e,i)=>{typeof R.emitWarning=="function"?R.emitWarning(a,t,e,i):console.error(`[${e}] ${t}: ${a}`)},C=globalThis.AbortController,D=globalThis.AbortSignal;if(typeof C>"u"){D=class{onabort;_onabort=[];reason;aborted=!1;addEventListener(i,s){this._onabort.push(s)}},C=class{constructor(){t()}signal=new D;abort(i){if(!this.signal.aborted){this.signal.reason=i,this.signal.aborted=!0;for(let s of this.signal._onabort)s(i);this.signal.onabort?.(i)}}};let a=R.env?.LRU_CACHE_IGNORE_AC_WARNING!=="1",t=()=>{a&&(a=!1,I("AbortController is not defined. If using lru-cache in node 14, load an AbortController polyfill from the `node-abort-controller` package. A minimal polyfill is provided for use by LRUCache.fetch(), but it should not be relied upon in other contexts (eg, passing it to other APIs that use AbortController/AbortSignal might have undesirable effects). You may disable this with LRU_CACHE_IGNORE_AC_WARNING=1 in the env.","NO_ABORT_CONTROLLER","ENOTSUP",t))}}var G=a=>!x.has(a),H=Symbol("type"),y=a=>a&&a===Math.floor(a)&&a>0&&isFinite(a),U=a=>y(a)?a<=Math.pow(2,8)?Uint8Array:a<=Math.pow(2,16)?Uint16Array:a<=Math.pow(2,32)?Uint32Array:a<=Number.MAX_SAFE_INTEGER?O:null:null,O=class extends Array{constructor(t){super(t),this.fill(0)}},W=class a{heap;length;static#l=!1;static create(t){let e=U(t);if(!e)return[];a.#l=!0;let i=new a(t,e);return a.#l=!1,i}constructor(t,e){if(!a.#l)throw new TypeError("instantiate Stack using Stack.create(n)");this.heap=new e(t),this.length=0}push(t){this.heap[this.length++]=t}pop(){return this.heap[--this.length]}},L=class a{#l;#c;#p;#v;#w;#D;#L;#S;get perf(){return this.#S}ttl;ttlResolution;ttlAutopurge;updateAgeOnGet;updateAgeOnHas;allowStale;noDisposeOnSet;noUpdateTTL;maxEntrySize;sizeCalculation;noDeleteOnFetchRejection;noDeleteOnStaleGet;allowStaleOnFetchAbort;allowStaleOnFetchRejection;ignoreFetchAbort;#n;#_;#s;#i;#t;#a;#u;#o;#h;#m;#r;#b;#y;#d;#A;#z;#f;#x;static unsafeExposeInternals(t){return{starts:t.#y,ttls:t.#d,sizes:t.#b,keyMap:t.#s,keyList:t.#i,valList:t.#t,next:t.#a,prev:t.#u,get head(){return t.#o},get tail(){return t.#h},free:t.#m,isBackgroundFetch:e=>t.#e(e),backgroundFetch:(e,i,s,n)=>t.#M(e,i,s,n),moveToTail:e=>t.#W(e),indexes:e=>t.#F(e),rindexes:e=>t.#T(e),isStale:e=>t.#g(e)}}get max(){return this.#l}get maxSize(){return this.#c}get calculatedSize(){return this.#_}get size(){return this.#n}get fetchMethod(){return this.#D}get memoMethod(){return this.#L}get dispose(){return this.#p}get onInsert(){return this.#v}get disposeAfter(){return this.#w}constructor(t){let{max:e=0,ttl:i,ttlResolution:s=1,ttlAutopurge:n,updateAgeOnGet:h,updateAgeOnHas:o,allowStale:r,dispose:p,onInsert:m,disposeAfter:f,noDisposeOnSet:u,noUpdateTTL:d,maxSize:A=0,maxEntrySize:g=0,sizeCalculation:_,fetchMethod:l,memoMethod:w,noDeleteOnFetchRejection:b,noDeleteOnStaleGet:c,allowStaleOnFetchRejection:S,allowStaleOnFetchAbort:z,ignoreFetchAbort:F,perf:v}=t;if(v!==void 0&&typeof v?.now!="function")throw new TypeError("perf option must have a now() method if specified");if(this.#S=v??M,e!==0&&!y(e))throw new TypeError("max option must be a nonnegative integer");let T=e?U(e):Array;if(!T)throw new Error("invalid max value: "+e);if(this.#l=e,this.#c=A,this.maxEntrySize=g||this.#c,this.sizeCalculation=_,this.sizeCalculation){if(!this.#c&&!this.maxEntrySize)throw new TypeError("cannot set sizeCalculation without setting maxSize or maxEntrySize");if(typeof this.sizeCalculation!="function")throw new TypeError("sizeCalculation set to non-function")}if(w!==void 0&&typeof w!="function")throw new TypeError("memoMethod must be a function if defined");if(this.#L=w,l!==void 0&&typeof l!="function")throw new TypeError("fetchMethod must be a function if specified");if(this.#D=l,this.#z=!!l,this.#s=new Map,this.#i=new Array(e).fill(void 0),this.#t=new Array(e).fill(void 0),this.#a=new T(e),this.#u=new T(e),this.#o=0,this.#h=0,this.#m=W.create(e),this.#n=0,this.#_=0,typeof p=="function"&&(this.#p=p),typeof m=="function"&&(this.#v=m),typeof f=="function"?(this.#w=f,this.#r=[]):(this.#w=void 0,this.#r=void 0),this.#A=!!this.#p,this.#x=!!this.#v,this.#f=!!this.#w,this.noDisposeOnSet=!!u,this.noUpdateTTL=!!d,this.noDeleteOnFetchRejection=!!b,this.allowStaleOnFetchRejection=!!S,this.allowStaleOnFetchAbort=!!z,this.ignoreFetchAbort=!!F,this.maxEntrySize!==0){if(this.#c!==0&&!y(this.#c))throw new TypeError("maxSize must be a positive integer if specified");if(!y(this.maxEntrySize))throw new TypeError("maxEntrySize must be a positive integer if specified");this.#V()}if(this.allowStale=!!r,this.noDeleteOnStaleGet=!!c,this.updateAgeOnGet=!!h,this.updateAgeOnHas=!!o,this.ttlResolution=y(s)||s===0?s:1,this.ttlAutopurge=!!n,this.ttl=i||0,this.ttl){if(!y(this.ttl))throw new TypeError("ttl must be a positive integer if specified");this.#G()}if(this.#l===0&&this.ttl===0&&this.#c===0)throw new TypeError("At least one of max, maxSize, or ttl is required");if(!this.ttlAutopurge&&!this.#l&&!this.#c){let E="LRU_CACHE_UNBOUNDED";G(E)&&(x.add(E),I("TTL caching without ttlAutopurge, max, or maxSize can result in unbounded memory consumption.","UnboundedCacheWarning",E,a))}}getRemainingTTL(t){return this.#s.has(t)?1/0:0}#G(){let t=new O(this.#l),e=new O(this.#l);this.#d=t,this.#y=e,this.#j=(n,h,o=this.#S.now())=>{if(e[n]=h!==0?o:0,t[n]=h,h!==0&&this.ttlAutopurge){let r=setTimeout(()=>{this.#g(n)&&this.#E(this.#i[n],"expire")},h+1);r.unref&&r.unref()}},this.#C=n=>{e[n]=t[n]!==0?this.#S.now():0},this.#O=(n,h)=>{if(t[h]){let o=t[h],r=e[h];if(!o||!r)return;n.ttl=o,n.start=r,n.now=i||s();let p=n.now-r;n.remainingTTL=o-p}};let i=0,s=()=>{let n=this.#S.now();if(this.ttlResolution>0){i=n;let h=setTimeout(()=>i=0,this.ttlResolution);h.unref&&h.unref()}return n};this.getRemainingTTL=n=>{let h=this.#s.get(n);if(h===void 0)return 0;let o=t[h],r=e[h];if(!o||!r)return 1/0;let p=(i||s())-r;return o-p},this.#g=n=>{let h=e[n],o=t[n];return!!o&&!!h&&(i||s())-h>o}}#C=()=>{};#O=()=>{};#j=()=>{};#g=()=>!1;#V(){let t=new O(this.#l);this.#_=0,this.#b=t,this.#R=e=>{this.#_-=t[e],t[e]=0},this.#N=(e,i,s,n)=>{if(this.#e(i))return 0;if(!y(s))if(n){if(typeof n!="function")throw new TypeError("sizeCalculation must be a function");if(s=n(i,e),!y(s))throw new TypeError("sizeCalculation return invalid (expect positive integer)")}else throw new TypeError("invalid size value (must be positive integer). When maxSize or maxEntrySize is used, sizeCalculation or size must be set.");return s},this.#I=(e,i,s)=>{if(t[e]=i,this.#c){let n=this.#c-t[e];for(;this.#_>n;)this.#U(!0)}this.#_+=t[e],s&&(s.entrySize=i,s.totalCalculatedSize=this.#_)}}#R=t=>{};#I=(t,e,i)=>{};#N=(t,e,i,s)=>{if(i||s)throw new TypeError("cannot set size without setting maxSize or maxEntrySize on cache");return 0};*#F({allowStale:t=this.allowStale}={}){if(this.#n)for(let e=this.#h;!(!this.#P(e)||((t||!this.#g(e))&&(yield e),e===this.#o));)e=this.#u[e]}*#T({allowStale:t=this.allowStale}={}){if(this.#n)for(let e=this.#o;!(!this.#P(e)||((t||!this.#g(e))&&(yield e),e===this.#h));)e=this.#a[e]}#P(t){return t!==void 0&&this.#s.get(this.#i[t])===t}*entries(){for(let t of this.#F())this.#t[t]!==void 0&&this.#i[t]!==void 0&&!this.#e(this.#t[t])&&(yield[this.#i[t],this.#t[t]])}*rentries(){for(let t of this.#T())this.#t[t]!==void 0&&this.#i[t]!==void 0&&!this.#e(this.#t[t])&&(yield[this.#i[t],this.#t[t]])}*keys(){for(let t of this.#F()){let e=this.#i[t];e!==void 0&&!this.#e(this.#t[t])&&(yield e)}}*rkeys(){for(let t of this.#T()){let e=this.#i[t];e!==void 0&&!this.#e(this.#t[t])&&(yield e)}}*values(){for(let t of this.#F())this.#t[t]!==void 0&&!this.#e(this.#t[t])&&(yield this.#t[t])}*rvalues(){for(let t of this.#T())this.#t[t]!==void 0&&!this.#e(this.#t[t])&&(yield this.#t[t])}[Symbol.iterator](){return this.entries()}[Symbol.toStringTag]="LRUCache";find(t,e={}){for(let i of this.#F()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;if(n!==void 0&&t(n,this.#i[i],this))return this.get(this.#i[i],e)}}forEach(t,e=this){for(let i of this.#F()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;n!==void 0&&t.call(e,n,this.#i[i],this)}}rforEach(t,e=this){for(let i of this.#T()){let s=this.#t[i],n=this.#e(s)?s.__staleWhileFetching:s;n!==void 0&&t.call(e,n,this.#i[i],this)}}purgeStale(){let t=!1;for(let e of this.#T({allowStale:!0}))this.#g(e)&&(this.#E(this.#i[e],"expire"),t=!0);return t}info(t){let e=this.#s.get(t);if(e===void 0)return;let i=this.#t[e],s=this.#e(i)?i.__staleWhileFetching:i;if(s===void 0)return;let n={value:s};if(this.#d&&this.#y){let h=this.#d[e],o=this.#y[e];if(h&&o){let r=h-(this.#S.now()-o);n.ttl=r,n.start=Date.now()}}return this.#b&&(n.size=this.#b[e]),n}dump(){let t=[];for(let e of this.#F({allowStale:!0})){let i=this.#i[e],s=this.#t[e],n=this.#e(s)?s.__staleWhileFetching:s;if(n===void 0||i===void 0)continue;let h={value:n};if(this.#d&&this.#y){h.ttl=this.#d[e];let o=this.#S.now()-this.#y[e];h.start=Math.floor(Date.now()-o)}this.#b&&(h.size=this.#b[e]),t.unshift([i,h])}return t}load(t){this.clear();for(let[e,i]of t){if(i.start){let s=Date.now()-i.start;i.start=this.#S.now()-s}this.set(e,i.value,i)}}set(t,e,i={}){if(e===void 0)return this.delete(t),this;let{ttl:s=this.ttl,start:n,noDisposeOnSet:h=this.noDisposeOnSet,sizeCalculation:o=this.sizeCalculation,status:r}=i,{noUpdateTTL:p=this.noUpdateTTL}=i,m=this.#N(t,e,i.size||0,o);if(this.maxEntrySize&&m>this.maxEntrySize)return r&&(r.set="miss",r.maxEntrySizeExceeded=!0),this.#E(t,"set"),this;let f=this.#n===0?void 0:this.#s.get(t);if(f===void 0)f=this.#n===0?this.#h:this.#m.length!==0?this.#m.pop():this.#n===this.#l?this.#U(!1):this.#n,this.#i[f]=t,this.#t[f]=e,this.#s.set(t,f),this.#a[this.#h]=f,this.#u[f]=this.#h,this.#h=f,this.#n++,this.#I(f,m,r),r&&(r.set="add"),p=!1,this.#x&&this.#v?.(e,t,"add");else{this.#W(f);let u=this.#t[f];if(e!==u){if(this.#z&&this.#e(u)){u.__abortController.abort(new Error("replaced"));let{__staleWhileFetching:d}=u;d!==void 0&&!h&&(this.#A&&this.#p?.(d,t,"set"),this.#f&&this.#r?.push([d,t,"set"]))}else h||(this.#A&&this.#p?.(u,t,"set"),this.#f&&this.#r?.push([u,t,"set"]));if(this.#R(f),this.#I(f,m,r),this.#t[f]=e,r){r.set="replace";let d=u&&this.#e(u)?u.__staleWhileFetching:u;d!==void 0&&(r.oldValue=d)}}else r&&(r.set="update");this.#x&&this.onInsert?.(e,t,e===u?"update":"replace")}if(s!==0&&!this.#d&&this.#G(),this.#d&&(p||this.#j(f,s,n),r&&this.#O(r,f)),!h&&this.#f&&this.#r){let u=this.#r,d;for(;d=u?.shift();)this.#w?.(...d)}return this}pop(){try{for(;this.#n;){let t=this.#t[this.#o];if(this.#U(!0),this.#e(t)){if(t.__staleWhileFetching)return t.__staleWhileFetching}else if(t!==void 0)return t}}finally{if(this.#f&&this.#r){let t=this.#r,e;for(;e=t?.shift();)this.#w?.(...e)}}}#U(t){let e=this.#o,i=this.#i[e],s=this.#t[e];return this.#z&&this.#e(s)?s.__abortController.abort(new Error("evicted")):(this.#A||this.#f)&&(this.#A&&this.#p?.(s,i,"evict"),this.#f&&this.#r?.push([s,i,"evict"])),this.#R(e),t&&(this.#i[e]=void 0,this.#t[e]=void 0,this.#m.push(e)),this.#n===1?(this.#o=this.#h=0,this.#m.length=0):this.#o=this.#a[e],this.#s.delete(i),this.#n--,e}has(t,e={}){let{updateAgeOnHas:i=this.updateAgeOnHas,status:s}=e,n=this.#s.get(t);if(n!==void 0){let h=this.#t[n];if(this.#e(h)&&h.__staleWhileFetching===void 0)return!1;if(this.#g(n))s&&(s.has="stale",this.#O(s,n));else return i&&this.#C(n),s&&(s.has="hit",this.#O(s,n)),!0}else s&&(s.has="miss");return!1}peek(t,e={}){let{allowStale:i=this.allowStale}=e,s=this.#s.get(t);if(s===void 0||!i&&this.#g(s))return;let n=this.#t[s];return this.#e(n)?n.__staleWhileFetching:n}#M(t,e,i,s){let n=e===void 0?void 0:this.#t[e];if(this.#e(n))return n;let h=new C,{signal:o}=i;o?.addEventListener("abort",()=>h.abort(o.reason),{signal:h.signal});let r={signal:h.signal,options:i,context:s},p=(g,_=!1)=>{let{aborted:l}=h.signal,w=i.ignoreFetchAbort&&g!==void 0;if(i.status&&(l&&!_?(i.status.fetchAborted=!0,i.status.fetchError=h.signal.reason,w&&(i.status.fetchAbortIgnored=!0)):i.status.fetchResolved=!0),l&&!w&&!_)return f(h.signal.reason);let b=d,c=this.#t[e];return(c===d||w&&_&&c===void 0)&&(g===void 0?b.__staleWhileFetching!==void 0?this.#t[e]=b.__staleWhileFetching:this.#E(t,"fetch"):(i.status&&(i.status.fetchUpdated=!0),this.set(t,g,r.options))),g},m=g=>(i.status&&(i.status.fetchRejected=!0,i.status.fetchError=g),f(g)),f=g=>{let{aborted:_}=h.signal,l=_&&i.allowStaleOnFetchAbort,w=l||i.allowStaleOnFetchRejection,b=w||i.noDeleteOnFetchRejection,c=d;if(this.#t[e]===d&&(!b||c.__staleWhileFetching===void 0?this.#E(t,"fetch"):l||(this.#t[e]=c.__staleWhileFetching)),w)return i.status&&c.__staleWhileFetching!==void 0&&(i.status.returnedStale=!0),c.__staleWhileFetching;if(c.__returned===c)throw g},u=(g,_)=>{let l=this.#D?.(t,n,r);l&&l instanceof Promise&&l.then(w=>g(w===void 0?void 0:w),_),h.signal.addEventListener("abort",()=>{(!i.ignoreFetchAbort||i.allowStaleOnFetchAbort)&&(g(void 0),i.allowStaleOnFetchAbort&&(g=w=>p(w,!0)))})};i.status&&(i.status.fetchDispatched=!0);let d=new Promise(u).then(p,m),A=Object.assign(d,{__abortController:h,__staleWhileFetching:n,__returned:void 0});return e===void 0?(this.set(t,A,{...r.options,status:void 0}),e=this.#s.get(t)):this.#t[e]=A,A}#e(t){if(!this.#z)return!1;let e=t;return!!e&&e instanceof Promise&&e.hasOwnProperty("__staleWhileFetching")&&e.__abortController instanceof C}async fetch(t,e={}){let{allowStale:i=this.allowStale,updateAgeOnGet:s=this.updateAgeOnGet,noDeleteOnStaleGet:n=this.noDeleteOnStaleGet,ttl:h=this.ttl,noDisposeOnSet:o=this.noDisposeOnSet,size:r=0,sizeCalculation:p=this.sizeCalculation,noUpdateTTL:m=this.noUpdateTTL,noDeleteOnFetchRejection:f=this.noDeleteOnFetchRejection,allowStaleOnFetchRejection:u=this.allowStaleOnFetchRejection,ignoreFetchAbort:d=this.ignoreFetchAbort,allowStaleOnFetchAbort:A=this.allowStaleOnFetchAbort,context:g,forceRefresh:_=!1,status:l,signal:w}=e;if(!this.#z)return l&&(l.fetch="get"),this.get(t,{allowStale:i,updateAgeOnGet:s,noDeleteOnStaleGet:n,status:l});let b={allowStale:i,updateAgeOnGet:s,noDeleteOnStaleGet:n,ttl:h,noDisposeOnSet:o,size:r,sizeCalculation:p,noUpdateTTL:m,noDeleteOnFetchRejection:f,allowStaleOnFetchRejection:u,allowStaleOnFetchAbort:A,ignoreFetchAbort:d,status:l,signal:w},c=this.#s.get(t);if(c===void 0){l&&(l.fetch="miss");let S=this.#M(t,c,b,g);return S.__returned=S}else{let S=this.#t[c];if(this.#e(S)){let E=i&&S.__staleWhileFetching!==void 0;return l&&(l.fetch="inflight",E&&(l.returnedStale=!0)),E?S.__staleWhileFetching:S.__returned=S}let z=this.#g(c);if(!_&&!z)return l&&(l.fetch="hit"),this.#W(c),s&&this.#C(c),l&&this.#O(l,c),S;let F=this.#M(t,c,b,g),T=F.__staleWhileFetching!==void 0&&i;return l&&(l.fetch=z?"stale":"refresh",T&&z&&(l.returnedStale=!0)),T?F.__staleWhileFetching:F.__returned=F}}async forceFetch(t,e={}){let i=await this.fetch(t,e);if(i===void 0)throw new Error("fetch() returned undefined");return i}memo(t,e={}){let i=this.#L;if(!i)throw new Error("no memoMethod provided to constructor");let{context:s,forceRefresh:n,...h}=e,o=this.get(t,h);if(!n&&o!==void 0)return o;let r=i(t,o,{options:h,context:s});return this.set(t,r,h),r}get(t,e={}){let{allowStale:i=this.allowStale,updateAgeOnGet:s=this.updateAgeOnGet,noDeleteOnStaleGet:n=this.noDeleteOnStaleGet,status:h}=e,o=this.#s.get(t);if(o!==void 0){let r=this.#t[o],p=this.#e(r);return h&&this.#O(h,o),this.#g(o)?(h&&(h.get="stale"),p?(h&&i&&r.__staleWhileFetching!==void 0&&(h.returnedStale=!0),i?r.__staleWhileFetching:void 0):(n||this.#E(t,"expire"),h&&i&&(h.returnedStale=!0),i?r:void 0)):(h&&(h.get="hit"),p?r.__staleWhileFetching:(this.#W(o),s&&this.#C(o),r))}else h&&(h.get="miss")}#H(t,e){this.#u[e]=t,this.#a[t]=e}#W(t){t!==this.#h&&(t===this.#o?this.#o=this.#a[t]:this.#H(this.#u[t],this.#a[t]),this.#H(this.#h,t),this.#h=t)}delete(t){return this.#E(t,"delete")}#E(t,e){let i=!1;if(this.#n!==0){let s=this.#s.get(t);if(s!==void 0)if(i=!0,this.#n===1)this.#k(e);else{this.#R(s);let n=this.#t[s];if(this.#e(n)?n.__abortController.abort(new Error("deleted")):(this.#A||this.#f)&&(this.#A&&this.#p?.(n,t,e),this.#f&&this.#r?.push([n,t,e])),this.#s.delete(t),this.#i[s]=void 0,this.#t[s]=void 0,s===this.#h)this.#h=this.#u[s];else if(s===this.#o)this.#o=this.#a[s];else{let h=this.#u[s];this.#a[h]=this.#a[s];let o=this.#a[s];this.#u[o]=this.#u[s]}this.#n--,this.#m.push(s)}}if(this.#f&&this.#r?.length){let s=this.#r,n;for(;n=s?.shift();)this.#w?.(...n)}return i}clear(){return this.#k("delete")}#k(t){for(let e of this.#T({allowStale:!0})){let i=this.#t[e];if(this.#e(i))i.__abortController.abort(new Error("deleted"));else{let s=this.#i[e];this.#A&&this.#p?.(i,s,t),this.#f&&this.#r?.push([i,s,t])}}if(this.#s.clear(),this.#t.fill(void 0),this.#i.fill(void 0),this.#d&&this.#y&&(this.#d.fill(0),this.#y.fill(0)),this.#b&&this.#b.fill(0),this.#o=0,this.#h=0,this.#m.length=0,this.#_=0,this.#n=0,this.#f&&this.#r){let e=this.#r,i;for(;i=e?.shift();)this.#w?.(...i)}}};export{L as LRUCache}; //# sourceMappingURL=index.min.js.map diff --git a/deps/npm/node_modules/lru-cache/package.json b/deps/npm/node_modules/lru-cache/package.json index 4953bdf4a7a35e..24bb077d632ea6 100644 --- a/deps/npm/node_modules/lru-cache/package.json +++ b/deps/npm/node_modules/lru-cache/package.json @@ -1,7 +1,7 @@ { "name": "lru-cache", "description": "A cache object that deletes the least-recently-used items.", - "version": "11.2.1", + "version": "11.2.2", "author": "Isaac Z. Schlueter ", "keywords": [ "mru", diff --git a/deps/npm/node_modules/normalize-package-data/LICENSE b/deps/npm/node_modules/normalize-package-data/LICENSE deleted file mode 100644 index 19d1364a8ac08f..00000000000000 --- a/deps/npm/node_modules/normalize-package-data/LICENSE +++ /dev/null @@ -1,15 +0,0 @@ -This package contains code originally written by Isaac Z. Schlueter. -Used with permission. - -Copyright (c) Meryn Stol ("Author") -All rights reserved. - -The BSD License - -Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - -1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - -2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - -THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. diff --git a/deps/npm/node_modules/normalize-package-data/lib/extract_description.js b/deps/npm/node_modules/normalize-package-data/lib/extract_description.js deleted file mode 100644 index 631966b5f29af5..00000000000000 --- a/deps/npm/node_modules/normalize-package-data/lib/extract_description.js +++ /dev/null @@ -1,24 +0,0 @@ -module.exports = extractDescription - -// Extracts description from contents of a readme file in markdown format -function extractDescription (d) { - if (!d) { - return - } - if (d === 'ERROR: No README data found!') { - return - } - // the first block of text before the first heading - // that isn't the first line heading - d = d.trim().split('\n') - let s = 0 - while (d[s] && d[s].trim().match(/^(#|$)/)) { - s++ - } - const l = d.length - let e = s + 1 - while (e < l && d[e].trim()) { - e++ - } - return d.slice(s, e).join(' ').trim() -} diff --git a/deps/npm/node_modules/normalize-package-data/lib/fixer.js b/deps/npm/node_modules/normalize-package-data/lib/fixer.js deleted file mode 100644 index 49b97f5e322e7a..00000000000000 --- a/deps/npm/node_modules/normalize-package-data/lib/fixer.js +++ /dev/null @@ -1,472 +0,0 @@ -var { URL } = require('node:url') -var isValidSemver = require('semver/functions/valid') -var cleanSemver = require('semver/functions/clean') -var validateLicense = require('validate-npm-package-license') -var hostedGitInfo = require('hosted-git-info') -var { isBuiltin } = require('node:module') -var depTypes = ['dependencies', 'devDependencies', 'optionalDependencies'] -var extractDescription = require('./extract_description') -var typos = require('./typos.json') - -var isEmail = str => str.includes('@') && (str.indexOf('@') < str.lastIndexOf('.')) - -module.exports = { - // default warning function - warn: function () {}, - - fixRepositoryField: function (data) { - if (data.repositories) { - this.warn('repositories') - data.repository = data.repositories[0] - } - if (!data.repository) { - return this.warn('missingRepository') - } - if (typeof data.repository === 'string') { - data.repository = { - type: 'git', - url: data.repository, - } - } - var r = data.repository.url || '' - if (r) { - var hosted = hostedGitInfo.fromUrl(r) - if (hosted) { - r = data.repository.url - = hosted.getDefaultRepresentation() === 'shortcut' ? hosted.https() : hosted.toString() - } - } - - if (r.match(/github.com\/[^/]+\/[^/]+\.git\.git$/)) { - this.warn('brokenGitUrl', r) - } - }, - - fixTypos: function (data) { - Object.keys(typos.topLevel).forEach(function (d) { - if (Object.prototype.hasOwnProperty.call(data, d)) { - this.warn('typo', d, typos.topLevel[d]) - } - }, this) - }, - - fixScriptsField: function (data) { - if (!data.scripts) { - return - } - if (typeof data.scripts !== 'object') { - this.warn('nonObjectScripts') - delete data.scripts - return - } - Object.keys(data.scripts).forEach(function (k) { - if (typeof data.scripts[k] !== 'string') { - this.warn('nonStringScript') - delete data.scripts[k] - } else if (typos.script[k] && !data.scripts[typos.script[k]]) { - this.warn('typo', k, typos.script[k], 'scripts') - } - }, this) - }, - - fixFilesField: function (data) { - var files = data.files - if (files && !Array.isArray(files)) { - this.warn('nonArrayFiles') - delete data.files - } else if (data.files) { - data.files = data.files.filter(function (file) { - if (!file || typeof file !== 'string') { - this.warn('invalidFilename', file) - return false - } else { - return true - } - }, this) - } - }, - - fixBinField: function (data) { - if (!data.bin) { - return - } - if (typeof data.bin === 'string') { - var b = {} - var match - if (match = data.name.match(/^@[^/]+[/](.*)$/)) { - b[match[1]] = data.bin - } else { - b[data.name] = data.bin - } - data.bin = b - } - }, - - fixManField: function (data) { - if (!data.man) { - return - } - if (typeof data.man === 'string') { - data.man = [data.man] - } - }, - fixBundleDependenciesField: function (data) { - var bdd = 'bundledDependencies' - var bd = 'bundleDependencies' - if (data[bdd] && !data[bd]) { - data[bd] = data[bdd] - delete data[bdd] - } - if (data[bd] && !Array.isArray(data[bd])) { - this.warn('nonArrayBundleDependencies') - delete data[bd] - } else if (data[bd]) { - data[bd] = data[bd].filter(function (filtered) { - if (!filtered || typeof filtered !== 'string') { - this.warn('nonStringBundleDependency', filtered) - return false - } else { - if (!data.dependencies) { - data.dependencies = {} - } - if (!Object.prototype.hasOwnProperty.call(data.dependencies, filtered)) { - this.warn('nonDependencyBundleDependency', filtered) - data.dependencies[filtered] = '*' - } - return true - } - }, this) - } - }, - - fixDependencies: function (data) { - objectifyDeps(data, this.warn) - addOptionalDepsToDeps(data, this.warn) - this.fixBundleDependenciesField(data) - - ;['dependencies', 'devDependencies'].forEach(function (deps) { - if (!(deps in data)) { - return - } - if (!data[deps] || typeof data[deps] !== 'object') { - this.warn('nonObjectDependencies', deps) - delete data[deps] - return - } - Object.keys(data[deps]).forEach(function (d) { - var r = data[deps][d] - if (typeof r !== 'string') { - this.warn('nonStringDependency', d, JSON.stringify(r)) - delete data[deps][d] - } - var hosted = hostedGitInfo.fromUrl(data[deps][d]) - if (hosted) { - data[deps][d] = hosted.toString() - } - }, this) - }, this) - }, - - fixModulesField: function (data) { - if (data.modules) { - this.warn('deprecatedModules') - delete data.modules - } - }, - - fixKeywordsField: function (data) { - if (typeof data.keywords === 'string') { - data.keywords = data.keywords.split(/,\s+/) - } - if (data.keywords && !Array.isArray(data.keywords)) { - delete data.keywords - this.warn('nonArrayKeywords') - } else if (data.keywords) { - data.keywords = data.keywords.filter(function (kw) { - if (typeof kw !== 'string' || !kw) { - this.warn('nonStringKeyword') - return false - } else { - return true - } - }, this) - } - }, - - fixVersionField: function (data, strict) { - // allow "loose" semver 1.0 versions in non-strict mode - // enforce strict semver 2.0 compliance in strict mode - var loose = !strict - if (!data.version) { - data.version = '' - return true - } - if (!isValidSemver(data.version, loose)) { - throw new Error('Invalid version: "' + data.version + '"') - } - data.version = cleanSemver(data.version, loose) - return true - }, - - fixPeople: function (data) { - modifyPeople(data, unParsePerson) - modifyPeople(data, parsePerson) - }, - - fixNameField: function (data, options) { - if (typeof options === 'boolean') { - options = { strict: options } - } else if (typeof options === 'undefined') { - options = {} - } - var strict = options.strict - if (!data.name && !strict) { - data.name = '' - return - } - if (typeof data.name !== 'string') { - throw new Error('name field must be a string.') - } - if (!strict) { - data.name = data.name.trim() - } - ensureValidName(data.name, strict, options.allowLegacyCase) - if (isBuiltin(data.name)) { - this.warn('conflictingName', data.name) - } - }, - - fixDescriptionField: function (data) { - if (data.description && typeof data.description !== 'string') { - this.warn('nonStringDescription') - delete data.description - } - if (data.readme && !data.description) { - data.description = extractDescription(data.readme) - } - if (data.description === undefined) { - delete data.description - } - if (!data.description) { - this.warn('missingDescription') - } - }, - - fixReadmeField: function (data) { - if (!data.readme) { - this.warn('missingReadme') - data.readme = 'ERROR: No README data found!' - } - }, - - fixBugsField: function (data) { - if (!data.bugs && data.repository && data.repository.url) { - var hosted = hostedGitInfo.fromUrl(data.repository.url) - if (hosted && hosted.bugs()) { - data.bugs = { url: hosted.bugs() } - } - } else if (data.bugs) { - if (typeof data.bugs === 'string') { - if (isEmail(data.bugs)) { - data.bugs = { email: data.bugs } - } else if (URL.canParse(data.bugs)) { - data.bugs = { url: data.bugs } - } else { - this.warn('nonEmailUrlBugsString') - } - } else { - bugsTypos(data.bugs, this.warn) - var oldBugs = data.bugs - data.bugs = {} - if (oldBugs.url) { - if (URL.canParse(oldBugs.url)) { - data.bugs.url = oldBugs.url - } else { - this.warn('nonUrlBugsUrlField') - } - } - if (oldBugs.email) { - if (typeof (oldBugs.email) === 'string' && isEmail(oldBugs.email)) { - data.bugs.email = oldBugs.email - } else { - this.warn('nonEmailBugsEmailField') - } - } - } - if (!data.bugs.email && !data.bugs.url) { - delete data.bugs - this.warn('emptyNormalizedBugs') - } - } - }, - - fixHomepageField: function (data) { - if (!data.homepage && data.repository && data.repository.url) { - var hosted = hostedGitInfo.fromUrl(data.repository.url) - if (hosted && hosted.docs()) { - data.homepage = hosted.docs() - } - } - if (!data.homepage) { - return - } - - if (typeof data.homepage !== 'string') { - this.warn('nonUrlHomepage') - return delete data.homepage - } - if (!URL.canParse(data.homepage)) { - data.homepage = 'http://' + data.homepage - } - }, - - fixLicenseField: function (data) { - const license = data.license || data.licence - if (!license) { - return this.warn('missingLicense') - } - if ( - typeof (license) !== 'string' || - license.length < 1 || - license.trim() === '' - ) { - return this.warn('invalidLicense') - } - if (!validateLicense(license).validForNewPackages) { - return this.warn('invalidLicense') - } - }, -} - -function isValidScopedPackageName (spec) { - if (spec.charAt(0) !== '@') { - return false - } - - var rest = spec.slice(1).split('/') - if (rest.length !== 2) { - return false - } - - return rest[0] && rest[1] && - rest[0] === encodeURIComponent(rest[0]) && - rest[1] === encodeURIComponent(rest[1]) -} - -function isCorrectlyEncodedName (spec) { - return !spec.match(/[/@\s+%:]/) && - spec === encodeURIComponent(spec) -} - -function ensureValidName (name, strict, allowLegacyCase) { - if (name.charAt(0) === '.' || - !(isValidScopedPackageName(name) || isCorrectlyEncodedName(name)) || - (strict && (!allowLegacyCase) && name !== name.toLowerCase()) || - name.toLowerCase() === 'node_modules' || - name.toLowerCase() === 'favicon.ico') { - throw new Error('Invalid name: ' + JSON.stringify(name)) - } -} - -function modifyPeople (data, fn) { - if (data.author) { - data.author = fn(data.author) - }['maintainers', 'contributors'].forEach(function (set) { - if (!Array.isArray(data[set])) { - return - } - data[set] = data[set].map(fn) - }) - return data -} - -function unParsePerson (person) { - if (typeof person === 'string') { - return person - } - var name = person.name || '' - var u = person.url || person.web - var wrappedUrl = u ? (' (' + u + ')') : '' - var e = person.email || person.mail - var wrappedEmail = e ? (' <' + e + '>') : '' - return name + wrappedEmail + wrappedUrl -} - -function parsePerson (person) { - if (typeof person !== 'string') { - return person - } - var matchedName = person.match(/^([^(<]+)/) - var matchedUrl = person.match(/\(([^()]+)\)/) - var matchedEmail = person.match(/<([^<>]+)>/) - var obj = {} - if (matchedName && matchedName[0].trim()) { - obj.name = matchedName[0].trim() - } - if (matchedEmail) { - obj.email = matchedEmail[1] - } - if (matchedUrl) { - obj.url = matchedUrl[1] - } - return obj -} - -function addOptionalDepsToDeps (data) { - var o = data.optionalDependencies - if (!o) { - return - } - var d = data.dependencies || {} - Object.keys(o).forEach(function (k) { - d[k] = o[k] - }) - data.dependencies = d -} - -function depObjectify (deps, type, warn) { - if (!deps) { - return {} - } - if (typeof deps === 'string') { - deps = deps.trim().split(/[\n\r\s\t ,]+/) - } - if (!Array.isArray(deps)) { - return deps - } - warn('deprecatedArrayDependencies', type) - var o = {} - deps.filter(function (d) { - return typeof d === 'string' - }).forEach(function (d) { - d = d.trim().split(/(:?[@\s><=])/) - var dn = d.shift() - var dv = d.join('') - dv = dv.trim() - dv = dv.replace(/^@/, '') - o[dn] = dv - }) - return o -} - -function objectifyDeps (data, warn) { - depTypes.forEach(function (type) { - if (!data[type]) { - return - } - data[type] = depObjectify(data[type], type, warn) - }) -} - -function bugsTypos (bugs, warn) { - if (!bugs) { - return - } - Object.keys(bugs).forEach(function (k) { - if (typos.bugs[k]) { - warn('typo', k, typos.bugs[k], 'bugs') - bugs[typos.bugs[k]] = bugs[k] - delete bugs[k] - } - }) -} diff --git a/deps/npm/node_modules/normalize-package-data/lib/make_warning.js b/deps/npm/node_modules/normalize-package-data/lib/make_warning.js deleted file mode 100644 index 3be9c86539952d..00000000000000 --- a/deps/npm/node_modules/normalize-package-data/lib/make_warning.js +++ /dev/null @@ -1,22 +0,0 @@ -var util = require('util') -var messages = require('./warning_messages.json') - -module.exports = function () { - var args = Array.prototype.slice.call(arguments, 0) - var warningName = args.shift() - if (warningName === 'typo') { - return makeTypoWarning.apply(null, args) - } else { - var msgTemplate = messages[warningName] ? messages[warningName] : warningName + ": '%s'" - args.unshift(msgTemplate) - return util.format.apply(null, args) - } -} - -function makeTypoWarning (providedName, probableName, field) { - if (field) { - providedName = field + "['" + providedName + "']" - probableName = field + "['" + probableName + "']" - } - return util.format(messages.typo, providedName, probableName) -} diff --git a/deps/npm/node_modules/normalize-package-data/lib/normalize.js b/deps/npm/node_modules/normalize-package-data/lib/normalize.js deleted file mode 100644 index e806f110315aae..00000000000000 --- a/deps/npm/node_modules/normalize-package-data/lib/normalize.js +++ /dev/null @@ -1,48 +0,0 @@ -module.exports = normalize - -var fixer = require('./fixer') -normalize.fixer = fixer - -var makeWarning = require('./make_warning') - -var fieldsToFix = ['name', 'version', 'description', 'repository', 'modules', 'scripts', - 'files', 'bin', 'man', 'bugs', 'keywords', 'readme', 'homepage', 'license'] -var otherThingsToFix = ['dependencies', 'people', 'typos'] - -var thingsToFix = fieldsToFix.map(function (fieldName) { - return ucFirst(fieldName) + 'Field' -}) -// two ways to do this in CoffeeScript on only one line, sub-70 chars: -// thingsToFix = fieldsToFix.map (name) -> ucFirst(name) + "Field" -// thingsToFix = (ucFirst(name) + "Field" for name in fieldsToFix) -thingsToFix = thingsToFix.concat(otherThingsToFix) - -function normalize (data, warn, strict) { - if (warn === true) { - warn = null - strict = true - } - if (!strict) { - strict = false - } - if (!warn || data.private) { - warn = function () { /* noop */ } - } - - if (data.scripts && - data.scripts.install === 'node-gyp rebuild' && - !data.scripts.preinstall) { - data.gypfile = true - } - fixer.warn = function () { - warn(makeWarning.apply(null, arguments)) - } - thingsToFix.forEach(function (thingName) { - fixer['fix' + ucFirst(thingName)](data, strict) - }) - data._id = data.name + '@' + data.version -} - -function ucFirst (string) { - return string.charAt(0).toUpperCase() + string.slice(1) -} diff --git a/deps/npm/node_modules/normalize-package-data/lib/safe_format.js b/deps/npm/node_modules/normalize-package-data/lib/safe_format.js deleted file mode 100644 index 5fc888e5450cdd..00000000000000 --- a/deps/npm/node_modules/normalize-package-data/lib/safe_format.js +++ /dev/null @@ -1,11 +0,0 @@ -var util = require('util') - -module.exports = function () { - var args = Array.prototype.slice.call(arguments, 0) - args.forEach(function (arg) { - if (!arg) { - throw new TypeError('Bad arguments.') - } - }) - return util.format.apply(null, arguments) -} diff --git a/deps/npm/node_modules/normalize-package-data/lib/typos.json b/deps/npm/node_modules/normalize-package-data/lib/typos.json deleted file mode 100644 index 7f9dd283b30ff3..00000000000000 --- a/deps/npm/node_modules/normalize-package-data/lib/typos.json +++ /dev/null @@ -1,25 +0,0 @@ -{ - "topLevel": { - "dependancies": "dependencies" - ,"dependecies": "dependencies" - ,"depdenencies": "dependencies" - ,"devEependencies": "devDependencies" - ,"depends": "dependencies" - ,"dev-dependencies": "devDependencies" - ,"devDependences": "devDependencies" - ,"devDepenencies": "devDependencies" - ,"devdependencies": "devDependencies" - ,"repostitory": "repository" - ,"repo": "repository" - ,"prefereGlobal": "preferGlobal" - ,"hompage": "homepage" - ,"hampage": "homepage" - ,"autohr": "author" - ,"autor": "author" - ,"contributers": "contributors" - ,"publicationConfig": "publishConfig" - ,"script": "scripts" - }, - "bugs": { "web": "url", "name": "url" }, - "script": { "server": "start", "tests": "test" } -} diff --git a/deps/npm/node_modules/normalize-package-data/lib/warning_messages.json b/deps/npm/node_modules/normalize-package-data/lib/warning_messages.json deleted file mode 100644 index 4890f506ed965a..00000000000000 --- a/deps/npm/node_modules/normalize-package-data/lib/warning_messages.json +++ /dev/null @@ -1,30 +0,0 @@ -{ - "repositories": "'repositories' (plural) Not supported. Please pick one as the 'repository' field" - ,"missingRepository": "No repository field." - ,"brokenGitUrl": "Probably broken git url: %s" - ,"nonObjectScripts": "scripts must be an object" - ,"nonStringScript": "script values must be string commands" - ,"nonArrayFiles": "Invalid 'files' member" - ,"invalidFilename": "Invalid filename in 'files' list: %s" - ,"nonArrayBundleDependencies": "Invalid 'bundleDependencies' list. Must be array of package names" - ,"nonStringBundleDependency": "Invalid bundleDependencies member: %s" - ,"nonDependencyBundleDependency": "Non-dependency in bundleDependencies: %s" - ,"nonObjectDependencies": "%s field must be an object" - ,"nonStringDependency": "Invalid dependency: %s %s" - ,"deprecatedArrayDependencies": "specifying %s as array is deprecated" - ,"deprecatedModules": "modules field is deprecated" - ,"nonArrayKeywords": "keywords should be an array of strings" - ,"nonStringKeyword": "keywords should be an array of strings" - ,"conflictingName": "%s is also the name of a node core module." - ,"nonStringDescription": "'description' field should be a string" - ,"missingDescription": "No description" - ,"missingReadme": "No README data" - ,"missingLicense": "No license field." - ,"nonEmailUrlBugsString": "Bug string field must be url, email, or {email,url}" - ,"nonUrlBugsUrlField": "bugs.url field must be a string url. Deleted." - ,"nonEmailBugsEmailField": "bugs.email field must be a string email. Deleted." - ,"emptyNormalizedBugs": "Normalized value of bugs field is an empty object. Deleted." - ,"nonUrlHomepage": "homepage field must be a string url. Deleted." - ,"invalidLicense": "license should be a valid SPDX license expression" - ,"typo": "%s should probably be %s." -} diff --git a/deps/npm/node_modules/normalize-package-data/package.json b/deps/npm/node_modules/normalize-package-data/package.json deleted file mode 100644 index e4fbdddce4d612..00000000000000 --- a/deps/npm/node_modules/normalize-package-data/package.json +++ /dev/null @@ -1,56 +0,0 @@ -{ - "name": "normalize-package-data", - "version": "8.0.0", - "author": "GitHub Inc.", - "description": "Normalizes data that can be found in package.json files.", - "license": "BSD-2-Clause", - "repository": { - "type": "git", - "url": "git+https://github.com/npm/normalize-package-data.git" - }, - "main": "lib/normalize.js", - "scripts": { - "test": "tap", - "npmclilint": "npmcli-lint", - "lint": "npm run eslint", - "lintfix": "npm run eslint -- --fix", - "posttest": "npm run lint", - "postsnap": "npm run lintfix --", - "postlint": "template-oss-check", - "snap": "tap", - "template-oss-apply": "template-oss-apply --force", - "eslint": "eslint \"**/*.{js,cjs,ts,mjs,jsx,tsx}\"" - }, - "dependencies": { - "hosted-git-info": "^9.0.0", - "semver": "^7.3.5", - "validate-npm-package-license": "^3.0.4" - }, - "devDependencies": { - "@npmcli/eslint-config": "^5.0.0", - "@npmcli/template-oss": "4.25.0", - "tap": "^16.0.1" - }, - "files": [ - "bin/", - "lib/" - ], - "engines": { - "node": "^20.17.0 || >=22.9.0" - }, - "templateOSS": { - "//@npmcli/template-oss": "This file is partially managed by @npmcli/template-oss. Edits may be overwritten.", - "version": "4.25.0", - "publish": "true" - }, - "tap": { - "branches": 86, - "functions": 92, - "lines": 86, - "statements": 86, - "nyc-arg": [ - "--exclude", - "tap-snapshots/**" - ] - } -} diff --git a/deps/npm/node_modules/npm-package-arg/lib/npa.js b/deps/npm/node_modules/npm-package-arg/lib/npa.js index d409b7f1becfcc..50121b99efbe36 100644 --- a/deps/npm/node_modules/npm-package-arg/lib/npa.js +++ b/deps/npm/node_modules/npm-package-arg/lib/npa.js @@ -14,7 +14,7 @@ const { log } = require('proc-log') const hasSlashes = isWindows ? /\\|[/]/ : /[/]/ const isURL = /^(?:git[+])?[a-z]+:/i const isGit = /^[^@]+@[^:.]+\.[^:]+:.+$/i -const isFileType = /[.](?:tgz|tar.gz|tar)$/i +const isFileType = /[.](?:tgz|tar\.gz|tar)$/i const isPortNumber = /:[0-9]+(\/|$)/i const isWindowsFile = /^(?:[.]|~[/]|[/\\]|[a-zA-Z]:)/ const isPosixFile = /^(?:[.]|~[/]|[/]|[a-zA-Z]:)/ diff --git a/deps/npm/node_modules/npm-package-arg/package.json b/deps/npm/node_modules/npm-package-arg/package.json index db6ce9074cfa2d..2d8f91deaeed2b 100644 --- a/deps/npm/node_modules/npm-package-arg/package.json +++ b/deps/npm/node_modules/npm-package-arg/package.json @@ -1,6 +1,6 @@ { "name": "npm-package-arg", - "version": "13.0.0", + "version": "13.0.1", "description": "Parse the things that can be arguments to `npm install`", "main": "./lib/npa.js", "directories": { diff --git a/deps/npm/node_modules/npm-packlist/lib/index.js b/deps/npm/node_modules/npm-packlist/lib/index.js index 9e4e7db07c01cb..ada704de4575da 100644 --- a/deps/npm/node_modules/npm-packlist/lib/index.js +++ b/deps/npm/node_modules/npm-packlist/lib/index.js @@ -3,6 +3,7 @@ const { Walker: IgnoreWalker } = require('ignore-walk') const { lstatSync: lstat, readFileSync: readFile } = require('fs') const { basename, dirname, extname, join, relative, resolve, sep } = require('path') +const { log } = require('proc-log') // symbols used to represent synthetic rule sets const defaultRules = Symbol('npm-packlist.rules.default') @@ -92,6 +93,7 @@ class PackWalker extends IgnoreWalker { } super(options) + this.isPackage = options.isPackage this.seen = options.seen || new Set() this.tree = tree @@ -168,6 +170,11 @@ class PackWalker extends IgnoreWalker { } else if (this.ignoreRules['.npmignore']) { // .npmignore means no .gitignore this.ignoreRules['.gitignore'] = null + } else if (this.ignoreRules['.gitignore'] && !this.ignoreRules['.npmignore']) { + log.warn( + 'gitignore-fallback', + 'No .npmignore file found, using .gitignore for file exclusion. Consider creating a .npmignore file to explicitly control published files.' + ) } return super.filterEntries() diff --git a/deps/npm/node_modules/npm-packlist/package.json b/deps/npm/node_modules/npm-packlist/package.json index 66212c9ba4240a..1ca942a536dbd7 100644 --- a/deps/npm/node_modules/npm-packlist/package.json +++ b/deps/npm/node_modules/npm-packlist/package.json @@ -1,13 +1,14 @@ { "name": "npm-packlist", - "version": "10.0.1", + "version": "10.0.2", "description": "Get a list of the files to add from a folder into an npm package", "directories": { "test": "test" }, "main": "lib/index.js", "dependencies": { - "ignore-walk": "^8.0.0" + "ignore-walk": "^8.0.0", + "proc-log": "^5.0.0" }, "author": "GitHub Inc.", "license": "ISC", @@ -18,7 +19,7 @@ "devDependencies": { "@npmcli/arborist": "^9.0.0", "@npmcli/eslint-config": "^5.0.1", - "@npmcli/template-oss": "4.25.0", + "@npmcli/template-oss": "4.25.1", "mutate-fs": "^2.1.1", "tap": "^16.0.1" }, @@ -55,7 +56,7 @@ }, "templateOSS": { "//@npmcli/template-oss": "This file is partially managed by @npmcli/template-oss. Edits may be overwritten.", - "version": "4.25.0", + "version": "4.25.1", "publish": true } } diff --git a/deps/npm/node_modules/semver/classes/range.js b/deps/npm/node_modules/semver/classes/range.js index f80c2359c6b82f..94629ce6f5df60 100644 --- a/deps/npm/node_modules/semver/classes/range.js +++ b/deps/npm/node_modules/semver/classes/range.js @@ -255,6 +255,7 @@ const isSatisfiable = (comparators, options) => { // already replaced the hyphen ranges // turn into a set of JUST comparators. const parseComparator = (comp, options) => { + comp = comp.replace(re[t.BUILD], '') debug('comp', comp, options) comp = replaceCarets(comp, options) debug('caret', comp) diff --git a/deps/npm/node_modules/semver/classes/semver.js b/deps/npm/node_modules/semver/classes/semver.js index 2efba0f4b6451e..92254be1bf075a 100644 --- a/deps/npm/node_modules/semver/classes/semver.js +++ b/deps/npm/node_modules/semver/classes/semver.js @@ -111,11 +111,25 @@ class SemVer { other = new SemVer(other, this.options) } - return ( - compareIdentifiers(this.major, other.major) || - compareIdentifiers(this.minor, other.minor) || - compareIdentifiers(this.patch, other.patch) - ) + if (this.major < other.major) { + return -1 + } + if (this.major > other.major) { + return 1 + } + if (this.minor < other.minor) { + return -1 + } + if (this.minor > other.minor) { + return 1 + } + if (this.patch < other.patch) { + return -1 + } + if (this.patch > other.patch) { + return 1 + } + return 0 } comparePre (other) { diff --git a/deps/npm/node_modules/semver/internal/identifiers.js b/deps/npm/node_modules/semver/internal/identifiers.js index a4613dee7977f0..d053472dd58b3c 100644 --- a/deps/npm/node_modules/semver/internal/identifiers.js +++ b/deps/npm/node_modules/semver/internal/identifiers.js @@ -2,6 +2,10 @@ const numeric = /^[0-9]+$/ const compareIdentifiers = (a, b) => { + if (typeof a === 'number' && typeof b === 'number') { + return a === b ? 0 : a < b ? -1 : 1 + } + const anum = numeric.test(a) const bnum = numeric.test(b) diff --git a/deps/npm/node_modules/semver/package.json b/deps/npm/node_modules/semver/package.json index 1fbef5a9bf9cd8..2b8cadaa2387ed 100644 --- a/deps/npm/node_modules/semver/package.json +++ b/deps/npm/node_modules/semver/package.json @@ -1,6 +1,6 @@ { "name": "semver", - "version": "7.7.2", + "version": "7.7.3", "description": "The semantic version parser used by npm.", "main": "index.js", "scripts": { @@ -15,7 +15,7 @@ }, "devDependencies": { "@npmcli/eslint-config": "^5.0.0", - "@npmcli/template-oss": "4.24.3", + "@npmcli/template-oss": "4.25.1", "benchmark": "^2.1.4", "tap": "^16.0.0" }, @@ -52,7 +52,7 @@ "author": "GitHub Inc.", "templateOSS": { "//@npmcli/template-oss": "This file is partially managed by @npmcli/template-oss. Edits may be overwritten.", - "version": "4.24.3", + "version": "4.25.1", "engines": ">=10", "distPaths": [ "classes/", diff --git a/deps/npm/package.json b/deps/npm/package.json index 3e4e05143aa709..ba3441726b01cb 100644 --- a/deps/npm/package.json +++ b/deps/npm/package.json @@ -1,5 +1,5 @@ { - "version": "11.6.1", + "version": "11.6.2", "name": "npm", "description": "a package manager for JavaScript", "workspaces": [ @@ -52,8 +52,8 @@ }, "dependencies": { "@isaacs/string-locale-compare": "^1.1.0", - "@npmcli/arborist": "^9.1.5", - "@npmcli/config": "^10.4.1", + "@npmcli/arborist": "^9.1.6", + "@npmcli/config": "^10.4.2", "@npmcli/fs": "^4.0.0", "@npmcli/map-workspaces": "^5.0.0", "@npmcli/package-json": "^7.0.1", @@ -65,24 +65,24 @@ "archy": "~1.0.0", "cacache": "^20.0.1", "chalk": "^5.6.2", - "ci-info": "^4.3.0", + "ci-info": "^4.3.1", "cli-columns": "^4.0.0", "fastest-levenshtein": "^1.0.16", "fs-minipass": "^3.0.3", "glob": "^11.0.3", "graceful-fs": "^4.2.11", - "hosted-git-info": "^9.0.0", + "hosted-git-info": "^9.0.2", "ini": "^5.0.0", "init-package-json": "^8.2.2", - "is-cidr": "^6.0.0", + "is-cidr": "^6.0.1", "json-parse-even-better-errors": "^4.0.0", - "libnpmaccess": "^10.0.2", - "libnpmdiff": "^8.0.8", - "libnpmexec": "^10.1.7", - "libnpmfund": "^7.0.8", + "libnpmaccess": "^10.0.3", + "libnpmdiff": "^8.0.9", + "libnpmexec": "^10.1.8", + "libnpmfund": "^7.0.9", "libnpmorg": "^8.0.1", - "libnpmpack": "^9.0.8", - "libnpmpublish": "^11.1.1", + "libnpmpack": "^9.0.9", + "libnpmpublish": "^11.1.2", "libnpmsearch": "^9.0.1", "libnpmteam": "^8.0.2", "libnpmversion": "^8.0.2", @@ -93,10 +93,9 @@ "ms": "^2.1.2", "node-gyp": "^11.4.2", "nopt": "^8.1.0", - "normalize-package-data": "^8.0.0", "npm-audit-report": "^6.0.0", "npm-install-checks": "^7.1.2", - "npm-package-arg": "^13.0.0", + "npm-package-arg": "^13.0.1", "npm-pick-manifest": "^11.0.1", "npm-profile": "^12.0.0", "npm-registry-fetch": "^19.0.0", @@ -107,7 +106,7 @@ "proc-log": "^5.0.0", "qrcode-terminal": "^0.12.0", "read": "^4.1.0", - "semver": "^7.7.2", + "semver": "^7.7.3", "spdx-expression-parse": "^4.0.0", "ssri": "^12.0.0", "supports-color": "^10.2.2", @@ -161,7 +160,6 @@ "ms", "node-gyp", "nopt", - "normalize-package-data", "npm-audit-report", "npm-install-checks", "npm-package-arg", @@ -200,7 +198,7 @@ "cli-table3": "^0.6.4", "diff": "^8.0.2", "nock": "^13.4.0", - "npm-packlist": "^10.0.0", + "npm-packlist": "^10.0.2", "remark": "^15.0.1", "remark-gfm": "^4.0.1", "remark-github": "^12.0.0", diff --git a/deps/npm/tap-snapshots/test/lib/commands/ls.js.test.cjs b/deps/npm/tap-snapshots/test/lib/commands/ls.js.test.cjs index 184259eafff836..175d85f9c07eec 100644 --- a/deps/npm/tap-snapshots/test/lib/commands/ls.js.test.cjs +++ b/deps/npm/tap-snapshots/test/lib/commands/ls.js.test.cjs @@ -248,7 +248,7 @@ exports[`test/lib/commands/ls.js TAP ls --parseable no args > should output pars {CWD}/prefix/node_modules/dog ` -exports[`test/lib/commands/ls.js TAP ls --parseable overridden dep > should contain overridden outout 1`] = ` +exports[`test/lib/commands/ls.js TAP ls --parseable overridden dep > should contain overridden output 1`] = ` {CWD}/prefix:test-overridden@1.0.0 {CWD}/prefix/node_modules/foo:foo@1.0.0 {CWD}/prefix/node_modules/bar:bar@1.0.0:OVERRIDDEN @@ -288,11 +288,11 @@ exports[`test/lib/commands/ls.js TAP ls --parseable using aliases > should outpu {CWD}/prefix/node_modules/a ` -exports[`test/lib/commands/ls.js TAP ls --parseable with filter arg > should output parseable contaning only occurrences of filtered by package 1`] = ` +exports[`test/lib/commands/ls.js TAP ls --parseable with filter arg > should output parseable containing only occurrences of filtered by package 1`] = ` {CWD}/prefix/node_modules/chai ` -exports[`test/lib/commands/ls.js TAP ls --parseable with filter arg nested dep > should output parseable contaning only occurrences of filtered package 1`] = ` +exports[`test/lib/commands/ls.js TAP ls --parseable with filter arg nested dep > should output parseable containing only occurrences of filtered package 1`] = ` {CWD}/prefix/node_modules/dog ` @@ -300,7 +300,7 @@ exports[`test/lib/commands/ls.js TAP ls --parseable with missing filter arg > sh ` -exports[`test/lib/commands/ls.js TAP ls --parseable with multiple filter args > should output parseable contaning only occurrences of multiple filtered packages and their ancestors 1`] = ` +exports[`test/lib/commands/ls.js TAP ls --parseable with multiple filter args > should output parseable containing only occurrences of multiple filtered packages and their ancestors 1`] = ` {CWD}/prefix/node_modules/chai {CWD}/prefix/node_modules/dog ` @@ -453,7 +453,7 @@ workspaces-tree@1.0.0 {CWD}/prefix \`-- bar@1.0.0 ` -exports[`test/lib/commands/ls.js TAP ls loading a tree containing workspaces should inlude root and specified workspace > output 1`] = ` +exports[`test/lib/commands/ls.js TAP ls loading a tree containing workspaces should include root and specified workspace > output 1`] = ` workspaces-tree@1.0.0 {CWD}/prefix +-- d@1.0.0 -> ./d | \`-- foo@1.1.1 @@ -541,13 +541,13 @@ test-npm-ls@1.0.0 {CWD}/prefix \`-- dog@1.0.0 ` -exports[`test/lib/commands/ls.js TAP ls overridden dep > should contain overridden outout 1`] = ` +exports[`test/lib/commands/ls.js TAP ls overridden dep > should contain overridden output 1`] = ` test-overridden@1.0.0 {CWD}/prefix \`-- foo@1.0.0 \`-- bar@1.0.0 overridden ` -exports[`test/lib/commands/ls.js TAP ls overridden dep w/ color > should contain overridden outout 1`] = ` +exports[`test/lib/commands/ls.js TAP ls overridden dep w/ color > should contain overridden output 1`] = ` test-overridden@1.0.0 {CWD}/prefix \`-- foo@1.0.0  \`-- bar@1.0.0 overridden @@ -609,18 +609,18 @@ dedupe-entries@1.0.0 {CWD}/prefix \`-- @npmcli/c@1.0.0 ` -exports[`test/lib/commands/ls.js TAP ls with dot filter arg > should output tree contaning only occurrences of filtered by package and colored output 1`] = ` +exports[`test/lib/commands/ls.js TAP ls with dot filter arg > should output tree containing only occurrences of filtered by package and colored output 1`] = ` test-npm-ls@1.0.0 {CWD}/prefix \`-- (empty) ` -exports[`test/lib/commands/ls.js TAP ls with filter arg > should output tree contaning only occurrences of filtered by package and colored output 1`] = ` +exports[`test/lib/commands/ls.js TAP ls with filter arg > should output tree containing only occurrences of filtered by package and colored output 1`] = ` test-npm-ls@1.0.0 {CWD}/prefix \`-- chai@1.0.0  ` -exports[`test/lib/commands/ls.js TAP ls with filter arg nested dep > should output tree contaning only occurrences of filtered package and its ancestors 1`] = ` +exports[`test/lib/commands/ls.js TAP ls with filter arg nested dep > should output tree containing only occurrences of filtered package and its ancestors 1`] = ` test-npm-ls@1.0.0 {CWD}/prefix \`-- foo@1.0.0 \`-- dog@1.0.0 @@ -631,7 +631,7 @@ test-npm-ls@1.0.0 {CWD}/prefix \`-- (empty) ` -exports[`test/lib/commands/ls.js TAP ls with multiple filter args > should output tree contaning only occurrences of multiple filtered packages and their ancestors 1`] = ` +exports[`test/lib/commands/ls.js TAP ls with multiple filter args > should output tree containing only occurrences of multiple filtered packages and their ancestors 1`] = ` test-npm-ls@1.0.0 {CWD}/prefix +-- chai@1.0.0 \`-- foo@1.0.0 diff --git a/deps/npm/tap-snapshots/test/lib/commands/outdated.js.test.cjs b/deps/npm/tap-snapshots/test/lib/commands/outdated.js.test.cjs index 164440d68c34c7..8eac2cc92dd4f5 100644 --- a/deps/npm/tap-snapshots/test/lib/commands/outdated.js.test.cjs +++ b/deps/npm/tap-snapshots/test/lib/commands/outdated.js.test.cjs @@ -289,7 +289,7 @@ exports[`test/lib/commands/outdated.js TAP workspaces should display ws outdated :theta@1.0.1:MISSING:theta@1.0.1:e ` -exports[`test/lib/commands/outdated.js TAP workspaces should highlight ws in dependend by section > output 1`] = ` +exports[`test/lib/commands/outdated.js TAP workspaces should highlight ws in depended by section > output 1`] = ` Package Current Wanted Latest Location Depended by cat 1.0.0 1.0.1 1.0.1 node_modules/cat a@1.0.0 dog 1.0.1 1.0.1 2.0.0 node_modules/dog prefix diff --git a/deps/npm/tap-snapshots/test/lib/commands/publish.js.test.cjs b/deps/npm/tap-snapshots/test/lib/commands/publish.js.test.cjs index 71ea8c025e9a53..96a9d064d0e4e5 100644 --- a/deps/npm/tap-snapshots/test/lib/commands/publish.js.test.cjs +++ b/deps/npm/tap-snapshots/test/lib/commands/publish.js.test.cjs @@ -402,7 +402,7 @@ exports[`test/lib/commands/publish.js TAP workspaces all workspaces - some marke + workspace-a@1.2.3-a ` -exports[`test/lib/commands/publish.js TAP workspaces differet package spec > publish different package spec 1`] = ` +exports[`test/lib/commands/publish.js TAP workspaces different package spec > publish different package spec 1`] = ` + pkg@1.2.3 ` diff --git a/deps/npm/tap-snapshots/test/lib/commands/sbom.js.test.cjs b/deps/npm/tap-snapshots/test/lib/commands/sbom.js.test.cjs index 5b2e93a3df6d61..1eb269e5671b28 100644 --- a/deps/npm/tap-snapshots/test/lib/commands/sbom.js.test.cjs +++ b/deps/npm/tap-snapshots/test/lib/commands/sbom.js.test.cjs @@ -791,7 +791,7 @@ exports[`test/lib/commands/sbom.js TAP sbom extraneous dep > must match snapshot } ` -exports[`test/lib/commands/sbom.js TAP sbom loading a tree containing workspaces should filter worksapces with --workspace > must match snapshot 1`] = ` +exports[`test/lib/commands/sbom.js TAP sbom loading a tree containing workspaces should filter workspaces with --workspace > must match snapshot 1`] = ` { "spdxVersion": "SPDX-2.3", "dataLicense": "CC0-1.0", diff --git a/deps/npm/tap-snapshots/test/lib/docs.js.test.cjs b/deps/npm/tap-snapshots/test/lib/docs.js.test.cjs index c1dac09901fd7c..5aa26c15fe95e3 100644 --- a/deps/npm/tap-snapshots/test/lib/docs.js.test.cjs +++ b/deps/npm/tap-snapshots/test/lib/docs.js.test.cjs @@ -195,7 +195,7 @@ safer to use a registry-provided authentication bearer token stored in the If you do not want your scoped package to be publicly viewable (and installable) set \`--access=restricted\`. -Unscoped packages can not be set to \`restricted\`. +Unscoped packages cannot be set to \`restricted\`. Note: This defaults to not changing the current access level for existing packages. Specifying a value of \`restricted\` or \`public\` during publish will @@ -405,7 +405,7 @@ are same as \`cpu\` field of package.json, which comes from \`process.arch\`. #### \`depth\` -* Default: \`Infinity\` if \`--all\` is set, otherwise \`0\` +* Default: \`Infinity\` if \`--all\` is set; otherwise, \`0\` * Type: null or Number The depth to go when recursing packages for \`npm ls\`. @@ -544,7 +544,7 @@ This can be overridden by setting the \`--force\` flag. Tells to expect a specific number of results from the command. -This config can not be used with: \`expect-results\` +This config cannot be used with: \`expect-results\` #### \`expect-results\` @@ -554,7 +554,7 @@ This config can not be used with: \`expect-results\` Tells npm whether or not to expect results from the command. Can be either true (expect some results) or false (expect no results). -This config can not be used with: \`expect-result-count\` +This config cannot be used with: \`expect-result-count\` #### \`fetch-retries\` @@ -992,8 +992,8 @@ instead of the current working directory. See #### \`lockfile-version\` -* Default: Version 3 if no lockfile, auto-converting v1 lockfiles to v3, - otherwise maintain current lockfile version. +* Default: Version 3 if no lockfile, auto-converting v1 lockfiles to v3; + otherwise, maintain current lockfile version. * Type: null, 1, 2, 3, "1", "2", or "3" Set the lockfile format version to be used in package-lock.json and @@ -1129,7 +1129,7 @@ allow the CLI to fill in missing cache data, see \`--prefer-offline\`. #### \`omit\` * Default: 'dev' if the \`NODE_ENV\` environment variable is set to - 'production', otherwise empty. + 'production'; otherwise, empty. * Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. @@ -1309,7 +1309,7 @@ Set to \`false\` to suppress the progress bar. When publishing from a supported cloud CI/CD system, the package will be publicly linked to where it was built and published from. -This config can not be used with: \`provenance-file\` +This config cannot be used with: \`provenance-file\` #### \`provenance-file\` @@ -1318,7 +1318,7 @@ This config can not be used with: \`provenance-file\` When publishing, the provenance bundle at the given path will be used. -This config can not be used with: \`provenance\` +This config cannot be used with: \`provenance\` #### \`proxy\` @@ -1410,7 +1410,7 @@ Ignored if \`--save-peer\` is set, since peerDependencies cannot be bundled. Save installed packages to a package.json file as \`devDependencies\`. -This config can not be used with: \`save-optional\`, \`save-peer\`, \`save-prod\` +This config cannot be used with: \`save-optional\`, \`save-peer\`, \`save-prod\` #### \`save-exact\` @@ -1429,7 +1429,7 @@ rather than using npm's default semver range operator. Save installed packages to a package.json file as \`optionalDependencies\`. -This config can not be used with: \`save-dev\`, \`save-peer\`, \`save-prod\` +This config cannot be used with: \`save-dev\`, \`save-peer\`, \`save-prod\` #### \`save-peer\` @@ -1438,7 +1438,7 @@ This config can not be used with: \`save-dev\`, \`save-peer\`, \`save-prod\` Save installed packages to a package.json file as \`peerDependencies\` -This config can not be used with: \`save-dev\`, \`save-optional\`, \`save-prod\` +This config cannot be used with: \`save-dev\`, \`save-optional\`, \`save-prod\` #### \`save-prefix\` @@ -1467,7 +1467,7 @@ you want to move it to be a non-optional production dependency. This is the default behavior if \`--save\` is true, and neither \`--save-dev\` or \`--save-optional\` are true. -This config can not be used with: \`save-dev\`, \`save-optional\`, \`save-peer\` +This config cannot be used with: \`save-dev\`, \`save-optional\`, \`save-peer\` #### \`sbom-format\` diff --git a/deps/npm/tap-snapshots/test/lib/utils/error-message.js.test.cjs b/deps/npm/tap-snapshots/test/lib/utils/error-message.js.test.cjs index 732c0b9747b9e9..22c4ba598a86be 100644 --- a/deps/npm/tap-snapshots/test/lib/utils/error-message.js.test.cjs +++ b/deps/npm/tap-snapshots/test/lib/utils/error-message.js.test.cjs @@ -1610,7 +1610,7 @@ Object { } ` -exports[`test/lib/utils/error-message.js TAP replace message/stack sensistive info > must match snapshot 1`] = ` +exports[`test/lib/utils/error-message.js TAP replace message/stack sensitive info > must match snapshot 1`] = ` Object { "detail": Array [], "summary": Array [ diff --git a/deps/npm/tap-snapshots/test/lib/utils/open-url.js.test.cjs b/deps/npm/tap-snapshots/test/lib/utils/open-url.js.test.cjs index fa256ba1314479..2b3fed2b326e42 100644 --- a/deps/npm/tap-snapshots/test/lib/utils/open-url.js.test.cjs +++ b/deps/npm/tap-snapshots/test/lib/utils/open-url.js.test.cjs @@ -22,7 +22,7 @@ npm home: https://www.npmjs.com ` -exports[`test/lib/utils/open-url.js TAP open url prompt does not error when opener can not find command > Outputs extra Browser unavailable message and url 1`] = ` +exports[`test/lib/utils/open-url.js TAP open url prompt does not error when opener cannot find command > Outputs extra Browser unavailable message and url 1`] = ` npm home: https://www.npmjs.com diff --git a/deps/npm/test/lib/cli/exit-handler.js b/deps/npm/test/lib/cli/exit-handler.js index 484704c7352790..c63141286a3f08 100644 --- a/deps/npm/test/lib/cli/exit-handler.js +++ b/deps/npm/test/lib/cli/exit-handler.js @@ -125,7 +125,7 @@ const mockExitHandler = async (t, { ...errors, ], npm, - // Make it async to make testing ergonomics a little easier so we dont need + // Make it async to make testing ergonomics a little easier so we don't need // to t.plan() every test to make sure we get process.exit called. exitHandler: (argErr) => new Promise(res => { process.once('exit', res) diff --git a/deps/npm/test/lib/cli/update-notifier.js b/deps/npm/test/lib/cli/update-notifier.js index a4f1ee6885a6b3..023a44294622ec 100644 --- a/deps/npm/test/lib/cli/update-notifier.js +++ b/deps/npm/test/lib/cli/update-notifier.js @@ -37,7 +37,7 @@ const packumentResponse = { [HAVE_BETA]: { version: HAVE_BETA, engines: { node: '>1' } }, [NEXT_VERSION_ENGINE_COMPATIBLE]: { version: NEXT_VERSION_ENGINE_COMPATIBLE, - engiges: { node: '<=1' }, + engines: { node: '<=1' }, }, [NEXT_VERSION_ENGINE_COMPATIBLE_MINOR]: { version: NEXT_VERSION_ENGINE_COMPATIBLE_MINOR, @@ -68,7 +68,7 @@ const runUpdateNotifier = async (t, { ...require('node:fs/promises'), stat: async (path) => { if (basename(path) !== '_update-notifier-last-checked') { - t.fail('no stat allowed for non upate notifier files') + t.fail('no stat allowed for non update notifier files') } if (STAT_ERROR) { throw STAT_ERROR @@ -81,7 +81,7 @@ const runUpdateNotifier = async (t, { t.fail('no write file content allowed') } if (basename(path) !== '_update-notifier-last-checked') { - t.fail('no writefile allowed for non upate notifier files') + t.fail('no writefile allowed for non update notifier files') } if (WRITE_ERROR) { throw WRITE_ERROR diff --git a/deps/npm/test/lib/commands/config.js b/deps/npm/test/lib/commands/config.js index bcd88915dc97a7..64977c6f6c2f0e 100644 --- a/deps/npm/test/lib/commands/config.js +++ b/deps/npm/test/lib/commands/config.js @@ -225,7 +225,7 @@ t.test('config delete single key', async t => { await npm.exec('config', ['delete', 'access']) - t.equal(npm.config.get('access'), null, 'acces should be defaulted') + t.equal(npm.config.get('access'), null, 'access should be defaulted') const contents = await fs.readFile(join(home, '.npmrc'), { encoding: 'utf8' }) const rc = ini.parse(contents) @@ -294,7 +294,7 @@ t.test('config delete key --global', async t => { t.test('config set invalid option', async t => { const { npm } = await loadMockNpm(t) await t.rejects( - npm.exec('config', ['set', 'nonexistantconfigoption', 'something']), + npm.exec('config', ['set', 'nonexistentconfigoption', 'something']), /not a valid npm option/ ) }) @@ -317,7 +317,7 @@ t.test('config set nerf-darted option', async t => { ) }) -t.test('config set scoped optoin', async t => { +t.test('config set scoped option', async t => { const { npm } = await loadMockNpm(t) await npm.exec('config', ['set', '@npm:registry', 'https://registry.npmjs.org']) t.equal( diff --git a/deps/npm/test/lib/commands/init.js b/deps/npm/test/lib/commands/init.js index 9a73f4924e7d16..1b59cc418c6786 100644 --- a/deps/npm/test/lib/commands/init.js +++ b/deps/npm/test/lib/commands/init.js @@ -16,7 +16,7 @@ const mockNpm = async (t, { noLog, libnpmexec, initPackageJson, ...opts } = {}) }, globals: { // init-package-json prints directly to console.log - // this avoids poluting test output with those logs + // this avoids polluting test output with those logs ...(noLog ? { 'console.log': () => {} } : {}), }, }) @@ -324,7 +324,7 @@ t.test('workspaces', async t => { ) }) - await t.test('missing top-level package.json when settting workspace', async t => { + await t.test('missing top-level package.json when setting workspace', async t => { const { npm, logs } = await mockNpm(t, { config: { workspace: 'a' }, }) @@ -338,7 +338,7 @@ t.test('workspaces', async t => { t.equal(logs.warn[0], 'init Missing package.json. Try with `--include-workspace-root`.') }) - await t.test('bad package.json when settting workspace', async t => { + await t.test('bad package.json when setting workspace', async t => { const { npm, logs } = await mockNpm(t, { prefixDir: { 'package.json': '{{{{', diff --git a/deps/npm/test/lib/commands/login.js b/deps/npm/test/lib/commands/login.js index a55637f9e00e2f..55568edd09f9d2 100644 --- a/deps/npm/test/lib/commands/login.js +++ b/deps/npm/test/lib/commands/login.js @@ -119,7 +119,7 @@ t.test('legacy', t => { t.test('web', t => { t.test('basic login', async t => { - const { npm, registry, login, rc } = await mockLogin(t, { + const { outputs, npm, registry, login, rc } = await mockLogin(t, { config: { 'auth-type': 'web' }, }) registry.weblogin({ token: 'npm_test-token' }) @@ -128,6 +128,7 @@ t.test('web', t => { t.same(rc(), { '//registry.npmjs.org/:_authToken': 'npm_test-token', }) + t.match(outputs[0], '/npm-cli-test/login/cli/00000000-0000-0000-0000-000000000000') }) t.test('server error', async t => { const { registry, login } = await mockLogin(t, { diff --git a/deps/npm/test/lib/commands/ls.js b/deps/npm/test/lib/commands/ls.js index cf96452d6cb5de..c876af9e83ddfc 100644 --- a/deps/npm/test/lib/commands/ls.js +++ b/deps/npm/test/lib/commands/ls.js @@ -263,7 +263,7 @@ t.test('ls', async t => { await ls.exec([]) - t.matchSnapshot(cleanCwd(result()), 'should contain overridden outout') + t.matchSnapshot(cleanCwd(result()), 'should contain overridden output') }) t.test('overridden dep w/ color', async t => { @@ -305,7 +305,7 @@ t.test('ls', async t => { }) await ls.exec([]) - t.matchSnapshot(cleanCwd(result()), 'should contain overridden outout') + t.matchSnapshot(cleanCwd(result()), 'should contain overridden output') }) t.test('with filter arg', async t => { @@ -329,7 +329,7 @@ t.test('ls', async t => { await ls.exec(['chai']) t.matchSnapshot( cleanCwd(result()), - 'should output tree contaning only occurrences of filtered by package and colored output' + 'should output tree containing only occurrences of filtered by package and colored output' ) }) @@ -355,7 +355,7 @@ t.test('ls', async t => { await ls.exec(['.']) t.matchSnapshot( cleanCwd(result()), - 'should output tree contaning only occurrences of filtered by package and colored output' + 'should output tree containing only occurrences of filtered by package and colored output' ) }) @@ -377,7 +377,7 @@ t.test('ls', async t => { await ls.exec(['dog']) t.matchSnapshot( cleanCwd(result()), - 'should output tree contaning only occurrences of filtered package and its ancestors' + 'should output tree containing only occurrences of filtered package and its ancestors' ) }) @@ -408,7 +408,7 @@ t.test('ls', async t => { await ls.exec(['dog@*', 'chai@1.0.0']) t.matchSnapshot( cleanCwd(result()), - 'should output tree contaning only occurrences of multiple filtered packages and their ancestors' + 'should output tree containing only occurrences of multiple filtered packages and their ancestors' ) }) @@ -1650,7 +1650,7 @@ t.test('ls', async t => { })) // filter out a single workspace and include root - t.test('should inlude root and specified workspace', t => mockWorkspaces(t, [], { + t.test('should include root and specified workspace', t => mockWorkspaces(t, [], { 'include-workspace-root': true, workspace: 'd', })) @@ -1823,7 +1823,7 @@ t.test('ls --parseable', async t => { }) await ls.exec([]) - t.matchSnapshot(cleanCwd(result()), 'should contain overridden outout') + t.matchSnapshot(cleanCwd(result()), 'should contain overridden output') }) t.test('with filter arg', async t => { @@ -1844,7 +1844,7 @@ t.test('ls --parseable', async t => { await ls.exec(['chai']) t.matchSnapshot( cleanCwd(result()), - 'should output parseable contaning only occurrences of filtered by package' + 'should output parseable containing only occurrences of filtered by package' ) }) @@ -1866,7 +1866,7 @@ t.test('ls --parseable', async t => { await ls.exec(['dog']) t.matchSnapshot( cleanCwd(result()), - 'should output parseable contaning only occurrences of filtered package' + 'should output parseable containing only occurrences of filtered package' ) }) @@ -1897,7 +1897,7 @@ t.test('ls --parseable', async t => { await ls.exec(['dog@*', 'chai@1.0.0']) t.matchSnapshot( cleanCwd(result()), - 'should output parseable contaning only occurrences of multiple filtered packages and their ancestors' + 'should output parseable containing only occurrences of multiple filtered packages and their ancestors' ) }) @@ -2941,7 +2941,7 @@ t.test('ls --json', async t => { }, }, }, - 'should output json contaning only occurrences of filtered by package' + 'should output json containing only occurrences of filtered by package' ) t.not(process.exitCode, 1, 'should not exit with error code 1') }) @@ -2982,7 +2982,7 @@ t.test('ls --json', async t => { }, }, }, - 'should output json contaning only occurrences of filtered by package' + 'should output json containing only occurrences of filtered by package' ) t.notOk(jsonParse(result()).dependencies.chai) }) @@ -3036,7 +3036,7 @@ t.test('ls --json', async t => { }, }, }, - 'should output json contaning only occurrences of multiple filtered packages and their ancestors' + 'should output json containing only occurrences of multiple filtered packages and their ancestors' ) }) @@ -3838,7 +3838,7 @@ t.test('ls --json', async t => { await t.rejects( ls.exec([]), { code: 'EJSONPARSE', message: 'Failed to parse root package.json' }, - 'should have missin root package.json msg' + 'should have missing root package.json msg' ) t.same( jsonParse(result()), @@ -4664,7 +4664,7 @@ t.test('ls --package-lock-only', async t => { }, }, }, - 'should output json contaning only occurrences of filtered by package' + 'should output json containing only occurrences of filtered by package' ) t.notOk(process.exitCode, 'should not set exit code') }) @@ -4724,7 +4724,7 @@ t.test('ls --package-lock-only', async t => { }, }, }, - 'should output json contaning only occurrences of filtered by package' + 'should output json containing only occurrences of filtered by package' ) }) @@ -4788,7 +4788,7 @@ t.test('ls --package-lock-only', async t => { }, }, }, - 'should output json contaning only occurrences of multiple filtered packages and their ancestors' + 'should output json containing only occurrences of multiple filtered packages and their ancestors' ) }) diff --git a/deps/npm/test/lib/commands/org.js b/deps/npm/test/lib/commands/org.js index 7a1538d9c69e4a..ad82e79dc5cc3a 100644 --- a/deps/npm/test/lib/commands/org.js +++ b/deps/npm/test/lib/commands/org.js @@ -424,7 +424,7 @@ t.test('npm org ls', async t => { org: 'orgname', opts: npm.flatOptions, }, - 'receieved the correct args' + 'received the correct args' ) t.strictSame(outputs, [ 'one - developer', @@ -450,7 +450,7 @@ t.test('npm org ls - user filter', async t => { org: 'orgname', opts: npm.flatOptions, }, - 'receieved the correct args' + 'received the correct args' ) t.strictSame(outputs, [ 'username - admin', @@ -473,7 +473,7 @@ t.test('npm org ls - user filter, missing user', async t => { org: 'orgname', opts: npm.flatOptions, }, - 'receieved the correct args' + 'received the correct args' ) t.strictSame(outputs, []) }) @@ -503,7 +503,7 @@ t.test('npm org ls - json output', async t => { org: 'orgname', opts: npm.flatOptions, }, - 'receieved the correct args' + 'received the correct args' ) t.strictSame(JSON.parse(outputs[0]), orgList, 'prints the correct output') }) @@ -528,7 +528,7 @@ t.test('npm org ls - parseable output', async t => { org: 'orgname', opts: npm.flatOptions, }, - 'receieved the correct args' + 'received the correct args' ) t.strictSame( outputs.map(line => line.split(/\t/)), @@ -562,7 +562,7 @@ t.test('npm org ls - silent output', async t => { org: 'orgname', opts: npm.flatOptions, }, - 'receieved the correct args' + 'received the correct args' ) t.strictSame(outputs, [], 'printed no output') }) diff --git a/deps/npm/test/lib/commands/outdated.js b/deps/npm/test/lib/commands/outdated.js index 36c3b9c9cabebb..e3709bf7c2b412 100644 --- a/deps/npm/test/lib/commands/outdated.js +++ b/deps/npm/test/lib/commands/outdated.js @@ -582,7 +582,7 @@ t.test('workspaces', async t => { await t.test('should display all dependencies', t => mockWorkspaces(t, { all: true })) - await t.test('should highlight ws in dependend by section', t => + await t.test('should highlight ws in depended by section', t => mockWorkspaces(t, { color: 'always' })) await t.test('should display results filtered by ws', t => @@ -666,7 +666,7 @@ t.test('aliases with version range', async t => { t.test('dependent location', async t => { const testDir = { 'package.json': JSON.stringify({ - name: 'similer-name', + name: 'similar-name', version: '1.0.0', workspaces: ['a', 'nest/a'], }), diff --git a/deps/npm/test/lib/commands/profile.js b/deps/npm/test/lib/commands/profile.js index 2204f2e9df1fba..e11ab4c05fa6c5 100644 --- a/deps/npm/test/lib/commands/profile.js +++ b/deps/npm/test/lib/commands/profile.js @@ -727,7 +727,7 @@ t.test('enable-2fa', async t => { mode: 'auth-only', }, }, - 'should set tfa mode approprietly in follow-up call' + 'should set tfa mode appropriately in follow-up call' ) } else if (setCount === 3) { t.match( @@ -968,7 +968,7 @@ t.test('disable-2fa', async t => { await profile.exec(['disable-2fa']) t.equal(result(), 'Two factor authentication not enabled.', - 'should output already disalbed msg') + 'should output already disabled msg') }) t.test('requests otp', async t => { @@ -1101,7 +1101,7 @@ t.test('disable-2fa', async t => { await profile.exec(['disable-2fa']) - t.equal(result(), 'Two factor authentication disabled.', 'should output already disalbed msg') + t.equal(result(), 'Two factor authentication disabled.', 'should output already disabled msg') }) }) diff --git a/deps/npm/test/lib/commands/publish.js b/deps/npm/test/lib/commands/publish.js index b06655d346026e..e444121b77e113 100644 --- a/deps/npm/test/lib/commands/publish.js +++ b/deps/npm/test/lib/commands/publish.js @@ -563,7 +563,7 @@ t.test('workspaces', t => { t.matchSnapshot(joinedOutput(), 'all workspaces in json') }) - t.test('differet package spec', async t => { + t.test('different package spec', async t => { const testDir = { 'package.json': JSON.stringify( { @@ -1191,7 +1191,7 @@ t.test('oidc token exchange - no provenance', t => { constructor (...args) { const [url] = args if (url === ACTIONS_ID_TOKEN_REQUEST_URL) { - throw 'Specifically throwing a non errror object to test global try-catch' + throw 'Specifically throwing a non error object to test global try-catch' } super(...args) } diff --git a/deps/npm/test/lib/commands/sbom.js b/deps/npm/test/lib/commands/sbom.js index c08756414d25e1..2603c26469eab5 100644 --- a/deps/npm/test/lib/commands/sbom.js +++ b/deps/npm/test/lib/commands/sbom.js @@ -581,7 +581,7 @@ t.test('sbom', async t => { workspaces: false, })) - t.test('should filter worksapces with --workspace', t => mockWorkspaces(t, [], { + t.test('should filter workspaces with --workspace', t => mockWorkspaces(t, [], { 'sbom-format': 'spdx', workspace: 'a', })) diff --git a/deps/npm/test/lib/commands/team.js b/deps/npm/test/lib/commands/team.js index 1a5480293edc9b..1a00e64cadddcd 100644 --- a/deps/npm/test/lib/commands/team.js +++ b/deps/npm/test/lib/commands/team.js @@ -422,7 +422,7 @@ t.test('completion', async t => { t.test('npm team unknown subcommand autocomplete', async t => { t.rejects( team.completion({ conf: { argv: { remain: ['npm', 'team', 'missing-subcommand'] } } }), - { message: 'missing-subcommand not recognized' }, 'should throw a a not recognized error' + { message: 'missing-subcommand not recognized' }, 'should throw a not recognized error' ) t.end() diff --git a/deps/npm/test/lib/load-all-commands.js b/deps/npm/test/lib/load-all-commands.js index 892dd466ac5c47..454dcf984fb91a 100644 --- a/deps/npm/test/lib/load-all-commands.js +++ b/deps/npm/test/lib/load-all-commands.js @@ -1,4 +1,4 @@ -// Our coverage mapping means that stuff like this doen't count for coverage. +// Our coverage mapping means that stuff like this doesn't count for coverage. // It does ensure that every command has a usage that renders, contains its // name, a description, and if it has completion it is a function. That it // renders also ensures that any params we've defined in our commands work. @@ -37,7 +37,7 @@ t.test('load each command', async t => { t.ok(impl.exec.length <= 1, 'exec fn has 0 or 1 args') // workspaces - t.type(ctor.ignoreImplicitWorkspace, 'boolean', 'ctor has ignoreImplictWorkspace boolean') + t.type(ctor.ignoreImplicitWorkspace, 'boolean', 'ctor has ignoreImplicitWorkspace boolean') if (ctor.ignoreImplicitWorkspace !== BaseCommand.ignoreImplicitWorkspace) { counts.ignoreImplicitWorkspace++ } @@ -78,7 +78,7 @@ t.test('load each command', async t => { }) } - // make sure refactors dont move or rename these static properties since + // make sure refactors don't move or rename these static properties since // we guard against the tests for them above t.ok(counts.completion > 0, 'has some completion functions') t.ok(counts.ignoreImplicitWorkspace > 0, 'has some commands that change ignoreImplicitWorkspace') diff --git a/deps/npm/test/lib/npm.js b/deps/npm/test/lib/npm.js index 1c4033b083e64c..b4ac509adb4952 100644 --- a/deps/npm/test/lib/npm.js +++ b/deps/npm/test/lib/npm.js @@ -180,7 +180,7 @@ t.test('npm.load', async t => { }) await t.rejects( npm.exec('run', []), - /Can not use --no-workspaces and --workspace at the same time/ + /Cannot use --no-workspaces and --workspace at the same time/ ) }) diff --git a/deps/npm/test/lib/utils/display.js b/deps/npm/test/lib/utils/display.js index 26f52b17a85283..bc4e23485fa3e4 100644 --- a/deps/npm/test/lib/utils/display.js +++ b/deps/npm/test/lib/utils/display.js @@ -15,7 +15,7 @@ const mockDisplay = async (t, { mocks, load } = {}) => { const displayLoad = async (opts) => display.load({ loglevel: 'silly', stderrColor: false, - stdoutColot: false, + stdoutColor: false, heading: 'npm', ...opts, }) diff --git a/deps/npm/test/lib/utils/error-message.js b/deps/npm/test/lib/utils/error-message.js index 1939e27c8ba922..380e8611645e90 100644 --- a/deps/npm/test/lib/utils/error-message.js +++ b/deps/npm/test/lib/utils/error-message.js @@ -91,7 +91,7 @@ t.test('just simple messages', async t => { } }) -t.test('replace message/stack sensistive info', async t => { +t.test('replace message/stack sensitive info', async t => { const { errorMessage } = await loadMockNpm(t, { command: 'audit' }) const er = Object.assign(new Error('Error at registry: https://user:pass@registry.npmjs.org/'), { code: 'ENOAUDIT', diff --git a/deps/npm/test/lib/utils/open-url.js b/deps/npm/test/lib/utils/open-url.js index 096533140757e6..e094effea2efe6 100644 --- a/deps/npm/test/lib/utils/open-url.js +++ b/deps/npm/test/lib/utils/open-url.js @@ -180,7 +180,7 @@ t.test('open url prompt', async t => { t.equal(openerUrl, 'https://www.npmjs.com', 'did not open') }) - t.test('does not error when opener can not find command', async t => { + t.test('does not error when opener cannot find command', async t => { const { OUTPUT, error, openerUrl } = await mockOpenUrlPrompt(t, { openerResult: Object.assign(new Error('Opener failed'), { code: 127 }), }) diff --git a/deps/npm/test/lib/utils/queryable.js b/deps/npm/test/lib/utils/queryable.js index fb0db5d021b57a..7716d203261d5f 100644 --- a/deps/npm/test/lib/utils/queryable.js +++ b/deps/npm/test/lib/utils/queryable.js @@ -829,7 +829,7 @@ t.test('set arrays', async t => { t.throws( () => qqqqq.set('lorem[]', 4), { code: 'ENOAPPEND' }, - 'should throw error if using empty square bracket in an non-array item' + 'should throw error if using empty square bracket in a non-array item' ) qqqqq.set('lorem[0]', 3) t.strictSame( @@ -960,6 +960,6 @@ t.test('bracket lovers', async t => { '[iLoveBrackets]': 'seriously?', '[0]': '-.-', }, - 'any top-level item can not be parsed with square bracket notation' + 'any top-level item cannot be parsed with square bracket notation' ) }) diff --git a/deps/npm/test/lib/utils/reify-output.js b/deps/npm/test/lib/utils/reify-output.js index 2496606abaef39..134951e40aabd1 100644 --- a/deps/npm/test/lib/utils/reify-output.js +++ b/deps/npm/test/lib/utils/reify-output.js @@ -13,7 +13,7 @@ const mockReify = async (t, reify, { command, ...config } = {}) => { // Hack to adapt existing fake test. Make npm.command // return whatever was passed in to this function. // What it should be doing is npm.exec(command) but that - // breaks most of these tests because they dont expect + // breaks most of these tests because they don't expect // a command to actually run. Object.defineProperty(mock.npm, 'command', { get () {