启动脚本完美

enviroment-check.ps1

@@ -118,17 +118,30 @@ if (-not $npmHealthy) {
 }
 
 if (-not $npmHealthy) {
-    $installNpmBat = Join-Path $nodeDir 'install-npm.bat'
-    if (-not (Test-Path $installNpmBat)) {
-        Write-Host ('[X] Run install-npm.bat in nodejs\node') -ForegroundColor Red
-        exit 1
+    $bootstrapNpmJs = Join-Path $scriptRoot 'nodejs\bootstrap-npm.js'
+    if (Test-Path $bootstrapNpmJs) {
+        Write-Host 'npm still missing or broken; running bootstrap-npm.js (copy from nodejs\backup\npm first; registry only if backup incomplete)...' -ForegroundColor Yellow
+        & $nodeExe $bootstrapNpmJs
+        if ($LASTEXITCODE -ne 0) { Write-Host '[X] bootstrap-npm.js failed' -ForegroundColor Red; exit 1 }
+    } else {
+        $installNpmBat = Join-Path $nodeDir 'install-npm.bat'
+        if (-not (Test-Path $installNpmBat)) {
+            Write-Host ('[X] Missing nodejs\bootstrap-npm.js and install-npm.bat under nodejs\node') -ForegroundColor Red
+            exit 1
+        }
+        Write-Host 'Running install-npm.bat (runs bootstrap-npm.js)...' -ForegroundColor Yellow
+        cmd /c "`"$installNpmBat`" /q"
+        if ($LASTEXITCODE -ne 0) { Write-Host '[X] npm installation failed' -ForegroundColor Red; exit 1 }
     }
-    Write-Host 'Running install-npm.bat...' -ForegroundColor Yellow
-    cmd /c "`"$installNpmBat`" /q"
-    if ($LASTEXITCODE -ne 0) { Write-Host '[X] npm installation failed' -ForegroundColor Red; exit 1 }
     if (-not (Test-Path $npmCliPath)) { Write-Host '[X] npm-cli.js still missing' -ForegroundColor Red; exit 1 }
     $npmHealthy = $true
-    Write-Host '[OK] npm installed' -ForegroundColor Green
+    if ($npmCmd -and (Test-Path $npmCmd)) {
+        $npmVersion = & $npmCmd --version 2>$null
+        if ($npmVersion) { Write-Host ('[OK] npm: ' + $npmVersion) -ForegroundColor Green }
+        else { Write-Host '[OK] npm installed to node_modules' -ForegroundColor Green }
+    } else {
+        Write-Host '[OK] npm installed to node_modules' -ForegroundColor Green
+    }
 }
 
 if ($npmHealthy -and (Test-Path (Join-Path $nodeModulesPath 'npm'))) {
@@ -224,22 +237,25 @@ $requiredPipFiles = @(
     (Join-Path $embSitePackages 'pip\_internal\cli\main.py')
 )
 $pipOk = @($requiredPipFiles | Where-Object { -not (Test-Path $_) }).Count -eq 0
+$getPipScript = Join-Path $scriptRoot 'python\get-pip.py'
 if (-not $pipOk) {
-    Write-Host 'Restoring pip from python\backup\site-packages...' -ForegroundColor Yellow
+    Write-Host '[i] pip repair order: (1) copy from python\backup\site-packages (2) get-pip.py from mirror only if backup cannot restore pip' -ForegroundColor DarkCyan
+    Write-Host 'Copying site-packages from python\backup\site-packages into embedded Lib\site-packages...' -ForegroundColor Yellow
     Get-ChildItem -LiteralPath $bakSitePackages -ErrorAction SilentlyContinue | ForEach-Object {
         Copy-Item -LiteralPath $_.FullName -Destination $embSitePackages -Recurse -Force
     }
     $pipOk = @($requiredPipFiles | Where-Object { -not (Test-Path $_) }).Count -eq 0
 }
-$getPipScript = Join-Path $scriptRoot 'python\get-pip.py'
 if (-not $pipOk -and (Test-Path $getPipScript)) {
+    Write-Host 'pip still missing or broken after backup copy; running get-pip.py (network download)...' -ForegroundColor Yellow
     & $pythonExe $getPipScript --force-reinstall -i $pypiIndexUrl --trusted-host $pypiTrustedHost --no-warn-script-location
+    if ($LASTEXITCODE -ne 0) { Write-Host '[WARN] get-pip.py exited with an error' -ForegroundColor Yellow }
     $pipOk = @($requiredPipFiles | Where-Object { -not (Test-Path $_) }).Count -eq 0
 }
 if ($pipOk) {
     Write-Host '[OK] pip ready' -ForegroundColor Green
 } else {
-    Write-Host '[WARN] pip may be incomplete; place get-pip.py under python/' -ForegroundColor Yellow
+    Write-Host '[WARN] pip still incomplete after backup and get-pip.py; fill python\backup\site-packages or add python\get-pip.py' -ForegroundColor Yellow
 }
 
 Write-Host ''

nodejs/bootstrap-npm.js

@@ -68,6 +68,7 @@ async function main() {
         console.log('[OK] npm already present in node_modules');
         return;
     }
+    console.log('[i] npm install order: (1) copy from nodejs/backup/npm if complete (2) else download from registry');
     if (fs.existsSync(npmDir)) {
         console.log('[WARN] npm folder missing or incomplete; will replace...');
         try {

nodejs/node/npm-extract/package/LICENSE

@@ -1,235 +0,0 @@
-The npm application
-Copyright (c) npm, Inc. and Contributors
-Licensed on the terms of The Artistic License 2.0
-
-Node package dependencies of the npm application
-Copyright (c) their respective copyright owners
-Licensed on their respective license terms
-
-The npm public registry at https://registry.npmjs.org
-and the npm website at https://www.npmjs.com
-Operated by npm, Inc.
-Use governed by terms published on https://www.npmjs.com
-
-"Node.js"
-Trademark Joyent, Inc., https://joyent.com
-Neither npm nor npm, Inc. are affiliated with Joyent, Inc.
-
-The Node.js application
-Project of Node Foundation, https://nodejs.org
-
-The npm Logo
-Copyright (c) Mathias Pettersson and Brian Hammond
-
-"Gubblebum Blocky" typeface
-Copyright (c) Tjarda Koster, https://jelloween.deviantart.com
-Used with permission
-
-
---------
-
-
-The Artistic License 2.0
-
-Copyright (c) 2000-2006, The Perl Foundation.
-
-Everyone is permitted to copy and distribute verbatim copies
-of this license document, but changing it is not allowed.
-
-Preamble
-
-This license establishes the terms under which a given free software
-Package may be copied, modified, distributed, and/or redistributed.
-The intent is that the Copyright Holder maintains some artistic
-control over the development of that Package while still keeping the
-Package available as open source and free software.
-
-You are always permitted to make arrangements wholly outside of this
-license directly with the Copyright Holder of a given Package.  If the
-terms of this license do not permit the full use that you propose to
-make of the Package, you should contact the Copyright Holder and seek
-a different licensing arrangement.
-
-Definitions
-
-    "Copyright Holder" means the individual(s) or organization(s)
-    named in the copyright notice for the entire Package.
-
-    "Contributor" means any party that has contributed code or other
-    material to the Package, in accordance with the Copyright Holder's
-    procedures.
-
-    "You" and "your" means any person who would like to copy,
-    distribute, or modify the Package.
-
-    "Package" means the collection of files distributed by the
-    Copyright Holder, and derivatives of that collection and/or of
-    those files. A given Package may consist of either the Standard
-    Version, or a Modified Version.
-
-    "Distribute" means providing a copy of the Package or making it
-    accessible to anyone else, or in the case of a company or
-    organization, to others outside of your company or organization.
-
-    "Distributor Fee" means any fee that you charge for Distributing
-    this Package or providing support for this Package to another
-    party.  It does not mean licensing fees.
-
-    "Standard Version" refers to the Package if it has not been
-    modified, or has been modified only in ways explicitly requested
-    by the Copyright Holder.
-
-    "Modified Version" means the Package, if it has been changed, and
-    such changes were not explicitly requested by the Copyright
-    Holder.
-
-    "Original License" means this Artistic License as Distributed with
-    the Standard Version of the Package, in its current version or as
-    it may be modified by The Perl Foundation in the future.
-
-    "Source" form means the source code, documentation source, and
-    configuration files for the Package.
-
-    "Compiled" form means the compiled bytecode, object code, binary,
-    or any other form resulting from mechanical transformation or
-    translation of the Source form.
-
-
-Permission for Use and Modification Without Distribution
-
-(1)  You are permitted to use the Standard Version and create and use
-Modified Versions for any purpose without restriction, provided that
-you do not Distribute the Modified Version.
-
-
-Permissions for Redistribution of the Standard Version
-
-(2)  You may Distribute verbatim copies of the Source form of the
-Standard Version of this Package in any medium without restriction,
-either gratis or for a Distributor Fee, provided that you duplicate
-all of the original copyright notices and associated disclaimers.  At
-your discretion, such verbatim copies may or may not include a
-Compiled form of the Package.
-
-(3)  You may apply any bug fixes, portability changes, and other
-modifications made available from the Copyright Holder.  The resulting
-Package will still be considered the Standard Version, and as such
-will be subject to the Original License.
-
-
-Distribution of Modified Versions of the Package as Source
-
-(4)  You may Distribute your Modified Version as Source (either gratis
-or for a Distributor Fee, and with or without a Compiled form of the
-Modified Version) provided that you clearly document how it differs
-from the Standard Version, including, but not limited to, documenting
-any non-standard features, executables, or modules, and provided that
-you do at least ONE of the following:
-
-    (a)  make the Modified Version available to the Copyright Holder
-    of the Standard Version, under the Original License, so that the
-    Copyright Holder may include your modifications in the Standard
-    Version.
-
-    (b)  ensure that installation of your Modified Version does not
-    prevent the user installing or running the Standard Version. In
-    addition, the Modified Version must bear a name that is different
-    from the name of the Standard Version.
-
-    (c)  allow anyone who receives a copy of the Modified Version to
-    make the Source form of the Modified Version available to others
-    under
-
-        (i)  the Original License or
-
-        (ii)  a license that permits the licensee to freely copy,
-        modify and redistribute the Modified Version using the same
-        licensing terms that apply to the copy that the licensee
-        received, and requires that the Source form of the Modified
-        Version, and of any works derived from it, be made freely
-        available in that license fees are prohibited but Distributor
-        Fees are allowed.
-
-
-Distribution of Compiled Forms of the Standard Version
-or Modified Versions without the Source
-
-(5)  You may Distribute Compiled forms of the Standard Version without
-the Source, provided that you include complete instructions on how to
-get the Source of the Standard Version.  Such instructions must be
-valid at the time of your distribution.  If these instructions, at any
-time while you are carrying out such distribution, become invalid, you
-must provide new instructions on demand or cease further distribution.
-If you provide valid instructions or cease distribution within thirty
-days after you become aware that the instructions are invalid, then
-you do not forfeit any of your rights under this license.
-
-(6)  You may Distribute a Modified Version in Compiled form without
-the Source, provided that you comply with Section 4 with respect to
-the Source of the Modified Version.
-
-
-Aggregating or Linking the Package
-
-(7)  You may aggregate the Package (either the Standard Version or
-Modified Version) with other packages and Distribute the resulting
-aggregation provided that you do not charge a licensing fee for the
-Package.  Distributor Fees are permitted, and licensing fees for other
-components in the aggregation are permitted. The terms of this license
-apply to the use and Distribution of the Standard or Modified Versions
-as included in the aggregation.
-
-(8) You are permitted to link Modified and Standard Versions with
-other works, to embed the Package in a larger work of your own, or to
-build stand-alone binary or bytecode versions of applications that
-include the Package, and Distribute the result without restriction,
-provided the result does not expose a direct interface to the Package.
-
-
-Items That are Not Considered Part of a Modified Version
-
-(9) Works (including, but not limited to, modules and scripts) that
-merely extend or make use of the Package, do not, by themselves, cause
-the Package to be a Modified Version.  In addition, such works are not
-considered parts of the Package itself, and are not subject to the
-terms of this license.
-
-
-General Provisions
-
-(10)  Any use, modification, and distribution of the Standard or
-Modified Versions is governed by this Artistic License. By using,
-modifying or distributing the Package, you accept this license. Do not
-use, modify, or distribute the Package, if you do not accept this
-license.
-
-(11)  If your Modified Version has been derived from a Modified
-Version made by someone other than you, you are nevertheless required
-to ensure that your Modified Version complies with the requirements of
-this license.
-
-(12)  This license does not grant you the right to use any trademark,
-service mark, tradename, or logo of the Copyright Holder.
-
-(13)  This license includes the non-exclusive, worldwide,
-free-of-charge patent license to make, have made, use, offer to sell,
-sell, import and otherwise transfer the Package with respect to any
-patent claims licensable by the Copyright Holder that are necessarily
-infringed by the Package. If you institute patent litigation
-(including a cross-claim or counterclaim) against any party alleging
-that the Package constitutes direct or contributory patent
-infringement, then this Artistic License to you shall terminate on the
-date that such litigation is filed.
-
-(14)  Disclaimer of Warranty:
-THE PACKAGE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTORS "AS
-IS' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES. THE IMPLIED
-WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
-NON-INFRINGEMENT ARE DISCLAIMED TO THE EXTENT PERMITTED BY YOUR LOCAL
-LAW. UNLESS REQUIRED BY LAW, NO COPYRIGHT HOLDER OR CONTRIBUTOR WILL
-BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
-DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THE PACKAGE, EVEN IF
-ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-
---------

nodejs/node/npm-extract/package/bin/node-gyp-bin/node-gyp

@@ -1,6 +0,0 @@
-#!/usr/bin/env sh
-if [ "x$npm_config_node_gyp" = "x" ]; then
-  node "`dirname "$0"`/../../node_modules/node-gyp/bin/node-gyp.js" "$@"
-else
-  "$npm_config_node_gyp" "$@"
-fi

nodejs/node/npm-extract/package/bin/npm

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

nodejs/node/npm-extract/package/bin/npx

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

nodejs/node/npm-extract/package/man/man1/npm-access.1

@@ -1,105 +0,0 @@
-.TH "NPM-ACCESS" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-access\fR - Set access level on published packages
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm access list packages \[lB]<user>|<scope>|<scope:team>\[rB] \[lB]<package>\[rB]
-npm access list collaborators \[lB]<package> \[lB]<user>\[rB]\[rB]
-npm access get status \[lB]<package>\[rB]
-npm access set status=public|private \[lB]<package>\[rB]
-npm access set mfa=none|publish|automation \[lB]<package>\[rB]
-npm access grant <read-only|read-write> <scope:team> \[lB]<package>\[rB]
-npm access revoke <scope:team> \[lB]<package>\[rB]
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-Used to set access controls on private packages.
-.P
-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
-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"
-.P
-\fBnpm access\fR always operates directly on the current registry, configurable from the command line using \fB--registry=<registry url>\fR.
-.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 set status=public\fR after the initial publish.
-.P
-You must have privileges to set the access of a package:
-.RS 0
-.IP \(bu 4
-You are an owner of an unscoped or scoped package.
-.IP \(bu 4
-You are a member of the team that owns a scope.
-.IP \(bu 4
-You have been given read-write privileges for a package, either as a member of a team or directly as an owner.
-.RE 0
-
-.P
-If you have two-factor authentication enabled then you'll be prompted to provide a second factor, or may use the \fB--otp=...\fR option to specify it on the command line.
-.P
-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 \fB--access=public\fR.
-.P
-Management of teams and team memberships is done with the \fBnpm team\fR command.
-.SS "Configuration"
-.SS "\fBjson\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Whether or not to output JSON data, rather than the normal output.
-.RS 0
-.IP \(bu 4
-In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
-.RE 0
-
-.P
-Not supported by all npm commands.
-.SS "\fBotp\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-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.
-.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"
-.RS 0
-.IP \(bu 4
-Default: "https://registry.npmjs.org/"
-.IP \(bu 4
-Type: URL
-.RE 0
-
-.P
-The base URL of the npm registry.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-\fB\[rs]fBlibnpmaccess\[rs]fR\fR \fI\(lahttps://npm.im/libnpmaccess\(ra\fR
-.IP \(bu 4
-npm help team
-.IP \(bu 4
-npm help publish
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help registry
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-adduser.1

@@ -1,93 +0,0 @@
-.TH "NPM-ADDUSER" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-adduser\fR - Add a registry user account
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm adduser
-
-alias: add-user
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-Create a new user in the specified registry, and save the credentials to the \fB.npmrc\fR file. If no registry is specified, the default registry will be used (see npm help registry).
-.P
-When you run \fBnpm adduser\fR, the CLI automatically generates a legacy token of \fBpublish\fR type. For more information, see \fBAbout legacy tokens\fR \fI\(la/about-access-tokens#about-legacy-tokens\(ra\fR.
-.P
-When using \fBlegacy\fR for your \fBauth-type\fR, the username, password, and email are read in from prompts.
-.SS "Configuration"
-.SS "\fBregistry\fR"
-.RS 0
-.IP \(bu 4
-Default: "https://registry.npmjs.org/"
-.IP \(bu 4
-Type: URL
-.RE 0
-
-.P
-The base URL of the npm registry.
-.SS "\fBscope\fR"
-.RS 0
-.IP \(bu 4
-Default: the scope of the current project, if any, or ""
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-Associate an operation with a scope for a scoped registry.
-.P
-Useful when logging in to or out of a private registry:
-.P
-.RS 2
-.nf
-# log in, linking the scope to the custom registry
-npm login --scope=@mycorp --registry=https://registry.mycorp.com
-
-# log out, removing the link and the auth token
-npm logout --scope=@mycorp
-.fi
-.RE
-.P
-This will cause \fB@mycorp\fR to be mapped to the registry for future installation of packages specified according to the pattern \fB@mycorp/package\fR.
-.P
-This will also cause \fBnpm init\fR to create a scoped package.
-.P
-.RS 2
-.nf
-# accept all defaults, and create a package named "@foo/whatever",
-# instead of just named "whatever"
-npm init --scope=@foo --yes
-.fi
-.RE
-.SS "\fBauth-type\fR"
-.RS 0
-.IP \(bu 4
-Default: "web"
-.IP \(bu 4
-Type: "legacy" or "web"
-.RE 0
-
-.P
-What authentication strategy to use with \fBlogin\fR. Note that if an \fBotp\fR config is given, this value will always be set to \fBlegacy\fR.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help registry
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.IP \(bu 4
-npm help owner
-.IP \(bu 4
-npm help whoami
-.IP \(bu 4
-npm help token
-.IP \(bu 4
-npm help profile
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-audit.1

@@ -1,466 +0,0 @@
-.TH "NPM-AUDIT" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-audit\fR - Run a security audit
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm audit \[lB]fix|signatures\[rB]
-.fi
-.RE
-.SS "Description"
-.P
-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 \fBfix\fR argument is provided, then remediations will be applied to the package tree.
-.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.
-.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"
-.P
-By default npm requires a package-lock or shrinkwrap in order to run the audit. You can bypass the package lock with \fB--no-package-lock\fR but be aware the results may be different with every run, since npm will re-build the dependency tree each time.
-.SS "Audit Signatures"
-.P
-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.
-.P
-Registry signatures can be verified using the following \fBaudit\fR command:
-.P
-.RS 2
-.nf
-$ npm audit signatures
-.fi
-.RE
-.P
-The \fBaudit signatures\fR 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.
-.P
-To include the full sigstore attestation bundles in JSON output, use:
-.P
-.RS 2
-.nf
-$ npm audit signatures --json --include-attestations
-.fi
-.RE
-.P
-This adds a \fBverified\fR array to the JSON output containing the attestation bundles (DSSE envelopes, verification material, and transparency log entries) for each verified package.
-.P
-The npm CLI supports registry signatures and signing keys provided by any registry if the following conventions are followed:
-.RS 0
-.IP 1. 4
-Signatures are provided in the package's \fBpackument\fR in each published version within the \fBdist\fR object:
-.RE 0
-
-.P
-.RS 2
-.nf
-"dist":{
-  "..omitted..": "..omitted..",
-  "signatures": \[lB]{
-    "keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
-    "sig": "a312b9c3cb4a1b693e8ebac5ee1ca9cc01f2661c14391917dcb111517f72370809..."
-  }\[rB]
-}
-.fi
-.RE
-.P
-See this \fBexample\fR \fI\(lahttps://registry.npmjs.org/light-cycle/1.4.3\(ra\fR of a signed package from the public npm registry.
-.P
-The \fBsig\fR is generated using the following template: \fB${package.name}@${package.version}:${package.dist.integrity}\fR and the \fBkeyid\fR has to match one of the public signing keys below.
-.RS 0
-.IP 2. 4
-Public signing keys are provided at \fBregistry-host.tld/-/npm/v1/keys\fR in the following format:
-.RE 0
-
-.P
-.RS 2
-.nf
-{
-  "keys": \[lB]{
-    "expires": null,
-    "keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
-    "keytype": "ecdsa-sha2-nistp256",
-    "scheme": "ecdsa-sha2-nistp256",
-    "key": "{{B64_PUBLIC_KEY}}"
-  }\[rB]
-}
-.fi
-.RE
-.P
-Keys response:
-.RS 0
-.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
-\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
-\fBscheme\fR: only \fBecdsa-sha2-nistp256\fR is currently supported by the npm CLI
-.IP \(bu 4
-\fBkey\fR: base64 encoded public key
-.RE 0
-
-.P
-See this \fBexample key's response from the public npm registry\fR \fI\(lahttps://registry.npmjs.org/-/npm/v1/keys\(ra\fR.
-.SS "Audit Endpoints"
-.P
-There are two audit endpoints that npm may use to fetch vulnerability information: the \fBBulk Advisory\fR endpoint and the \fBQuick Audit\fR endpoint.
-.SS "Bulk Advisory Endpoint"
-.P
-As of version 7, npm uses the much faster \fBBulk Advisory\fR endpoint to optimize the speed of calculating audit results.
-.P
-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 \fB/-/npm/v1/security/advisories/bulk\fR.
-.P
-Any packages in the tree that do not have a \fBversion\fR field in their package.json file will be ignored. If any \fB--omit\fR options are specified (either via the \fB\[rs]fB--omit\[rs]fR config\fR \fI\(la/using-npm/config#omit\(ra\fR, or one of the shorthands such as \fB--production\fR, \fB--only=dev\fR, and so on), then packages will be omitted from the submitted payload as appropriate.
-.P
-If the registry responds with an error, or with an invalid response, then npm will attempt to load advisory data from the \fBQuick Audit\fR endpoint.
-.P
-The expected result will contain a set of advisory objects for each dependency that matches the advisory range. Each advisory object contains a \fBname\fR, \fBurl\fR, \fBid\fR, \fBseverity\fR, \fBvulnerable_versions\fR, and \fBtitle\fR.
-.P
-npm then uses these advisory objects to calculate vulnerabilities and meta-vulnerabilities of the dependencies within the tree.
-.SS "Quick Audit Endpoint"
-.P
-If the \fBBulk Advisory\fR endpoint returns an error, or invalid data, npm will attempt to load advisory data from the \fBQuick Audit\fR endpoint, which is considerably slower in most cases.
-.P
-The full package tree as found in \fBpackage-lock.json\fR is submitted, along with the following pieces of additional metadata:
-.RS 0
-.IP \(bu 4
-\fBnpm_version\fR
-.IP \(bu 4
-\fBnode_version\fR
-.IP \(bu 4
-\fBplatform\fR
-.IP \(bu 4
-\fBarch\fR
-.IP \(bu 4
-\fBnode_env\fR
-.RE 0
-
-.P
-All packages in the tree are submitted to the Quick Audit endpoint. Omitted dependency types are skipped when generating the report.
-.SS "Scrubbing"
-.P
-Out of an abundance of caution, npm versions 5 and 6 would "scrub" any packages from the submitted report if their name contained a \fB/\fR character, so as to avoid leaking the names of potentially private packages or git URLs.
-.P
-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.
-.P
-This scrubbing has been removed from npm as of version 7.
-.SS "Calculating Meta-Vulnerabilities and Remediations"
-.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".
-.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
-If the chain of metavulnerabilities extends all the way to the root project, and it cannot be updated without changing its dependency ranges, then \fBnpm audit fix\fR will require the \fB--force\fR 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.
-.SS "Exit Code"
-.P
-The \fBnpm audit\fR command will exit with a 0 exit code if no vulnerabilities were found. The \fBnpm audit fix\fR command will exit with 0 exit code if no vulnerabilities are found \fIor\fR if the remediation is able to successfully fix all vulnerabilities.
-.P
-If vulnerabilities were found the exit code will depend on the \fB\[rs]fBaudit-level\[rs]fR config\fR \fI\(la/using-npm/config#audit-level\(ra\fR.
-.SS "Examples"
-.P
-Scan your project for vulnerabilities and automatically install any compatible updates to vulnerable dependencies:
-.P
-.RS 2
-.nf
-$ npm audit fix
-.fi
-.RE
-.P
-Run \fBaudit fix\fR without modifying \fBnode_modules\fR, but still updating the pkglock:
-.P
-.RS 2
-.nf
-$ npm audit fix --package-lock-only
-.fi
-.RE
-.P
-Skip updating \fBdevDependencies\fR:
-.P
-.RS 2
-.nf
-$ npm audit fix --only=prod
-.fi
-.RE
-.P
-Have \fBaudit fix\fR install SemVer-major updates to toplevel dependencies, not just SemVer-compatible ones:
-.P
-.RS 2
-.nf
-$ npm audit fix --force
-.fi
-.RE
-.P
-Do a dry run to get an idea of what \fBaudit fix\fR will do, and \fIalso\fR output install information in JSON format:
-.P
-.RS 2
-.nf
-$ npm audit fix --dry-run --json
-.fi
-.RE
-.P
-Scan your project for vulnerabilities and just show the details, without fixing anything:
-.P
-.RS 2
-.nf
-$ npm audit
-.fi
-.RE
-.P
-Get the detailed audit report in JSON format:
-.P
-.RS 2
-.nf
-$ npm audit --json
-.fi
-.RE
-.P
-Fail an audit only if the results include a vulnerability with a level of moderate or higher:
-.P
-.RS 2
-.nf
-$ npm audit --audit-level=moderate
-.fi
-.RE
-.SS "Configuration"
-.SS "\fBaudit-level\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null, "info", "low", "moderate", "high", "critical", or "none"
-.RE 0
-
-.P
-The minimum level of vulnerability for \fBnpm audit\fR to exit with a non-zero exit code.
-.SS "\fBdry-run\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-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, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
-.P
-Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
-.SS "\fBforce\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
-.RS 0
-.IP \(bu 4
-Allow clobbering non-npm files in global installs.
-.IP \(bu 4
-Allow the \fBnpm version\fR command to work on an unclean git repository.
-.IP \(bu 4
-Allow deleting the cache folder with \fBnpm cache clean\fR.
-.IP \(bu 4
-Allow installing packages that have an \fBengines\fR declaration requiring a different version of npm.
-.IP \(bu 4
-Allow installing packages that have an \fBengines\fR declaration requiring a different version of \fBnode\fR, even if \fB--engine-strict\fR is enabled.
-.IP \(bu 4
-Allow \fBnpm audit fix\fR to install modules outside your stated dependency range (including SemVer-major changes).
-.IP \(bu 4
-Allow unpublishing all versions of a published package.
-.IP \(bu 4
-Allow conflicting peerDependencies to be installed in the root project.
-.IP \(bu 4
-Implicitly set \fB--yes\fR during \fBnpm init\fR.
-.IP \(bu 4
-Allow clobbering existing values in \fBnpm pkg\fR
-.IP \(bu 4
-Allow unpublishing of entire packages (not just a single version).
-.RE 0
-
-.P
-If you don't have a clear idea of what you want to do, it is strongly recommended that you do not use this option!
-.SS "\fBjson\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Whether or not to output JSON data, rather than the normal output.
-.RS 0
-.IP \(bu 4
-In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
-.RE 0
-
-.P
-Not supported by all npm commands.
-.SS "\fBpackage-lock-only\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-If set to true, the current operation will only use the \fBpackage-lock.json\fR, ignoring \fBnode_modules\fR.
-.P
-For \fBupdate\fR this means only the \fBpackage-lock.json\fR will be updated, instead of checking \fBnode_modules\fR and downloading dependencies.
-.P
-For \fBlist\fR this means the output will be based on the tree described by the \fBpackage-lock.json\fR, rather than the contents of \fBnode_modules\fR.
-.SS "\fBpackage-lock\fR"
-.RS 0
-.IP \(bu 4
-Default: true
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-If set to false, then ignore \fBpackage-lock.json\fR files when installing. This will also prevent \fIwriting\fR \fBpackage-lock.json\fR if \fBsave\fR is true.
-.SS "\fBomit\fR"
-.RS 0
-.IP \(bu 4
-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
-
-.P
-Dependency types to omit from the installation tree on disk.
-.P
-Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
-.P
-If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
-.P
-If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
-.SS "\fBinclude\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
-.RE 0
-
-.P
-Option that allows for defining which types of dependencies to install.
-.P
-This is the inverse of \fB--omit=<type>\fR.
-.P
-Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
-.SS "\fBforeground-scripts\fR"
-.RS 0
-.IP \(bu 4
-Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
-.P
-Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
-.SS "\fBignore-scripts\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.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.
-.SS "\fBinclude-attestations\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-When used with \fBnpm audit signatures --json\fR, includes the full sigstore attestation bundles in the JSON output for each verified package. The bundles contain DSSE envelopes, verification material, and transparency log entries.
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR 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.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinstall-links\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-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.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-npm help config
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-bugs.1

@@ -1,115 +0,0 @@
-.TH "NPM-BUGS" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-bugs\fR - Report bugs for a package in a web browser
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm bugs \[lB]<pkgname> \[lB]<pkgname> ...\[rB]\[rB]
-
-alias: issues
-.fi
-.RE
-.SS "Description"
-.P
-This command tries to guess at the likely location of a package's bug tracker URL or the \fBmailto\fR URL of the support email, and then tries to open it using the \fB\[rs]fB--browser\[rs]fR config\fR \fI\(la/using-npm/config#browser\(ra\fR param. If no package name is provided, it will search for a \fBpackage.json\fR in the current folder and use the \fBname\fR property.
-.SS "Configuration"
-.SS "\fBbrowser\fR"
-.RS 0
-.IP \(bu 4
-Default: macOS: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg-open"\fR
-.IP \(bu 4
-Type: null, Boolean, or String
-.RE 0
-
-.P
-The browser that is called by npm commands to open websites.
-.P
-Set to \fBfalse\fR to suppress browser behavior and instead print urls to terminal.
-.P
-Set to \fBtrue\fR to use default system URL opener.
-.SS "\fBregistry\fR"
-.RS 0
-.IP \(bu 4
-Default: "https://registry.npmjs.org/"
-.IP \(bu 4
-Type: URL
-.RE 0
-
-.P
-The base URL of the npm registry.
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR 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.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help docs
-.IP \(bu 4
-npm help view
-.IP \(bu 4
-npm help publish
-.IP \(bu 4
-npm help registry
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.IP \(bu 4
-\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-cache.1

@@ -1,95 +0,0 @@
-.TH "NPM-CACHE" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-cache\fR - Manipulates packages cache
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm cache add <package-spec>
-npm cache clean \[lB]<key>\[rB]
-npm cache ls \[lB]<name>@<version>\[rB]
-npm cache verify
-npm cache npx ls
-npm cache npx rm \[lB]<key>...\[rB]
-npm cache npx info <key>...
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-Used to add, list, or clean the \fBnpm cache\fR folder. Also used to view info about entries in the \fBnpm exec\fR (aka \fBnpx\fR) cache folder.
-.SS "\fBnpm cache\fR"
-.RS 0
-.IP \(bu 4
-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.
-.IP \(bu 4
-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.
-.IP \(bu 4
-ls: List given entries or all entries in the local cache.
-.IP \(bu 4
-verify: Verify the contents of the cache folder, garbage collecting any unneeded data, and verifying the integrity of the cache index and all cached data.
-.RE 0
-
-.SS "\fBnpm cache npx\fR"
-.RS 0
-.IP \(bu 4
-ls: List all entries in the npx cache.
-.IP \(bu 4
-rm: Remove given entries or all entries from the npx cache.
-.IP \(bu 4
-info: Get detailed information about given entries in the npx cache.
-.RE 0
-
-.SS "Details"
-.P
-npm stores cache data in an opaque directory within the configured \fBcache\fR, named \fB_cacache\fR. This directory is a \fB\[rs]fBcacache\[rs]fR\fR \fI\(lahttp://npm.im/cacache\(ra\fR-based content-addressable cache that stores all http request data as well as other package-related data. This directory is primarily accessed through \fBpacote\fR, the library responsible for all package fetching as of npm@5.
-.P
-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 \fBpacote\fR 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 \fBclean\fR now requires \fB--force\fR to run.
-.P
-There is currently no method exposed through npm to inspect or directly manage the contents of this cache. In order to access it, \fBcacache\fR must be used directly.
-.P
-npm will not remove data by itself: the cache will grow as new packages are installed.
-.SS "A note about the cache's design"
-.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.
-.SS "Configuration"
-.SS "\fBcache\fR"
-.RS 0
-.IP \(bu 4
-Default: Windows: \fB%LocalAppData%\[rs]npm-cache\fR, Posix: \fB~/.npm\fR
-.IP \(bu 4
-Type: Path
-.RE 0
-
-.P
-The location of npm's cache directory.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help "package spec"
-.IP \(bu 4
-npm help folders
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-npm help publish
-.IP \(bu 4
-npm help pack
-.IP \(bu 4
-npm help exec
-.IP \(bu 4
-https://npm.im/cacache
-.IP \(bu 4
-https://npm.im/pacote
-.IP \(bu 4
-https://npm.im/@npmcli/arborist
-.IP \(bu 4
-https://npm.im/make-fetch-happen
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-ci.1

@@ -1,301 +0,0 @@
-.TH "NPM-CI" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-ci\fR - Clean install a project
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm ci
-
-aliases: clean-install, ic, install-clean, isntall-clean
-.fi
-.RE
-.SS "Description"
-.P
-This command is similar to npm help 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.
-.P
-The main differences between using \fBnpm install\fR and \fBnpm ci\fR are:
-.RS 0
-.IP \(bu 4
-The project \fBmust\fR have an existing \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR.
-.IP \(bu 4
-If dependencies in the package lock do not match those in \fBpackage.json\fR, \fBnpm ci\fR will exit with an error, instead of updating the package lock.
-.IP \(bu 4
-\fBnpm ci\fR can only install entire projects at a time: individual dependencies cannot be added with this command.
-.IP \(bu 4
-If a \fBnode_modules\fR is already present, it will be automatically removed before \fBnpm ci\fR begins its install.
-.IP \(bu 4
-It will never write to \fBpackage.json\fR or any of the package-locks: installs are essentially frozen.
-.RE 0
-
-.P
-NOTE: If you create your \fBpackage-lock.json\fR file by running \fBnpm install\fR with flags that can affect the shape of your dependency tree, such as \fB--legacy-peer-deps\fR or \fB--install-links\fR, you \fImust\fR provide the same flags to \fBnpm ci\fR or you are likely to encounter errors. An easy way to do this is to run, for example, \fBnpm config set legacy-peer-deps=true --location=project\fR and commit the \fB.npmrc\fR file to your repo.
-.SS "Example"
-.P
-Make sure you have a package-lock and an up-to-date install:
-.P
-.RS 2
-.nf
-$ cd ./my/npm/project
-$ npm install
-added 154 packages in 10s
-$ ls | grep package-lock
-.fi
-.RE
-.P
-Run \fBnpm ci\fR in that project
-.P
-.RS 2
-.nf
-$ npm ci
-added 154 packages in 5s
-.fi
-.RE
-.P
-Configure Travis CI to build using \fBnpm ci\fR instead of \fBnpm install\fR:
-.P
-.RS 2
-.nf
-# .travis.yml
-install:
-- npm ci
-# keep the npm cache around to speed up installs
-cache:
-  directories:
-  - "$HOME/.npm"
-.fi
-.RE
-.SS "Configuration"
-.SS "\fBinstall-strategy\fR"
-.RS 0
-.IP \(bu 4
-Default: "hoisted"
-.IP \(bu 4
-Type: "hoisted", "nested", "shallow", or "linked"
-.RE 0
-
-.P
-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.
-.SS "\fBlegacy-bundling\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.IP \(bu 4
-DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
-.RE 0
-
-.P
-Instead of hoisting package installs in \fBnode_modules\fR, 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 \fB--install-strategy=nested\fR.
-.SS "\fBglobal-style\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.IP \(bu 4
-DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
-.RE 0
-
-.P
-Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
-.SS "\fBomit\fR"
-.RS 0
-.IP \(bu 4
-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
-
-.P
-Dependency types to omit from the installation tree on disk.
-.P
-Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
-.P
-If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
-.P
-If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
-.SS "\fBinclude\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
-.RE 0
-
-.P
-Option that allows for defining which types of dependencies to install.
-.P
-This is the inverse of \fB--omit=<type>\fR.
-.P
-Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
-.SS "\fBstrict-peer-deps\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
-.P
-By default, conflicting \fBpeerDependencies\fR 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 \fBpeerDependencies\fR object.
-.P
-When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
-.SS "\fBforeground-scripts\fR"
-.RS 0
-.IP \(bu 4
-Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
-.P
-Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
-.SS "\fBignore-scripts\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.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.
-.SS "\fBallow-git\fR"
-.RS 0
-.IP \(bu 4
-Default: "all"
-.IP \(bu 4
-Type: "all", "none", or "root"
-.RE 0
-
-.P
-Limits the ability for npm to fetch dependencies from git references. That is, dependencies that point to a git repo instead of a version or semver range. Please note that this could leave your tree incomplete and some packages may not function as intended or designed.
-.P
-\fBall\fR allows any git dependencies to be fetched and installed. \fBnone\fR prevents any git dependencies from being fetched and installed. \fBroot\fR only allows git dependencies defined in your project's package.json to be fetched installed. Also allows git dependencies to be fetched for other commands like \fBnpm view\fR
-.SS "\fBaudit\fR"
-.RS 0
-.IP \(bu 4
-Default: true
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-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 help audit for details on what is submitted.
-.SS "\fBbin-links\fR"
-.RS 0
-.IP \(bu 4
-Default: true
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
-.P
-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.
-.SS "\fBfund\fR"
-.RS 0
-.IP \(bu 4
-Default: true
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
-.SS "\fBdry-run\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-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, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
-.P
-Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR 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.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinstall-links\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-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.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-\fBpackage-lock.json\fR \fI\(la/configuring-npm/package-lock-json\(ra\fR
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-completion.1

@@ -1,35 +0,0 @@
-.TH "NPM-COMPLETION" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-completion\fR - Tab Completion for npm
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm completion
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-Enables tab-completion in all npm commands.
-.P
-The synopsis above loads the completions into your current shell. Adding it to your ~/.bashrc or ~/.zshrc will make the completions available everywhere:
-.P
-.RS 2
-.nf
-npm completion >> ~/.bashrc
-npm completion >> ~/.zshrc
-.fi
-.RE
-.P
-You may of course also pipe the output of \fBnpm completion\fR to a file such as \fB/usr/local/etc/bash_completion.d/npm\fR or \fB/etc/bash_completion.d/npm\fR if you have a system that will read that file for you.
-.P
-When \fBCOMP_CWORD\fR, \fBCOMP_LINE\fR, and \fBCOMP_POINT\fR are defined in the environment, \fBnpm completion\fR acts in "plumbing mode", and outputs completions based on the arguments.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help developers
-.IP \(bu 4
-npm help npm
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-config.1

@@ -1,186 +0,0 @@
-.TH "NPM-CONFIG" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-config\fR - Manage the npm configuration files
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm config set <key>=<value> \[lB]<key>=<value> ...\[rB]
-npm config get \[lB]<key> \[lB]<key> ...\[rB]\[rB]
-npm config delete <key> \[lB]<key> ...\[rB]
-npm config list \[lB]--json\[rB]
-npm config edit
-npm config fix
-
-alias: c
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-npm gets its config settings from the command line, environment variables, \fBnpmrc\fR files, and in some cases, the \fBpackage.json\fR file.
-.P
-See npm help npmrc for more information about the npmrc files.
-.P
-See npm help config for a more thorough explanation of the mechanisms involved, and a full list of config options available.
-.P
-The \fBnpm config\fR command can be used to update and edit the contents of the user and global npmrc files.
-.SS "Sub-commands"
-.P
-Config supports the following sub-commands:
-.SS "set"
-.P
-.RS 2
-.nf
-npm config set key=value \[lB]key=value...\[rB]
-npm set key=value \[lB]key=value...\[rB]
-.fi
-.RE
-.P
-Sets each of the config keys to the value provided. Modifies the user configuration file unless \fB\[rs]fBlocation\[rs]fR\fR \fI\(la/commands/npm-config#location\(ra\fR is passed.
-.P
-If value is omitted, the key will be removed from your config file entirely.
-.P
-Note: for backwards compatibility, \fBnpm config set key value\fR is supported as an alias for \fBnpm config set key=value\fR.
-.SS "get"
-.P
-.RS 2
-.nf
-npm config get \[lB]key ...\[rB]
-npm get \[lB]key ...\[rB]
-.fi
-.RE
-.P
-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.
-.SS "list"
-.P
-.RS 2
-.nf
-npm config list
-.fi
-.RE
-.P
-Show all the config settings. Use \fB-l\fR to also show defaults. Use \fB--json\fR to show the settings in json format.
-.SS "delete"
-.P
-.RS 2
-.nf
-npm config delete key \[lB]key ...\[rB]
-.fi
-.RE
-.P
-Deletes the specified keys from all configuration files.
-.SS "edit"
-.P
-.RS 2
-.nf
-npm config edit
-.fi
-.RE
-.P
-Opens the config file in an editor. Use the \fB--global\fR flag to edit the global config.
-.SS "fix"
-.P
-.RS 2
-.nf
-npm config fix
-.fi
-.RE
-.P
-Attempts to repair invalid configuration items. Usually this means attaching authentication config (i.e. \fB_auth\fR, \fB_authToken\fR) to the configured \fBregistry\fR.
-.SS "Configuration"
-.SS "\fBjson\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Whether or not to output JSON data, rather than the normal output.
-.RS 0
-.IP \(bu 4
-In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
-.RE 0
-
-.P
-Not supported by all npm commands.
-.SS "\fBglobal\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
-.RS 0
-.IP \(bu 4
-packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
-.IP \(bu 4
-bin files are linked to \fB{prefix}/bin\fR
-.IP \(bu 4
-man pages are linked to \fB{prefix}/share/man\fR
-.RE 0
-
-.SS "\fBeditor\fR"
-.RS 0
-.IP \(bu 4
-Default: The EDITOR or VISUAL environment variables, or '%SYSTEMROOT%\[rs]notepad.exe' on Windows, or 'vi' on Unix systems
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-The command to run for \fBnpm edit\fR and \fBnpm config edit\fR.
-.SS "\fBlocation\fR"
-.RS 0
-.IP \(bu 4
-Default: "user" unless \fB--global\fR is passed, which will also set this value to "global"
-.IP \(bu 4
-Type: "global", "user", or "project"
-.RE 0
-
-.P
-When passed to \fBnpm config\fR this refers to which config file to use.
-.P
-When set to "global" mode, packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
-.RS 0
-.IP \(bu 4
-packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
-.IP \(bu 4
-bin files are linked to \fB{prefix}/bin\fR
-.IP \(bu 4
-man pages are linked to \fB{prefix}/share/man\fR
-.RE 0
-
-.SS "\fBlong\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Show extended information in \fBls\fR, \fBsearch\fR, and \fBhelp-search\fR.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help folders
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
-.IP \(bu 4
-npm help npmrc
-.IP \(bu 4
-npm help npm
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-dedupe.1

@@ -1,302 +0,0 @@
-.TH "NPM-DEDUPE" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-dedupe\fR - Reduce duplication in the package tree
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm dedupe
-
-alias: ddp
-.fi
-.RE
-.SS "Description"
-.P
-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.
-.P
-For example, consider this dependency graph:
-.P
-.RS 2
-.nf
-a
-+-- b <-- depends on c@1.0.x
-|   `-- c@1.0.3
-`-- d <-- depends on c@~1.0.9
-    `-- c@1.0.10
-.fi
-.RE
-.P
-In this case, \fBnpm dedupe\fR will transform the tree to:
-.P
-.RS 2
-.nf
-a
-+-- b
-+-- d
-`-- c@1.0.10
-.fi
-.RE
-.P
-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.
-.P
-In some cases, you may have a dependency graph like this:
-.P
-.RS 2
-.nf
-a
-+-- b <-- depends on c@1.0.x
-+-- c@1.0.3
-`-- d <-- depends on c@1.x
-    `-- c@1.9.9
-.fi
-.RE
-.P
-During the installation process, the \fBc@1.0.3\fR dependency for \fBb\fR was placed in the root of the tree. Though \fBd\fR's dependency on \fBc@1.x\fR could have been satisfied by \fBc@1.0.3\fR, the newer \fBc@1.9.9\fR dependency was used, because npm favors updates by default, even when doing so causes duplication.
-.P
-Running \fBnpm dedupe\fR will cause npm to note the duplication and re-evaluate, deleting the nested \fBc\fR module, because the one in the root is sufficient.
-.P
-To prefer deduplication over novelty during the installation process, run \fBnpm install --prefer-dedupe\fR or \fBnpm config set prefer-dedupe true\fR.
-.P
-Arguments are ignored. Dedupe always acts on the entire tree.
-.P
-Note that this operation transforms the dependency tree, but will never result in new modules being installed.
-.P
-Using \fBnpm find-dupes\fR will run the command in \fB--dry-run\fR mode.
-.P
-Note: \fBnpm dedupe\fR will never update the semver values of direct dependencies in your project \fBpackage.json\fR, if you want to update values in \fBpackage.json\fR you can run: \fBnpm update --save\fR instead.
-.SS "Configuration"
-.SS "\fBinstall-strategy\fR"
-.RS 0
-.IP \(bu 4
-Default: "hoisted"
-.IP \(bu 4
-Type: "hoisted", "nested", "shallow", or "linked"
-.RE 0
-
-.P
-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.
-.SS "\fBlegacy-bundling\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.IP \(bu 4
-DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
-.RE 0
-
-.P
-Instead of hoisting package installs in \fBnode_modules\fR, 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 \fB--install-strategy=nested\fR.
-.SS "\fBglobal-style\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.IP \(bu 4
-DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
-.RE 0
-
-.P
-Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
-.SS "\fBstrict-peer-deps\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
-.P
-By default, conflicting \fBpeerDependencies\fR 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 \fBpeerDependencies\fR object.
-.P
-When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
-.SS "\fBpackage-lock\fR"
-.RS 0
-.IP \(bu 4
-Default: true
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-If set to false, then ignore \fBpackage-lock.json\fR files when installing. This will also prevent \fIwriting\fR \fBpackage-lock.json\fR if \fBsave\fR is true.
-.SS "\fBomit\fR"
-.RS 0
-.IP \(bu 4
-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
-
-.P
-Dependency types to omit from the installation tree on disk.
-.P
-Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
-.P
-If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
-.P
-If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
-.SS "\fBinclude\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
-.RE 0
-
-.P
-Option that allows for defining which types of dependencies to install.
-.P
-This is the inverse of \fB--omit=<type>\fR.
-.P
-Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
-.SS "\fBignore-scripts\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.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.
-.SS "\fBallow-git\fR"
-.RS 0
-.IP \(bu 4
-Default: "all"
-.IP \(bu 4
-Type: "all", "none", or "root"
-.RE 0
-
-.P
-Limits the ability for npm to fetch dependencies from git references. That is, dependencies that point to a git repo instead of a version or semver range. Please note that this could leave your tree incomplete and some packages may not function as intended or designed.
-.P
-\fBall\fR allows any git dependencies to be fetched and installed. \fBnone\fR prevents any git dependencies from being fetched and installed. \fBroot\fR only allows git dependencies defined in your project's package.json to be fetched installed. Also allows git dependencies to be fetched for other commands like \fBnpm view\fR
-.SS "\fBaudit\fR"
-.RS 0
-.IP \(bu 4
-Default: true
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-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 help audit for details on what is submitted.
-.SS "\fBbin-links\fR"
-.RS 0
-.IP \(bu 4
-Default: true
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
-.P
-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.
-.SS "\fBfund\fR"
-.RS 0
-.IP \(bu 4
-Default: true
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
-.SS "\fBdry-run\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-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, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
-.P
-Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR 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.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinstall-links\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-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.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help find-dupes
-.IP \(bu 4
-npm help ls
-.IP \(bu 4
-npm help update
-.IP \(bu 4
-npm help install
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-deprecate.1

@@ -1,85 +0,0 @@
-.TH "NPM-DEPRECATE" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-deprecate\fR - Deprecate a version of a package
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm deprecate <package-spec> <message>
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-This command will update the npm registry entry for a package, providing a deprecation warning to all who attempt to install it.
-.P
-It works on \fBversion ranges\fR \fI\(lahttps://semver.npmjs.com/\(ra\fR as well as specific versions, so you can do something like this:
-.P
-.RS 2
-.nf
-npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
-.fi
-.RE
-.P
-SemVer ranges passed to this command are interpreted such that they \fIdo\fR include prerelease versions. For example:
-.P
-.RS 2
-.nf
-npm deprecate my-thing@1.x "1.x is no longer supported"
-.fi
-.RE
-.P
-In this case, a version \fBmy-thing@1.0.0-beta.0\fR will also be deprecated.
-.P
-You must be the package owner to deprecate something. See the \fBowner\fR and \fBadduser\fR help topics.
-.P
-To un-deprecate a package, specify an empty string (\fB""\fR) for the \fBmessage\fR argument. Note that you must use double quotes with no space between them to format an empty string.
-.SS "Configuration"
-.SS "\fBregistry\fR"
-.RS 0
-.IP \(bu 4
-Default: "https://registry.npmjs.org/"
-.IP \(bu 4
-Type: URL
-.RE 0
-
-.P
-The base URL of the npm registry.
-.SS "\fBotp\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-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.
-.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"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-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, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
-.P
-Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help "package spec"
-.IP \(bu 4
-npm help publish
-.IP \(bu 4
-npm help registry
-.IP \(bu 4
-npm help owner
-.IP \(bu 4
-npm help adduser
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-diff.1

@@ -1,310 +0,0 @@
-.TH "NPM-DIFF" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-diff\fR - The registry diff command
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm diff \[lB]...<paths>\[rB]
-.fi
-.RE
-.SS "Description"
-.P
-Similar to its \fBgit diff\fR counterpart, this command will print diff patches of files for packages published to the npm registry.
-.RS 0
-.IP \(bu 4
-\fBnpm diff --diff=<spec-a> --diff=<spec-b>\fR
-.P
-Compares two package versions using their registry specifiers, e.g: \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0\fR. It's also possible to compare across forks of any package, e.g: \fBnpm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0\fR.
-.P
-Any valid spec can be used, so that it's also possible to compare directories or git repositories, e.g: \fBnpm diff --diff=pkg@latest --diff=./packages/pkg\fR
-.P
-Here's an example comparing two different versions of a package named \fBabbrev\fR from the registry:
-.P
-.RS 2
-.nf
-npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1
-.fi
-.RE
-.P
-On success, output looks like:
-.P
-.RS 2
-.nf
-diff --git a/package.json b/package.json
-index v1.1.0..v1.1.1 100644
---- a/package.json
-+++ b/package.json
-@@ -1,6 +1,6 @@
- {
-   "name": "abbrev",
--  "version": "1.1.0",
-+  "version": "1.1.1",
-   "description": "Like ruby's abbrev module, but in js",
-   "author": "Isaac Z. Schlueter <i@izs.me>",
-   "main": "abbrev.js",
-.fi
-.RE
-.P
-Given the flexible nature of npm specs, you can also target local directories or git repos just like when using \fBnpm install\fR:
-.P
-.RS 2
-.nf
-npm diff --diff=https://github.com/npm/libnpmdiff --diff=./local-path
-.fi
-.RE
-.P
-In the example above we can compare the contents from the package installed from the git repo at \fBgithub.com/npm/libnpmdiff\fR with the contents of the \fB./local-path\fR that contains a valid package, such as a modified copy of the original.
-.IP \(bu 4
-\fBnpm diff\fR (in a package directory, no arguments):
-.P
-If the package is published to the registry, \fBnpm diff\fR will fetch the tarball version tagged as \fBlatest\fR (this value can be configured using the \fBtag\fR option) and proceed to compare the contents of files present in that tarball, with the current files in your local file system.
-.P
-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.
-.IP \(bu 4
-\fBnpm diff --diff=<pkg-name>\fR (in a package directory):
-.P
-When using a single package name (with no version or tag specifier) as an argument, \fBnpm diff\fR will work in a similar way to \fB\[rs]fBnpm-outdated\[rs]fR\fR \fI\(lanpm-outdated\(ra\fR and reach for the registry to figure out what current published version of the package named \fB<pkg-name>\fR will satisfy its dependent declared semver-range. Once that specific version is known \fBnpm diff\fR will print diff patches comparing the current version of \fB<pkg-name>\fR found in the local file system with that specific version returned by the registry.
-.P
-Given a package named \fBabbrev\fR that is currently installed:
-.P
-.RS 2
-.nf
-npm diff --diff=abbrev
-.fi
-.RE
-.P
-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.
-.IP \(bu 4
-\fBnpm diff --diff=<spec-a>\fR (in a package directory):
-.P
-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 \fB<spec-a>\fR.
-.P
-An example: assuming \fBpkg@1.0.0\fR is installed in the current \fBnode_modules\fR folder, running:
-.P
-.RS 2
-.nf
-npm diff --diff=pkg@2.0.0
-.fi
-.RE
-.P
-It will effectively be an alias to \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@2.0.0\fR.
-.IP \(bu 4
-\fBnpm diff --diff=<semver-a> \[lB]--diff=<semver-b>\[rB]\fR (in a package directory):
-.P
-Using \fBnpm diff\fR along with semver-valid version numbers is a shorthand to compare different versions of the current package.
-.P
-It needs to be run from a package directory, such that for a package named \fBpkg\fR running \fBnpm diff --diff=1.0.0 --diff=1.0.1\fR is the same as running \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1\fR.
-.P
-If only a single argument \fB<version-a>\fR is provided, then the current local file system is going to be compared against that version.
-.P
-Here's an example comparing two specific versions (published to the configured registry) of the current project directory:
-.P
-.RS 2
-.nf
-npm diff --diff=1.0.0 --diff=1.1.0
-.fi
-.RE
-.RE 0
-
-.P
-Note that tag names are not valid \fB--diff\fR argument values, if you wish to compare to a published tag, you must use the \fBpkg@tagname\fR syntax.
-.SS "Filtering files"
-.P
-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:
-.P
-.RS 2
-.nf
-npm diff --diff=pkg@2 ./lib/ CHANGELOG.md
-.fi
-.RE
-.P
-In the example above the diff output is only going to print contents of files located within the folder \fB./lib/\fR and changed lines of code within the \fBCHANGELOG.md\fR file.
-.SS "Configuration"
-.SS "\fBdiff\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-Define arguments to compare in \fBnpm diff\fR.
-.SS "\fBdiff-name-only\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Prints only filenames when using \fBnpm diff\fR.
-.SS "\fBdiff-unified\fR"
-.RS 0
-.IP \(bu 4
-Default: 3
-.IP \(bu 4
-Type: Number
-.RE 0
-
-.P
-The number of lines of context to print in \fBnpm diff\fR.
-.SS "\fBdiff-ignore-all-space\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Ignore whitespace when comparing lines in \fBnpm diff\fR.
-.SS "\fBdiff-no-prefix\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Do not show any source or destination prefix in \fBnpm diff\fR output.
-.P
-Note: this causes \fBnpm diff\fR to ignore the \fB--diff-src-prefix\fR and \fB--diff-dst-prefix\fR configs.
-.SS "\fBdiff-src-prefix\fR"
-.RS 0
-.IP \(bu 4
-Default: "a/"
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-Source prefix to be used in \fBnpm diff\fR output.
-.SS "\fBdiff-dst-prefix\fR"
-.RS 0
-.IP \(bu 4
-Default: "b/"
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-Destination prefix to be used in \fBnpm diff\fR output.
-.SS "\fBdiff-text\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Treat all files as text in \fBnpm diff\fR.
-.SS "\fBglobal\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
-.RS 0
-.IP \(bu 4
-packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
-.IP \(bu 4
-bin files are linked to \fB{prefix}/bin\fR
-.IP \(bu 4
-man pages are linked to \fB{prefix}/share/man\fR
-.RE 0
-
-.SS "\fBtag\fR"
-.RS 0
-.IP \(bu 4
-Default: "latest"
-.IP \(bu 4
-Type: String
-.RE 0
-
-.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.
-.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
-If used in the \fBnpm publish\fR command, this is the tag that will be added to the package submitted to the registry.
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR 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.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SH "SEE ALSO"
-.RS 0
-.IP \(bu 4
-npm help outdated
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help registry
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-dist-tag.1

@@ -1,144 +0,0 @@
-.TH "NPM-DIST-TAG" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-dist-tag\fR - Modify package distribution tags
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm dist-tag add <package-spec (with version)> \[lB]<tag>\[rB]
-npm dist-tag rm <package-spec> <tag>
-npm dist-tag ls \[lB]<package-spec>\[rB]
-
-alias: dist-tags
-.fi
-.RE
-.SS "Description"
-.P
-Add, remove, and enumerate distribution tags on a package:
-.RS 0
-.IP \(bu 4
-add: Tags the specified version of the package with the specified tag, or the \fB\[rs]fB--tag\[rs]fR config\fR \fI\(la/using-npm/config#tag\(ra\fR if not specified. If you have two-factor authentication on auth-and-writes then you\[cq]ll need to include a one-time password on the command line with \fB--otp <one-time password>\fR, or go through a second factor flow based on your \fBauthtype\fR.
-.IP \(bu 4
-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\[cq]ll need to include a one-time password on the command line with \fB--otp <one-time password>\fR, or go through a second factor flow based on your \fBauthtype\fR
-.IP \(bu 4
-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.
-.RE 0
-
-.P
-A tag can be used when installing packages as a reference to a version instead of using a specific version number:
-.P
-.RS 2
-.nf
-npm install <name>@<tag>
-.fi
-.RE
-.P
-When installing dependencies, a preferred tagged version may be specified:
-.P
-.RS 2
-.nf
-npm install --tag <tag>
-.fi
-.RE
-.P
-(This also applies to any other commands that resolve and install dependencies, such as \fBnpm dedupe\fR, \fBnpm update\fR, and \fBnpm audit fix\fR.)
-.P
-Publishing a package sets the \fBlatest\fR tag to the published version unless the \fB--tag\fR option is used. For example, \fBnpm publish --tag=beta\fR.
-.P
-By default, \fBnpm install <pkg>\fR (without any \fB@<version>\fR or \fB@<tag>\fR specifier) installs the \fBlatest\fR tag.
-.SS "Purpose"
-.P
-Tags can be used to provide an alias instead of version numbers.
-.P
-For example, a project might choose to have multiple streams of development and use a different tag for each stream, e.g., \fBstable\fR, \fBbeta\fR, \fBdev\fR, \fBcanary\fR.
-.P
-By default, the \fBlatest\fR tag is used by npm to identify the current version of a package, and \fBnpm install <pkg>\fR (without any \fB@<version>\fR or \fB@<tag>\fR specifier) installs the \fBlatest\fR tag. Typically, projects only use the \fBlatest\fR tag for stable release versions, and use other tags for unstable versions such as prereleases.
-.P
-The \fBnext\fR tag is used by some projects to identify the upcoming version.
-.P
-Other than \fBlatest\fR, no tag has any special significance to npm itself.
-.SS "Caveats"
-.P
-This command used to be known as \fBnpm tag\fR, which only created new tags, and so had a different syntax.
-.P
-Tags must share a namespace with version numbers, because they are specified in the same slot: \fBnpm install <pkg>@<version>\fR vs \fBnpm install <pkg>@<tag>\fR.
-.P
-Tags that can be interpreted as valid semver ranges will be rejected. For example, \fBv1.4\fR cannot be used as a tag, because it is interpreted by semver as \fB>=1.4.0 <1.5.0\fR. See \fI\(lahttps://github.com/npm/npm/issues/6082\(ra\fR.
-.P
-The simplest way to avoid semver problems with tags is to use tags that do not begin with a number or the letter \fBv\fR.
-.SS "Configuration"
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR 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.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help "package spec"
-.IP \(bu 4
-npm help publish
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-npm help dedupe
-.IP \(bu 4
-npm help registry
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-docs.1

@@ -1,113 +0,0 @@
-.TH "NPM-DOCS" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-docs\fR - Open documentation for a package in a web browser
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm docs \[lB]<pkgname> \[lB]<pkgname> ...\[rB]\[rB]
-
-alias: home
-.fi
-.RE
-.SS "Description"
-.P
-This command tries to guess at the likely location of a package's documentation URL, and then tries to open it using the \fB\[rs]fB--browser\[rs]fR config\fR \fI\(la/using-npm/config#browser\(ra\fR param. You can pass multiple package names at once. If no package name is provided, it will search for a \fBpackage.json\fR in the current folder and use the \fBname\fR property.
-.SS "Configuration"
-.SS "\fBbrowser\fR"
-.RS 0
-.IP \(bu 4
-Default: macOS: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg-open"\fR
-.IP \(bu 4
-Type: null, Boolean, or String
-.RE 0
-
-.P
-The browser that is called by npm commands to open websites.
-.P
-Set to \fBfalse\fR to suppress browser behavior and instead print urls to terminal.
-.P
-Set to \fBtrue\fR to use default system URL opener.
-.SS "\fBregistry\fR"
-.RS 0
-.IP \(bu 4
-Default: "https://registry.npmjs.org/"
-.IP \(bu 4
-Type: URL
-.RE 0
-
-.P
-The base URL of the npm registry.
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR 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.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help view
-.IP \(bu 4
-npm help publish
-.IP \(bu 4
-npm help registry
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.IP \(bu 4
-\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-doctor.1

@@ -1,82 +0,0 @@
-.TH "NPM-DOCTOR" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-doctor\fR - Check the health of your npm environment
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm doctor \[lB]connection\[rB] \[lB]registry\[rB] \[lB]versions\[rB] \[lB]environment\[rB] \[lB]permissions\[rB] \[lB]cache\[rB]
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-\fBnpm doctor\fR 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:
-.RS 0
-.IP \(bu 4
-Node.js and git must be executable by npm.
-.IP \(bu 4
-The primary npm registry, \fBregistry.npmjs.com\fR, or another service that uses the registry API, is available.
-.IP \(bu 4
-The directories that npm uses, \fBnode_modules\fR (both locally and globally), exist and can be written by the current user.
-.IP \(bu 4
-The npm cache exists, and the package tarballs within it aren't corrupt.
-.RE 0
-
-.P
-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 \fBnpm doctor\fR confirms that the npm installation is in a good state.
-.P
-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 \fBnpm@latest\fR is better than an old version.
-.P
-\fBnpm doctor\fR 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.
-.SS "\fBConnecting to the registry\fR"
-.P
-By default, npm installs from the primary npm registry, \fBregistry.npmjs.org\fR. \fBnpm doctor\fR hits a special connection testing endpoint within the registry. This can also be checked with \fBnpm ping\fR. 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 \fBregistry.npmjs.org\fR.
-.P
-This check is done against whichever registry you've configured (you can see what that is by running \fBnpm config get registry\fR), and if you're using a private registry that doesn't support the \fB/whoami\fR endpoint supported by the primary registry, this check may fail.
-.SS "\fBChecking npm version\fR"
-.P
-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 \fBnpm@latest\fR 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.
-.SS "\fBChecking node version\fR"
-.P
-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.
-.SS "\fBChecking configured npm registry\fR"
-.P
-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 \fBnpm doctor\fR just lets you, and maybe whoever's helping you with support, know that you're not using the default registry.
-.SS "\fBChecking for git executable in PATH\fR"
-.P
-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 \[en] especially on Windows \[en] you may have Git set up in such a way that it's not accessible via your \fBPATH\fR so that npm can find it. This check ensures that Git is available.
-.SS "Permissions checks"
-.RS 0
-.IP \(bu 4
-Your cache must be readable and writable by the user running npm.
-.IP \(bu 4
-Global package binaries must be writable by the user running npm.
-.IP \(bu 4
-Your local \fBnode_modules\fR path, if you're running \fBnpm doctor\fR with a project directory, must be readable and writable by the user running npm.
-.RE 0
-
-.SS "Validate the checksums of cached packages"
-.P
-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. \fBnpm doctor\fR uses these checksums to validate the package tarballs in your local cache (you can see where that cache is located with \fBnpm config get cache\fR). In the event that there are corrupt packages in your cache, you should probably run \fBnpm cache clean -f\fR and reset the cache.
-.SS "Configuration"
-.SS "\fBregistry\fR"
-.RS 0
-.IP \(bu 4
-Default: "https://registry.npmjs.org/"
-.IP \(bu 4
-Type: URL
-.RE 0
-
-.P
-The base URL of the npm registry.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help bugs
-.IP \(bu 4
-npm help help
-.IP \(bu 4
-npm help ping
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-edit.1

@@ -1,43 +0,0 @@
-.TH "NPM-EDIT" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-edit\fR - Edit an installed package
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm edit <pkg>\[lB]/<subpkg>...\[rB]
-.fi
-.RE
-.P
-Note: This command is unaware of workspaces.
-.SS "Description"
-.P
-Selects a dependency in the current project and opens the package folder in the default editor (or whatever you've configured as the npm \fBeditor\fR config -- see \fB\[rs]fBnpm-config\[rs]fR\fR \fI\(lanpm-config\(ra\fR.)
-.P
-After it has been edited, the package is rebuilt so as to pick up any changes in compiled packages.
-.P
-For instance, you can do \fBnpm install connect\fR to install connect into your package, and then \fBnpm edit connect\fR to make a few changes to your locally installed copy.
-.SS "Configuration"
-.SS "\fBeditor\fR"
-.RS 0
-.IP \(bu 4
-Default: The EDITOR or VISUAL environment variables, or '%SYSTEMROOT%\[rs]notepad.exe' on Windows, or 'vi' on Unix systems
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-The command to run for \fBnpm edit\fR and \fBnpm config edit\fR.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help folders
-.IP \(bu 4
-npm help explore
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-exec.1

@@ -1,350 +0,0 @@
-.TH "NPM-EXEC" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-exec\fR - Run a command from a local or remote npm package
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm exec -- <pkg>\[lB]@<version>\[rB] \[lB]args...\[rB]
-npm exec --package=<pkg>\[lB]@<version>\[rB] -- <cmd> \[lB]args...\[rB]
-npm exec -c '<cmd> \[lB]args...\[rB]'
-npm exec --package=foo -c '<cmd> \[lB]args...\[rB]'
-
-alias: x
-.fi
-.RE
-.SS "Description"
-.P
-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 \fBnpm run\fR.
-.P
-Run without positional arguments or \fB--call\fR, this allows you to interactively run commands in the same sort of shell environment that \fBpackage.json\fR scripts are run. Interactive mode is not supported in CI environments when standard input is a TTY, to prevent hangs.
-.P
-Whatever packages are specified by the \fB--package\fR option will be provided in the \fBPATH\fR of the executed command, along with any locally installed package executables. The \fB--package\fR option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available.
-.P
-If any requested packages are not present in the local project dependencies, then a prompt is printed, which can be suppressed by providing either \fB--yes\fR or \fB--no\fR. When standard input is not a TTY or a CI environment is detected, \fB--yes\fR is assumed. The requested packages are installed to a folder in the npm cache, which is added to the \fBPATH\fR environment variable in the executed process.
-.P
-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.
-.P
-If no \fB-c\fR or \fB--call\fR option is provided, then the positional arguments are used to generate the command string. If no \fB--package\fR 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:
-.RS 0
-.IP \(bu 4
-If the package has a single entry in its \fBbin\fR field in \fBpackage.json\fR, or if all entries are aliases of the same command, then that command will be used.
-.IP \(bu 4
-If the package has multiple \fBbin\fR entries, and one of them matches the unscoped portion of the \fBname\fR field, then that command will be used.
-.IP \(bu 4
-If this does not result in exactly one option (either because there are no bin entries, or none of them match the \fBname\fR of the package), then \fBnpm exec\fR exits with an error.
-.RE 0
-
-.P
-To run a binary \fIother than\fR the named binary, specify one or more \fB--package\fR options, which will prevent npm from inferring the package from the first command argument.
-.SS "\fBnpx\fR vs \fBnpm exec\fR"
-.P
-When run via the \fBnpx\fR binary, all flags and options \fImust\fR be set prior to any positional arguments. When run via \fBnpm exec\fR, a double-hyphen \fB--\fR flag can be used to suppress npm's parsing of switches and options that should be sent to the executed command.
-.P
-For example:
-.P
-.RS 2
-.nf
-$ npx foo@latest bar --package=@npmcli/foo
-.fi
-.RE
-.P
-In this case, npm will resolve the \fBfoo\fR package name, and run the following command:
-.P
-.RS 2
-.nf
-$ foo bar --package=@npmcli/foo
-.fi
-.RE
-.P
-Since the \fB--package\fR option comes \fIafter\fR the positional arguments, it is treated as an argument to the executed command.
-.P
-In contrast, due to npm's argument parsing logic, running this command is different:
-.P
-.RS 2
-.nf
-$ npm exec foo@latest bar --package=@npmcli/foo
-.fi
-.RE
-.P
-In this case, npm will parse the \fB--package\fR option first, resolving the \fB@npmcli/foo\fR package. Then, it will execute the following command in that context:
-.P
-.RS 2
-.nf
-$ foo@latest bar
-.fi
-.RE
-.P
-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 \fBnpx\fR command above:
-.P
-.RS 2
-.nf
-$ npm exec -- foo@latest bar --package=@npmcli/foo
-.fi
-.RE
-.SS "Configuration"
-.SS "\fBpackage\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-The package or packages to install for npm help exec
-.SS "\fBcall\fR"
-.RS 0
-.IP \(bu 4
-Default: ""
-.IP \(bu 4
-Type: String
-.RE 0
-
-.P
-Optional companion option for \fBnpm exec\fR, \fBnpx\fR that allows for specifying a custom command to be run along with the installed packages.
-.P
-.RS 2
-.nf
-npm exec --package yo --package generator-node --call "yo node"
-.fi
-.RE
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR 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.
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBworkspaces\fR"
-.RS 0
-.IP \(bu 4
-Default: null
-.IP \(bu 4
-Type: null or Boolean
-.RE 0
-
-.P
-Set to true to run the command in the context of \fBall\fR configured workspaces.
-.P
-Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
-.RS 0
-.IP \(bu 4
-Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "\fBinclude-workspace-root\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Include the workspace root when workspaces are enabled for a command.
-.P
-When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
-.P
-This value is not exported to the environment for child processes.
-.SS "Examples"
-.P
-Run the version of \fBtap\fR in the local dependencies, with the provided arguments:
-.P
-.RS 2
-.nf
-$ npm exec -- tap --bail test/foo.js
-$ npx tap --bail test/foo.js
-.fi
-.RE
-.P
-Run a command \fIother than\fR the command whose name matches the package name by specifying a \fB--package\fR option:
-.P
-.RS 2
-.nf
-$ npm exec --package=foo -- bar --bar-argument
-# ~ or ~
-$ npx --package=foo bar --bar-argument
-.fi
-.RE
-.P
-Run an arbitrary shell script, in the context of the current project:
-.P
-.RS 2
-.nf
-$ npm x -c 'eslint && say "hooray, lint passed"'
-$ npx -c 'eslint && say "hooray, lint passed"'
-.fi
-.RE
-.SS "Workspaces support"
-.P
-You may use the \fB\[rs]fBworkspace\[rs]fR\fR \fI\(la/using-npm/config#workspace\(ra\fR or \fB\[rs]fBworkspaces\[rs]fR\fR \fI\(la/using-npm/config#workspaces\(ra\fR 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 \fB--call\fR option is provided, it will open an interactive subshell in the context of each of these configured workspaces one at a time.
-.P
-Given a project with configured workspaces, e.g:
-.P
-.RS 2
-.nf
-.
-+-- package.json
-`-- packages
-   +-- a
-   |   `-- package.json
-   +-- b
-   |   `-- package.json
-   `-- c
-       `-- package.json
-.fi
-.RE
-.P
-Assuming the workspace configuration is properly set up at the root level \fBpackage.json\fR file. e.g:
-.P
-.RS 2
-.nf
-{
-    "workspaces": \[lB] "./packages/*" \[rB]
-}
-.fi
-.RE
-.P
-You can execute an arbitrary command from a package in the context of each of the configured workspaces when using the \fB\[rs]fBworkspaces\[rs]fR config options\fR \fI\(la/using-npm/config#workspace\(ra\fR, in this example we're using \fBeslint\fR to lint any js file found within each workspace folder:
-.P
-.RS 2
-.nf
-npm exec --ws -- eslint ./*.js
-.fi
-.RE
-.SS "Filtering workspaces"
-.P
-It's also possible to execute a command in a single workspace using the \fBworkspace\fR config along with a name or directory path:
-.P
-.RS 2
-.nf
-npm exec --workspace=a -- eslint ./*.js
-.fi
-.RE
-.P
-The \fBworkspace\fR 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 \fBworkspace\fR config in the command line, it also possible to use \fB-w\fR as a shorthand, e.g:
-.P
-.RS 2
-.nf
-npm exec -w a -w b -- eslint ./*.js
-.fi
-.RE
-.P
-This last command will run the \fBeslint\fR command in both \fB./packages/a\fR and \fB./packages/b\fR folders.
-.SS "Compatibility with Older npx Versions"
-.P
-The \fBnpx\fR binary was rewritten in npm v7.0.0, and the standalone \fBnpx\fR package deprecated at that time. \fBnpx\fR uses the \fBnpm exec\fR 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.
-.P
-This resulted in some shifts in its functionality:
-.RS 0
-.IP \(bu 4
-Any \fBnpm\fR config value may be provided.
-.IP \(bu 4
-To prevent security and user-experience problems from mistyping package names, \fBnpx\fR prompts before installing anything. Suppress this prompt with the \fB-y\fR or \fB--yes\fR option.
-.IP \(bu 4
-The \fB--no-install\fR option is deprecated, and will be converted to \fB--no\fR.
-.IP \(bu 4
-Shell fallback functionality is removed, as it is not advisable.
-.IP \(bu 4
-The \fB-p\fR argument is a shorthand for \fB--parseable\fR in npm, but shorthand for \fB--package\fR in npx. This is maintained, but only for the \fBnpx\fR executable.
-.IP \(bu 4
-The \fB--ignore-existing\fR option is removed. Locally installed bins are always present in the executed process \fBPATH\fR.
-.IP \(bu 4
-The \fB--npm\fR option is removed. \fBnpx\fR will always use the \fBnpm\fR it ships with.
-.IP \(bu 4
-The \fB--node-arg\fR and \fB-n\fR options are removed.
-.IP \(bu 4
-The \fB--always-spawn\fR option is redundant, and thus removed.
-.IP \(bu 4
-The \fB--shell\fR option is replaced with \fB--script-shell\fR, but maintained in the \fBnpx\fR executable for backwards compatibility.
-.RE 0
-
-.SS "A note on caching"
-.P
-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 help cache for more on how the cache works.
-.SS "prefer-online"
-.P
-Forces staleness checks for packages, making the cli look for updates immediately even if the package is already in the cache.
-.SS "prefer-offline"
-.P
-Bypasses staleness checks for packages. Missing data will still be requested from the server. To force full offline mode, use \fBoffline\fR.
-.SS "offline"
-.P
-Forces full offline mode. Any packages not locally cached will result in an error.
-.SS "workspace"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result to selecting all of the nested workspaces)
-.RE 0
-
-.P
-This value is not exported to the environment for child processes.
-.SS "workspaces"
-.RS 0
-.IP \(bu 4
-Alias: \fB--ws\fR
-.IP \(bu 4
-Type: Boolean
-.IP \(bu 4
-Default: \fBfalse\fR
-.RE 0
-
-.P
-Run scripts in the context of all configured workspaces for the current project.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help run
-.IP \(bu 4
-npm help scripts
-.IP \(bu 4
-npm help test
-.IP \(bu 4
-npm help start
-.IP \(bu 4
-npm help restart
-.IP \(bu 4
-npm help stop
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help workspaces
-.IP \(bu 4
-npm help npx
-.RE 0

nodejs/node/npm-extract/package/man/man1/npm-explain.1

@@ -1,118 +0,0 @@
-.TH "NPM-EXPLAIN" "1" "March 2026" "NPM@11.12.0" ""
-.SH "NAME"
-\fBnpm-explain\fR - Explain installed packages
-.SS "Synopsis"
-.P
-.RS 2
-.nf
-npm explain <package-spec>
-
-alias: why
-.fi
-.RE
-.SS "Description"
-.P
-This command will print the chain of dependencies causing a given package to be installed in the current project.
-.P
-If one or more package specs are provided, then only packages matching one of the specifiers will have their relationships explained.
-.P
-The package spec can also refer to a folder within \fB./node_modules\fR
-.P
-For example, running \fBnpm explain glob\fR within npm's source tree will show:
-.P
-.RS 2
-.nf
-glob@7.1.6
-node_modules/glob
-  glob@"^7.1.4" from the root project
-
-glob@7.1.1 dev
-node_modules/tacks/node_modules/glob
-  glob@"^7.0.5" from rimraf@2.6.2
-  node_modules/tacks/node_modules/rimraf
-    rimraf@"^2.6.2" from tacks@1.3.0
-    node_modules/tacks
-      dev tacks@"^1.3.0" from the root project
-.fi
-.RE
-.P
-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.
-.P
-.RS 2
-.nf
-$ npm explain node_modules/nyc/node_modules/find-up
-find-up@3.0.0 dev
-node_modules/nyc/node_modules/find-up
-  find-up@"^3.0.0" from nyc@14.1.1
-  node_modules/nyc
-    nyc@"^14.1.1" from tap@14.10.8
-    node_modules/tap
-      dev tap@"^14.10.8" from the root project
-.fi
-.RE
-.SS "Configuration"
-.SS "\fBjson\fR"
-.RS 0
-.IP \(bu 4
-Default: false
-.IP \(bu 4
-Type: Boolean
-.RE 0
-
-.P
-Whether or not to output JSON data, rather than the normal output.
-.RS 0
-.IP \(bu 4
-In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
-.RE 0
-
-.P
-Not supported by all npm commands.
-.SS "\fBworkspace\fR"
-.RS 0
-.IP \(bu 4
-Default:
-.IP \(bu 4
-Type: String (can be set multiple times)
-.RE 0
-
-.P
-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.
-.P
-Valid values for the \fBworkspace\fR config are either:
-.RS 0
-.IP \(bu 4
-Workspace names
-.IP \(bu 4
-Path to a workspace directory
-.IP \(bu 4
-Path to a parent workspace directory (will result in selecting all workspaces within that folder)
-.RE 0
-
-.P
-When set for the \fBnpm init\fR 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.
-.P
-This value is not exported to the environment for child processes.
-.SS "See Also"
-.RS 0
-.IP \(bu 4
-npm help "package spec"
-.IP \(bu 4
-npm help config
-.IP \(bu 4
-npm help npmrc
-.IP \(bu 4
-npm help folders
-.IP \(bu 4
-npm help ls
-.IP \(bu 4
-npm help install
-.IP \(bu 4
-npm help link
-.IP \(bu 4
-npm help prune
-.IP \(bu 4
-npm help outdated
-.IP \(bu 4
-npm help update
-.RE 0