.-.-.-.-.-

PK�~�\�F�c!c!man7/developers.7nu�[���.TH "DEVELOPERS" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBdevelopers\fR - Developer Guide
.SS "Description"
.P
So, you've decided to use npm to develop (and maybe publish/deploy) your project.
.P
Fantastic!
.P
There are a few things that you need to do above the simple steps that your users will do to install your program.
.SS "About These Documents"
.P
These are man pages. If you install npm, you should be able to then do \fBman npm-thing\fR to get the documentation on a particular topic, or \fBnpm help thing\fR to see the same information.
.SS "What is a Package"
.P
A package is:
.RS 0
.IP \(bu 4
a) a folder containing a program described by a package.json file
.IP \(bu 4
b) a gzipped tarball containing (a)
.IP \(bu 4
c) a url that resolves to (b)
.IP \(bu 4
d) a \fB<name>@<version>\fR that is published on the registry with (c)
.IP \(bu 4
e) a \fB<name>@<tag>\fR that points to (d)
.IP \(bu 4
f) a \fB<name>\fR that has a "latest" tag satisfying (e)
.IP \(bu 4
g) a \fBgit\fR url that, when cloned, results in (a).
.RE 0

.P
Even if you never publish your package, you can still get a lot of benefits of using npm if you just want to write a node program (a), and perhaps if you also want to be able to easily install it elsewhere after packing it up into a tarball (b).
.P
Git urls can be of the form:
.P
.RS 2
.nf
git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish
.fi
.RE
.P
The \fBcommit-ish\fR can be any tag, sha, or branch which can be supplied as an argument to \fBgit checkout\fR. The default is whatever the repository uses as its default branch.
.SS "The package.json File"
.P
You need to have a \fBpackage.json\fR file in the root of your project to do much of anything with npm. That is basically the whole interface.
.P
See \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR for details about what goes in that file. At the very least, you need:
.RS 0
.IP \(bu 4
name: This should be a string that identifies your project. Please do not use the name to specify that it runs on node, or is in JavaScript. You can use the "engines" field to explicitly state the versions of node (or whatever else) that your program requires, and it's pretty well assumed that it's JavaScript.
.P
It does not necessarily need to match your github repository name.
.P
So, \fBnode-foo\fR and \fBbar-js\fR are bad names. \fBfoo\fR or \fBbar\fR are better.
.IP \(bu 4
version: A semver-compatible version.
.IP \(bu 4
engines: Specify the versions of node (or whatever else) that your program runs on. The node API changes a lot, and there may be bugs or new functionality that you depend on. Be explicit.
.IP \(bu 4
author: Take some credit.
.IP \(bu 4
scripts: If you have a special compilation or installation script, then you should put it in the \fBscripts\fR object. You should definitely have at least a basic smoke-test command as the "scripts.test" field. See npm help scripts.
.IP \(bu 4
main: If you have a single module that serves as the entry point to your program (like what the "foo" package gives you at require("foo")), then you need to specify that in the "main" field.
.IP \(bu 4
directories: This is an object mapping names to folders. The best ones to include are "lib" and "doc", but if you use "man" to specify a folder full of man pages, they'll get installed just like these ones.
.RE 0

.P
You can use \fBnpm init\fR in the root of your package in order to get you started with a pretty basic package.json file. See npm help init for more info.
.SS "Keeping files \fIout\fR of your Package"
.P
Use a \fB.npmignore\fR file to keep stuff out of your package. If there's no \fB.npmignore\fR file, but there \fIis\fR a \fB.gitignore\fR file, then npm will ignore the stuff matched by the \fB.gitignore\fR file. If you \fIwant\fR to include something that is excluded by your \fB.gitignore\fR file, you can create an empty \fB.npmignore\fR file to override it. Like \fBgit\fR, \fBnpm\fR looks for \fB.npmignore\fR and \fB.gitignore\fR files in all subdirectories of your package, not only the root directory.
.P
\fB.npmignore\fR files follow the \fBsame pattern rules\fR \fI\(lahttps://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring\(ra\fR as \fB.gitignore\fR files:
.RS 0
.IP \(bu 4
Blank lines or lines starting with \fB#\fR are ignored.
.IP \(bu 4
Standard glob patterns work.
.IP \(bu 4
You can end patterns with a forward slash \fB/\fR to specify a directory.
.IP \(bu 4
You can negate a pattern by starting it with an exclamation point \fB!\fR.
.RE 0

.P
By default, the following paths and files are ignored, so there's no need to add them to \fB.npmignore\fR explicitly:
.RS 0
.IP \(bu 4
\fB.*.swp\fR
.IP \(bu 4
\fB._*\fR
.IP \(bu 4
\fB.DS_Store\fR
.IP \(bu 4
\fB.git\fR
.IP \(bu 4
\fB.gitignore\fR
.IP \(bu 4
\fB.hg\fR
.IP \(bu 4
\fB.npmignore\fR
.IP \(bu 4
\fB.npmrc\fR
.IP \(bu 4
\fB.lock-wscript\fR
.IP \(bu 4
\fB.svn\fR
.IP \(bu 4
\fB.wafpickle-*\fR
.IP \(bu 4
\fBconfig.gypi\fR
.IP \(bu 4
\fBCVS\fR
.IP \(bu 4
\fBnpm-debug.log\fR
.RE 0

.P
Additionally, everything in \fBnode_modules\fR is ignored, except for bundled dependencies. npm automatically handles this for you, so don't bother adding \fBnode_modules\fR to \fB.npmignore\fR.
.P
The following paths and files are never ignored, so adding them to \fB.npmignore\fR is pointless:
.RS 0
.IP \(bu 4
\fBpackage.json\fR
.IP \(bu 4
\fBREADME\fR (and its variants)
.IP \(bu 4
\fBCHANGELOG\fR (and its variants)
.IP \(bu 4
\fBLICENSE\fR / \fBLICENCE\fR
.RE 0

.P
If, given the structure of your project, you find \fB.npmignore\fR to be a maintenance headache, you might instead try populating the \fBfiles\fR property of \fBpackage.json\fR, which is an array of file or directory names that should be included in your package. Sometimes manually picking which items to allow is easier to manage than building a block list.
.SS "Testing whether your \fB.npmignore\fR or \fBfiles\fR config works"
.P
If you want to double check that your package will include only the files you intend it to when published, you can run the \fBnpm pack\fR command locally which will generate a tarball in the working directory, the same way it does for publishing.
.SS "Link Packages"
.P
\fBnpm link\fR is designed to install a development package and see the changes in real time without having to keep re-installing it. (You do need to either re-link or \fBnpm rebuild -g\fR to update compiled packages, of course.)
.P
More info at npm help link.
.SS "Before Publishing: Make Sure Your Package Installs and Works"
.P
\fBThis is important.\fR
.P
If you can not install it locally, you'll have problems trying to publish it. Or, worse yet, you'll be able to publish it, but you'll be publishing a broken or pointless package. So don't do that.
.P
In the root of your package, do this:
.P
.RS 2
.nf
npm install . -g
.fi
.RE
.P
That'll show you that it's working. If you'd rather just create a symlink package that points to your working directory, then do this:
.P
.RS 2
.nf
npm link
.fi
.RE
.P
Use \fBnpm ls -g\fR to see if it's there.
.P
To test a local install, go into some other folder, and then do:
.P
.RS 2
.nf
cd ../some-other-folder
npm install ../my-package
.fi
.RE
.P
to install it locally into the node_modules folder in that other place.
.P
Then go into the node-repl, and try using require("my-thing") to bring in your module's main module.
.SS "Create a User Account"
.P
Create a user with the adduser command. It works like this:
.P
.RS 2
.nf
npm adduser
.fi
.RE
.P
and then follow the prompts.
.P
This is documented better in npm help adduser.
.SS "Publish your Package"
.P
This part's easy. In the root of your folder, do this:
.P
.RS 2
.nf
npm publish
.fi
.RE
.P
You can give publish a url to a tarball, or a filename of a tarball, or a path to a folder.
.P
Note that pretty much \fBeverything in that folder will be exposed\fR by default. So, if you have secret stuff in there, use a \fB.npmignore\fR file to list out the globs to ignore, or publish from a fresh checkout.
.SS "Brag about it"
.P
Send emails, write blogs, blab in IRC.
.P
Tell the world how easy it is to install your program!
.SS "See also"
.RS 0
.IP \(bu 4
npm help npm
.IP \(bu 4
npm help init
.IP \(bu 4
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
.IP \(bu 4
npm help scripts
.IP \(bu 4
npm help publish
.IP \(bu 4
npm help adduser
.IP \(bu 4
npm help registry
.RE 0
PK�~�\�N?"
"
man7/orgs.7nu�[���.TH "ORGS" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBorgs\fR - Working with Teams & Orgs
.SS "Description"
.P
There are three levels of org users:
.RS 0
.IP 1. 4
Super admin, controls billing & adding people to the org.
.IP 2. 4
Team admin, manages team membership & package access.
.IP 3. 4
Developer, works on packages they are given access to.
.RE 0

.P
The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a \fBdevelopers\fR team that all users are automatically added to.
.P
The team admin is the person who manages team creation, team membership, and package access for teams. The team admin grants package access to teams, not individuals.
.P
The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only.
.P
There are two main commands:
.RS 0
.IP 1. 4
\fBnpm team\fR see npm help team for more details
.IP 2. 4
\fBnpm access\fR see npm help access for more details
.RE 0

.SS "Team Admins create teams"
.RS 0
.IP \(bu 4
Check who you\[cq]ve added to your org:
.RE 0

.P
.RS 2
.nf
npm team ls <org>:developers
.fi
.RE
.RS 0
.IP \(bu 4
Each org is automatically given a \fBdevelopers\fR team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the \fBaccess\fR command.
.IP \(bu 4
Create a new team:
.RE 0

.P
.RS 2
.nf
npm team create <org:team>
.fi
.RE
.RS 0
.IP \(bu 4
Add members to that team:
.RE 0

.P
.RS 2
.nf
npm team add <org:team> <user>
.fi
.RE
.SS "Publish a package and adjust package access"
.RS 0
.IP \(bu 4
In package directory, run
.RE 0

.P
.RS 2
.nf
npm init --scope=<org>
.fi
.RE
.P
to scope it for your org & publish as usual
.RS 0
.IP \(bu 4
Grant access:
.RE 0

.P
.RS 2
.nf
npm access grant <read-only|read-write> <org:team> \[lB]<package>\[rB]
.fi
.RE
.RS 0
.IP \(bu 4
Revoke access:
.RE 0

.P
.RS 2
.nf
npm access revoke <org:team> \[lB]<package>\[rB]
.fi
.RE
.SS "Monitor your package access"
.RS 0
.IP \(bu 4
See what org packages a team member can access:
.RE 0

.P
.RS 2
.nf
npm access ls-packages <org> <user>
.fi
.RE
.RS 0
.IP \(bu 4
See packages available to a specific team:
.RE 0

.P
.RS 2
.nf
npm access ls-packages <org:team>
.fi
.RE
.RS 0
.IP \(bu 4
Check which teams are collaborating on a package:
.RE 0

.P
.RS 2
.nf
npm access ls-collaborators <pkg>
.fi
.RE
.SS "See also"
.RS 0
.IP \(bu 4
npm help team
.IP \(bu 4
npm help access
.IP \(bu 4
npm help scope
.RE 0
PK�~�\����man7/removal.7nu�[���.TH "REMOVAL" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBremoval\fR - Cleaning the Slate
.SS "Synopsis"
.P
So sad to see you go.
.P
.RS 2
.nf
sudo npm uninstall npm -g
.fi
.RE
.P
Or, if that fails, please proceed to more severe uninstalling methods.
.SS "More Severe Uninstalling"
.P
Usually, the above instructions are sufficient. That will remove npm, but leave behind anything you've installed.
.P
If that doesn't work, or if you require more drastic measures, continue reading.
.P
Note that this is only necessary for globally-installed packages. Local installs are completely contained within a project's \fBnode_modules\fR folder. Delete that folder, and everything is gone unless a package's install script is particularly ill-behaved.
.P
This assumes that you installed node and npm in the default place. If you configured node with a different \fB--prefix\fR, or installed npm with a different prefix setting, then adjust the paths accordingly, replacing \fB/usr/local\fR with your install prefix.
.P
To remove everything npm-related manually:
.P
.RS 2
.nf
rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
.fi
.RE
.P
If you installed things \fIwith\fR npm, then your best bet is to uninstall them with npm first, and then install them again once you have a proper install. This can help find any symlinks that are lying around:
.P
.RS 2
.nf
ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
.fi
.RE
.P
Prior to version 0.3, npm used shim files for executables and node modules. To track those down, you can do the following:
.P
.RS 2
.nf
find /usr/local/{lib/node,bin} -exec grep -l npm \[rs]{\[rs]} \[rs]; ;
.fi
.RE
.SS "See also"
.RS 0
.IP \(bu 4
npm help uninstall
.IP \(bu 4
npm help prune
.RE 0
PK�~�\0cKO�O�
man7/config.7nu�[���.TH "CONFIG" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBconfig\fR - More than you probably want to know about npm configuration
.SS "Description"
.P
This article details npm configuration in general. To learn about the \fBconfig\fR command, see npm help config.
.P
npm gets its configuration values from the following sources, sorted by priority:
.SS "Command Line Flags"
.P
Putting \fB--foo bar\fR on the command line sets the \fBfoo\fR configuration parameter to \fB"bar"\fR. A \fB--\fR argument tells the cli parser to stop reading flags. Using \fB--flag\fR without specifying any value will set the value to \fBtrue\fR.
.P
Example: \fB--flag1 --flag2\fR will set both configuration parameters to \fBtrue\fR, while \fB--flag1 --flag2 bar\fR will set \fBflag1\fR to \fBtrue\fR, and \fBflag2\fR to \fBbar\fR. Finally, \fB--flag1 --flag2 -- bar\fR will set both configuration parameters to \fBtrue\fR, and the \fBbar\fR is taken as a command argument.
.SS "Environment Variables"
.P
Any environment variables that start with \fBnpm_config_\fR will be interpreted as a configuration parameter. For example, putting \fBnpm_config_foo=bar\fR in your environment will set the \fBfoo\fR configuration parameter to \fBbar\fR. Any environment configurations that are not given a value will be given the value of \fBtrue\fR. Config values are case-insensitive, so \fBNPM_CONFIG_FOO=bar\fR will work the same. However, please note that inside npm help scripts npm will set its own environment variables and Node will prefer those lowercase versions over any uppercase ones that you might set. For details see \fBthis issue\fR \fI\(lahttps://github.com/npm/npm/issues/14528\(ra\fR.
.P
Notice that you need to use underscores instead of dashes, so \fB--allow-same-version\fR would become \fBnpm_config_allow_same_version=true\fR.
.SS "npmrc Files"
.P
The four relevant files are:
.RS 0
.IP \(bu 4
per-project configuration file (\fB/path/to/my/project/.npmrc\fR)
.IP \(bu 4
per-user configuration file (defaults to \fB$HOME/.npmrc\fR; configurable via CLI option \fB--userconfig\fR or environment variable \fB$NPM_CONFIG_USERCONFIG\fR)
.IP \(bu 4
global configuration file (defaults to \fB$PREFIX/etc/npmrc\fR; configurable via CLI option \fB--globalconfig\fR or environment variable \fB$NPM_CONFIG_GLOBALCONFIG\fR)
.IP \(bu 4
npm's built-in configuration file (\fB/path/to/npm/npmrc\fR)
.RE 0

.P
See npm help npmrc for more details.
.SS "Default Configs"
.P
Run \fBnpm config ls -l\fR to see a set of configuration parameters that are internal to npm, and are defaults if nothing else is specified.
.SS "Shorthands and Other CLI Niceties"
.P
The following shorthands are parsed on the command-line:
.RS 0
.IP \(bu 4
\fB-a\fR: \fB--all\fR
.IP \(bu 4
\fB--enjoy-by\fR: \fB--before\fR
.IP \(bu 4
\fB-c\fR: \fB--call\fR
.IP \(bu 4
\fB--desc\fR: \fB--description\fR
.IP \(bu 4
\fB-f\fR: \fB--force\fR
.IP \(bu 4
\fB-g\fR: \fB--global\fR
.IP \(bu 4
\fB--iwr\fR: \fB--include-workspace-root\fR
.IP \(bu 4
\fB-L\fR: \fB--location\fR
.IP \(bu 4
\fB-d\fR: \fB--loglevel info\fR
.IP \(bu 4
\fB-s\fR: \fB--loglevel silent\fR
.IP \(bu 4
\fB--silent\fR: \fB--loglevel silent\fR
.IP \(bu 4
\fB--ddd\fR: \fB--loglevel silly\fR
.IP \(bu 4
\fB--dd\fR: \fB--loglevel verbose\fR
.IP \(bu 4
\fB--verbose\fR: \fB--loglevel verbose\fR
.IP \(bu 4
\fB-q\fR: \fB--loglevel warn\fR
.IP \(bu 4
\fB--quiet\fR: \fB--loglevel warn\fR
.IP \(bu 4
\fB-l\fR: \fB--long\fR
.IP \(bu 4
\fB-m\fR: \fB--message\fR
.IP \(bu 4
\fB--local\fR: \fB--no-global\fR
.IP \(bu 4
\fB-n\fR: \fB--no-yes\fR
.IP \(bu 4
\fB--no\fR: \fB--no-yes\fR
.IP \(bu 4
\fB-p\fR: \fB--parseable\fR
.IP \(bu 4
\fB--porcelain\fR: \fB--parseable\fR
.IP \(bu 4
\fB-C\fR: \fB--prefix\fR
.IP \(bu 4
\fB--readonly\fR: \fB--read-only\fR
.IP \(bu 4
\fB--reg\fR: \fB--registry\fR
.IP \(bu 4
\fB-S\fR: \fB--save\fR
.IP \(bu 4
\fB-B\fR: \fB--save-bundle\fR
.IP \(bu 4
\fB-D\fR: \fB--save-dev\fR
.IP \(bu 4
\fB-E\fR: \fB--save-exact\fR
.IP \(bu 4
\fB-O\fR: \fB--save-optional\fR
.IP \(bu 4
\fB-P\fR: \fB--save-prod\fR
.IP \(bu 4
\fB-?\fR: \fB--usage\fR
.IP \(bu 4
\fB-h\fR: \fB--usage\fR
.IP \(bu 4
\fB-H\fR: \fB--usage\fR
.IP \(bu 4
\fB--help\fR: \fB--usage\fR
.IP \(bu 4
\fB-v\fR: \fB--version\fR
.IP \(bu 4
\fB-w\fR: \fB--workspace\fR
.IP \(bu 4
\fB--ws\fR: \fB--workspaces\fR
.IP \(bu 4
\fB-y\fR: \fB--yes\fR
.RE 0

.P
If the specified configuration param resolves unambiguously to a known configuration parameter, then it is expanded to that configuration parameter. For example:
.P
.RS 2
.nf
npm ls --par
# same as:
npm ls --parseable
.fi
.RE
.P
If multiple single-character shorthands are strung together, and the resulting combination is unambiguously not some other configuration param, then it is expanded to its various component pieces. For example:
.P
.RS 2
.nf
npm ls -gpld
# same as:
npm ls --global --parseable --long --loglevel info
.fi
.RE
.SS "Config Settings"
.SS "\fB_auth\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String
.RE 0

.P
A basic-auth string to use when authenticating against the npm registry. This will ONLY be used to authenticate against the npm registry. For other registries you will need to scope it like "//other-registry.tld/:_auth"
.P
Warning: This should generally not be set via a command-line option. It is safer to use a registry-provided authentication bearer token stored in the ~/.npmrc file by running \fBnpm login\fR.
.SS "\fBaccess\fR"
.RS 0
.IP \(bu 4
Default: 'public' for new packages, existing packages it will not change the current level
.IP \(bu 4
Type: null, "restricted", or "public"
.RE 0

.P
If you do not want your scoped package to be publicly viewable (and installable) set \fB--access=restricted\fR.
.P
Unscoped packages can not be set to \fBrestricted\fR.
.P
Note: This defaults to not changing the current access level for existing packages. Specifying a value of \fBrestricted\fR or \fBpublic\fR during publish will change the access for an existing package the same way that \fBnpm access set
status\fR would.
.SS "\fBall\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
When running \fBnpm outdated\fR and \fBnpm ls\fR, setting \fB--all\fR will show all outdated or installed packages, rather than only those directly depended upon by the current project.
.SS "\fBallow-same-version\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Prevents throwing an error when \fBnpm version\fR is used to set the new version to the same value as the current version.
.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 "\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 "\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 "\fBbefore\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or Date
.RE 0

.P
If passed to \fBnpm install\fR, will rebuild the npm tree such that only versions that were available \fBon or before\fR the \fB--before\fR time get installed. If there's no versions available for the current set of direct dependencies, the command will error.
.P
If the requested version is a \fBdist-tag\fR and the given tag does not pass the \fB--before\fR filter, the most recent version less than or equal to that tag will be used. For example, \fBfoo@latest\fR might install \fBfoo@1.2\fR even though \fBlatest\fR is \fB2.0\fR.
.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 "\fBbrowser\fR"
.RS 0
.IP \(bu 4
Default: OS X: \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 "\fBca\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String (can be set multiple times)
.RE 0

.P
The Certificate Authority signing certificate that is trusted for SSL connections to the registry. Values should be in PEM format (Windows calls it "Base-64 encoded X.509 (.CER)") with newlines replaced by the string "\[rs]n". For example:
.P
.RS 2
.nf
ca="-----BEGIN CERTIFICATE-----\[rs]nXXXX\[rs]nXXXX\[rs]n-----END CERTIFICATE-----"
.fi
.RE
.P
Set to \fBnull\fR to only allow "known" registrars, or to a specific CA cert to trust only that specific signing authority.
.P
Multiple CAs can be trusted by specifying an array of certificates:
.P
.RS 2
.nf
ca\[lB]\[rB]="..."
ca\[lB]\[rB]="..."
.fi
.RE
.P
See also the \fBstrict-ssl\fR config.
.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 "\fBcafile\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: Path
.RE 0

.P
A path to a file containing one or multiple Certificate Authority signing certificates. Similar to the \fBca\fR setting, but allows for multiple CA's, as well as for the CA information to be stored in a file on disk.
.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 "\fBcidr\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String (can be set multiple times)
.RE 0

.P
This is a list of CIDR address to be used when configuring limited access tokens with the \fBnpm token create\fR command.
.SS "\fBcolor\fR"
.RS 0
.IP \(bu 4
Default: true unless the NO_COLOR environ is set to something other than '0'
.IP \(bu 4
Type: "always" or Boolean
.RE 0

.P
If false, never shows colors. If \fB"always"\fR then always shows colors. If true, then only prints color codes for tty file descriptors.
.SS "\fBcommit-hooks\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.RE 0

.P
Run git commit hooks when using the \fBnpm version\fR command.
.SS "\fBcpu\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String
.RE 0

.P
Override CPU architecture of native modules to install. Acceptable values are same as \fBcpu\fR field of package.json, which comes from \fBprocess.arch\fR.
.SS "\fBdepth\fR"
.RS 0
.IP \(bu 4
Default: \fBInfinity\fR if \fB--all\fR is set, otherwise \fB1\fR
.IP \(bu 4
Type: null or Number
.RE 0

.P
The depth to go when recursing packages for \fBnpm ls\fR.
.P
If not set, \fBnpm ls\fR will show only the immediate dependencies of the root project. If \fB--all\fR is set, then npm will show all dependencies by default.
.SS "\fBdescription\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.RE 0

.P
Show the description in \fBnpm search\fR
.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-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-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-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-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-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 "\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 "\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 "\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 "\fBengine-strict\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If set to true, then npm will stubbornly refuse to install (or even consider installing) any package that claims to not be compatible with the current Node.js version.
.P
This can be overridden by setting the \fB--force\fR flag.
.SS "\fBexpect-result-count\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or Number
.RE 0

.P
Tells to expect a specific number of results from the command.
.P
This config can not be used with: \fBexpect-results\fR
.SS "\fBexpect-results\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or Boolean
.RE 0

.P
Tells npm whether or not to expect results from the command. Can be either true (expect some results) or false (expect no results).
.P
This config can not be used with: \fBexpect-result-count\fR
.SS "\fBfetch-retries\fR"
.RS 0
.IP \(bu 4
Default: 2
.IP \(bu 4
Type: Number
.RE 0

.P
The "retries" config for the \fBretry\fR module to use when fetching packages from the registry.
.P
npm will retry idempotent read requests to the registry in the case of network failures or 5xx HTTP errors.
.SS "\fBfetch-retry-factor\fR"
.RS 0
.IP \(bu 4
Default: 10
.IP \(bu 4
Type: Number
.RE 0

.P
The "factor" config for the \fBretry\fR module to use when fetching packages.
.SS "\fBfetch-retry-maxtimeout\fR"
.RS 0
.IP \(bu 4
Default: 60000 (1 minute)
.IP \(bu 4
Type: Number
.RE 0

.P
The "maxTimeout" config for the \fBretry\fR module to use when fetching packages.
.SS "\fBfetch-retry-mintimeout\fR"
.RS 0
.IP \(bu 4
Default: 10000 (10 seconds)
.IP \(bu 4
Type: Number
.RE 0

.P
The "minTimeout" config for the \fBretry\fR module to use when fetching packages.
.SS "\fBfetch-timeout\fR"
.RS 0
.IP \(bu 4
Default: 300000 (5 minutes)
.IP \(bu 4
Type: Number
.RE 0

.P
The maximum amount of time to wait for HTTP requests to complete.
.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 "\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 "\fBformat-package-lock\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.RE 0

.P
Format \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR as a human readable file.
.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 "\fBgit\fR"
.RS 0
.IP \(bu 4
Default: "git"
.IP \(bu 4
Type: String
.RE 0

.P
The command to use for git commands. If git is installed on the computer, but is not in the \fBPATH\fR, then set this to the full path to the git binary.
.SS "\fBgit-tag-version\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.RE 0

.P
Tag the commit when using the \fBnpm version\fR command. Setting this to false results in no commit being made at all.
.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 "\fBglobalconfig\fR"
.RS 0
.IP \(bu 4
Default: The global --prefix setting plus 'etc/npmrc'. For example, '/usr/local/etc/npmrc'
.IP \(bu 4
Type: Path
.RE 0

.P
The config file to read for global config options.
.SS "\fBheading\fR"
.RS 0
.IP \(bu 4
Default: "npm"
.IP \(bu 4
Type: String
.RE 0

.P
The string that starts all the debugging log output.
.SS "\fBhttps-proxy\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or URL
.RE 0

.P
A proxy to use for outgoing https requests. If the \fBHTTPS_PROXY\fR or \fBhttps_proxy\fR or \fBHTTP_PROXY\fR or \fBhttp_proxy\fR environment variables are set, proxy settings will be honored by the underlying \fBmake-fetch-happen\fR library.
.SS "\fBif-present\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If true, npm will not exit with an error code when \fBrun-script\fR is invoked for a script that isn't defined in the \fBscripts\fR section of \fBpackage.json\fR. This option can be used when it's desirable to optionally run a script when it's present and fail if the script fails. This is useful, for example, when running scripts that may only apply for some builds in an otherwise generic CI setup.
.P
This value is not exported to the environment for child processes.
.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-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
.SS "\fBinclude\fR"
.RS 0
.IP \(bu 4
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 "\fBinclude-staged\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Allow installing "staged" published packages, as defined by \fBnpm RFC PR #92\fR \fI\(lahttps://github.com/npm/rfcs/pull/92\(ra\fR.
.P
This is experimental, and not implemented by the npm public registry.
.SS "\fBinclude-workspace-root\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
The value \fBnpm init\fR should use by default for the package author's email.
.SS "\fBinit-author-name\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: String
.RE 0

.P
The value \fBnpm init\fR should use by default for the package author's name.
.SS "\fBinit-author-url\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: "" or URL
.RE 0

.P
The value \fBnpm init\fR should use by default for the package author's homepage.
.SS "\fBinit-license\fR"
.RS 0
.IP \(bu 4
Default: "ISC"
.IP \(bu 4
Type: String
.RE 0

.P
The value \fBnpm init\fR should use by default for the package license.
.SS "\fBinit-module\fR"
.RS 0
.IP \(bu 4
Default: "~/.npm-init.js"
.IP \(bu 4
Type: Path
.RE 0

.P
A module that will be loaded by the \fBnpm init\fR command. See the documentation for the \fBinit-package-json\fR \fI\(lahttps://github.com/npm/init-package-json\(ra\fR module for more information, or npm help init.
.SS "\fBinit-version\fR"
.RS 0
.IP \(bu 4
Default: "1.0.0"
.IP \(bu 4
Type: SemVer string
.RE 0

.P
The value that \fBnpm init\fR should use by default for the package version number, if not already set in package.json.
.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 "\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 "\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 "\fBlegacy-peer-deps\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Causes npm to completely ignore \fBpeerDependencies\fR when building a package tree, as in npm versions 3 through 6.
.P
If a package cannot be installed because of overly strict \fBpeerDependencies\fR that collide, it provides a way to move forward resolving the situation.
.P
This differs from \fB--omit=peer\fR, in that \fB--omit=peer\fR will avoid unpacking \fBpeerDependencies\fR on disk, but will still design a tree such that \fBpeerDependencies\fR \fIcould\fR be unpacked in a correct place.
.P
Use of \fBlegacy-peer-deps\fR is not recommended, as it will not enforce the \fBpeerDependencies\fR contract that meta-dependencies may rely on.
.SS "\fBlibc\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String
.RE 0

.P
Override libc of native modules to install. Acceptable values are same as \fBlibc\fR field of package.json
.SS "\fBlink\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Used with \fBnpm ls\fR, limiting output to only those packages that are linked.
.SS "\fBlocal-address\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: IP Address
.RE 0

.P
The IP address of the local interface to use when making connections to the npm registry. Must be IPv4 in versions of Node prior to 0.12.
.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 "\fBlockfile-version\fR"
.RS 0
.IP \(bu 4
Default: Version 3 if no lockfile, auto-converting v1 lockfiles to v3, otherwise maintain current lockfile version.
.IP \(bu 4
Type: null, 1, 2, 3, "1", "2", or "3"
.RE 0

.P
Set the lockfile format version to be used in package-lock.json and npm-shrinkwrap-json files. Possible options are:
.P
1: The lockfile version used by npm versions 5 and 6. Lacks some data that is used during the install, resulting in slower and possibly less deterministic installs. Prevents lockfile churn when interoperating with older npm versions.
.P
2: The default lockfile version used by npm version 7 and 8. Includes both the version 1 lockfile data and version 3 lockfile data, for maximum determinism and interoperability, at the expense of more bytes on disk.
.P
3: Only the new lockfile information introduced in npm version 7. Smaller on disk than lockfile version 2, but not interoperable with older npm versions. Ideal if all users are on npm version 7 and higher.
.SS "\fBloglevel\fR"
.RS 0
.IP \(bu 4
Default: "notice"
.IP \(bu 4
Type: "silent", "error", "warn", "notice", "http", "info", "verbose", or "silly"
.RE 0

.P
What level of logs to report. All logs are written to a debug log, with the path to that file printed if the execution of a command fails.
.P
Any logs of a higher level than the setting are shown. The default is "notice".
.P
See also the \fBforeground-scripts\fR config.
.SS "\fBlogs-dir\fR"
.RS 0
.IP \(bu 4
Default: A directory named \fB_logs\fR inside the cache
.IP \(bu 4
Type: null or Path
.RE 0

.P
The location of npm's log directory. See npm help logging for more information.
.SS "\fBlogs-max\fR"
.RS 0
.IP \(bu 4
Default: 10
.IP \(bu 4
Type: Number
.RE 0

.P
The maximum number of log files to store.
.P
If set to 0, no log files will be written for the current run.
.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 "\fBmaxsockets\fR"
.RS 0
.IP \(bu 4
Default: 15
.IP \(bu 4
Type: Number
.RE 0

.P
The maximum number of connections to use per origin (protocol/host/port combination).
.SS "\fBmessage\fR"
.RS 0
.IP \(bu 4
Default: "%s"
.IP \(bu 4
Type: String
.RE 0

.P
Commit message which is used by \fBnpm version\fR when creating version commit.
.P
Any "%s" in the message will be replaced with the version number.
.SS "\fBnode-options\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String
.RE 0

.P
Options to pass through to Node.js via the \fBNODE_OPTIONS\fR environment variable. This does not impact how npm itself is executed but it does impact how lifecycle scripts are called.
.SS "\fBnoproxy\fR"
.RS 0
.IP \(bu 4
Default: The value of the NO_PROXY environment variable
.IP \(bu 4
Type: String (can be set multiple times)
.RE 0

.P
Domain extensions that should bypass any proxies.
.P
Also accepts a comma-delimited string.
.SS "\fBoffline\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Force offline mode: no network requests will be done during install. To allow the CLI to fill in missing cache data, see \fB--prefer-offline\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 "\fBomit-lockfile-registry-resolved\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
This option causes npm to create lock files without a \fBresolved\fR key for registry dependencies. Subsequent installs will need to resolve tarball endpoints with the configured registry, likely resulting in a longer install time.
.SS "\fBos\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String
.RE 0

.P
Override OS of native modules to install. Acceptable values are same as \fBos\fR field of package.json, which comes from \fBprocess.platform\fR.
.SS "\fBotp\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String
.RE 0

.P
Directory in which \fBnpm pack\fR will save tarballs.
.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 "\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 "\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 "\fBparseable\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
.SS "\fBprefer-dedupe\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Prefer to deduplicate packages if possible, rather than choosing a newer version of a dependency.
.SS "\fBprefer-offline\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If true, staleness checks for cached data will be bypassed, but missing data will be requested from the server. To force full offline mode, use \fB--offline\fR.
.SS "\fBprefer-online\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If true, staleness checks for cached data will be forced, making the CLI look for updates immediately even for fresh package data.
.SS "\fBprefix\fR"
.RS 0
.IP \(bu 4
Default: In global mode, the folder where the node executable is installed. Otherwise, the nearest parent folder containing either a package.json file or a node_modules folder.
.IP \(bu 4
Type: Path
.RE 0

.P
The location to install global items. If set on the command line, then it forces non-global commands to run in the specified folder.
.SS "\fBpreid\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: String
.RE 0

.P
The "prerelease identifier" to use as a prefix for the "prerelease" part of a semver. Like the \fBrc\fR in \fB1.2.0-rc.8\fR.
.SS "\fBprogress\fR"
.RS 0
.IP \(bu 4
Default: \fBtrue\fR unless running in a known CI system
.IP \(bu 4
Type: Boolean
.RE 0

.P
When set to \fBtrue\fR, npm will display a progress bar during time intensive operations, if \fBprocess.stderr\fR and \fBprocess.stdout\fR are a TTY.
.P
Set to \fBfalse\fR to suppress the progress bar.
.SS "\fBprovenance\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
When publishing from a supported cloud CI/CD system, the package will be publicly linked to where it was built and published from.
.P
This config can not be used with: \fBprovenance-file\fR
.SS "\fBprovenance-file\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: Path
.RE 0

.P
When publishing, the provenance bundle at the given path will be used.
.P
This config can not be used with: \fBprovenance\fR
.SS "\fBproxy\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null, false, or URL
.RE 0

.P
A proxy to use for outgoing http requests. If the \fBHTTP_PROXY\fR or \fBhttp_proxy\fR environment variables are set, proxy settings will be honored by the underlying \fBrequest\fR library.
.SS "\fBread-only\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
This is used to mark a token as unable to publish when configuring limited access tokens with the \fBnpm token create\fR command.
.SS "\fBrebuild-bundle\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.RE 0

.P
Rebuild bundled dependencies after installation.
.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 "\fBreplace-registry-host\fR"
.RS 0
.IP \(bu 4
Default: "npmjs"
.IP \(bu 4
Type: "npmjs", "never", "always", or String
.RE 0

.P
Defines behavior for replacing the registry host in a lockfile with the configured registry.
.P
The default behavior is to replace package dist URLs from the default registry (https://registry.npmjs.org) to the configured registry. If set to "never", then use the registry value. If set to "always", then replace the registry host with the configured host every time.
.P
You may also specify a bare hostname (e.g., "registry.npmjs.org").
.SS "\fBsave\fR"
.RS 0
.IP \(bu 4
Default: \fBtrue\fR unless when using \fBnpm update\fR where it defaults to \fBfalse\fR
.IP \(bu 4
Type: Boolean
.RE 0

.P
Save installed packages to a \fBpackage.json\fR file as dependencies.
.P
When used with the \fBnpm rm\fR command, removes the dependency from \fBpackage.json\fR.
.P
Will also prevent writing to \fBpackage-lock.json\fR if set to \fBfalse\fR.
.SS "\fBsave-bundle\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If a package would be saved at install time by the use of \fB--save\fR, \fB--save-dev\fR, or \fB--save-optional\fR, then also put it in the \fBbundleDependencies\fR list.
.P
Ignored if \fB--save-peer\fR is set, since peerDependencies cannot be bundled.
.SS "\fBsave-dev\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Save installed packages to a package.json file as \fBdevDependencies\fR.
.SS "\fBsave-exact\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
.SS "\fBsave-optional\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Save installed packages to a package.json file as \fBoptionalDependencies\fR.
.SS "\fBsave-peer\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Save installed packages to a package.json file as \fBpeerDependencies\fR
.SS "\fBsave-prefix\fR"
.RS 0
.IP \(bu 4
Default: "^"
.IP \(bu 4
Type: String
.RE 0

.P
Configure how versions of packages installed to a package.json file via \fB--save\fR or \fB--save-dev\fR get prefixed.
.P
For example if a package has version \fB1.2.3\fR, by default its version is set to \fB^1.2.3\fR which allows minor upgrades for that package, but after \fBnpm
config set save-prefix='~'\fR it would be set to \fB~1.2.3\fR which only allows patch upgrades.
.SS "\fBsave-prod\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Save installed packages into \fBdependencies\fR specifically. This is useful if a package already exists in \fBdevDependencies\fR or \fBoptionalDependencies\fR, but you want to move it to be a non-optional production dependency.
.P
This is the default behavior if \fB--save\fR is true, and neither \fB--save-dev\fR or \fB--save-optional\fR are true.
.SS "\fBsbom-format\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: "cyclonedx" or "spdx"
.RE 0

.P
SBOM format to use when generating SBOMs.
.SS "\fBsbom-type\fR"
.RS 0
.IP \(bu 4
Default: "library"
.IP \(bu 4
Type: "library", "application", or "framework"
.RE 0

.P
The type of package described by the generated SBOM. For SPDX, this is the value for the \fBprimaryPackagePurpose\fR field. For CycloneDX, this is the value for the \fBtype\fR field.
.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 "\fBscript-shell\fR"
.RS 0
.IP \(bu 4
Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
.IP \(bu 4
Type: null or String
.RE 0

.P
The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm
init <package-spec>\fR commands.
.SS "\fBsearchexclude\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: String
.RE 0

.P
Space-separated options that limit the results from search.
.SS "\fBsearchlimit\fR"
.RS 0
.IP \(bu 4
Default: 20
.IP \(bu 4
Type: Number
.RE 0

.P
Number of items to limit search results to. Will not apply at all to legacy searches.
.SS "\fBsearchopts\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: String
.RE 0

.P
Space-separated options that are always passed to search.
.SS "\fBsearchstaleness\fR"
.RS 0
.IP \(bu 4
Default: 900
.IP \(bu 4
Type: Number
.RE 0

.P
The age of the cache, in seconds, before another registry request is made if using legacy search endpoint.
.SS "\fBshell\fR"
.RS 0
.IP \(bu 4
Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" on Windows
.IP \(bu 4
Type: String
.RE 0

.P
The shell to run for the \fBnpm explore\fR command.
.SS "\fBsign-git-commit\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If set to true, then the \fBnpm version\fR command will commit the new package version using \fB-S\fR to add a signature.
.P
Note that git requires you to have set up GPG keys in your git configs for this to work properly.
.SS "\fBsign-git-tag\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If set to true, then the \fBnpm version\fR command will tag the version using \fB-s\fR to add a signature.
.P
Note that git requires you to have set up GPG keys in your git configs for this to work properly.
.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 "\fBstrict-ssl\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.RE 0

.P
Whether or not to do SSL key validation when making requests to the registry via https.
.P
See also the \fBca\fR config.
.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 "\fBtag-version-prefix\fR"
.RS 0
.IP \(bu 4
Default: "v"
.IP \(bu 4
Type: String
.RE 0

.P
If set, alters the prefix used when tagging a new version when performing a version increment using \fBnpm version\fR. To remove the prefix altogether, set it to the empty string: \fB""\fR.
.P
Because other tools may rely on the convention that npm version tags look like \fBv1.0.0\fR, \fIonly use this property if it is absolutely necessary\fR. In particular, use care when overriding this setting for public packages.
.SS "\fBtiming\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If true, writes timing information to a process specific json file in the cache or \fBlogs-dir\fR. The file name ends with \fB-timing.json\fR.
.P
You can quickly view it with this \fBjson\fR \fI\(lahttps://npm.im/json\(ra\fR command line: \fBcat ~/.npm/_logs/*-timing.json | npm exec -- json -g\fR.
.P
Timing information will also be reported in the terminal. To suppress this while still writing the timing file, use \fB--silent\fR.
.SS "\fBumask\fR"
.RS 0
.IP \(bu 4
Default: 0
.IP \(bu 4
Type: Octal numeric string in range 0000..0777 (0..511)
.RE 0

.P
The "umask" value to use when setting the file creation mode on files and folders.
.P
Folders and executables are given a mode which is \fB0o777\fR masked against this value. Other files are given a mode which is \fB0o666\fR masked against this value.
.P
Note that the underlying system will \fIalso\fR apply its own umask value to files and folders that are created, and npm does not circumvent this, but rather adds the \fB--umask\fR config to it.
.P
Thus, the effective default umask value on most POSIX systems is 0o22, meaning that folders and executables are created with a mode of 0o755 and other files are created with a mode of 0o644.
.SS "\fBunicode\fR"
.RS 0
.IP \(bu 4
Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the \fBLC_ALL\fR, \fBLC_CTYPE\fR, or \fBLANG\fR environment variables.
.IP \(bu 4
Type: Boolean
.RE 0

.P
When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
.SS "\fBupdate-notifier\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.RE 0

.P
Set to false to suppress the update notification when using an older version of npm than the latest.
.SS "\fBusage\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Show short usage output about the command specified.
.SS "\fBuser-agent\fR"
.RS 0
.IP \(bu 4
Default: "npm/{npm-version} node/{node-version} {platform} {arch} workspaces/{workspaces} {ci}"
.IP \(bu 4
Type: String
.RE 0

.P
Sets the User-Agent request header. The following fields are replaced with their actual counterparts:
.RS 0
.IP \(bu 4
\fB{npm-version}\fR - The npm version in use
.IP \(bu 4
\fB{node-version}\fR - The Node.js version in use
.IP \(bu 4
\fB{platform}\fR - The value of \fBprocess.platform\fR
.IP \(bu 4
\fB{arch}\fR - The value of \fBprocess.arch\fR
.IP \(bu 4
\fB{workspaces}\fR - Set to \fBtrue\fR if the \fBworkspaces\fR or \fBworkspace\fR options are set.
.IP \(bu 4
\fB{ci}\fR - The value of the \fBci-name\fR config, if set, prefixed with \fBci/\fR, or an empty string if \fBci-name\fR is empty.
.RE 0

.SS "\fBuserconfig\fR"
.RS 0
.IP \(bu 4
Default: "~/.npmrc"
.IP \(bu 4
Type: Path
.RE 0

.P
The location of user-level configuration settings.
.P
This may be overridden by the \fBnpm_config_userconfig\fR environment variable or the \fB--userconfig\fR command line option, but may \fInot\fR be overridden by settings in the \fBglobalconfig\fR file.
.SS "\fBversion\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If true, output the npm version and exit successfully.
.P
Only relevant when specified explicitly on the command line.
.SS "\fBversions\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If true, output the npm version as well as node's \fBprocess.versions\fR map and the version in the current working directory's \fBpackage.json\fR file if one exists, and exit successfully.
.P
Only relevant when specified explicitly on the command line.
.SS "\fBviewer\fR"
.RS 0
.IP \(bu 4
Default: "man" on Posix, "browser" on Windows
.IP \(bu 4
Type: String
.RE 0

.P
The program to use to view help content.
.P
Set to \fB"browser"\fR to view html help content in the default web browser.
.SS "\fBwhich\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or Number
.RE 0

.P
If there are multiple funding sources, which 1-indexed source URL to open.
.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
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 "\fBworkspaces-update\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.RE 0

.P
If set to true, the npm cli will run an update after operations that may possibly change the workspaces installed to the \fBnode_modules\fR folder.
.SS "\fByes\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or Boolean
.RE 0

.P
Automatically answer "yes" to any prompts that npm might print on the command line.
.SS "\fBalso\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null, "dev", or "development"
.IP \(bu 4
DEPRECATED: Please use --include=dev instead.
.RE 0

.P
When set to \fBdev\fR or \fBdevelopment\fR, this is an alias for \fB--include=dev\fR.
.SS "\fBcache-max\fR"
.RS 0
.IP \(bu 4
Default: Infinity
.IP \(bu 4
Type: Number
.IP \(bu 4
DEPRECATED: This option has been deprecated in favor of \fB--prefer-online\fR
.RE 0

.P
\fB--cache-max=0\fR is an alias for \fB--prefer-online\fR
.SS "\fBcache-min\fR"
.RS 0
.IP \(bu 4
Default: 0
.IP \(bu 4
Type: Number
.IP \(bu 4
DEPRECATED: This option has been deprecated in favor of \fB--prefer-offline\fR.
.RE 0

.P
\fB--cache-min=9999 (or bigger)\fR is an alias for \fB--prefer-offline\fR.
.SS "\fBcert\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String
.IP \(bu 4
DEPRECATED: \fBkey\fR and \fBcert\fR are no longer used for most registry operations. Use registry scoped \fBkeyfile\fR and \fBcertfile\fR instead. Example: //other-registry.tld/:keyfile=/path/to/key.pem //other-registry.tld/:certfile=/path/to/cert.crt
.RE 0

.P
A client certificate to pass when accessing the registry. Values should be in PEM format (Windows calls it "Base-64 encoded X.509 (.CER)") with newlines replaced by the string "\[rs]n". For example:
.P
.RS 2
.nf
cert="-----BEGIN CERTIFICATE-----\[rs]nXXXX\[rs]nXXXX\[rs]n-----END CERTIFICATE-----"
.fi
.RE
.P
It is \fInot\fR the path to a certificate file, though you can set a registry-scoped "certfile" path like "//other-registry.tld/:certfile=/path/to/cert.pem".
.SS "\fBdev\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.IP \(bu 4
DEPRECATED: Please use --include=dev instead.
.RE 0

.P
Alias for \fB--include=dev\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 "\fBinit.author.email\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: String
.IP \(bu 4
DEPRECATED: Use \fB--init-author-email\fR instead.
.RE 0

.P
Alias for \fB--init-author-email\fR
.SS "\fBinit.author.name\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: String
.IP \(bu 4
DEPRECATED: Use \fB--init-author-name\fR instead.
.RE 0

.P
Alias for \fB--init-author-name\fR
.SS "\fBinit.author.url\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: "" or URL
.IP \(bu 4
DEPRECATED: Use \fB--init-author-url\fR instead.
.RE 0

.P
Alias for \fB--init-author-url\fR
.SS "\fBinit.license\fR"
.RS 0
.IP \(bu 4
Default: "ISC"
.IP \(bu 4
Type: String
.IP \(bu 4
DEPRECATED: Use \fB--init-license\fR instead.
.RE 0

.P
Alias for \fB--init-license\fR
.SS "\fBinit.module\fR"
.RS 0
.IP \(bu 4
Default: "~/.npm-init.js"
.IP \(bu 4
Type: Path
.IP \(bu 4
DEPRECATED: Use \fB--init-module\fR instead.
.RE 0

.P
Alias for \fB--init-module\fR
.SS "\fBinit.version\fR"
.RS 0
.IP \(bu 4
Default: "1.0.0"
.IP \(bu 4
Type: SemVer string
.IP \(bu 4
DEPRECATED: Use \fB--init-version\fR instead.
.RE 0

.P
Alias for \fB--init-version\fR
.SS "\fBkey\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String
.IP \(bu 4
DEPRECATED: \fBkey\fR and \fBcert\fR are no longer used for most registry operations. Use registry scoped \fBkeyfile\fR and \fBcertfile\fR instead. Example: //other-registry.tld/:keyfile=/path/to/key.pem //other-registry.tld/:certfile=/path/to/cert.crt
.RE 0

.P
A client key to pass when accessing the registry. Values should be in PEM format with newlines replaced by the string "\[rs]n". For example:
.P
.RS 2
.nf
key="-----BEGIN PRIVATE KEY-----\[rs]nXXXX\[rs]nXXXX\[rs]n-----END PRIVATE KEY-----"
.fi
.RE
.P
It is \fInot\fR the path to a key file, though you can set a registry-scoped "keyfile" path like "//other-registry.tld/:keyfile=/path/to/key.pem".
.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 "\fBonly\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null, "prod", or "production"
.IP \(bu 4
DEPRECATED: Use \fB--omit=dev\fR to omit dev dependencies from the install.
.RE 0

.P
When set to \fBprod\fR or \fBproduction\fR, this is an alias for \fB--omit=dev\fR.
.SS "\fBoptional\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or Boolean
.IP \(bu 4
DEPRECATED: Use \fB--omit=optional\fR to exclude optional dependencies, or \fB--include=optional\fR to include them.
.RE 0

.P
Default value does install optional deps unless otherwise omitted.
.P
Alias for --include=optional or --omit=optional
.SS "\fBproduction\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or Boolean
.IP \(bu 4
DEPRECATED: Use \fB--omit=dev\fR instead.
.RE 0

.P
Alias for \fB--omit=dev\fR
.SS "\fBshrinkwrap\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.IP \(bu 4
DEPRECATED: Use the --package-lock setting instead.
.RE 0

.P
Alias for --package-lock
.SS "See also"
.RS 0
.IP \(bu 4
npm help config
.IP \(bu 4
npm help npmrc
.IP \(bu 4
npm help scripts
.IP \(bu 4
npm help folders
.IP \(bu 4
npm help npm
.RE 0
PK�~�\;!���man7/registry.7nu�[���.TH "REGISTRY" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBregistry\fR - The JavaScript Package Registry
.SS "Description"
.P
To resolve packages by name and version, npm talks to a registry website that implements the CommonJS Package Registry specification for reading package info.
.P
npm is configured to use the \fBnpm public registry\fR at \fI\(lahttps://registry.npmjs.org\(ra\fR by default. Use of the npm public registry is subject to terms of use available at \fI\(lahttps://docs.npmjs.com/policies/terms\(ra\fR.
.P
You can configure npm to use any compatible registry you like, and even run your own registry. Use of someone else's registry may be governed by their terms of use.
.P
npm's package registry implementation supports several write APIs as well, to allow for publishing packages and managing user account information.
.P
The npm public registry is powered by a CouchDB database, of which there is a public mirror at \fI\(lahttps://skimdb.npmjs.com/registry\(ra\fR.
.P
The registry URL used is determined by the scope of the package (see npm help scope. If no scope is specified, the default registry is used, which is supplied by the \fB\fBregistry\fR config\fR \fI\(la/using-npm/config#registry\(ra\fR parameter. See npm help config, npm help npmrc, and npm help config for more on managing npm's configuration. Authentication configuration such as auth tokens and certificates are configured specifically scoped to an individual registry. See \fBAuth Related Configuration\fR \fI\(la/configuring-npm/npmrc#auth-related-configuration\(ra\fR
.P
When the default registry is used in a package-lock or shrinkwrap it has the special meaning of "the currently configured registry". If you create a lock file while using the default registry you can switch to another registry and npm will install packages from the new registry, but if you create a lock file while using a custom registry packages will be installed from that registry even after you change to another registry.
.SS "Does npm send any information about me back to the registry?"
.P
Yes.
.P
When making requests of the registry npm adds two headers with information about your environment:
.RS 0
.IP \(bu 4
\fBNpm-Scope\fR \[en] If your project is scoped, this header will contain its scope. In the future npm hopes to build registry features that use this information to allow you to customize your experience for your organization.
.IP \(bu 4
\fBNpm-In-CI\fR \[en] Set to "true" if npm believes this install is running in a continuous integration environment, "false" otherwise. This is detected by looking for the following environment variables: \fBCI\fR, \fBTDDIUM\fR, \fBJENKINS_URL\fR, \fBbamboo.buildKey\fR. If you'd like to learn more you may find the \fBoriginal PR\fR \fI\(lahttps://github.com/npm/npm-registry-client/pull/129\(ra\fR interesting. This is used to gather better metrics on how npm is used by humans, versus build farms.
.RE 0

.P
The npm registry does not try to correlate the information in these headers with any authenticated accounts that may be used in the same requests.
.SS "How can I prevent my package from being published in the official registry?"
.P
Set \fB"private": true\fR in your \fBpackage.json\fR to prevent it from being published at all, or \fB"publishConfig":{"registry":"http://my-internal-registry.local"}\fR to force it to be published only to your internal/private registry.
.P
See \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR for more info on what goes in the package.json file.
.SS "Where can I find my (and others') published packages?"
.P
\fI\(lahttps://www.npmjs.com/\(ra\fR
.SS "See also"
.RS 0
.IP \(bu 4
npm help config
.IP \(bu 4
npm help config
.IP \(bu 4
npm help npmrc
.IP \(bu 4
npm help developers
.RE 0
PK�~�\V#����man7/workspaces.7nu�[���.TH "WORKSPACES" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBworkspaces\fR - Working with workspaces
.SS "Description"
.P
\fBWorkspaces\fR is a generic term that refers to the set of features in the npm cli that provides support for managing multiple packages from your local file system from within a singular top-level, root package.
.P
This set of features makes up for a much more streamlined workflow handling linked packages from the local file system. It automates the linking process as part of \fBnpm install\fR and removes the need to manually use \fBnpm link\fR in order to add references to packages that should be symlinked into the current \fBnode_modules\fR folder.
.P
We also refer to these packages being auto-symlinked during \fBnpm install\fR as a single \fBworkspace\fR, meaning it's a nested package within the current local file system that is explicitly defined in the \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json#workspaces\(ra\fR \fBworkspaces\fR configuration.
.SS "Defining workspaces"
.P
Workspaces are usually defined via the \fBworkspaces\fR property of the \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json#workspaces\(ra\fR file, e.g:
.P
.RS 2
.nf
{
  "name": "my-workspaces-powered-project",
  "workspaces": \[lB]
    "packages/a"
  \[rB]
}
.fi
.RE
.P
Given the above \fBpackage.json\fR example living at a current working directory \fB.\fR that contains a folder named \fBpackages/a\fR that itself contains a \fBpackage.json\fR inside it, defining a Node.js package, e.g:
.P
.RS 2
.nf
.
+-- package.json
`-- packages
   +-- a
   |   `-- package.json
.fi
.RE
.P
The expected result once running \fBnpm install\fR in this current working directory \fB.\fR is that the folder \fBpackages/a\fR will get symlinked to the \fBnode_modules\fR folder of the current working dir.
.P
Below is a post \fBnpm install\fR example, given that same previous example structure of files and folders:
.P
.RS 2
.nf
.
+-- node_modules
|  `-- a -> ../packages/a
+-- package-lock.json
+-- package.json
`-- packages
   +-- a
   |   `-- package.json
.fi
.RE
.SS "Getting started with workspaces"
.P
You may automate the required steps to define a new workspace using npm help init. For example in a project that already has a \fBpackage.json\fR defined you can run:
.P
.RS 2
.nf
npm init -w ./packages/a
.fi
.RE
.P
This command will create the missing folders and a new \fBpackage.json\fR file (if needed) while also making sure to properly configure the \fB"workspaces"\fR property of your root project \fBpackage.json\fR.
.SS "Adding dependencies to a workspace"
.P
It's possible to directly add/remove/update dependencies of your workspaces using the \fB\fBworkspace\fR config\fR \fI\(la/using-npm/config#workspace\(ra\fR.
.P
For example, assuming the following structure:
.P
.RS 2
.nf
.
+-- package.json
`-- packages
   +-- a
   |   `-- package.json
   `-- b
       `-- package.json
.fi
.RE
.P
If you want to add a dependency named \fBabbrev\fR from the registry as a dependency of your workspace \fBa\fR, you may use the workspace config to tell the npm installer that package should be added as a dependency of the provided workspace:
.P
.RS 2
.nf
npm install abbrev -w a
.fi
.RE
.P
Note: other installing commands such as \fBuninstall\fR, \fBci\fR, etc will also respect the provided \fBworkspace\fR configuration.
.SS "Using workspaces"
.P
Given the \fBspecifics of how Node.js handles module resolution\fR \fI\(lahttps://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together\(ra\fR it's possible to consume any defined workspace by its declared \fBpackage.json\fR \fBname\fR. Continuing from the example defined above, let's also create a Node.js script that will require the workspace \fBa\fR example module, e.g:
.P
.RS 2
.nf
// ./packages/a/index.js
module.exports = 'a'

// ./lib/index.js
const moduleA = require('a')
console.log(moduleA) // -> a
.fi
.RE
.P
When running it with:
.P
\fBnode lib/index.js\fR
.P
This demonstrates how the nature of \fBnode_modules\fR resolution allows for \fBworkspaces\fR to enable a portable workflow for requiring each \fBworkspace\fR in such a way that is also easy to npm help publish these nested workspaces to be consumed elsewhere.
.SS "Running commands in the context of workspaces"
.P
You can use the \fBworkspace\fR configuration option to run commands in the context of a configured workspace. Additionally, if your current directory is in a workspace, the \fBworkspace\fR configuration is implicitly set, and \fBprefix\fR is set to the root workspace.
.P
Following is a quick example on how to use the \fBnpm run\fR command in the context of nested workspaces. For a project containing multiple workspaces, e.g:
.P
.RS 2
.nf
.
+-- package.json
`-- packages
   +-- a
   |   `-- package.json
   `-- b
       `-- package.json
.fi
.RE
.P
By running a command using the \fBworkspace\fR option, it's possible to run the given command in the context of that specific workspace. e.g:
.P
.RS 2
.nf
npm run test --workspace=a
.fi
.RE
.P
You could also run the command within the workspace.
.P
.RS 2
.nf
cd packages/a && npm run test
.fi
.RE
.P
Either will run the \fBtest\fR script defined within the \fB./packages/a/package.json\fR file.
.P
Please note that you can also specify this argument multiple times in the command-line in order to target multiple workspaces, e.g:
.P
.RS 2
.nf
npm run test --workspace=a --workspace=b
.fi
.RE
.P
Or run the command for each workspace within the 'packages' folder:
.P
.RS 2
.nf
npm run test --workspace=packages
.fi
.RE
.P
It's also possible to use the \fBworkspaces\fR (plural) configuration option to enable the same behavior but running that command in the context of \fBall\fR configured workspaces. e.g:
.P
.RS 2
.nf
npm run test --workspaces
.fi
.RE
.P
Will run the \fBtest\fR script in both \fB./packages/a\fR and \fB./packages/b\fR.
.P
Commands will be run in each workspace in the order they appear in your \fBpackage.json\fR
.P
.RS 2
.nf
{
  "workspaces": \[lB] "packages/a", "packages/b" \[rB]
}
.fi
.RE
.P
Order of run is different with:
.P
.RS 2
.nf
{
  "workspaces": \[lB] "packages/b", "packages/a" \[rB]
}
.fi
.RE
.SS "Ignoring missing scripts"
.P
It is not required for all of the workspaces to implement scripts run with the \fBnpm run\fR command.
.P
By running the command with the \fB--if-present\fR flag, npm will ignore workspaces missing target script.
.P
.RS 2
.nf
npm run test --workspaces --if-present
.fi
.RE
.SS "See also"
.RS 0
.IP \(bu 4
npm help install
.IP \(bu 4
npm help publish
.IP \(bu 4
npm help run-script
.IP \(bu 4
npm help config
.RE 0
PK�~�\U�[!!man7/scope.7nu�[���.TH "SCOPE" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBscope\fR - Scoped packages
.SS "Description"
.P
All npm packages have a name. Some package names also have a scope. A scope follows the usual rules for package names (URL-safe characters, no leading dots or underscores). When used in package names, scopes are preceded by an \fB@\fR symbol and followed by a slash, e.g.
.P
.RS 2
.nf
@somescope/somepackagename
.fi
.RE
.P
Scopes are a way of grouping related packages together, and also affect a few things about the way npm treats the package.
.P
Each npm user/organization has their own scope, and only you can add packages in your scope. This means you don't have to worry about someone taking your package name ahead of you. Thus it is also a good way to signal official packages for organizations.
.P
Scoped packages can be published and installed as of \fBnpm@2\fR and are supported by the primary npm registry. Unscoped packages can depend on scoped packages and vice versa. The npm client is backwards-compatible with unscoped registries, so it can be used to work with scoped and unscoped registries at the same time.
.SS "Installing scoped packages"
.P
Scoped packages are installed to a sub-folder of the regular installation folder, e.g. if your other packages are installed in \fBnode_modules/packagename\fR, scoped modules will be installed in \fBnode_modules/@myorg/packagename\fR. The scope folder (\fB@myorg\fR) is simply the name of the scope preceded by an \fB@\fR symbol, and can contain any number of scoped packages.
.P
A scoped package is installed by referencing it by name, preceded by an \fB@\fR symbol, in \fBnpm install\fR:
.P
.RS 2
.nf
npm install @myorg/mypackage
.fi
.RE
.P
Or in \fBpackage.json\fR:
.P
.RS 2
.nf
"dependencies": {
  "@myorg/mypackage": "^1.3.0"
}
.fi
.RE
.P
Note that if the \fB@\fR symbol is omitted, in either case, npm will instead attempt to install from GitHub; see npm help install.
.SS "Requiring scoped packages"
.P
Because scoped packages are installed into a scope folder, you have to include the name of the scope when requiring them in your code, e.g.
.P
.RS 2
.nf
require('@myorg/mypackage')
.fi
.RE
.P
There is nothing special about the way Node treats scope folders. This simply requires the \fBmypackage\fR module in the folder named \fB@myorg\fR.
.SS "Publishing scoped packages"
.P
Scoped packages can be published from the CLI as of \fBnpm@2\fR and can be published to any registry that supports them, including the primary npm registry.
.P
(As of 2015-04-19, and with npm 2.0 or better, the primary npm registry \fBdoes\fR support scoped packages.)
.P
If you wish, you may associate a scope with a registry; see below.
.SS "Publishing public scoped packages to the primary npm registry"
.P
Publishing to a scope, you have two options:
.RS 0
.IP \(bu 4
Publishing to your user scope (example: \fB@username/module\fR)
.IP \(bu 4
Publishing to an organization scope (example: \fB@org/module\fR)
.RE 0

.P
If publishing a public module to an organization scope, you must first either create an organization with the name of the scope that you'd like to publish to or be added to an existing organization with the appropriate permissions. For example, if you'd like to publish to \fB@org\fR, you would need to create the \fBorg\fR organization on npmjs.com prior to trying to publish.
.P
Scoped packages are not public by default. You will need to specify \fB--access public\fR with the initial \fBnpm publish\fR command. This will publish the package and set access to \fBpublic\fR as if you had run \fBnpm access public\fR after publishing. You do not need to do this when publishing new versions of an existing scoped package.
.SS "Publishing private scoped packages to the npm registry"
.P
To publish a private scoped package to the npm registry, you must have an \fBnpm Private Modules\fR \fI\(lahttps://docs.npmjs.com/private-modules/intro\(ra\fR account.
.P
You can then publish the module with \fBnpm publish\fR or \fBnpm publish
--access restricted\fR, and it will be present in the npm registry, with restricted access. You can then change the access permissions, if desired, with \fBnpm access\fR or on the npmjs.com website.
.SS "Associating a scope with a registry"
.P
Scopes can be associated with a separate registry. This allows you to seamlessly use a mix of packages from the primary npm registry and one or more private registries, such as \fBGitHub Packages\fR \fI\(lahttps://github.com/features/packages\(ra\fR or the open source \fBVerdaccio\fR \fI\(lahttps://verdaccio.org\(ra\fR project.
.P
You can associate a scope with a registry at login, e.g.
.P
.RS 2
.nf
npm login --registry=http://reg.example.com --scope=@myco
.fi
.RE
.P
Scopes have a many-to-one relationship with registries: one registry can host multiple scopes, but a scope only ever points to one registry.
.P
You can also associate a scope with a registry using \fBnpm config\fR:
.P
.RS 2
.nf
npm config set @myco:registry=http://reg.example.com
.fi
.RE
.P
Once a scope is associated with a registry, any \fBnpm install\fR for a package with that scope will request packages from that registry instead. Any \fBnpm publish\fR for a package name that contains the scope will be published to that registry instead.
.SS "See also"
.RS 0
.IP \(bu 4
npm help install
.IP \(bu 4
npm help publish
.IP \(bu 4
npm help access
.IP \(bu 4
npm help registry
.RE 0
PK�~�\��-��
�
man7/package-spec.7nu�[���.TH "PACKAGE-SPEC" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBpackage-spec\fR - Package name specifier
.SS "Description"
.P
Commands like \fBnpm install\fR and the dependency sections in the \fBpackage.json\fR use a package name specifier. This can be many different things that all refer to a "package". Examples include a package name, git url, tarball, or local directory. These will generally be referred to as \fB<package-spec>\fR in the help output for the npm commands that use this package name specifier.
.SS "Package name"
.RS 0
.IP \(bu 4
\fB\[lB]<@scope>/\[rB]<pkg>\fR
.IP \(bu 4
\fB\[lB]<@scope>/\[rB]<pkg>@<tag>\fR
.IP \(bu 4
\fB\[lB]<@scope>/\[rB]<pkg>@<version>\fR
.IP \(bu 4
\fB\[lB]<@scope>/\[rB]<pkg>@<version range>\fR
.RE 0

.P
Refers to a package by name, with or without a scope, and optionally tag, version, or version range. This is typically used in combination with the \fBregistry\fR \fI\(la/using-npm/config#registry\(ra\fR config to refer to a package in a registry.
.P
Examples:
.RS 0
.IP \(bu 4
\fBnpm\fR
.IP \(bu 4
\fB@npmcli/arborist\fR
.IP \(bu 4
\fB@npmcli/arborist@latest\fR
.IP \(bu 4
\fBnpm@6.13.1\fR
.IP \(bu 4
\fBnpm@^4.0.0\fR
.RE 0

.SS "Aliases"
.RS 0
.IP \(bu 4
\fB<alias>@npm:<name>\fR
.RE 0

.P
Primarily used by commands like \fBnpm install\fR and in the dependency sections in the \fBpackage.json\fR, this refers to a package by an alias. The \fB<alias>\fR is the name of the package as it is reified in the \fBnode_modules\fR folder, and the \fB<name>\fR refers to a package name as found in the configured registry.
.P
See \fBPackage name\fR above for more info on referring to a package by name, and \fBregistry\fR \fI\(la/using-npm/config#registry\(ra\fR for configuring which registry is used when referring to a package by name.
.P
Examples:
.RS 0
.IP \(bu 4
\fBsemver:@npm:@npmcli/semver-with-patch\fR
.IP \(bu 4
\fBsemver:@npm:semver@7.2.2\fR
.IP \(bu 4
\fBsemver:@npm:semver@legacy\fR
.RE 0

.SS "Folders"
.RS 0
.IP \(bu 4
\fB<folder>\fR
.RE 0

.P
This refers to a package on the local filesystem. Specifically this is a folder with a \fBpackage.json\fR file in it. This \fIshould\fR always be prefixed with a \fB/\fR or \fB./\fR (or your OS equivalent) to reduce confusion. npm currently will parse a string with more than one \fB/\fR in it as a folder, but this is legacy behavior that may be removed in a future version.
.P
Examples:
.RS 0
.IP \(bu 4
\fB./my-package\fR
.IP \(bu 4
\fB/opt/npm/my-package\fR
.RE 0

.SS "Tarballs"
.RS 0
.IP \(bu 4
\fB<tarball file>\fR
.IP \(bu 4
\fB<tarball url>\fR
.RE 0

.P
Examples:
.RS 0
.IP \(bu 4
\fB./my-package.tgz\fR
.IP \(bu 4
\fBhttps://registry.npmjs.org/semver/-/semver-1.0.0.tgz\fR
.RE 0

.P
Refers to a package in a tarball format, either on the local filesystem or remotely via url. This is the format that packages exist in when uploaded to a registry.
.SS "git urls"
.RS 0
.IP \(bu 4
\fB<git:// url>\fR
.IP \(bu 4
\fB<github username>/<github project>\fR
.RE 0

.P
Refers to a package in a git repo. This can be a full git url, git shorthand, or a username/package on GitHub. You can specify a git tag, branch, or other git ref by appending \fB#ref\fR.
.P
Examples:
.RS 0
.IP \(bu 4
\fBhttps://github.com/npm/cli.git\fR
.IP \(bu 4
\fBgit@github.com:npm/cli.git\fR
.IP \(bu 4
\fBgit+ssh://git@github.com/npm/cli#v6.0.0\fR
.IP \(bu 4
\fBgithub:npm/cli#HEAD\fR
.IP \(bu 4
\fBnpm/cli#c12ea07\fR
.RE 0

.SS "See also"
.RS 0
.IP \(bu 4
\fBnpm-package-arg\fR \fI\(lahttps://npm.im/npm-package-arg\(ra\fR
.IP \(bu 4
npm help scope
.IP \(bu 4
npm help config
.RE 0
PK�~�\:�.�!8!8man7/dependency-selectors.7nu�[���.TH "QUERYING" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBQuerying\fR - Dependency Selector Syntax & Querying
.SS "Description"
.P
The npm help query command exposes a new dependency selector syntax (informed by & respecting many aspects of the \fBCSS Selectors 4 Spec\fR \fI\(lahttps://dev.w3.org/csswg/selectors4/#relational\(ra\fR) which:
.RS 0
.IP \(bu 4
Standardizes the shape of, & querying of, dependency graphs with a robust object model, metadata & selector syntax
.IP \(bu 4
Leverages existing, known language syntax & operators from CSS to make disparate package information broadly accessible
.IP \(bu 4
Unlocks the ability to answer complex, multi-faceted questions about dependencies, their relationships & associative metadata
.IP \(bu 4
Consolidates redundant logic of similar query commands in \fBnpm\fR (ex. \fBnpm fund\fR, \fBnpm ls\fR, \fBnpm outdated\fR, \fBnpm audit\fR ...)
.RE 0

.SS "Dependency Selector Syntax"
.SS "Overview:"
.RS 0
.IP \(bu 4
there is no "type" or "tag" selectors (ex. \fBdiv, h1, a\fR) as a dependency/target is the only type of \fBNode\fR that can be queried
.IP \(bu 4
the term "dependencies" is in reference to any \fBNode\fR found in a \fBtree\fR returned by \fBArborist\fR
.RE 0

.SS "Combinators"
.RS 0
.IP \(bu 4
\fB>\fR direct descendant/child
.IP \(bu 4
\fB \fR any descendant/child
.IP \(bu 4
\fB~\fR sibling
.RE 0

.SS "Selectors"
.RS 0
.IP \(bu 4
\fB*\fR universal selector
.IP \(bu 4
\fB#<name>\fR dependency selector (equivalent to \fB\[lB]name="..."\[rB]\fR)
.IP \(bu 4
\fB#<name>@<version>\fR (equivalent to \fB\[lB]name=<name>\[rB]:semver(<version>)\fR)
.IP \(bu 4
\fB,\fR selector list delimiter
.IP \(bu 4
\fB.\fR dependency type selector
.IP \(bu 4
\fB:\fR pseudo selector
.RE 0

.SS "Dependency Type Selectors"
.RS 0
.IP \(bu 4
\fB.prod\fR dependency found in the \fBdependencies\fR section of \fBpackage.json\fR, or is a child of said dependency
.IP \(bu 4
\fB.dev\fR dependency found in the \fBdevDependencies\fR section of \fBpackage.json\fR, or is a child of said dependency
.IP \(bu 4
\fB.optional\fR dependency found in the \fBoptionalDependencies\fR section of \fBpackage.json\fR, or has \fB"optional": true\fR set in its entry in the \fBpeerDependenciesMeta\fR section of \fBpackage.json\fR, or a child of said dependency
.IP \(bu 4
\fB.peer\fR dependency found in the \fBpeerDependencies\fR section of \fBpackage.json\fR
.IP \(bu 4
\fB.workspace\fR dependency found in the \fB\fBworkspaces\fR\fR \fI\(lahttps://docs.npmjs.com/cli/v8/using-npm/workspaces\(ra\fR section of \fBpackage.json\fR
.IP \(bu 4
\fB.bundled\fR dependency found in the \fBbundleDependencies\fR section of \fBpackage.json\fR, or is a child of said dependency
.RE 0

.SS "Pseudo Selectors"
.RS 0
.IP \(bu 4
\fB\fB:not(<selector>)\fR\fR \fI\(lahttps://developer.mozilla.org/en-US/docs/Web/CSS/:not\(ra\fR
.IP \(bu 4
\fB\fB:has(<selector>)\fR\fR \fI\(lahttps://developer.mozilla.org/en-US/docs/Web/CSS/:has\(ra\fR
.IP \(bu 4
\fB\fB:is(<selector list>)\fR\fR \fI\(lahttps://developer.mozilla.org/en-US/docs/Web/CSS/:is\(ra\fR
.IP \(bu 4
\fB\fB:root\fR\fR \fI\(lahttps://developer.mozilla.org/en-US/docs/Web/CSS/:root\(ra\fR matches the root node/dependency
.IP \(bu 4
\fB\fB:scope\fR\fR \fI\(lahttps://developer.mozilla.org/en-US/docs/Web/CSS/:scope\(ra\fR matches node/dependency it was queried against
.IP \(bu 4
\fB\fB:empty\fR\fR \fI\(lahttps://developer.mozilla.org/en-US/docs/Web/CSS/:empty\(ra\fR when a dependency has no dependencies
.IP \(bu 4
\fB\fB:private\fR\fR \fI\(lahttps://docs.npmjs.com/cli/v8/configuring-npm/package-json#private\(ra\fR when a dependency is private
.IP \(bu 4
\fB:link\fR when a dependency is linked (for instance, workspaces or packages manually \fB\fBlinked\fR\fR \fI\(lahttps://docs.npmjs.com/cli/v8/commands/npm-link\(ra\fR
.IP \(bu 4
\fB:deduped\fR when a dependency has been deduped (note that this does \fInot\fR always mean the dependency has been hoisted to the root of node_modules)
.IP \(bu 4
\fB:overridden\fR when a dependency has been overridden
.IP \(bu 4
\fB:extraneous\fR when a dependency exists but is not defined as a dependency of any node
.IP \(bu 4
\fB:invalid\fR when a dependency version is out of its ancestors specified range
.IP \(bu 4
\fB:missing\fR when a dependency is not found on disk
.IP \(bu 4
\fB:semver(<spec>, \[lB]selector\[rB], \[lB]function\[rB])\fR match a valid \fB\fBnode-semver\fR\fR \fI\(lahttps://github.com/npm/node-semver\(ra\fR version or range to a selector
.IP \(bu 4
\fB:path(<path>)\fR \fBglob\fR \fI\(lahttps://www.npmjs.com/package/glob\(ra\fR matching based on dependencies path relative to the project
.IP \(bu 4
\fB:type(<type>)\fR \fBbased on currently recognized types\fR \fI\(lahttps://github.com/npm/npm-package-arg#result-object\(ra\fR
.IP \(bu 4
\fB:outdated(<type>)\fR when a dependency is outdated
.IP \(bu 4
\fB:vuln(<selector>)\fR when a dependency has a known vulnerability
.RE 0

.SS "\fB:semver(<spec>, \[lB]selector\[rB], \[lB]function\[rB])\fR"
.P
The \fB:semver()\fR pseudo selector allows comparing fields from each node's \fBpackage.json\fR using \fBsemver\fR \fI\(lahttps://github.com/npm/node-semver#readme\(ra\fR methods. It accepts up to 3 parameters, all but the first of which are optional.
.RS 0
.IP \(bu 4
\fBspec\fR a semver version or range
.IP \(bu 4
\fBselector\fR an attribute selector for each node (default \fB\[lB]version\[rB]\fR)
.IP \(bu 4
\fBfunction\fR a semver method to apply, one of: \fBsatisfies\fR, \fBintersects\fR, \fBsubset\fR, \fBgt\fR, \fBgte\fR, \fBgtr\fR, \fBlt\fR, \fBlte\fR, \fBltr\fR, \fBeq\fR, \fBneq\fR or the special function \fBinfer\fR (default \fBinfer\fR)
.RE 0

.P
When the special \fBinfer\fR function is used the \fBspec\fR and the actual value from the node are compared. If both are versions, according to \fBsemver.valid()\fR, \fBeq\fR is used. If both values are ranges, according to \fB!semver.valid()\fR, \fBintersects\fR is used. If the values are mixed types \fBsatisfies\fR is used.
.P
Some examples:
.RS 0
.IP \(bu 4
\fB:semver(^1.0.0)\fR returns every node that has a \fBversion\fR satisfied by the provided range \fB^1.0.0\fR
.IP \(bu 4
\fB:semver(16.0.0, :attr(engines, \[lB]node\[rB]))\fR returns every node which has an \fBengines.node\fR property satisfying the version \fB16.0.0\fR
.IP \(bu 4
\fB:semver(1.0.0, \[lB]version\[rB], lt)\fR every node with a \fBversion\fR less than \fB1.0.0\fR
.RE 0

.SS "\fB:outdated(<type>)\fR"
.P
The \fB:outdated\fR pseudo selector retrieves data from the registry and returns information about which of your dependencies are outdated. The type parameter may be one of the following:
.RS 0
.IP \(bu 4
\fBany\fR (default) a version exists that is greater than the current one
.IP \(bu 4
\fBin-range\fR a version exists that is greater than the current one, and satisfies at least one if its parent's dependencies
.IP \(bu 4
\fBout-of-range\fR a version exists that is greater than the current one, does not satisfy at least one of its parent's dependencies
.IP \(bu 4
\fBmajor\fR a version exists that is a semver major greater than the current one
.IP \(bu 4
\fBminor\fR a version exists that is a semver minor greater than the current one
.IP \(bu 4
\fBpatch\fR a version exists that is a semver patch greater than the current one
.RE 0

.P
In addition to the filtering performed by the pseudo selector, some extra data is added to the resulting objects. The following data can be found under the \fBqueryContext\fR property of each node.
.RS 0
.IP \(bu 4
\fBversions\fR an array of every available version of the given node
.IP \(bu 4
\fBoutdated.inRange\fR an array of objects, each with a \fBfrom\fR and \fBversions\fR, where \fBfrom\fR is the on-disk location of the node that depends on the current node and \fBversions\fR is an array of all available versions that satisfies that dependency. This is only populated if \fB:outdated(in-range)\fR is used.
.IP \(bu 4
\fBoutdated.outOfRange\fR an array of objects, identical in shape to \fBinRange\fR, but where the \fBversions\fR array is every available version that does not satisfy the dependency. This is only populated if \fB:outdated(out-of-range)\fR is used.
.RE 0

.P
Some examples:
.RS 0
.IP \(bu 4
\fB:root > :outdated(major)\fR returns every direct dependency that has a new semver major release
.IP \(bu 4
\fB.prod:outdated(in-range)\fR returns production dependencies that have a new release that satisfies at least one of its parent's dependencies
.RE 0

.SS "\fB:vuln\fR"
.P
The \fB:vuln\fR pseudo selector retrieves data from the registry and returns information about which if your dependencies has a known vulnerability. Only dependencies whose current version matches a vulnerability will be returned. For example if you have \fBsemver@7.6.0\fR in your tree, a vulnerability for \fBsemver\fR which affects versions \fB<=6.3.1\fR will not match.
.P
You can also filter results by certain attributes in advisories. Currently that includes \fBseverity\fR and \fBcwe\fR. Note that severity filtering is done per severity, it does not include severities "higher" or "lower" than the one specified.
.P
In addition to the filtering performed by the pseudo selector, info about each relevant advisory will be added to the \fBqueryContext\fR attribute of each node under the \fBadvisories\fR attribute.
.P
Some examples:
.RS 0
.IP \(bu 4
\fB:root > .prod:vuln\fR returns direct production dependencies with any known vulnerability
.IP \(bu 4
\fB:vuln(\[lB]severity=high\[rB])\fR returns only dependencies with a vulnerability with a \fBhigh\fR severity.
.IP \(bu 4
\fB:vuln(\[lB]severity=high\[rB],\[lB]severity=moderate\[rB])\fR returns only dependencies with a vulnerability with a \fBhigh\fR or \fBmoderate\fR severity.
.IP \(bu 4
\fB:vuln(\[lB]cwe=1333\[rB])\fR returns only dependencies with a vulnerability that includes CWE-1333 (ReDoS)
.RE 0

.SS "\fBAttribute Selectors\fR \fI\(lahttps://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors\(ra\fR"
.P
The attribute selector evaluates the key/value pairs in \fBpackage.json\fR if they are \fBString\fRs.
.RS 0
.IP \(bu 4
\fB\[lB]\[rB]\fR attribute selector (ie. existence of attribute)
.IP \(bu 4
\fB\[lB]attribute=value\[rB]\fR attribute value is equivalent...
.IP \(bu 4
\fB\[lB]attribute~=value\[rB]\fR attribute value contains word...
.IP \(bu 4
\fB\[lB]attribute*=value\[rB]\fR attribute value contains string...
.IP \(bu 4
\fB\[lB]attribute|=value\[rB]\fR attribute value is equal to or starts with...
.IP \(bu 4
\fB\[lB]attribute^=value\[rB]\fR attribute value starts with...
.IP \(bu 4
\fB\[lB]attribute$=value\[rB]\fR attribute value ends with...
.RE 0

.SS "\fBArray\fR & \fBObject\fR Attribute Selectors"
.P
The generic \fB:attr()\fR pseudo selector standardizes a pattern which can be used for attribute selection of \fBObject\fRs, \fBArray\fRs or \fBArrays\fR of \fBObject\fRs accessible via \fBArborist\fR's \fBNode.package\fR metadata. This allows for iterative attribute selection beyond top-level \fBString\fR evaluation. The last argument passed to \fB:attr()\fR must be an \fBattribute\fR selector or a nested \fB:attr()\fR. See examples below:
.SS "\fBObjects\fR"
.P
.RS 2
.nf
/* return dependencies that have a `scripts.test` containing `"tap"` */
*:attr(scripts, \[lB]test~=tap\[rB])
.fi
.RE
.SS "Nested \fBObjects\fR"
.P
Nested objects are expressed as sequential arguments to \fB:attr()\fR.
.P
.RS 2
.nf
/* return dependencies that have a testling config for opera browsers */
*:attr(testling, browsers, \[lB]~=opera\[rB])
.fi
.RE
.SS "\fBArrays\fR"
.P
\fBArray\fRs specifically uses a special/reserved \fB.\fR character in place of a typical attribute name. \fBArrays\fR also support exact \fBvalue\fR matching when a \fBString\fR is passed to the selector.
.SS "Example of an \fBArray\fR Attribute Selection:"
.P
.RS 2
.nf
/* removes the distinction between properties & arrays */
/* ie. we'd have to check the property & iterate to match selection */
*:attr(\[lB]keywords^=react\[rB])
*:attr(contributors, :attr(\[lB]name~=Jordan\[rB]))
.fi
.RE
.SS "Example of an \fBArray\fR matching directly to a value:"
.P
.RS 2
.nf
/* return dependencies that have the exact keyword "react" */
/* this is equivalent to `*:keywords(\[lB]value="react"\[rB])` */
*:attr(\[lB]keywords=react\[rB])
.fi
.RE
.SS "Example of an \fBArray\fR of \fBObject\fRs:"
.P
.RS 2
.nf
/* returns */
*:attr(contributors, \[lB]email=ruyadorno@github.com\[rB])
.fi
.RE
.SS "Groups"
.P
Dependency groups are defined by the package relationships to their ancestors (ie. the dependency types that are defined in \fBpackage.json\fR). This approach is user-centric as the ecosystem has been taught to think about dependencies in these groups first-and-foremost. Dependencies are allowed to be included in multiple groups (ex. a \fBprod\fR dependency may also be a \fBdev\fR dependency (in that it's also required by another \fBdev\fR dependency) & may also be \fBbundled\fR - a selector for that type of dependency would look like: \fB*.prod.dev.bundled\fR).
.RS 0
.IP \(bu 4
\fB.prod\fR
.IP \(bu 4
\fB.dev\fR
.IP \(bu 4
\fB.optional\fR
.IP \(bu 4
\fB.peer\fR
.IP \(bu 4
\fB.bundled\fR
.IP \(bu 4
\fB.workspace\fR
.RE 0

.P
Please note that currently \fBworkspace\fR deps are always \fBprod\fR dependencies. Additionally the \fB.root\fR dependency is also considered a \fBprod\fR dependency.
.SS "Programmatic Usage"
.RS 0
.IP \(bu 4
\fBArborist\fR's \fBNode\fR Class has a \fB.querySelectorAll()\fR method
.RS 4
.IP \(bu 4
this method will return a filtered, flattened dependency Arborist \fBNode\fR list based on a valid query selector
.RE 0

.RE 0

.P
.RS 2
.nf
const Arborist = require('@npmcli/arborist')
const arb = new Arborist({})
.fi
.RE
.P
.RS 2
.nf
// root-level
arb.loadActual().then(async (tree) => {
  // query all production dependencies
  const results = await tree.querySelectorAll('.prod')
  console.log(results)
})
.fi
.RE
.P
.RS 2
.nf
// iterative
arb.loadActual().then(async (tree) => {
  // query for the deduped version of react
  const results = await tree.querySelectorAll('#react:not(:deduped)')
  // query the deduped react for git deps
  const deps = await results\[lB]0\[rB].querySelectorAll(':type(git)')
  console.log(deps)
})
.fi
.RE
.SH "SEE ALSO"
.RS 0
.IP \(bu 4
npm help query
.IP \(bu 4
\fB@npmcli/arborist\fR \fI\(lahttps://npm.im/@npmcli/arborist\(ra\fR
.RE 0
PK�~�\���66man7/scripts.7nu�[���.TH "SCRIPTS" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBscripts\fR - How npm handles the "scripts" field
.SS "Description"
.P
The \fB"scripts"\fR property of your \fBpackage.json\fR file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running \fBnpm run-script <stage>\fR or \fBnpm run <stage>\fR for short. \fIPre\fR and \fIpost\fR commands with matching names will be run for those as well (e.g. \fBpremyscript\fR, \fBmyscript\fR, \fBpostmyscript\fR). Scripts from dependencies can be run with \fBnpm explore <pkg> -- npm run <stage>\fR.
.SS "Pre & Post Scripts"
.P
To create "pre" or "post" scripts for any scripts defined in the \fB"scripts"\fR section of the \fBpackage.json\fR, simply create another script \fIwith a matching name\fR and add "pre" or "post" to the beginning of them.
.P
.RS 2
.nf
{
  "scripts": {
    "precompress": "{{ executes BEFORE the `compress` script }}",
    "compress": "{{ run command to compress files }}",
    "postcompress": "{{ executes AFTER `compress` script }}"
  }
}
.fi
.RE
.P
In this example \fBnpm run compress\fR would execute these scripts as described.
.SS "Life Cycle Scripts"
.P
There are some special life cycle scripts that happen only in certain situations. These scripts happen in addition to the \fBpre<event>\fR, \fBpost<event>\fR, and \fB<event>\fR scripts.
.RS 0
.IP \(bu 4
\fBprepare\fR, \fBprepublish\fR, \fBprepublishOnly\fR, \fBprepack\fR, \fBpostpack\fR, \fBdependencies\fR
.RE 0

.P
\fBprepare\fR (since \fBnpm@4.0.0\fR)
.RS 0
.IP \(bu 4
Runs BEFORE the package is packed, i.e. during \fBnpm publish\fR and \fBnpm pack\fR
.IP \(bu 4
Runs on local \fBnpm install\fR without any arguments
.IP \(bu 4
Runs AFTER \fBprepublish\fR, but BEFORE \fBprepublishOnly\fR
.IP \(bu 4
NOTE: If a package being installed through git contains a \fBprepare\fR script, its \fBdependencies\fR and \fBdevDependencies\fR will be installed, and the prepare script will be run, before the package is packaged and installed.
.IP \(bu 4
As of \fBnpm@7\fR these scripts run in the background. To see the output, run with: \fB--foreground-scripts\fR.
.RE 0

.P
\fBprepublish\fR (DEPRECATED)
.RS 0
.IP \(bu 4
Does not run during \fBnpm publish\fR, but does run during \fBnpm ci\fR and \fBnpm install\fR. See below for more info.
.RE 0

.P
\fBprepublishOnly\fR
.RS 0
.IP \(bu 4
Runs BEFORE the package is prepared and packed, ONLY on \fBnpm publish\fR.
.RE 0

.P
\fBprepack\fR
.RS 0
.IP \(bu 4
Runs BEFORE a tarball is packed (on "\fBnpm pack\fR", "\fBnpm publish\fR", and when installing a git dependency).
.IP \(bu 4
NOTE: "\fBnpm run pack\fR" is NOT the same as "\fBnpm pack\fR". "\fBnpm run pack\fR" is an arbitrary user defined script name, where as, "\fBnpm pack\fR" is a CLI defined command.
.RE 0

.P
\fBpostpack\fR
.RS 0
.IP \(bu 4
Runs AFTER the tarball has been generated but before it is moved to its final destination (if at all, publish does not save the tarball locally)
.RE 0

.P
\fBdependencies\fR
.RS 0
.IP \(bu 4
Runs AFTER any operations that modify the \fBnode_modules\fR directory IF changes occurred.
.IP \(bu 4
Does NOT run in global mode
.RE 0

.SS "Prepare and Prepublish"
.P
\fBDeprecation Note: prepublish\fR
.P
Since \fBnpm@1.1.71\fR, the npm CLI has run the \fBprepublish\fR script for both \fBnpm publish\fR and \fBnpm install\fR, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, \fBvery confusing\fR \fI\(lahttps://github.com/npm/npm/issues/10074\(ra\fR. As of \fBnpm@4.0.0\fR, a new event has been introduced, \fBprepare\fR, that preserves this existing behavior. A \fInew\fR event, \fBprepublishOnly\fR has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on \fBnpm publish\fR (for instance, running the tests one last time to ensure they're in good shape).
.P
See \fI\(lahttps://github.com/npm/npm/issues/10074\(ra\fR for a much lengthier justification, with further reading, for this change.
.P
\fBUse Cases\fR
.P
If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a \fBprepublish\fR script. This includes tasks such as:
.RS 0
.IP \(bu 4
Compiling CoffeeScript source code into JavaScript.
.IP \(bu 4
Creating minified versions of JavaScript source code.
.IP \(bu 4
Fetching remote resources that your package will use.
.RE 0

.P
The advantage of doing these things at \fBprepublish\fR time is that they can be done once, in a single place, thus reducing complexity and variability. Additionally, this means that:
.RS 0
.IP \(bu 4
You can depend on \fBcoffee-script\fR as a \fBdevDependency\fR, and thus your users don't need to have it installed.
.IP \(bu 4
You don't need to include minifiers in your package, reducing the size for your users.
.IP \(bu 4
You don't need to rely on your users having \fBcurl\fR or \fBwget\fR or other system tools on the target machines.
.RE 0

.SS "Dependencies"
.P
The \fBdependencies\fR script is run any time an \fBnpm\fR command causes changes to the \fBnode_modules\fR directory. It is run AFTER the changes have been applied and the \fBpackage.json\fR and \fBpackage-lock.json\fR files have been updated.
.SS "Life Cycle Operation Order"
.SS "npm help \"cache add\""
.RS 0
.IP \(bu 4
\fBprepare\fR
.RE 0

.SS "npm help ci"
.RS 0
.IP \(bu 4
\fBpreinstall\fR
.IP \(bu 4
\fBinstall\fR
.IP \(bu 4
\fBpostinstall\fR
.IP \(bu 4
\fBprepublish\fR
.IP \(bu 4
\fBpreprepare\fR
.IP \(bu 4
\fBprepare\fR
.IP \(bu 4
\fBpostprepare\fR
.RE 0

.P
These all run after the actual installation of modules into \fBnode_modules\fR, in order, with no internal actions happening in between
.SS "npm help diff"
.RS 0
.IP \(bu 4
\fBprepare\fR
.RE 0

.SS "npm help install"
.P
These also run when you run \fBnpm install -g <pkg-name>\fR
.RS 0
.IP \(bu 4
\fBpreinstall\fR
.IP \(bu 4
\fBinstall\fR
.IP \(bu 4
\fBpostinstall\fR
.IP \(bu 4
\fBprepublish\fR
.IP \(bu 4
\fBpreprepare\fR
.IP \(bu 4
\fBprepare\fR
.IP \(bu 4
\fBpostprepare\fR
.RE 0

.P
If there is a \fBbinding.gyp\fR file in the root of your package and you haven't defined your own \fBinstall\fR or \fBpreinstall\fR scripts, npm will default the \fBinstall\fR command to compile using node-gyp via \fBnode-gyp
rebuild\fR
.P
These are run from the scripts of \fB<pkg-name>\fR
.SS "npm help pack"
.RS 0
.IP \(bu 4
\fBprepack\fR
.IP \(bu 4
\fBprepare\fR
.IP \(bu 4
\fBpostpack\fR
.RE 0

.SS "npm help publish"
.RS 0
.IP \(bu 4
\fBprepublishOnly\fR
.IP \(bu 4
\fBprepack\fR
.IP \(bu 4
\fBprepare\fR
.IP \(bu 4
\fBpostpack\fR
.IP \(bu 4
\fBpublish\fR
.IP \(bu 4
\fBpostpublish\fR
.RE 0

.SS "npm help rebuild"
.RS 0
.IP \(bu 4
\fBpreinstall\fR
.IP \(bu 4
\fBinstall\fR
.IP \(bu 4
\fBpostinstall\fR
.IP \(bu 4
\fBprepare\fR
.RE 0

.P
\fBprepare\fR is only run if the current directory is a symlink (e.g. with linked packages)
.SS "npm help restart"
.P
If there is a \fBrestart\fR script defined, these events are run, otherwise \fBstop\fR and \fBstart\fR are both run if present, including their \fBpre\fR and \fBpost\fR iterations)
.RS 0
.IP \(bu 4
\fBprerestart\fR
.IP \(bu 4
\fBrestart\fR
.IP \(bu 4
\fBpostrestart\fR
.RE 0

.SS "\fB\fBnpm run <user defined>\fR\fR \fI\(la/commands/npm-run-script\(ra\fR"
.RS 0
.IP \(bu 4
\fBpre<user-defined>\fR
.IP \(bu 4
\fB<user-defined>\fR
.IP \(bu 4
\fBpost<user-defined>\fR
.RE 0

.SS "npm help start"
.RS 0
.IP \(bu 4
\fBprestart\fR
.IP \(bu 4
\fBstart\fR
.IP \(bu 4
\fBpoststart\fR
.RE 0

.P
If there is a \fBserver.js\fR file in the root of your package, then npm will default the \fBstart\fR command to \fBnode server.js\fR. \fBprestart\fR and \fBpoststart\fR will still run in this case.
.SS "npm help stop"
.RS 0
.IP \(bu 4
\fBprestop\fR
.IP \(bu 4
\fBstop\fR
.IP \(bu 4
\fBpoststop\fR
.RE 0

.SS "npm help test"
.RS 0
.IP \(bu 4
\fBpretest\fR
.IP \(bu 4
\fBtest\fR
.IP \(bu 4
\fBposttest\fR
.RE 0

.SS "npm help version"
.RS 0
.IP \(bu 4
\fBpreversion\fR
.IP \(bu 4
\fBversion\fR
.IP \(bu 4
\fBpostversion\fR
.RE 0

.SS "A Note on a lack of npm help uninstall scripts"
.P
While npm v6 had \fBuninstall\fR lifecycle scripts, npm v7 does not. Removal of a package can happen for a wide variety of reasons, and there's no clear way to currently give the script enough context to be useful.
.P
Reasons for a package removal include:
.RS 0
.IP \(bu 4
a user directly uninstalled this package
.IP \(bu 4
a user uninstalled a dependant package and so this dependency is being uninstalled
.IP \(bu 4
a user uninstalled a dependant package but another package also depends on this version
.IP \(bu 4
this version has been merged as a duplicate with another version
.IP \(bu 4
etc.
.RE 0

.P
Due to the lack of necessary context, \fBuninstall\fR lifecycle scripts are not implemented and will not function.
.SS "User"
.P
When npm is run as root, scripts are always run with the effective uid and gid of the working directory owner.
.SS "Environment"
.P
Package scripts run in an environment where many pieces of information are made available regarding the setup of npm and the current state of the process.
.SS "path"
.P
If you depend on modules that define executable scripts, like test suites, then those executables will be added to the \fBPATH\fR for executing the scripts. So, if your package.json has this:
.P
.RS 2
.nf
{
  "name" : "foo",
  "dependencies" : {
    "bar" : "0.1.x"
  },
  "scripts": {
    "start" : "bar ./test"
  }
}
.fi
.RE
.P
then you could run \fBnpm start\fR to execute the \fBbar\fR script, which is exported into the \fBnode_modules/.bin\fR directory on \fBnpm install\fR.
.SS "package.json vars"
.P
The package.json fields are tacked onto the \fBnpm_package_\fR prefix. So, for instance, if you had \fB{"name":"foo", "version":"1.2.5"}\fR in your package.json file, then your package scripts would have the \fBnpm_package_name\fR environment variable set to "foo", and the \fBnpm_package_version\fR set to "1.2.5". You can access these variables in your code with \fBprocess.env.npm_package_name\fR and \fBprocess.env.npm_package_version\fR, and so on for other fields.
.P
See \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR for more on package configs.
.SS "current lifecycle event"
.P
Lastly, the \fBnpm_lifecycle_event\fR environment variable is set to whichever stage of the cycle is being executed. So, you could have a single script used for different parts of the process which switches based on what's currently happening.
.P
Objects are flattened following this format, so if you had \fB{"scripts":{"install":"foo.js"}}\fR in your package.json, then you'd see this in the script:
.P
.RS 2
.nf
process.env.npm_package_scripts_install === "foo.js"
.fi
.RE
.SS "Examples"
.P
For example, if your package.json contains this:
.P
.RS 2
.nf
{
  "scripts" : {
    "install" : "scripts/install.js",
    "postinstall" : "scripts/install.js"
  }
}
.fi
.RE
.P
then \fBscripts/install.js\fR will be called for the install and post-install stages of the lifecycle. Since \fBscripts/install.js\fR is running for two different phases, it would be wise in this case to look at the \fBnpm_lifecycle_event\fR environment variable.
.P
If you want to run a make command, you can do so. This works just fine:
.P
.RS 2
.nf
{
  "scripts" : {
    "preinstall" : "./configure",
    "install" : "make && make install",
    "test" : "make test"
  }
}
.fi
.RE
.SS "Exiting"
.P
Scripts are run by passing the line as a script argument to \fBsh\fR.
.P
If the script exits with a code other than 0, then this will abort the process.
.P
Note that these script files don't have to be Node.js or even JavaScript programs. They just have to be some kind of executable file.
.SS "Best Practices"
.RS 0
.IP \(bu 4
Don't exit with a non-zero error code unless you \fIreally\fR mean it. If the failure is minor or only will prevent some optional features, then it's better to just print a warning and exit successfully.
.IP \(bu 4
Try not to use scripts to do what npm can do for you. Read through \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR to see all the things that you can specify and enable by simply describing your package appropriately. In general, this will lead to a more robust and consistent state.
.IP \(bu 4
Inspect the env to determine where to put things. For instance, if the \fBnpm_config_binroot\fR environment variable is set to \fB/home/user/bin\fR, then don't try to install executables into \fB/usr/local/bin\fR. The user probably set it up that way for a reason.
.IP \(bu 4
Don't prefix your script commands with "sudo". If root permissions are required for some reason, then it'll fail with that error, and the user will sudo the npm command in question.
.IP \(bu 4
Don't use \fBinstall\fR. Use a \fB.gyp\fR file for compilation, and \fBprepare\fR for anything else. You should almost never have to explicitly set a preinstall or install script. If you are doing this, please consider if there is another option. The only valid use of \fBinstall\fR or \fBpreinstall\fR scripts is for compilation which must be done on the target architecture.
.IP \(bu 4
Scripts are run from the root of the package folder, regardless of what the current working directory is when \fBnpm\fR is invoked. If you want your script to use different behavior based on what subdirectory you're in, you can use the \fBINIT_CWD\fR environment variable, which holds the full path you were in when you ran \fBnpm run\fR.
.RE 0

.SS "See Also"
.RS 0
.IP \(bu 4
npm help run-script
.IP \(bu 4
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
.IP \(bu 4
npm help developers
.IP \(bu 4
npm help install
.RE 0
PK�~�\���KKman7/logging.7nu�[���.TH "LOGGING" "7" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBLogging\fR - Why, What & How We Log
.SS "Description"
.P
The \fBnpm\fR CLI has various mechanisms for showing different levels of information back to end-users for certain commands, configurations & environments.
.SS "Setting Log File Location"
.P
All logs are written to a debug log, with the path to that file printed if the execution of a command fails.
.P
The default location of the logs directory is a directory named \fB_logs\fR inside the npm cache. This can be changed with the \fBlogs-dir\fR config option.
.P
For example, if you wanted to write all your logs to the current working directory, you could run: \fBnpm install --logs-dir=.\fR. This is especially helpful in debugging a specific \fBnpm\fR issue as you can run a command multiple times with different config values and then diff all the log files.
.P
Log files will be removed from the \fBlogs-dir\fR when the number of log files exceeds \fBlogs-max\fR, with the oldest logs being deleted first.
.P
To turn off logs completely set \fB--logs-max=0\fR.
.SS "Setting Log Levels"
.SS "\fBloglevel\fR"
.P
\fBloglevel\fR is a global argument/config that can be set to determine the type of information to be displayed.
.P
The default value of \fBloglevel\fR is \fB"notice"\fR but there are several levels/types of logs available, including:
.RS 0
.IP \(bu 4
\fB"silent"\fR
.IP \(bu 4
\fB"error"\fR
.IP \(bu 4
\fB"warn"\fR
.IP \(bu 4
\fB"notice"\fR
.IP \(bu 4
\fB"http"\fR
.IP \(bu 4
\fB"info"\fR
.IP \(bu 4
\fB"verbose"\fR
.IP \(bu 4
\fB"silly"\fR
.RE 0

.P
All logs pertaining to a level proceeding the current setting will be shown.
.SS "Aliases"
.P
The log levels listed above have various corresponding aliases, including:
.RS 0
.IP \(bu 4
\fB-d\fR: \fB--loglevel info\fR
.IP \(bu 4
\fB--dd\fR: \fB--loglevel verbose\fR
.IP \(bu 4
\fB--verbose\fR: \fB--loglevel verbose\fR
.IP \(bu 4
\fB--ddd\fR: \fB--loglevel silly\fR
.IP \(bu 4
\fB-q\fR: \fB--loglevel warn\fR
.IP \(bu 4
\fB--quiet\fR: \fB--loglevel warn\fR
.IP \(bu 4
\fB-s\fR: \fB--loglevel silent\fR
.IP \(bu 4
\fB--silent\fR: \fB--loglevel silent\fR
.RE 0

.SS "\fBforeground-scripts\fR"
.P
The \fBnpm\fR CLI began hiding the output of lifecycle scripts for \fBnpm install\fR as of \fBv7\fR. Notably, this means you will not see logs/output from packages that may be using "install scripts" to display information back to you or from your own project's scripts defined in \fBpackage.json\fR. If you'd like to change this behavior & log this output you can set \fBforeground-scripts\fR to \fBtrue\fR.
.SS "Timing Information"
.P
The \fB\fB--timing\fR config\fR \fI\(la/using-npm/config#timing\(ra\fR can be set which does a few things:
.RS 0
.IP 1. 4
Always shows the full path to the debug log regardless of command exit status
.IP 2. 4
Write timing information to a process specific timing file in the cache or \fBlogs-dir\fR
.IP 3. 4
Output timing information to the terminal
.RE 0

.P
This file contains a \fBtimers\fR object where the keys are an identifier for the portion of the process being timed and the value is the number of milliseconds it took to complete.
.P
Sometimes it is helpful to get timing information without outputting anything to the terminal. For example, the performance might be affected by writing to the terminal. In this case you can use \fB--timing --silent\fR which will still write the timing file, but not output anything to the terminal while running.
.SS "Registry Response Headers"
.SS "\fBnpm-notice\fR"
.P
The \fBnpm\fR CLI reads from & logs any \fBnpm-notice\fR headers that are returned from the configured registry. This mechanism can be used by third-party registries to provide useful information when network-dependent requests occur.
.P
This header is not cached, and will not be logged if the request is served from the cache.
.SS "Logs and Sensitive Information"
.P
The \fBnpm\fR CLI makes a best effort to redact the following from terminal output and log files:
.RS 0
.IP \(bu 4
Passwords inside basic auth URLs
.IP \(bu 4
npm tokens
.RE 0

.P
However, this behavior should not be relied on to keep all possible sensitive information redacted. If you are concerned about secrets in your log file or terminal output, you can use \fB--loglevel=silent\fR and \fB--logs-max=0\fR to ensure no logs are written to your terminal or filesystem.
.SS "See also"
.RS 0
.IP \(bu 4
npm help config
.RE 0
PK�~�\\X��\\man5/npm-shrinkwrap-json.5nu�[���.TH "NPM-SHRINKWRAP.JSON" "5" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-shrinkwrap.json\fR - A publishable lockfile
.SS "Description"
.P
\fBnpm-shrinkwrap.json\fR is a file created by npm help shrinkwrap. It is identical to \fBpackage-lock.json\fR, with one major caveat: Unlike \fBpackage-lock.json\fR, \fBnpm-shrinkwrap.json\fR may be included when publishing a package.
.P
The recommended use-case for \fBnpm-shrinkwrap.json\fR is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs or \fBdevDependencies\fR. It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates.
.P
If both \fBpackage-lock.json\fR and \fBnpm-shrinkwrap.json\fR are present in a package root, \fBnpm-shrinkwrap.json\fR will be preferred over the \fBpackage-lock.json\fR file.
.P
For full details and description of the \fBnpm-shrinkwrap.json\fR file format, refer to the manual page for \fBpackage-lock.json\fR \fI\(la/configuring-npm/package-lock-json\(ra\fR.
.SS "See also"
.RS 0
.IP \(bu 4
npm help shrinkwrap
.IP \(bu 4
\fBpackage-lock.json\fR \fI\(la/configuring-npm/package-lock-json\(ra\fR
.IP \(bu 4
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
.IP \(bu 4
npm help install
.RE 0
PK�~�\(�ρ�man5/npmrc.5nu�[���.TH "NPMRC" "5" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpmrc\fR - The npm config files
.SS "Description"
.P
npm gets its config settings from the command line, environment variables, and \fBnpmrc\fR files.
.P
The \fBnpm config\fR command can be used to update and edit the contents of the user and global npmrc files.
.P
For a list of available configuration options, see npm help config.
.SS "Files"
.P
The four relevant files are:
.RS 0
.IP \(bu 4
per-project config file (\fB/path/to/my/project/.npmrc\fR)
.IP \(bu 4
per-user config file (\fB~/.npmrc\fR)
.IP \(bu 4
global config file (\fB$PREFIX/etc/npmrc\fR)
.IP \(bu 4
npm builtin config file (\fB/path/to/npm/npmrc\fR)
.RE 0

.P
All npm config files are an ini-formatted list of \fBkey = value\fR parameters. Environment variables can be replaced using \fB${VARIABLE_NAME}\fR. For example:
.P
.RS 2
.nf
prefix = ${HOME}/.npm-packages
.fi
.RE
.P
Each of these files is loaded, and config options are resolved in priority order. For example, a setting in the userconfig file would override the setting in the globalconfig file.
.P
Array values are specified by adding "\[lB]\[rB]" after the key name. For example:
.P
.RS 2
.nf
key\[lB]\[rB] = "first value"
key\[lB]\[rB] = "second value"
.fi
.RE
.SS "Comments"
.P
Lines in \fB.npmrc\fR files are interpreted as comments when they begin with a \fB;\fR or \fB#\fR character. \fB.npmrc\fR files are parsed by \fBnpm/ini\fR \fI\(lahttps://github.com/npm/ini\(ra\fR, which specifies this comment syntax.
.P
For example:
.P
.RS 2
.nf
# last modified: 01 Jan 2016
; Set a new registry for a scoped package
@myscope:registry=https://mycustomregistry.example.org
.fi
.RE
.SS "Per-project config file"
.P
When working locally in a project, a \fB.npmrc\fR file in the root of the project (ie, a sibling of \fBnode_modules\fR and \fBpackage.json\fR) will set config values specific to this project.
.P
Note that this only applies to the root of the project that you're running npm in. It has no effect when your module is published. For example, you can't publish a module that forces itself to install globally, or in a different location.
.P
Additionally, this file is not read in global mode, such as when running \fBnpm install -g\fR.
.SS "Per-user config file"
.P
\fB$HOME/.npmrc\fR (or the \fBuserconfig\fR param, if set in the environment or on the command line)
.SS "Global config file"
.P
\fB$PREFIX/etc/npmrc\fR (or the \fBglobalconfig\fR param, if set above): This file is an ini-file formatted list of \fBkey = value\fR parameters. Environment variables can be replaced as above.
.SS "Built-in config file"
.P
\fBpath/to/npm/itself/npmrc\fR
.P
This is an unchangeable "builtin" configuration file that npm keeps consistent across updates. Set fields in here using the \fB./configure\fR script that comes with npm. This is primarily for distribution maintainers to override default configs in a standard and consistent manner.
.SS "Auth related configuration"
.P
The settings \fB_auth\fR, \fB_authToken\fR, \fBusername\fR and \fB_password\fR must all be scoped to a specific registry. This ensures that \fBnpm\fR will never send credentials to the wrong host.
.P
The full list is:
.RS 0
.IP \(bu 4
\fB_auth\fR (base64 authentication string)
.IP \(bu 4
\fB_authToken\fR (authentication token)
.IP \(bu 4
\fBusername\fR
.IP \(bu 4
\fB_password\fR
.IP \(bu 4
\fBemail\fR
.IP \(bu 4
\fBcertfile\fR (path to certificate file)
.IP \(bu 4
\fBkeyfile\fR (path to key file)
.RE 0

.P
In order to scope these values, they must be prefixed by a URI fragment. If the credential is meant for any request to a registry on a single host, the scope may look like \fB//registry.npmjs.org/:\fR. If it must be scoped to a specific path on the host that path may also be provided, such as \fB//my-custom-registry.org/unique/path:\fR.
.P
.RS 2
.nf
; bad config
_authToken=MYTOKEN

; good config
@myorg:registry=https://somewhere-else.com/myorg
@another:registry=https://somewhere-else.com/another
//registry.npmjs.org/:_authToken=MYTOKEN
; would apply to both @myorg and @another
; //somewhere-else.com/:_authToken=MYTOKEN
; would apply only to @myorg
//somewhere-else.com/myorg/:_authToken=MYTOKEN1
; would apply only to @another
//somewhere-else.com/another/:_authToken=MYTOKEN2
.fi
.RE
.SS "See also"
.RS 0
.IP \(bu 4
npm help folders
.IP \(bu 4
npm help config
.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 npm
.RE 0
PK�~�\��Lʥ���man5/npm-json.5nu�[���.TH "PACKAGE.JSON" "5" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBpackage.json\fR - Specifics of npm's package.json handling
.SS "Description"
.P
This document is all you need to know about what's required in your package.json file. It must be actual JSON, not just a JavaScript object literal.
.P
A lot of the behavior described in this document is affected by the config settings described in npm help config.
.SS "name"
.P
If you plan to publish your package, the \fImost\fR important things in your package.json are the name and version fields as they will be required. The name and version together form an identifier that is assumed to be completely unique. Changes to the package should come along with changes to the version. If you don't plan to publish your package, the name and version fields are optional.
.P
The name is what your thing is called.
.P
Some rules:
.RS 0
.IP \(bu 4
The name must be less than or equal to 214 characters. This includes the scope for scoped packages.
.IP \(bu 4
The names of scoped packages can begin with a dot or an underscore. This is not permitted without a scope.
.IP \(bu 4
New packages must not have uppercase letters in the name.
.IP \(bu 4
The name ends up being part of a URL, an argument on the command line, and a folder name. Therefore, the name can't contain any non-URL-safe characters.
.RE 0

.P
Some tips:
.RS 0
.IP \(bu 4
Don't use the same name as a core Node module.
.IP \(bu 4
Don't put "js" or "node" in the name. It's assumed that it's js, since you're writing a package.json file, and you can specify the engine using the "\fBengines\fR \fI(engines)\fR" field. (See below.)
.IP \(bu 4
The name will probably be passed as an argument to require(), so it should be something short, but also reasonably descriptive.
.IP \(bu 4
You may want to check the npm registry to see if there's something by that name already, before you get too attached to it. \fI\(lahttps://www.npmjs.com/\(ra\fR
.RE 0

.P
A name can be optionally prefixed by a scope, e.g. \fB@myorg/mypackage\fR. See npm help scope for more detail.
.SS "version"
.P
If you plan to publish your package, the \fImost\fR important things in your package.json are the name and version fields as they will be required. The name and version together form an identifier that is assumed to be completely unique. Changes to the package should come along with changes to the version. If you don't plan to publish your package, the name and version fields are optional.
.P
Version must be parseable by \fBnode-semver\fR \fI\(lahttps://github.com/npm/node-semver\(ra\fR, which is bundled with npm as a dependency. (\fBnpm install semver\fR to use it yourself.)
.SS "description"
.P
Put a description in it. It's a string. This helps people discover your package, as it's listed in \fBnpm search\fR.
.SS "keywords"
.P
Put keywords in it. It's an array of strings. This helps people discover your package as it's listed in \fBnpm search\fR.
.SS "homepage"
.P
The URL to the project homepage.
.P
Example:
.P
.RS 2
.nf
"homepage": "https://github.com/owner/project#readme"
.fi
.RE
.SS "bugs"
.P
The URL to your project's issue tracker and / or the email address to which issues should be reported. These are helpful for people who encounter issues with your package.
.P
It should look like this:
.P
.RS 2
.nf
{
  "bugs": {
    "url": "https://github.com/owner/project/issues",
    "email": "project@hostname.com"
  }
}
.fi
.RE
.P
You can specify either one or both values. If you want to provide only a URL, you can specify the value for "bugs" as a simple string instead of an object.
.P
If a URL is provided, it will be used by the \fBnpm bugs\fR command.
.SS "license"
.P
You should specify a license for your package so that people know how they are permitted to use it, and any restrictions you're placing on it.
.P
If you're using a common license such as BSD-2-Clause or MIT, add a current SPDX license identifier for the license you're using, like this:
.P
.RS 2
.nf
{
  "license" : "BSD-3-Clause"
}
.fi
.RE
.P
You can check \fBthe full list of SPDX license IDs\fR \fI\(lahttps://spdx.org/licenses/\(ra\fR. Ideally you should pick one that is \fBOSI\fR \fI\(lahttps://opensource.org/licenses/\(ra\fR approved.
.P
If your package is licensed under multiple common licenses, use an \fBSPDX license expression syntax version 2.0 string\fR \fI\(lahttps://spdx.dev/specifications/\(ra\fR, like this:
.P
.RS 2
.nf
{
  "license" : "(ISC OR GPL-3.0)"
}
.fi
.RE
.P
If you are using a license that hasn't been assigned an SPDX identifier, or if you are using a custom license, use a string value like this one:
.P
.RS 2
.nf
{
  "license" : "SEE LICENSE IN <filename>"
}
.fi
.RE
.P
Then include a file named \fB<filename>\fR at the top level of the package.
.P
Some old packages used license objects or a "licenses" property containing an array of license objects:
.P
.RS 2
.nf
// Not valid metadata
{
  "license" : {
    "type" : "ISC",
    "url" : "https://opensource.org/licenses/ISC"
  }
}

// Not valid metadata
{
  "licenses" : \[lB]
    {
      "type": "MIT",
      "url": "https://www.opensource.org/licenses/mit-license.php"
    },
    {
      "type": "Apache-2.0",
      "url": "https://opensource.org/licenses/apache2.0.php"
    }
  \[rB]
}
.fi
.RE
.P
Those styles are now deprecated. Instead, use SPDX expressions, like this:
.P
.RS 2
.nf
{
  "license": "ISC"
}
.fi
.RE
.P
.RS 2
.nf
{
  "license": "(MIT OR Apache-2.0)"
}
.fi
.RE
.P
Finally, if you do not wish to grant others the right to use a private or unpublished package under any terms:
.P
.RS 2
.nf
{
  "license": "UNLICENSED"
}
.fi
.RE
.P
Consider also setting \fB"private": true\fR to prevent accidental publication.
.SS "people fields: author, contributors"
.P
The "author" is one person. "contributors" is an array of people. A "person" is an object with a "name" field and optionally "url" and "email", like this:
.P
.RS 2
.nf
{
  "name" : "Barney Rubble",
  "email" : "b@rubble.com",
  "url" : "http://barnyrubble.tumblr.com/"
}
.fi
.RE
.P
Or you can shorten that all into a single string, and npm will parse it for you:
.P
.RS 2
.nf
{
  "author": "Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
}
.fi
.RE
.P
Both email and url are optional either way.
.P
npm also sets a top-level "maintainers" field with your npm user info.
.SS "funding"
.P
You can specify an object containing a URL that provides up-to-date information about ways to help fund development of your package, or a string URL, or an array of these:
.P
.RS 2
.nf
{
  "funding": {
    "type" : "individual",
    "url" : "http://example.com/donate"
  },

"funding": {
    "type" : "patreon",
    "url" : "https://www.patreon.com/my-account"
  },

"funding": "http://example.com/donate",

"funding": \[lB]
    {
      "type" : "individual",
      "url" : "http://example.com/donate"
    },
    "http://example.com/donateAlso",
    {
      "type" : "patreon",
      "url" : "https://www.patreon.com/my-account"
    }
  \[rB]
}
.fi
.RE
.P
Users can use the \fBnpm fund\fR subcommand to list the \fBfunding\fR URLs of all dependencies of their project, direct and indirect. A shortcut to visit each funding url is also available when providing the project name such as: \fBnpm fund <projectname>\fR (when there are multiple URLs, the first one will be visited)
.SS "files"
.P
The optional \fBfiles\fR field is an array of file patterns that describes the entries to be included when your package is installed as a dependency. File patterns follow a similar syntax to \fB.gitignore\fR, but reversed: including a file, directory, or glob pattern (\fB*\fR, \fB**/*\fR, and such) will make it so that file is included in the tarball when it's packed. Omitting the field will make it default to \fB\[lB]"*"\[rB]\fR, which means it will include all files.
.P
Some special files and directories are also included or excluded regardless of whether they exist in the \fBfiles\fR array (see below).
.P
You can also provide a \fB.npmignore\fR file in the root of your package or in subdirectories, which will keep files from being included. At the root of your package it will not override the "files" field, but in subdirectories it will. The \fB.npmignore\fR file works just like a \fB.gitignore\fR. If there is a \fB.gitignore\fR file, and \fB.npmignore\fR is missing, \fB.gitignore\fR's contents will be used instead.
.P
Certain files are always included, regardless of settings:
.RS 0
.IP \(bu 4
\fBpackage.json\fR
.IP \(bu 4
\fBREADME\fR
.IP \(bu 4
\fBLICENSE\fR / \fBLICENCE\fR
.IP \(bu 4
The file in the "main" field
.IP \(bu 4
The file(s) in the "bin" field
.RE 0

.P
\fBREADME\fR & \fBLICENSE\fR can have any case and extension.
.P
Some files are always ignored by default:
.RS 0
.IP \(bu 4
\fB*.orig\fR
.IP \(bu 4
\fB.*.swp\fR
.IP \(bu 4
\fB.DS_Store\fR
.IP \(bu 4
\fB._*\fR
.IP \(bu 4
\fB.git\fR
.IP \(bu 4
\fB.hg\fR
.IP \(bu 4
\fB.lock-wscript\fR
.IP \(bu 4
\fB.npmrc\fR
.IP \(bu 4
\fB.svn\fR
.IP \(bu 4
\fB.wafpickle-N\fR
.IP \(bu 4
\fBCVS\fR
.IP \(bu 4
\fBconfig.gypi\fR
.IP \(bu 4
\fBnode_modules\fR
.IP \(bu 4
\fBnpm-debug.log\fR
.IP \(bu 4
\fBpackage-lock.json\fR (use \fB\fBnpm-shrinkwrap.json\fR\fR \fI\(la/configuring-npm/npm-shrinkwrap-json\(ra\fR if you wish it to be published)
.IP \(bu 4
\fBpnpm-lock.yaml\fR
.IP \(bu 4
\fByarn.lock\fR
.RE 0

.P
Most of these ignored files can be included specifically if included in the \fBfiles\fR globs. Exceptions to this are:
.RS 0
.IP \(bu 4
\fB.git\fR
.IP \(bu 4
\fB.npmrc\fR
.IP \(bu 4
\fBnode_modules\fR
.IP \(bu 4
\fBpackage-lock.json\fR
.IP \(bu 4
\fBpnpm-lock.yaml\fR
.IP \(bu 4
\fByarn.lock\fR
.RE 0

.P
These can not be included.
.SS "main"
.P
The main field is a module ID that is the primary entry point to your program. That is, if your package is named \fBfoo\fR, and a user installs it, and then does \fBrequire("foo")\fR, then your main module's exports object will be returned.
.P
This should be a module relative to the root of your package folder.
.P
For most modules, it makes the most sense to have a main script and often not much else.
.P
If \fBmain\fR is not set, it defaults to \fBindex.js\fR in the package's root folder.
.SS "browser"
.P
If your module is meant to be used client-side the browser field should be used instead of the main field. This is helpful to hint users that it might rely on primitives that aren't available in Node.js modules. (e.g. \fBwindow\fR)
.SS "bin"
.P
A lot of packages have one or more executable files that they'd like to install into the PATH. npm makes this pretty easy (in fact, it uses this feature to install the "npm" executable.)
.P
To use this, supply a \fBbin\fR field in your package.json which is a map of command name to local file name. When this package is installed globally, that file will be either linked inside the global bins directory or a cmd (Windows Command File) will be created which executes the specified file in the \fBbin\fR field, so it is available to run by \fBname\fR or \fBname.cmd\fR (on Windows PowerShell). When this package is installed as a dependency in another package, the file will be linked where it will be available to that package either directly by \fBnpm exec\fR or by name in other scripts when invoking them via \fBnpm run-script\fR.
.P
For example, myapp could have this:
.P
.RS 2
.nf
{
  "bin": {
    "myapp": "bin/cli.js"
  }
}
.fi
.RE
.P
So, when you install myapp, in case of unix-like OS it'll create a symlink from the \fBcli.js\fR script to \fB/usr/local/bin/myapp\fR and in case of windows it will create a cmd file usually at \fBC:\[rs]Users\[rs]{Username}\[rs]AppData\[rs]Roaming\[rs]npm\[rs]myapp.cmd\fR which runs the \fBcli.js\fR script.
.P
If you have a single executable, and its name should be the name of the package, then you can just supply it as a string. For example:
.P
.RS 2
.nf
{
  "name": "my-program",
  "version": "1.2.5",
  "bin": "path/to/program"
}
.fi
.RE
.P
would be the same as this:
.P
.RS 2
.nf
{
  "name": "my-program",
  "version": "1.2.5",
  "bin": {
    "my-program": "path/to/program"
  }
}
.fi
.RE
.P
Please make sure that your file(s) referenced in \fBbin\fR starts with \fB#!/usr/bin/env node\fR, otherwise the scripts are started without the node executable!
.P
Note that you can also set the executable files using \fBdirectories.bin\fR \fI(directories.bin)\fR.
.P
See \fBfolders\fR \fI\(la/configuring-npm/folders#executables\(ra\fR for more info on executables.
.SS "man"
.P
Specify either a single file or an array of filenames to put in place for the \fBman\fR program to find.
.P
If only a single file is provided, then it's installed such that it is the result from \fBman <pkgname>\fR, regardless of its actual filename. For example:
.P
.RS 2
.nf
{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": "./man/doc.1"
}
.fi
.RE
.P
would link the \fB./man/doc.1\fR file in such that it is the target for \fBman
foo\fR
.P
If the filename doesn't start with the package name, then it's prefixed. So, this:
.P
.RS 2
.nf
{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": \[lB]
    "./man/foo.1",
    "./man/bar.1"
  \[rB]
}
.fi
.RE
.P
will create files to do \fBman foo\fR and \fBman foo-bar\fR.
.P
Man files must end with a number, and optionally a \fB.gz\fR suffix if they are compressed. The number dictates which man section the file is installed into.
.P
.RS 2
.nf
{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": \[lB]
    "./man/foo.1",
    "./man/foo.2"
  \[rB]
}
.fi
.RE
.P
will create entries for \fBman foo\fR and \fBman 2 foo\fR
.SS "directories"
.P
The CommonJS \fBPackages\fR \fI\(lahttp://wiki.commonjs.org/wiki/Packages/1.0\(ra\fR spec details a few ways that you can indicate the structure of your package using a \fBdirectories\fR object. If you look at \fBnpm's package.json\fR \fI\(lahttps://registry.npmjs.org/npm/latest\(ra\fR, you'll see that it has directories for doc, lib, and man.
.P
In the future, this information may be used in other creative ways.
.SS "directories.bin"
.P
If you specify a \fBbin\fR directory in \fBdirectories.bin\fR, all the files in that folder will be added.
.P
Because of the way the \fBbin\fR directive works, specifying both a \fBbin\fR path and setting \fBdirectories.bin\fR is an error. If you want to specify individual files, use \fBbin\fR, and for all the files in an existing \fBbin\fR directory, use \fBdirectories.bin\fR.
.SS "directories.man"
.P
A folder that is full of man pages. Sugar to generate a "man" array by walking the folder.
.SS "repository"
.P
Specify the place where your code lives. This is helpful for people who want to contribute. If the git repo is on GitHub, then the \fBnpm repo\fR command will be able to find you.
.P
Do it like this:
.P
.RS 2
.nf
{
  "repository": {
    "type": "git",
    "url": "https://github.com/npm/cli.git"
  }
}
.fi
.RE
.P
The URL should be a publicly available (perhaps read-only) URL that can be handed directly to a VCS program without any modification. It should not be a URL to an html project page that you put in your browser. It's for computers.
.P
For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same shortcut syntax you use for \fBnpm install\fR:
.P
.RS 2
.nf
{
  "repository": "npm/npm",

"repository": "github:user/repo",

"repository": "gist:11081aaa281",

"repository": "bitbucket:user/repo",

"repository": "gitlab:user/repo"
}
.fi
.RE
.P
If the \fBpackage.json\fR for your package is not in the root directory (for example if it is part of a monorepo), you can specify the directory in which it lives:
.P
.RS 2
.nf
{
  "repository": {
    "type": "git",
    "url": "https://github.com/facebook/react.git",
    "directory": "packages/react-dom"
  }
}
.fi
.RE
.SS "scripts"
.P
The "scripts" property is a dictionary containing script commands that are run at various times in the lifecycle of your package. The key is the lifecycle event, and the value is the command to run at that point.
.P
See npm help scripts to find out more about writing package scripts.
.SS "config"
.P
A "config" object can be used to set configuration parameters used in package scripts that persist across upgrades. For instance, if a package had the following:
.P
.RS 2
.nf
{
  "name": "foo",
  "config": {
    "port": "8080"
  }
}
.fi
.RE
.P
It could also have a "start" command that referenced the \fBnpm_package_config_port\fR environment variable.
.SS "dependencies"
.P
Dependencies are specified in a simple object that maps a package name to a version range. The version range is a string which has one or more space-separated descriptors. Dependencies can also be identified with a tarball or git URL.
.P
\fBPlease do not put test harnesses or transpilers or other "development" time tools in your \fBdependencies\fB object.\fR See \fBdevDependencies\fR, below.
.P
See \fBsemver\fR \fI\(lahttps://github.com/npm/node-semver#versions\(ra\fR for more details about specifying version ranges.
.RS 0
.IP \(bu 4
\fBversion\fR Must match \fBversion\fR exactly
.IP \(bu 4
\fB>version\fR Must be greater than \fBversion\fR
.IP \(bu 4
\fB>=version\fR etc
.IP \(bu 4
\fB<version\fR
.IP \(bu 4
\fB<=version\fR
.IP \(bu 4
\fB~version\fR "Approximately equivalent to version" See \fBsemver\fR \fI\(lahttps://github.com/npm/node-semver#versions\(ra\fR
.IP \(bu 4
\fB^version\fR "Compatible with version" See \fBsemver\fR \fI\(lahttps://github.com/npm/node-semver#versions\(ra\fR
.IP \(bu 4
\fB1.2.x\fR 1.2.0, 1.2.1, etc., but not 1.3.0
.IP \(bu 4
\fBhttp://...\fR See 'URLs as Dependencies' below
.IP \(bu 4
\fB*\fR Matches any version
.IP \(bu 4
\fB""\fR (just an empty string) Same as \fB*\fR
.IP \(bu 4
\fBversion1 - version2\fR Same as \fB>=version1 <=version2\fR.
.IP \(bu 4
\fBrange1 || range2\fR Passes if either range1 or range2 are satisfied.
.IP \(bu 4
\fBgit...\fR See 'Git URLs as Dependencies' below
.IP \(bu 4
\fBuser/repo\fR See 'GitHub URLs' below
.IP \(bu 4
\fBtag\fR A specific version tagged and published as \fBtag\fR See npm help dist-tag
.IP \(bu 4
\fBpath/path/path\fR See \fBLocal Paths\fR \fI(Local Paths)\fR below
.RE 0

.P
For example, these are all valid:
.P
.RS 2
.nf
{
  "dependencies": {
    "foo": "1.0.0 - 2.9999.9999",
    "bar": ">=1.0.2 <2.1.2",
    "baz": ">1.0.2 <=2.3.4",
    "boo": "2.0.1",
    "qux": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0",
    "asd": "http://asdf.com/asdf.tar.gz",
    "til": "~1.2",
    "elf": "~1.2.3",
    "two": "2.x",
    "thr": "3.3.x",
    "lat": "latest",
    "dyl": "file:../dyl"
  }
}
.fi
.RE
.SS "URLs as Dependencies"
.P
You may specify a tarball URL in place of a version range.
.P
This tarball will be downloaded and installed locally to your package at install time.
.SS "Git URLs as Dependencies"
.P
Git URLs are of the form:
.P
.RS 2
.nf
<protocol>://\[lB]<user>\[lB]:<password>\[rB]@\[rB]<hostname>\[lB]:<port>\[rB]\[lB]:\[rB]\[lB]/\[rB]<path>\[lB]#<commit-ish> | #semver:<semver>\[rB]
.fi
.RE
.P
\fB<protocol>\fR is one of \fBgit\fR, \fBgit+ssh\fR, \fBgit+http\fR, \fBgit+https\fR, or \fBgit+file\fR.
.P
If \fB#<commit-ish>\fR is provided, it will be used to clone exactly that commit. If the commit-ish has the format \fB#semver:<semver>\fR, \fB<semver>\fR can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. If neither \fB#<commit-ish>\fR or \fB#semver:<semver>\fR is specified, then the default branch is used.
.P
Examples:
.P
.RS 2
.nf
git+ssh://git@github.com:npm/cli.git#v1.0.27
git+ssh://git@github.com:npm/cli#semver:^5.0
git+https://isaacs@github.com/npm/cli.git
git://github.com/npm/cli.git#v1.0.27
.fi
.RE
.P
When installing from a \fBgit\fR repository, the presence of certain fields in the \fBpackage.json\fR will cause npm to believe it needs to perform a build. To do so your repository will be cloned into a temporary directory, all of its deps installed, relevant scripts run, and the resulting directory packed and installed.
.P
This flow will occur if your git dependency uses \fBworkspaces\fR, or if any of the following scripts are present:
.RS 0
.IP \(bu 4
\fBbuild\fR
.IP \(bu 4
\fBprepare\fR
.IP \(bu 4
\fBprepack\fR
.IP \(bu 4
\fBpreinstall\fR
.IP \(bu 4
\fBinstall\fR
.IP \(bu 4
\fBpostinstall\fR
.RE 0

.P
If your git repository includes pre-built artifacts, you will likely want to make sure that none of the above scripts are defined, or your dependency will be rebuilt for every installation.
.SS "GitHub URLs"
.P
As of version 1.1.65, you can refer to GitHub URLs as just "foo": "user/foo-project". Just as with git URLs, a \fBcommit-ish\fR suffix can be included. For example:
.P
.RS 2
.nf
{
  "name": "foo",
  "version": "0.0.0",
  "dependencies": {
    "express": "expressjs/express",
    "mocha": "mochajs/mocha#4727d357ea",
    "module": "user/repo#feature\[rs]/branch"
  }
}
.fi
.RE
.SS "Local Paths"
.P
As of version 2.0.0 you can provide a path to a local directory that contains a package. Local paths can be saved using \fBnpm install -S\fR or \fBnpm
install --save\fR, using any of these forms:
.P
.RS 2
.nf
../foo/bar
~/foo/bar
./foo/bar
/foo/bar
.fi
.RE
.P
in which case they will be normalized to a relative path and added to your \fBpackage.json\fR. For example:
.P
.RS 2
.nf
{
  "name": "baz",
  "dependencies": {
    "bar": "file:../foo/bar"
  }
}
.fi
.RE
.P
This feature is helpful for local offline development and creating tests that require npm installing where you don't want to hit an external server, but should not be used when publishing your package to the public registry.
.P
\fInote\fR: Packages linked by local path will not have their own dependencies installed when \fBnpm install\fR is ran in this case. You must run \fBnpm install\fR from inside the local path itself.
.SS "devDependencies"
.P
If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use.
.P
In this case, it's best to map these additional items in a \fBdevDependencies\fR object.
.P
These things will be installed when doing \fBnpm link\fR or \fBnpm install\fR from the root of a package, and can be managed like any other npm configuration param. See npm help config for more on the topic.
.P
For build steps that are not platform-specific, such as compiling CoffeeScript or other languages to JavaScript, use the \fBprepare\fR script to do this, and make the required package a devDependency.
.P
For example:
.P
.RS 2
.nf
{
  "name": "ethopia-waza",
  "description": "a delightfully fruity coffee varietal",
  "version": "1.2.3",
  "devDependencies": {
    "coffee-script": "~1.6.3"
  },
  "scripts": {
    "prepare": "coffee -o lib/ -c src/waza.coffee"
  },
  "main": "lib/waza.js"
}
.fi
.RE
.P
The \fBprepare\fR script will be run before publishing, so that users can consume the functionality without requiring them to compile it themselves. In dev mode (ie, locally running \fBnpm install\fR), it'll run this script as well, so that you can test it easily.
.SS "peerDependencies"
.P
In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a \fBrequire\fR of this host. This is usually referred to as a \fIplugin\fR. Notably, your module may be exposing a specific interface, expected and specified by the host documentation.
.P
For example:
.P
.RS 2
.nf
{
  "name": "tea-latte",
  "version": "1.3.5",
  "peerDependencies": {
    "tea": "2.x"
  }
}
.fi
.RE
.P
This ensures your package \fBtea-latte\fR can be installed \fIalong\fR with the second major version of the host package \fBtea\fR only. \fBnpm install
tea-latte\fR could possibly yield the following dependency graph:
.P
.RS 2
.nf
├── tea-latte@1.3.5
└── tea@2.2.0
.fi
.RE
.P
In npm versions 3 through 6, \fBpeerDependencies\fR were not automatically installed, and would raise a warning if an invalid version of the peer dependency was found in the tree. As of npm v7, peerDependencies \fIare\fR installed by default.
.P
Trying to install another plugin with a conflicting requirement may cause an error if the tree cannot be resolved correctly. For this reason, make sure your plugin requirement is as broad as possible, and not to lock it down to specific patch versions.
.P
Assuming the host complies with \fBsemver\fR \fI\(lahttps://semver.org/\(ra\fR, only changes in the host package's major version will break your plugin. Thus, if you've worked with every 1.x version of the host package, use \fB"^1.0"\fR or \fB"1.x"\fR to express this. If you depend on features introduced in 1.5.2, use \fB"^1.5.2"\fR.
.SS "peerDependenciesMeta"
.P
The \fBpeerDependenciesMeta\fR field serves to provide npm more information on how your peer dependencies are to be used. Specifically, it allows peer dependencies to be marked as optional. Npm will not automatically install optional peer dependencies. This allows you to integrate and interact with a variety of host packages without requiring all of them to be installed.
.P
For example:
.P
.RS 2
.nf
{
  "name": "tea-latte",
  "version": "1.3.5",
  "peerDependencies": {
    "tea": "2.x",
    "soy-milk": "1.2"
  },
  "peerDependenciesMeta": {
    "soy-milk": {
      "optional": true
    }
  }
}
.fi
.RE
.SS "bundleDependencies"
.P
This defines an array of package names that will be bundled when publishing the package.
.P
In cases where you need to preserve npm packages locally or have them available through a single file download, you can bundle the packages in a tarball file by specifying the package names in the \fBbundleDependencies\fR array and executing \fBnpm pack\fR.
.P
For example:
.P
If we define a package.json like this:
.P
.RS 2
.nf
{
  "name": "awesome-web-framework",
  "version": "1.0.0",
  "bundleDependencies": \[lB]
    "renderized",
    "super-streams"
  \[rB]
}
.fi
.RE
.P
we can obtain \fBawesome-web-framework-1.0.0.tgz\fR file by running \fBnpm pack\fR. This file contains the dependencies \fBrenderized\fR and \fBsuper-streams\fR which can be installed in a new project by executing \fBnpm install
awesome-web-framework-1.0.0.tgz\fR. Note that the package names do not include any versions, as that information is specified in \fBdependencies\fR.
.P
If this is spelled \fB"bundledDependencies"\fR, then that is also honored.
.P
Alternatively, \fB"bundleDependencies"\fR can be defined as a boolean value. A value of \fBtrue\fR will bundle all dependencies, a value of \fBfalse\fR will bundle none.
.SS "optionalDependencies"
.P
If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the \fBoptionalDependencies\fR object. This is a map of package name to version or URL, just like the \fBdependencies\fR object. The difference is that build failures do not cause installation to fail. Running \fBnpm install
--omit=optional\fR will prevent these dependencies from being installed.
.P
It is still your program's responsibility to handle the lack of the dependency. For example, something like this:
.P
.RS 2
.nf
try {
  var foo = require('foo')
  var fooVersion = require('foo/package.json').version
} catch (er) {
  foo = null
}
if ( notGoodFooVersion(fooVersion) ) {
  foo = null
}

// .. then later in your program ..

if (foo) {
  foo.doFooThings()
}
.fi
.RE
.P
Entries in \fBoptionalDependencies\fR will override entries of the same name in \fBdependencies\fR, so it's usually best to only put in one place.
.SS "overrides"
.P
If you need to make specific changes to dependencies of your dependencies, for example replacing the version of a dependency with a known security issue, replacing an existing dependency with a fork, or making sure that the same version of a package is used everywhere, then you may add an override.
.P
Overrides provide a way to replace a package in your dependency tree with another version, or another package entirely. These changes can be scoped as specific or as vague as desired.
.P
Overrides are only considered in the root \fBpackage.json\fR file for a project. Overrides in installed dependencies (including npm help workspaces) are not considered in dependency tree resolution. Published packages may dictate their resolutions by pinning dependencies or using an \fB\fBnpm-shrinkwrap.json\fR\fR \fI\(la/configuring-npm/npm-shrinkwrap-json\(ra\fR file.
.P
To make sure the package \fBfoo\fR is always installed as version \fB1.0.0\fR no matter what version your dependencies rely on:
.P
.RS 2
.nf
{
  "overrides": {
    "foo": "1.0.0"
  }
}
.fi
.RE
.P
The above is a short hand notation, the full object form can be used to allow overriding a package itself as well as a child of the package. This will cause \fBfoo\fR to always be \fB1.0.0\fR while also making \fBbar\fR at any depth beyond \fBfoo\fR also \fB1.0.0\fR:
.P
.RS 2
.nf
{
  "overrides": {
    "foo": {
      ".": "1.0.0",
      "bar": "1.0.0"
    }
  }
}
.fi
.RE
.P
To only override \fBfoo\fR to be \fB1.0.0\fR when it's a child (or grandchild, or great grandchild, etc) of the package \fBbar\fR:
.P
.RS 2
.nf
{
  "overrides": {
    "bar": {
      "foo": "1.0.0"
    }
  }
}
.fi
.RE
.P
Keys can be nested to any arbitrary length. To override \fBfoo\fR only when it's a child of \fBbar\fR and only when \fBbar\fR is a child of \fBbaz\fR:
.P
.RS 2
.nf
{
  "overrides": {
    "baz": {
      "bar": {
        "foo": "1.0.0"
      }
    }
  }
}
.fi
.RE
.P
The key of an override can also include a version, or range of versions. To override \fBfoo\fR to \fB1.0.0\fR, but only when it's a child of \fBbar@2.0.0\fR:
.P
.RS 2
.nf
{
  "overrides": {
    "bar@2.0.0": {
      "foo": "1.0.0"
    }
  }
}
.fi
.RE
.P
You may not set an override for a package that you directly depend on unless both the dependency and the override itself share the exact same spec. To make this limitation easier to deal with, overrides may also be defined as a reference to a spec for a direct dependency by prefixing the name of the package you wish the version to match with a \fB$\fR.
.P
.RS 2
.nf
{
  "dependencies": {
    "foo": "^1.0.0"
  },
  "overrides": {
    // BAD, will throw an EOVERRIDE error
    // "foo": "^2.0.0"
    // GOOD, specs match so override is allowed
    // "foo": "^1.0.0"
    // BEST, the override is defined as a reference to the dependency
    "foo": "$foo",
    // the referenced package does not need to match the overridden one
    "bar": "$foo"
  }
}
.fi
.RE
.SS "engines"
.P
You can specify the version of node that your stuff works on:
.P
.RS 2
.nf
{
  "engines": {
    "node": ">=0.10.3 <15"
  }
}
.fi
.RE
.P
And, like with dependencies, if you don't specify the version (or if you specify "*" as the version), then any version of node will do.
.P
You can also use the "engines" field to specify which versions of npm are capable of properly installing your program. For example:
.P
.RS 2
.nf
{
  "engines": {
    "npm": "~1.0.20"
  }
}
.fi
.RE
.P
Unless the user has set the \fB\fBengine-strict\fR config\fR \fI\(la/using-npm/config#engine-strict\(ra\fR flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.
.SS "os"
.P
You can specify which operating systems your module will run on:
.P
.RS 2
.nf
{
  "os": \[lB]
    "darwin",
    "linux"
  \[rB]
}
.fi
.RE
.P
You can also block instead of allowing operating systems, just prepend the blocked os with a '!':
.P
.RS 2
.nf
{
  "os": \[lB]
    "!win32"
  \[rB]
}
.fi
.RE
.P
The host operating system is determined by \fBprocess.platform\fR
.P
It is allowed to both block and allow an item, although there isn't any good reason to do this.
.SS "cpu"
.P
If your code only runs on certain cpu architectures, you can specify which ones.
.P
.RS 2
.nf
{
  "cpu": \[lB]
    "x64",
    "ia32"
  \[rB]
}
.fi
.RE
.P
Like the \fBos\fR option, you can also block architectures:
.P
.RS 2
.nf
{
  "cpu": \[lB]
    "!arm",
    "!mips"
  \[rB]
}
.fi
.RE
.P
The host architecture is determined by \fBprocess.arch\fR
.SS "private"
.P
If you set \fB"private": true\fR in your package.json, then npm will refuse to publish it.
.P
This is a way to prevent accidental publication of private repositories. If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the \fBpublishConfig\fR dictionary described below to override the \fBregistry\fR config param at publish-time.
.SS "publishConfig"
.P
This is a set of config values that will be used at publish-time. It's especially handy if you want to set the tag, registry or access, so that you can ensure that a given package is not tagged with "latest", published to the global public registry or that a scoped module is private by default.
.P
See npm help config to see the list of config options that can be overridden.
.SS "workspaces"
.P
The optional \fBworkspaces\fR field is an array of file patterns that describes locations within the local file system that the install client should look up to find each npm help workspace that needs to be symlinked to the top level \fBnode_modules\fR folder.
.P
It can describe either the direct paths of the folders to be used as workspaces or it can define globs that will resolve to these same folders.
.P
In the following example, all folders located inside the folder \fB./packages\fR will be treated as workspaces as long as they have valid \fBpackage.json\fR files inside them:
.P
.RS 2
.nf
{
  "name": "workspace-example",
  "workspaces": \[lB]
    "./packages/*"
  \[rB]
}
.fi
.RE
.P
See npm help workspaces for more examples.
.SS "DEFAULT VALUES"
.P
npm will default some values based on package contents.
.RS 0
.IP \(bu 4
\fB"scripts": {"start": "node server.js"}\fR
.P
If there is a \fBserver.js\fR file in the root of your package, then npm will default the \fBstart\fR command to \fBnode server.js\fR.
.IP \(bu 4
\fB"scripts":{"install": "node-gyp rebuild"}\fR
.P
If there is a \fBbinding.gyp\fR file in the root of your package and you have not defined an \fBinstall\fR or \fBpreinstall\fR script, npm will default the \fBinstall\fR command to compile using node-gyp.
.IP \(bu 4
\fB"contributors": \[lB]...\[rB]\fR
.P
If there is an \fBAUTHORS\fR file in the root of your package, npm will treat each line as a \fBName <email> (url)\fR format, where email and url are optional. Lines which start with a \fB#\fR or are blank, will be ignored.
.RE 0

.SS "SEE ALSO"
.RS 0
.IP \(bu 4
\fBsemver\fR \fI\(lahttps://github.com/npm/node-semver#versions\(ra\fR
.IP \(bu 4
npm help workspaces
.IP \(bu 4
npm help init
.IP \(bu 4
npm help version
.IP \(bu 4
npm help config
.IP \(bu 4
npm help help
.IP \(bu 4
npm help install
.IP \(bu 4
npm help publish
.IP \(bu 4
npm help uninstall
.RE 0
PK�~�\��.G�*�*man5/package-lock-json.5nu�[���.TH "PACKAGE-LOCK.JSON" "5" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBpackage-lock.json\fR - A manifestation of the manifest
.SS "Description"
.P
\fBpackage-lock.json\fR is automatically generated for any operations where npm modifies either the \fBnode_modules\fR tree, or \fBpackage.json\fR. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
.P
This file is intended to be committed into source repositories, and serves various purposes:
.RS 0
.IP \(bu 4
Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
.IP \(bu 4
Provide a facility for users to "time-travel" to previous states of \fBnode_modules\fR without having to commit the directory itself.
.IP \(bu 4
Facilitate greater visibility of tree changes through readable source control diffs.
.IP \(bu 4
Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
.IP \(bu 4
As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read \fBpackage.json\fR files, and allowing for significant performance improvements.
.RE 0

.P
When \fBnpm\fR creates or updates \fBpackage-lock.json\fR, it will infer line endings and indentation from \fBpackage.json\fR so that the formatting of both files matches.
.SS "\fBpackage-lock.json\fR vs \fBnpm-shrinkwrap.json\fR"
.P
Both of these files have the same format, and perform similar functions in the root of a project.
.P
The difference is that \fBpackage-lock.json\fR cannot be published, and it will be ignored if found in any place other than the root project.
.P
In contrast, \fBnpm-shrinkwrap.json\fR \fI\(la/configuring-npm/npm-shrinkwrap-json\(ra\fR allows publication, and defines the dependency tree from the point encountered. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.
.P
If both \fBpackage-lock.json\fR and \fBnpm-shrinkwrap.json\fR are present in the root of a project, \fBnpm-shrinkwrap.json\fR will take precedence and \fBpackage-lock.json\fR will be ignored.
.SS "Hidden Lockfiles"
.P
In order to avoid processing the \fBnode_modules\fR folder repeatedly, npm as of v7 uses a "hidden" lockfile present in \fBnode_modules/.package-lock.json\fR. This contains information about the tree, and is used in lieu of reading the entire \fBnode_modules\fR hierarchy provided that the following conditions are met:
.RS 0
.IP \(bu 4
All package folders it references exist in the \fBnode_modules\fR hierarchy.
.IP \(bu 4
No package folders exist in the \fBnode_modules\fR hierarchy that are not listed in the lockfile.
.IP \(bu 4
The modified time of the file is at least as recent as all of the package folders it references.
.RE 0

.P
That is, the hidden lockfile will only be relevant if it was created as part of the most recent update to the package tree. If another CLI mutates the tree in any way, this will be detected, and the hidden lockfile will be ignored.
.P
Note that it \fIis\fR possible to manually change the \fIcontents\fR of a package in such a way that the modified time of the package folder is unaffected. For example, if you add a file to \fBnode_modules/foo/lib/bar.js\fR, then the modified time on \fBnode_modules/foo\fR will not reflect this change. If you are manually editing files in \fBnode_modules\fR, it is generally best to delete the file at \fBnode_modules/.package-lock.json\fR.
.P
As the hidden lockfile is ignored by older npm versions, it does not contain the backwards compatibility affordances present in "normal" lockfiles. That is, it is \fBlockfileVersion: 3\fR, rather than \fBlockfileVersion: 2\fR.
.SS "Handling Old Lockfiles"
.P
When npm detects a lockfile from npm v6 or before during the package installation process, it is automatically updated to fetch missing information from either the \fBnode_modules\fR tree or (in the case of empty \fBnode_modules\fR trees or very old lockfile formats) the npm registry.
.SS "File Format"
.SS "\fBname\fR"
.P
The name of the package this is a package-lock for. This will match what's in \fBpackage.json\fR.
.SS "\fBversion\fR"
.P
The version of the package this is a package-lock for. This will match what's in \fBpackage.json\fR.
.SS "\fBlockfileVersion\fR"
.P
An integer version, starting at \fB1\fR with the version number of this document whose semantics were used when generating this \fBpackage-lock.json\fR.
.P
Note that the file format changed significantly in npm v7 to track information that would have otherwise required looking in \fBnode_modules\fR or the npm registry. Lockfiles generated by npm v7 will contain \fBlockfileVersion: 2\fR.
.RS 0
.IP \(bu 4
No version provided: an "ancient" shrinkwrap file from a version of npm prior to npm v5.
.IP \(bu 4
\fB1\fR: The lockfile version used by npm v5 and v6.
.IP \(bu 4
\fB2\fR: The lockfile version used by npm v7 and v8. Backwards compatible to v1 lockfiles.
.IP \(bu 4
\fB3\fR: The lockfile version used by npm v9 and above. Backwards compatible to npm v7.
.RE 0

.P
npm will always attempt to get whatever data it can out of a lockfile, even if it is not a version that it was designed to support.
.SS "\fBpackages\fR"
.P
This is an object that maps package locations to an object containing the information about that package.
.P
The root project is typically listed with a key of \fB""\fR, and all other packages are listed with their relative paths from the root project folder.
.P
Package descriptors have the following fields:
.RS 0
.IP \(bu 4
version: The version found in \fBpackage.json\fR
.IP \(bu 4
resolved: The place where the package was actually resolved from. In the case of packages fetched from the registry, this will be a url to a tarball. In the case of git dependencies, this will be the full git url with commit sha. In the case of link dependencies, this will be the location of the link target. \fBregistry.npmjs.org\fR is a magic value meaning "the currently configured registry".
.IP \(bu 4
integrity: A \fBsha512\fR or \fBsha1\fR \fBStandard Subresource Integrity\fR \fI\(lahttps://w3c.github.io/webappsec/specs/subresourceintegrity/\(ra\fR string for the artifact that was unpacked in this location.
.IP \(bu 4
link: A flag to indicate that this is a symbolic link. If this is present, no other fields are specified, since the link target will also be included in the lockfile.
.IP \(bu 4
dev, optional, devOptional: If the package is strictly part of the \fBdevDependencies\fR tree, then \fBdev\fR will be true. If it is strictly part of the \fBoptionalDependencies\fR tree, then \fBoptional\fR will be set. If it is both a \fBdev\fR dependency \fIand\fR an \fBoptional\fR dependency of a non-dev dependency, then \fBdevOptional\fR will be set. (An \fBoptional\fR dependency of a \fBdev\fR dependency will have both \fBdev\fR and \fBoptional\fR set.)
.IP \(bu 4
inBundle: A flag to indicate that the package is a bundled dependency.
.IP \(bu 4
hasInstallScript: A flag to indicate that the package has a \fBpreinstall\fR, \fBinstall\fR, or \fBpostinstall\fR script.
.IP \(bu 4
hasShrinkwrap: A flag to indicate that the package has an \fBnpm-shrinkwrap.json\fR file.
.IP \(bu 4
bin, license, engines, dependencies, optionalDependencies: fields from \fBpackage.json\fR
.RE 0

.SS "dependencies"
.P
Legacy data for supporting versions of npm that use \fBlockfileVersion: 1\fR. This is a mapping of package names to dependency objects. Because the object structure is strictly hierarchical, symbolic link dependencies are somewhat challenging to represent in some cases.
.P
npm v7 ignores this section entirely if a \fBpackages\fR section is present, but does keep it up to date in order to support switching between npm v6 and npm v7.
.P
Dependency objects have the following fields:
.RS 0
.IP \(bu 4
version: a specifier that varies depending on the nature of the package, and is usable in fetching a new copy of it.
.RS 4
.IP \(bu 4
bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.
.IP \(bu 4
registry sources: This is a version number. (eg, \fB1.2.3\fR)
.IP \(bu 4
git sources: This is a git specifier with resolved committish. (eg, \fBgit+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e\fR)
.IP \(bu 4
http tarball sources: This is the URL of the tarball. (eg, \fBhttps://example.com/example-1.3.0.tgz\fR)
.IP \(bu 4
local tarball sources: This is the file URL of the tarball. (eg \fBfile:///opt/storage/example-1.3.0.tgz\fR)
.IP \(bu 4
local link sources: This is the file URL of the link. (eg \fBfile:libs/our-module\fR)
.RE 0

.IP \(bu 4
integrity: A \fBsha512\fR or \fBsha1\fR \fBStandard Subresource Integrity\fR \fI\(lahttps://w3c.github.io/webappsec/specs/subresourceintegrity/\(ra\fR string for the artifact that was unpacked in this location. For git dependencies, this is the commit sha.
.IP \(bu 4
resolved: For registry sources this is path of the tarball relative to the registry URL. If the tarball URL isn't on the same server as the registry URL then this is a complete URL. \fBregistry.npmjs.org\fR is a magic value meaning "the currently configured registry".
.IP \(bu 4
bundled: If true, this is the bundled dependency and will be installed by the parent module. When installing, this module will be extracted from the parent module during the extract phase, not installed as a separate dependency.
.IP \(bu 4
dev: If true then this dependency is either a development dependency ONLY of the top level module or a transitive dependency of one. This is false for dependencies that are both a development dependency of the top level and a transitive dependency of a non-development dependency of the top level.
.IP \(bu 4
optional: If true then this dependency is either an optional dependency ONLY of the top level module or a transitive dependency of one. This is false for dependencies that are both an optional dependency of the top level and a transitive dependency of a non-optional dependency of the top level.
.IP \(bu 4
requires: This is a mapping of module name to version. This is a list of everything this module requires, regardless of where it will be installed. The version should match via normal matching rules a dependency either in our \fBdependencies\fR or in a level higher than us.
.IP \(bu 4
dependencies: The dependencies of this dependency, exactly as at the top level.
.RE 0

.SS "See also"
.RS 0
.IP \(bu 4
npm help shrinkwrap
.IP \(bu 4
\fBnpm-shrinkwrap.json\fR \fI\(la/configuring-npm/npm-shrinkwrap-json\(ra\fR
.IP \(bu 4
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
.IP \(bu 4
npm help install
.RE 0
PK�~�\�Y�""man5/npm-global.5nu�[���.TH "FOLDERS" "5" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBfolders\fR - Folder Structures Used by npm
.SS "Description"
.P
npm puts various things on your computer. That's its job.
.P
This document will tell you what it puts where.
.SS "tl;dr"
.RS 0
.IP \(bu 4
Local install (default): puts stuff in \fB./node_modules\fR of the current package root.
.IP \(bu 4
Global install (with \fB-g\fR): puts stuff in /usr/local or wherever node is installed.
.IP \(bu 4
Install it \fBlocally\fR if you're going to \fBrequire()\fR it.
.IP \(bu 4
Install it \fBglobally\fR if you're going to run it on the command line.
.IP \(bu 4
If you need both, then install it in both places, or use \fBnpm link\fR.
.RE 0

.SS "prefix Configuration"
.P
The \fB\fBprefix\fR config\fR \fI\(la/using-npm/config#prefix\(ra\fR defaults to the location where node is installed. On most systems, this is \fB/usr/local\fR. On Windows, it's \fB%AppData%\[rs]npm\fR. On Unix systems, it's one level up, since node is typically installed at \fB{prefix}/bin/node\fR rather than \fB{prefix}/node.exe\fR.
.P
When the \fBglobal\fR flag is set, npm installs things into this prefix. When it is not set, it uses the root of the current package, or the current working directory if not in a package already.
.SS "Node Modules"
.P
Packages are dropped into the \fBnode_modules\fR folder under the \fBprefix\fR. When installing locally, this means that you can \fBrequire("packagename")\fR to load its main module, or \fBrequire("packagename/lib/path/to/sub/module")\fR to load other modules.
.P
Global installs on Unix systems go to \fB{prefix}/lib/node_modules\fR. Global installs on Windows go to \fB{prefix}/node_modules\fR (that is, no \fBlib\fR folder.)
.P
Scoped packages are installed the same way, except they are grouped together in a sub-folder of the relevant \fBnode_modules\fR folder with the name of that scope prefix by the @ symbol, e.g. \fBnpm install @myorg/package\fR would place the package in \fB{prefix}/node_modules/@myorg/package\fR. See npm help scope for more details.
.P
If you wish to \fBrequire()\fR a package, then install it locally.
.SS "Executables"
.P
When in global mode, executables are linked into \fB{prefix}/bin\fR on Unix, or directly into \fB{prefix}\fR on Windows. Ensure that path is in your terminal's \fBPATH\fR environment to run them.
.P
When in local mode, executables are linked into \fB./node_modules/.bin\fR so that they can be made available to scripts run through npm. (For example, so that a test runner will be in the path when you run \fBnpm test\fR.)
.SS "Man Pages"
.P
When in global mode, man pages are linked into \fB{prefix}/share/man\fR.
.P
When in local mode, man pages are not installed.
.P
Man pages are not installed on Windows systems.
.SS "Cache"
.P
See npm help cache. Cache files are stored in \fB~/.npm\fR on Posix, or \fB%LocalAppData%/npm-cache\fR on Windows.
.P
This is controlled by the \fB\fBcache\fR config\fR \fI\(la/using-npm/config#cache\(ra\fR param.
.SS "Temp Files"
.P
Temporary files are stored by default in the folder specified by the \fB\fBtmp\fR config\fR \fI\(la/using-npm/config#tmp\(ra\fR, which defaults to the TMPDIR, TMP, or TEMP environment variables, or \fB/tmp\fR on Unix and \fBc:\[rs]windows\[rs]temp\fR on Windows.
.P
Temp files are given a unique folder under this root for each run of the program, and are deleted upon successful exit.
.SS "More Information"
.P
When installing locally, npm first tries to find an appropriate \fBprefix\fR folder. This is so that \fBnpm install foo@1.2.3\fR will install to the sensible root of your package, even if you happen to have \fBcd\fRed into some other folder.
.P
Starting at the $PWD, npm will walk up the folder tree checking for a folder that contains either a \fBpackage.json\fR file, or a \fBnode_modules\fR folder. If such a thing is found, then that is treated as the effective "current directory" for the purpose of running npm commands. (This behavior is inspired by and similar to git's .git-folder seeking logic when running git commands in a working dir.)
.P
If no package root is found, then the current folder is used.
.P
When you run \fBnpm install foo@1.2.3\fR, then the package is loaded into the cache, and then unpacked into \fB./node_modules/foo\fR. Then, any of foo's dependencies are similarly unpacked into \fB./node_modules/foo/node_modules/...\fR.
.P
Any bin files are symlinked to \fB./node_modules/.bin/\fR, so that they may be found by npm scripts when necessary.
.SS "Global Installation"
.P
If the \fB\fBglobal\fR config\fR \fI\(la/using-npm/config#global\(ra\fR is set to true, then npm will install packages "globally".
.P
For global installation, packages are installed roughly the same way, but using the folders described above.
.SS "Cycles, Conflicts, and Folder Parsimony"
.P
Cycles are handled using the property of node's module system that it walks up the directories looking for \fBnode_modules\fR folders. So, at every stage, if a package is already installed in an ancestor \fBnode_modules\fR folder, then it is not installed at the current location.
.P
Consider the case above, where \fBfoo -> bar -> baz\fR. Imagine if, in addition to that, baz depended on bar, so you'd have: \fBfoo -> bar -> baz -> bar -> baz ...\fR. However, since the folder structure is: \fBfoo/node_modules/bar/node_modules/baz\fR, there's no need to put another copy of bar into \fB.../baz/node_modules\fR, since when baz calls \fBrequire("bar")\fR, it will get the copy that is installed in \fBfoo/node_modules/bar\fR.
.P
This shortcut is only used if the exact same version would be installed in multiple nested \fBnode_modules\fR folders. It is still possible to have \fBa/node_modules/b/node_modules/a\fR if the two "a" packages are different versions. However, without repeating the exact same package multiple times, an infinite regress will always be prevented.
.P
Another optimization can be made by installing dependencies at the highest level possible, below the localized "target" folder (hoisting). Since version 3, npm hoists dependencies by default.
.SS "Example"
.P
Consider this dependency graph:
.P
.RS 2
.nf
foo
+-- blerg@1.2.5
+-- bar@1.2.3
|   +-- blerg@1.x (latest=1.3.7)
|   +-- baz@2.x
|   |   `-- quux@3.x
|   |       `-- bar@1.2.3 (cycle)
|   `-- asdf@*
`-- baz@1.2.3
    `-- quux@3.x
        `-- bar
.fi
.RE
.P
In this case, we might expect a folder structure like this (with all dependencies hoisted to the highest level possible):
.P
.RS 2
.nf
foo
+-- node_modules
    +-- blerg (1.2.5) <---\[lB]A\[rB]
    +-- bar (1.2.3) <---\[lB]B\[rB]
    |   +-- node_modules
    |       +-- baz (2.0.2) <---\[lB]C\[rB]
    +-- asdf (2.3.4)
    +-- baz (1.2.3) <---\[lB]D\[rB]
    +-- quux (3.2.0) <---\[lB]E\[rB]
.fi
.RE
.P
Since foo depends directly on \fBbar@1.2.3\fR and \fBbaz@1.2.3\fR, those are installed in foo's \fBnode_modules\fR folder.
.P
Even though the latest copy of blerg is 1.3.7, foo has a specific dependency on version 1.2.5. So, that gets installed at \[lB]A\[rB]. Since the parent installation of blerg satisfies bar's dependency on \fBblerg@1.x\fR, it does not install another copy under \[lB]B\[rB].
.P
Bar \[lB]B\[rB] also has dependencies on baz and asdf. Because it depends on \fBbaz@2.x\fR, it cannot re-use the \fBbaz@1.2.3\fR installed in the parent \fBnode_modules\fR folder \[lB]D\[rB], and must install its own copy \[lB]C\[rB]. In order to minimize duplication, npm hoists dependencies to the top level by default, so asdf is installed under \[lB]A\[rB].
.P
Underneath bar, the \fBbaz -> quux -> bar\fR dependency creates a cycle. However, because bar is already in quux's ancestry \[lB]B\[rB], it does not unpack another copy of bar into that folder. Likewise, quux's \[lB]E\[rB] folder tree is empty, because its dependency on bar is satisfied by the parent folder copy installed at \[lB]B\[rB].
.P
For a graphical breakdown of what is installed where, use \fBnpm ls\fR.
.SS "Publishing"
.P
Upon publishing, npm will look in the \fBnode_modules\fR folder. If any of the items there are not in the \fBbundleDependencies\fR array, then they will not be included in the package tarball.
.P
This allows a package maintainer to install all of their dependencies (and dev dependencies) locally, but only re-publish those items that cannot be found elsewhere. See \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR for more information.
.SS "See also"
.RS 0
.IP \(bu 4
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
.IP \(bu 4
npm help install
.IP \(bu 4
npm help pack
.IP \(bu 4
npm help cache
.IP \(bu 4
npm help config
.IP \(bu 4
npm help npmrc
.IP \(bu 4
npm help config
.IP \(bu 4
npm help publish
.RE 0
PK�~�\&Oף##man5/install.5nu�[���.TH "INSTALL" "5" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBinstall\fR - Download and install node and npm
.SS "Description"
.P
To publish and install packages to and from the public npm registry, you must install Node.js and the npm command line interface using either a Node version manager or a Node installer. \fBWe strongly recommend using a Node version manager to install Node.js and npm.\fR We do not recommend using a Node installer, since the Node installation process installs npm in a directory with local permissions and can cause permissions errors when you run npm packages globally.
.SS "Overview"
.RS 0
.IP \(bu 4
\fBChecking your version of npm and Node.js\fR \fI(Checking your version of npm and Node.js)\fR
.IP \(bu 4
\fBUsing a Node version manager to install Node.js and npm\fR \fI(Using a Node version manager to install Node.js and npm)\fR
.IP \(bu 4
\fBUsing a Node installer to install Node.js and npm\fR \fI(Using a Node installer to install Node.js and npm)\fR
.RE 0

.SS "Checking your version of npm and Node.js"
.P
To see if you already have Node.js and npm installed and check the installed version, run the following commands:
.P
.RS 2
.nf
node -v
npm -v
.fi
.RE
.SS "Using a Node version manager to install Node.js and npm"
.P
Node version managers allow you to install and switch between multiple versions of Node.js and npm on your system so you can test your applications on multiple versions of npm to ensure they work for users on different versions. You can \fBsearch for them on GitHub\fR \fI\(lahttps://github.com/search?q=node+version+manager+archived%3Afalse&type=repositories&ref=advsearch\(ra\fR.
.SS "Using a Node installer to install Node.js and npm"
.P
If you are unable to use a Node version manager, you can use a Node installer to install both Node.js and npm on your system.
.RS 0
.IP \(bu 4
\fBNode.js installer\fR \fI\(lahttps://nodejs.org/en/download/\(ra\fR
.IP \(bu 4
\fBNodeSource installer\fR \fI\(lahttps://github.com/nodesource/distributions\(ra\fR. If you use Linux, we recommend that you use a NodeSource installer.
.RE 0

.SS "OS X or Windows Node installers"
.P
If you're using OS X or Windows, use one of the installers from the \fBNode.js download page\fR \fI\(lahttps://nodejs.org/en/download/\(ra\fR. Be sure to install the version labeled \fBLTS\fR. Other versions have not yet been tested with npm.
.SS "Linux or other operating systems Node installers"
.P
If you're using Linux or another operating system, use one of the following installers:
.RS 0
.IP \(bu 4
\fBNodeSource installer\fR \fI\(lahttps://github.com/nodesource/distributions\(ra\fR (recommended)
.IP \(bu 4
One of the installers on the \fBNode.js download page\fR \fI\(lahttps://nodejs.org/en/download/\(ra\fR
.RE 0

.P
Or see \fBthis page\fR \fI\(lahttps://nodejs.org/en/download/package-manager/\(ra\fR to install npm for Linux in the way many Linux developers prefer.
.SS "Less-common operating systems"
.P
For more information on installing Node.js on a variety of operating systems, see \fBthis page\fR \fI\(lahttps://nodejs.org/en/download/package-manager/\(ra\fR.
PK�~�\��Lʥ���man5/package-json.5nu�[���.TH "PACKAGE.JSON" "5" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBpackage.json\fR - Specifics of npm's package.json handling
.SS "Description"
.P
This document is all you need to know about what's required in your package.json file. It must be actual JSON, not just a JavaScript object literal.
.P
A lot of the behavior described in this document is affected by the config settings described in npm help config.
.SS "name"
.P
If you plan to publish your package, the \fImost\fR important things in your package.json are the name and version fields as they will be required. The name and version together form an identifier that is assumed to be completely unique. Changes to the package should come along with changes to the version. If you don't plan to publish your package, the name and version fields are optional.
.P
The name is what your thing is called.
.P
Some rules:
.RS 0
.IP \(bu 4
The name must be less than or equal to 214 characters. This includes the scope for scoped packages.
.IP \(bu 4
The names of scoped packages can begin with a dot or an underscore. This is not permitted without a scope.
.IP \(bu 4
New packages must not have uppercase letters in the name.
.IP \(bu 4
The name ends up being part of a URL, an argument on the command line, and a folder name. Therefore, the name can't contain any non-URL-safe characters.
.RE 0

"funding": {
    "type" : "patreon",
    "url" : "https://www.patreon.com/my-account"
  },

"funding": "http://example.com/donate",

"repository": "github:user/repo",

"repository": "gist:11081aaa281",

"repository": "bitbucket:user/repo",

// .. then later in your program ..

.SS "prefix Configuration"
.P
The \fB\fBprefix\fR config\fR \fI\(la/using-npm/config#prefix\(ra\fR defaults to the location where node is installed. On most systems, this is \fB/usr/local\fR. On Windows, it's \fB%AppData%\[rs]npm\fR. On Unix systems, it's one level up, since node is typically installed at \fB{prefix}/bin/node\fR rather than \fB{prefix}/node.exe\fR.
.P
When the \fBglobal\fR flag is set, npm installs things into this prefix. When it is not set, it uses the root of the current package, or the current working directory if not in a package already.
.SS "Node Modules"
.P
Packages are dropped into the \fBnode_modules\fR folder under the \fBprefix\fR. When installing locally, this means that you can \fBrequire("packagename")\fR to load its main module, or \fBrequire("packagename/lib/path/to/sub/module")\fR to load other modules.
.P
Global installs on Unix systems go to \fB{prefix}/lib/node_modules\fR. Global installs on Windows go to \fB{prefix}/node_modules\fR (that is, no \fBlib\fR folder.)
.P
Scoped packages are installed the same way, except they are grouped together in a sub-folder of the relevant \fBnode_modules\fR folder with the name of that scope prefix by the @ symbol, e.g. \fBnpm install @myorg/package\fR would place the package in \fB{prefix}/node_modules/@myorg/package\fR. See npm help scope for more details.
.P
If you wish to \fBrequire()\fR a package, then install it locally.
.SS "Executables"
.P
When in global mode, executables are linked into \fB{prefix}/bin\fR on Unix, or directly into \fB{prefix}\fR on Windows. Ensure that path is in your terminal's \fBPATH\fR environment to run them.
.P
When in local mode, executables are linked into \fB./node_modules/.bin\fR so that they can be made available to scripts run through npm. (For example, so that a test runner will be in the path when you run \fBnpm test\fR.)
.SS "Man Pages"
.P
When in global mode, man pages are linked into \fB{prefix}/share/man\fR.
.P
When in local mode, man pages are not installed.
.P
Man pages are not installed on Windows systems.
.SS "Cache"
.P
See npm help cache. Cache files are stored in \fB~/.npm\fR on Posix, or \fB%LocalAppData%/npm-cache\fR on Windows.
.P
This is controlled by the \fB\fBcache\fR config\fR \fI\(la/using-npm/config#cache\(ra\fR param.
.SS "Temp Files"
.P
Temporary files are stored by default in the folder specified by the \fB\fBtmp\fR config\fR \fI\(la/using-npm/config#tmp\(ra\fR, which defaults to the TMPDIR, TMP, or TEMP environment variables, or \fB/tmp\fR on Unix and \fBc:\[rs]windows\[rs]temp\fR on Windows.
.P
Temp files are given a unique folder under this root for each run of the program, and are deleted upon successful exit.
.SS "More Information"
.P
When installing locally, npm first tries to find an appropriate \fBprefix\fR folder. This is so that \fBnpm install foo@1.2.3\fR will install to the sensible root of your package, even if you happen to have \fBcd\fRed into some other folder.
.P
Starting at the $PWD, npm will walk up the folder tree checking for a folder that contains either a \fBpackage.json\fR file, or a \fBnode_modules\fR folder. If such a thing is found, then that is treated as the effective "current directory" for the purpose of running npm commands. (This behavior is inspired by and similar to git's .git-folder seeking logic when running git commands in a working dir.)
.P
If no package root is found, then the current folder is used.
.P
When you run \fBnpm install foo@1.2.3\fR, then the package is loaded into the cache, and then unpacked into \fB./node_modules/foo\fR. Then, any of foo's dependencies are similarly unpacked into \fB./node_modules/foo/node_modules/...\fR.
.P
Any bin files are symlinked to \fB./node_modules/.bin/\fR, so that they may be found by npm scripts when necessary.
.SS "Global Installation"
.P
If the \fB\fBglobal\fR config\fR \fI\(la/using-npm/config#global\(ra\fR is set to true, then npm will install packages "globally".
.P
For global installation, packages are installed roughly the same way, but using the folders described above.
.SS "Cycles, Conflicts, and Folder Parsimony"
.P
Cycles are handled using the property of node's module system that it walks up the directories looking for \fBnode_modules\fR folders. So, at every stage, if a package is already installed in an ancestor \fBnode_modules\fR folder, then it is not installed at the current location.
.P
Consider the case above, where \fBfoo -> bar -> baz\fR. Imagine if, in addition to that, baz depended on bar, so you'd have: \fBfoo -> bar -> baz -> bar -> baz ...\fR. However, since the folder structure is: \fBfoo/node_modules/bar/node_modules/baz\fR, there's no need to put another copy of bar into \fB.../baz/node_modules\fR, since when baz calls \fBrequire("bar")\fR, it will get the copy that is installed in \fBfoo/node_modules/bar\fR.
.P
This shortcut is only used if the exact same version would be installed in multiple nested \fBnode_modules\fR folders. It is still possible to have \fBa/node_modules/b/node_modules/a\fR if the two "a" packages are different versions. However, without repeating the exact same package multiple times, an infinite regress will always be prevented.
.P
Another optimization can be made by installing dependencies at the highest level possible, below the localized "target" folder (hoisting). Since version 3, npm hoists dependencies by default.
.SS "Example"
.P
Consider this dependency graph:
.P
.RS 2
.nf
foo
+-- blerg@1.2.5
+-- bar@1.2.3
|   +-- blerg@1.x (latest=1.3.7)
|   +-- baz@2.x
|   |   `-- quux@3.x
|   |       `-- bar@1.2.3 (cycle)
|   `-- asdf@*
`-- baz@1.2.3
    `-- quux@3.x
        `-- bar
.fi
.RE
.P
In this case, we might expect a folder structure like this (with all dependencies hoisted to the highest level possible):
.P
.RS 2
.nf
foo
+-- node_modules
    +-- blerg (1.2.5) <---\[lB]A\[rB]
    +-- bar (1.2.3) <---\[lB]B\[rB]
    |   +-- node_modules
    |       +-- baz (2.0.2) <---\[lB]C\[rB]
    +-- asdf (2.3.4)
    +-- baz (1.2.3) <---\[lB]D\[rB]
    +-- quux (3.2.0) <---\[lB]E\[rB]
.fi
.RE
.P
Since foo depends directly on \fBbar@1.2.3\fR and \fBbaz@1.2.3\fR, those are installed in foo's \fBnode_modules\fR folder.
.P
Even though the latest copy of blerg is 1.3.7, foo has a specific dependency on version 1.2.5. So, that gets installed at \[lB]A\[rB]. Since the parent installation of blerg satisfies bar's dependency on \fBblerg@1.x\fR, it does not install another copy under \[lB]B\[rB].
.P
Bar \[lB]B\[rB] also has dependencies on baz and asdf. Because it depends on \fBbaz@2.x\fR, it cannot re-use the \fBbaz@1.2.3\fR installed in the parent \fBnode_modules\fR folder \[lB]D\[rB], and must install its own copy \[lB]C\[rB]. In order to minimize duplication, npm hoists dependencies to the top level by default, so asdf is installed under \[lB]A\[rB].
.P
Underneath bar, the \fBbaz -> quux -> bar\fR dependency creates a cycle. However, because bar is already in quux's ancestry \[lB]B\[rB], it does not unpack another copy of bar into that folder. Likewise, quux's \[lB]E\[rB] folder tree is empty, because its dependency on bar is satisfied by the parent folder copy installed at \[lB]B\[rB].
.P
For a graphical breakdown of what is installed where, use \fBnpm ls\fR.
.SS "Publishing"
.P
Upon publishing, npm will look in the \fBnode_modules\fR folder. If any of the items there are not in the \fBbundleDependencies\fR array, then they will not be included in the package tarball.
.P
This allows a package maintainer to install all of their dependencies (and dev dependencies) locally, but only re-publish those items that cannot be found elsewhere. See \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR for more information.
.SS "See also"
.RS 0
.IP \(bu 4
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
.IP \(bu 4
npm help install
.IP \(bu 4
npm help pack
.IP \(bu 4
npm help cache
.IP \(bu 4
npm help config
.IP \(bu 4
npm help npmrc
.IP \(bu 4
npm help config
.IP \(bu 4
npm help publish
.RE 0
PK�~�\Ѳ1##man1/npm-unpublish.1nu�[���.TH "NPM-UNPUBLISH" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-unpublish\fR - Remove a package from the registry
.SS "Synopsis"
.P
.RS 2
.nf
npm unpublish \[lB]<package-spec>\[rB]
.fi
.RE
.P
To learn more about how the npm registry treats unpublish, see our \fBunpublish policies\fR \fI\(lahttps://docs.npmjs.com/policies/unpublish\(ra\fR.
.SS "Warning"
.P
Consider using the npm help deprecate command instead, if your intent is to encourage users to upgrade, or if you no longer want to maintain a package.
.SS "Description"
.P
This removes a package version from the registry, deleting its entry and removing the tarball.
.P
The npm registry will return an error if you are not npm help "logged in".
.P
If you do not specify a package name at all, the name and version to be unpublished will be pulled from the project in the current directory.
.P
If you specify a package name but do not specify a version or if you remove all of a package's versions then the registry will remove the root package entry entirely.
.P
Even if you unpublish a package version, that specific name and version combination can never be reused. In order to publish the package again, you must use a new version number. If you unpublish the entire package, you may not publish any new versions of that package until 24 hours have passed.
.SS "Configuration"
.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
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 "\fBworkspace\fR"
.RS 0
.IP \(bu 4
Default:
.IP \(bu 4
Type: String (can be set multiple times)
.RE 0

.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 deprecate
.IP \(bu 4
npm help publish
.IP \(bu 4
npm help registry
.IP \(bu 4
npm help adduser
.IP \(bu 4
npm help owner
.IP \(bu 4
npm help login
.RE 0
PK�~�\���V��man1/npm-doctor.1nu�[���.TH "NPM-DOCTOR" "1" "May 2024" "NPM@10.8.1" ""
.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
PK�~�\�Z��**man1/npm-start.1nu�[���.TH "NPM-START" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-start\fR - Start a package
.SS "Synopsis"
.P
.RS 2
.nf
npm start \[lB]-- <args>\[rB]
.fi
.RE
.SS "Description"
.P
This runs a predefined command specified in the \fB"start"\fR property of a package's \fB"scripts"\fR object.
.P
If the \fB"scripts"\fR object does not define a \fB"start"\fR property, npm will run \fBnode server.js\fR.
.P
Note that this is different from the default node behavior of running the file specified in a package's \fB"main"\fR attribute when evoking with \fBnode .\fR
.P
As of \fB\fBnpm@2.0.0\fR\fR \fI\(lahttps://blog.npmjs.org/post/98131109725/npm-2-0-0\(ra\fR, you can use custom arguments when executing scripts. Refer to npm help run-script for more details.
.SS "Example"
.P
.RS 2
.nf
{
  "scripts": {
    "start": "node foo.js"
  }
}
.fi
.RE
.P
.RS 2
.nf
npm start

> npm@x.x.x start
> node foo.js

(foo.js output would be here)

.fi
.RE
.SS "Configuration"
.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-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
.SS "\fBscript-shell\fR"
.RS 0
.IP \(bu 4
Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
.IP \(bu 4
Type: null or String
.RE 0

.P
The base URL of the npm registry.
.SS "\fBunicode\fR"
.RS 0
.IP \(bu 4
Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the \fBLC_ALL\fR, \fBLC_CTYPE\fR, or \fBLANG\fR environment variables.
.IP \(bu 4
Type: Boolean
.RE 0

.P
When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
.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 "See Also"
.RS 0
.IP \(bu 4
npm help star
.IP \(bu 4
npm help stars
.IP \(bu 4
npm help view
.IP \(bu 4
npm help whoami
.IP \(bu 4
npm help adduser
.RE 0
PK�~�\G�c$*&*&man1/npm-diff.1nu�[���.TH "NPM-DIFF" "1" "May 2024" "NPM@10.8.1" ""
.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\fBnpm-outdated\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
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

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

aliases: up, upgrade, udpate
.fi
.RE
.SS "Description"
.P
This command will update all the packages listed to the latest version (specified by the \fB\fBtag\fR config\fR \fI\(la/using-npm/config#tag\(ra\fR), respecting the semver constraints of both your package and its dependencies (if they also require the same package).
.P
It will also install missing packages.
.P
If the \fB-g\fR flag is specified, this command will update globally installed packages.
.P
If no package name is specified, all packages in the specified location (global or local) will be updated.
.P
Note that by default \fBnpm update\fR will not update the semver values of direct dependencies in your project \fBpackage.json\fR. If you want to also update values in \fBpackage.json\fR you can run: \fBnpm update --save\fR (or add the \fBsave=true\fR option to a npm help "configuration file" to make that the default behavior).
.SS "Example"
.P
For the examples below, assume that the current package is \fBapp\fR and it depends on dependencies, \fBdep1\fR (\fBdep2\fR, .. etc.). The published versions of \fBdep1\fR are:
.P
.RS 2
.nf
{
  "dist-tags": { "latest": "1.2.2" },
  "versions": \[lB]
    "1.2.2",
    "1.2.1",
    "1.2.0",
    "1.1.2",
    "1.1.1",
    "1.0.0",
    "0.4.1",
    "0.4.0",
    "0.2.0"
  \[rB]
}
.fi
.RE
.SS "Caret Dependencies"
.P
If \fBapp\fR's \fBpackage.json\fR contains:
.P
.RS 2
.nf
"dependencies": {
  "dep1": "^1.1.1"
}
.fi
.RE
.P
Then \fBnpm update\fR will install \fBdep1@1.2.2\fR, because \fB1.2.2\fR is \fBlatest\fR and \fB1.2.2\fR satisfies \fB^1.1.1\fR.
.SS "Tilde Dependencies"
.P
However, if \fBapp\fR's \fBpackage.json\fR contains:
.P
.RS 2
.nf
"dependencies": {
  "dep1": "~1.1.1"
}
.fi
.RE
.P
In this case, running \fBnpm update\fR will install \fBdep1@1.1.2\fR. Even though the \fBlatest\fR tag points to \fB1.2.2\fR, this version does not satisfy \fB~1.1.1\fR, which is equivalent to \fB>=1.1.1 <1.2.0\fR. So the highest-sorting version that satisfies \fB~1.1.1\fR is used, which is \fB1.1.2\fR.
.SS "Caret Dependencies below 1.0.0"
.P
Suppose \fBapp\fR has a caret dependency on a version below \fB1.0.0\fR, for example:
.P
.RS 2
.nf
"dependencies": {
  "dep1": "^0.2.0"
}
.fi
.RE
.P
\fBnpm update\fR will install \fBdep1@0.2.0\fR.
.P
If the dependence were on \fB^0.4.0\fR:
.P
.RS 2
.nf
"dependencies": {
  "dep1": "^0.4.0"
}
.fi
.RE
.P
Then \fBnpm update\fR will install \fBdep1@0.4.1\fR, because that is the highest-sorting version that satisfies \fB^0.4.0\fR (\fB>= 0.4.0 <0.5.0\fR)
.SS "Subdependencies"
.P
Suppose your app now also has a dependency on \fBdep2\fR
.P
.RS 2
.nf
{
  "name": "my-app",
  "dependencies": {
      "dep1": "^1.0.0",
      "dep2": "1.0.0"
  }
}
.fi
.RE
.P
and \fBdep2\fR itself depends on this limited range of \fBdep1\fR
.P
.RS 2
.nf
{
"name": "dep2",
  "dependencies": {
    "dep1": "~1.1.1"
  }
}
.fi
.RE
.P
Then \fBnpm update\fR will install \fBdep1@1.1.2\fR because that is the highest version that \fBdep2\fR allows. npm will prioritize having a single version of \fBdep1\fR in your tree rather than two when that single version can satisfy the semver requirements of multiple dependencies in your tree. In this case if you really did need your package to use a newer version you would need to use \fBnpm install\fR.
.SS "Updating Globally-Installed Packages"
.P
\fBnpm update -g\fR will apply the \fBupdate\fR action to each globally installed package that is \fBoutdated\fR -- that is, has a version that is different from \fBwanted\fR.
.P
Note: Globally installed packages are treated as if they are installed with a caret semver range specified. So if you require to update to \fBlatest\fR you may need to run \fBnpm install -g \[lB]<pkg>...\[rB]\fR
.P
NOTE: If a package has been upgraded to a version newer than \fBlatest\fR, it will be \fIdowngraded\fR.
.SS "Configuration"
.SS "\fBsave\fR"
.RS 0
.IP \(bu 4
Default: \fBtrue\fR unless when using \fBnpm update\fR where it defaults to \fBfalse\fR
.IP \(bu 4
Type: Boolean
.RE 0

.P
Save installed packages to a \fBpackage.json\fR file as dependencies.
.P
When used with the \fBnpm rm\fR command, removes the dependency from \fBpackage.json\fR.
.P
Will also prevent writing to \fBpackage-lock.json\fR if set to \fBfalse\fR.
.SS "\fBglobal\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.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 "\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 "\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-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
.SS "\fBaudit\fR"
.RS 0
.IP \(bu 4
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
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
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
PK�~�\�B]��man1/npm-shrinkwrap.1nu�[���.TH "NPM-SHRINKWRAP" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-shrinkwrap\fR - Lock down dependency versions for publication
.SS "Synopsis"
.P
.RS 2
.nf
npm shrinkwrap
.fi
.RE
.P
Note: This command is unaware of workspaces.
.SS "Description"
.P
This command repurposes \fBpackage-lock.json\fR into a publishable \fBnpm-shrinkwrap.json\fR or simply creates a new one. The file created and updated by this command will then take precedence over any other existing or future \fBpackage-lock.json\fR files. For a detailed explanation of the design and purpose of package locks in npm, see npm help package-lock-json.
.SS "See Also"
.RS 0
.IP \(bu 4
npm help install
.IP \(bu 4
npm help run-script
.IP \(bu 4
npm help scripts
.IP \(bu 4
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
.IP \(bu 4
\fBpackage-lock.json\fR \fI\(la/configuring-npm/package-lock-json\(ra\fR
.IP \(bu 4
\fBnpm-shrinkwrap.json\fR \fI\(la/configuring-npm/npm-shrinkwrap-json\(ra\fR
.IP \(bu 4
npm help ls
.RE 0
PK�~�\��y		man1/npm-org.1nu�[���.TH "NPM-ORG" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-org\fR - Manage orgs
.SS "Synopsis"
.P
.RS 2
.nf
npm org set orgname username \[lB]developer | admin | owner\[rB]
npm org rm orgname username
npm org ls orgname \[lB]<username>\[rB]

alias: ogr
.fi
.RE
.P
Note: This command is unaware of workspaces.
.SS "Example"
.P
Add a new developer to an org:
.P
.RS 2
.nf
$ npm org set my-org @mx-smith
.fi
.RE
.P
Add a new admin to an org (or change a developer to an admin):
.P
.RS 2
.nf
$ npm org set my-org @mx-santos admin
.fi
.RE
.P
Remove a user from an org:
.P
.RS 2
.nf
$ npm org rm my-org mx-santos
.fi
.RE
.P
List all users in an org:
.P
.RS 2
.nf
$ npm org ls my-org
.fi
.RE
.P
List all users in JSON format:
.P
.RS 2
.nf
$ npm org ls my-org --json
.fi
.RE
.P
See what role a user has in an org:
.P
.RS 2
.nf
$ npm org ls my-org @mx-santos
.fi
.RE
.SS "Description"
.P
You can use the \fBnpm org\fR commands to manage and view users of an organization. It supports adding and removing users, changing their roles, listing them, and finding specific ones and their roles.
.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
Not supported by all npm commands.
.SS "\fBparseable\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
.SS "See Also"
.RS 0
.IP \(bu 4
npm help "using orgs"
.IP \(bu 4
\fBDocumentation on npm Orgs\fR \fI\(lahttps://docs.npmjs.com/orgs/\(ra\fR
.RE 0
PK�~�\j|g####man1/npm-sbom.1nu�[���.TH "NPM-SBOM" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-sbom\fR - Generate a Software Bill of Materials (SBOM)
.SS "Synopsis"
.P
.RS 2
.nf
npm sbom
.fi
.RE
.SS "Description"
.P
The \fBnpm sbom\fR command generates a Software Bill of Materials (SBOM) listing the dependencies for the current project. SBOMs can be generated in either \fBSPDX\fR \fI\(lahttps://spdx.dev/\(ra\fR or \fBCycloneDX\fR \fI\(lahttps://cyclonedx.org/\(ra\fR format.
.SS "Example CycloneDX SBOM"
.P
.RS 2
.nf
{
  "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:09f55116-97e1-49cf-b3b8-44d0207e7730",
  "version": 1,
  "metadata": {
    "timestamp": "2023-09-01T00:00:00.001Z",
    "lifecycles": \[lB]
      {
        "phase": "build"
      }
    \[rB],
    "tools": \[lB]
      {
        "vendor": "npm",
        "name": "cli",
        "version": "10.1.0"
      }
    \[rB],
    "component": {
      "bom-ref": "simple@1.0.0",
      "type": "library",
      "name": "simple",
      "version": "1.0.0",
      "scope": "required",
      "author": "John Doe",
      "description": "simple react app",
      "purl": "pkg:npm/simple@1.0.0",
      "properties": \[lB]
        {
          "name": "cdx:npm:package:path",
          "value": ""
        }
      \[rB],
      "externalReferences": \[lB]\[rB],
      "licenses": \[lB]
        {
          "license": {
            "id": "MIT"
          }
        }
      \[rB]
    }
  },
  "components": \[lB]
    {
      "bom-ref": "lodash@4.17.21",
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "scope": "required",
      "author": "John-David Dalton",
      "description": "Lodash modular utilities.",
      "purl": "pkg:npm/lodash@4.17.21",
      "properties": \[lB]
        {
          "name": "cdx:npm:package:path",
          "value": "node_modules/lodash"
        }
      \[rB],
      "externalReferences": \[lB]
        {
          "type": "distribution",
          "url": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz"
        },
        {
          "type": "vcs",
          "url": "git+https://github.com/lodash/lodash.git"
        },
        {
          "type": "website",
          "url": "https://lodash.com/"
        },
        {
          "type": "issue-tracker",
          "url": "https://github.com/lodash/lodash/issues"
        }
      \[rB],
      "hashes": \[lB]
        {
          "alg": "SHA-512",
          "content": "bf690311ee7b95e713ba568322e3533f2dd1cb880b189e99d4edef13592b81764daec43e2c54c61d5c558dc5cfb35ecb85b65519e74026ff17675b6f8f916f4a"
        }
      \[rB],
      "licenses": \[lB]
        {
          "license": {
            "id": "MIT"
          }
        }
      \[rB]
    }
  \[rB],
  "dependencies": \[lB]
    {
      "ref": "simple@1.0.0",
      "dependsOn": \[lB]
        "lodash@4.17.21"
      \[rB]
    },
    {
      "ref": "lodash@4.17.21",
      "dependsOn": \[lB]\[rB]
    }
  \[rB]
}
.fi
.RE
.SS "Example SPDX SBOM"
.P
.RS 2
.nf
{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "simple@1.0.0",
  "documentNamespace": "http://spdx.org/spdxdocs/simple-1.0.0-bf81090e-8bbc-459d-bec9-abeb794e096a",
  "creationInfo": {
    "created": "2023-09-01T00:00:00.001Z",
    "creators": \[lB]
      "Tool: npm/cli-10.1.0"
    \[rB]
  },
  "documentDescribes": \[lB]
    "SPDXRef-Package-simple-1.0.0"
  \[rB],
  "packages": \[lB]
    {
      "name": "simple",
      "SPDXID": "SPDXRef-Package-simple-1.0.0",
      "versionInfo": "1.0.0",
      "packageFileName": "",
      "description": "simple react app",
      "primaryPackagePurpose": "LIBRARY",
      "downloadLocation": "NOASSERTION",
      "filesAnalyzed": false,
      "homepage": "NOASSERTION",
      "licenseDeclared": "MIT",
      "externalRefs": \[lB]
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/simple@1.0.0"
        }
      \[rB]
    },
    {
      "name": "lodash",
      "SPDXID": "SPDXRef-Package-lodash-4.17.21",
      "versionInfo": "4.17.21",
      "packageFileName": "node_modules/lodash",
      "description": "Lodash modular utilities.",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "filesAnalyzed": false,
      "homepage": "https://lodash.com/",
      "licenseDeclared": "MIT",
      "externalRefs": \[lB]
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/lodash@4.17.21"
        }
      \[rB],
      "checksums": \[lB]
        {
          "algorithm": "SHA512",
          "checksumValue": "bf690311ee7b95e713ba568322e3533f2dd1cb880b189e99d4edef13592b81764daec43e2c54c61d5c558dc5cfb35ecb85b65519e74026ff17675b6f8f916f4a"
        }
      \[rB]
    }
  \[rB],
  "relationships": \[lB]
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relatedSpdxElement": "SPDXRef-Package-simple-1.0.0",
      "relationshipType": "DESCRIBES"
    },
    {
      "spdxElementId": "SPDXRef-Package-simple-1.0.0",
      "relatedSpdxElement": "SPDXRef-Package-lodash-4.17.21",
      "relationshipType": "DEPENDS_ON"
    }
  \[rB]
}
.fi
.RE
.SS "Package lock only mode"
.P
If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. This means that information from the package.json files of your dependencies will not be included in the result set (e.g. description, homepage, engines).
.SS "Configuration"
.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 "\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 "\fBsbom-format\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: "cyclonedx" or "spdx"
.RE 0

.P
SBOM format to use when generating SBOMs.
.SS "\fBsbom-type\fR"
.RS 0
.IP \(bu 4
Default: "library"
.IP \(bu 4
Type: "library", "application", or "framework"
.RE 0

.P
The type of package described by the generated SBOM. For SPDX, this is the value for the \fBprimaryPackagePurpose\fR field. For CycloneDX, this is the value for the \fBtype\fR field.
.SS "\fBworkspace\fR"
.RS 0
.IP \(bu 4
Default:
.IP \(bu 4
Type: String (can be set multiple times)
.RE 0

.P
This value is not exported to the environment for child processes.
.SH "SEE ALSO"
.RS 0
.IP \(bu 4
npm help "package spec"
.IP \(bu 4
npm help "dependency selectors"
.IP \(bu 4
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
.IP \(bu 4
npm help workspaces
.RE 0
PK�~�\��Ra�C�Cman1/npm-audit.1nu�[���.TH "NPM-AUDIT" "1" "May 2024" "NPM@10.8.1" ""
.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
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
\fBkeydid\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\fB--omit\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\fB@npmcli/metavuln-calculator\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\fBaudit-level\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
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
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-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
.SS "\fBworkspace\fR"
.RS 0
.IP \(bu 4
Default:
.IP \(bu 4
Type: String (can be set multiple times)
.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
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
PK�~�\�����man1/npm-outdated.1nu�[���.TH "NPM-OUTDATED" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-outdated\fR - Check for outdated packages
.SS "Synopsis"
.P
.RS 2
.nf
npm outdated \[lB]<package-spec> ...\[rB]
.fi
.RE
.SS "Description"
.P
This command will check the registry to see if any (or, specific) installed packages are currently outdated.
.P
By default, only the direct dependencies of the root project and direct dependencies of your configured \fIworkspaces\fR are shown. Use \fB--all\fR to find all outdated meta-dependencies as well.
.P
In the output:
.RS 0
.IP \(bu 4
\fBwanted\fR is the maximum version of the package that satisfies the semver range specified in \fBpackage.json\fR. If there's no available semver range (i.e. you're running \fBnpm outdated --global\fR, or the package isn't included in \fBpackage.json\fR), then \fBwanted\fR shows the currently-installed version.
.IP \(bu 4
\fBlatest\fR is the version of the package tagged as latest in the registry. Running \fBnpm publish\fR with no special configuration will publish the package with a dist-tag of \fBlatest\fR. This may or may not be the maximum version of the package, or the most-recently published version of the package, depending on how the package's developer manages the latest npm help dist-tag.
.IP \(bu 4
\fBlocation\fR is where in the physical tree the package is located.
.IP \(bu 4
\fBdepended by\fR shows which package depends on the displayed dependency
.IP \(bu 4
\fBpackage type\fR (when using \fB--long\fR / \fB-l\fR) tells you whether this package is a \fBdependency\fR or a dev/peer/optional dependency. Packages not included in \fBpackage.json\fR are always marked \fBdependencies\fR.
.IP \(bu 4
\fBhomepage\fR (when using \fB--long\fR / \fB-l\fR) is the \fBhomepage\fR value contained in the package's packument
.IP \(bu 4
Red means there's a newer version matching your semver requirements, so you should update now.
.IP \(bu 4
Yellow indicates that there's a newer version \fIabove\fR your semver requirements (usually new major, or new 0.x minor) so proceed with caution.
.RE 0

.SS "An example"
.P
.RS 2
.nf
$ npm outdated
Package      Current   Wanted   Latest  Location                  Depended by
glob          5.0.15   5.0.15    6.0.1  node_modules/glob         dependent-package-name
nothingness    0.0.3      git      git  node_modules/nothingness  dependent-package-name
npm            3.5.1    3.5.2    3.5.1  node_modules/npm          dependent-package-name
local-dev      0.0.3   linked   linked  local-dev                 dependent-package-name
once           1.3.2    1.3.3    1.3.3  node_modules/once         dependent-package-name
.fi
.RE
.P
With these \fBdependencies\fR:
.P
.RS 2
.nf
{
  "glob": "^5.0.15",
  "nothingness": "github:othiym23/nothingness#master",
  "npm": "^3.5.1",
  "once": "^1.3.1"
}
.fi
.RE
.P
A few things to note:
.RS 0
.IP \(bu 4
\fBglob\fR requires \fB^5\fR, which prevents npm from installing \fBglob@6\fR, which is outside the semver range.
.IP \(bu 4
Git dependencies will always be reinstalled, because of how they're specified. The installed committish might satisfy the dependency specifier (if it's something immutable, like a commit SHA), or it might not, so \fBnpm outdated\fR and \fBnpm update\fR have to fetch Git repos to check. This is why currently doing a reinstall of a Git dependency always forces a new clone and install.
.IP \(bu 4
\fBnpm@3.5.2\fR is marked as "wanted", but "latest" is \fBnpm@3.5.1\fR because npm uses dist-tags to manage its \fBlatest\fR and \fBnext\fR release channels. \fBnpm update\fR will install the \fInewest\fR version, but \fBnpm install npm\fR (with no semver range) will install whatever's tagged as \fBlatest\fR.
.IP \(bu 4
\fBonce\fR is just plain out of date. Reinstalling \fBnode_modules\fR from scratch or running \fBnpm update\fR will bring it up to spec.
.RE 0

.SS "Configuration"
.SS "\fBall\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
When running \fBnpm outdated\fR and \fBnpm ls\fR, setting \fB--all\fR will show all outdated or installed packages, rather than only those directly depended upon by the current project.
.SS "\fBjson\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Not supported by all npm commands.
.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 "\fBparseable\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
.SS "\fBglobal\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.SS "\fBworkspace\fR"
.RS 0
.IP \(bu 4
Default:
.IP \(bu 4
Type: String (can be set multiple times)
.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 update
.IP \(bu 4
npm help dist-tag
.IP \(bu 4
npm help registry
.IP \(bu 4
npm help folders
.IP \(bu 4
npm help workspaces
.RE 0
PK�~�\��f!xxman1/npm-explain.1nu�[���.TH "NPM-EXPLAIN" "1" "May 2024" "NPM@10.8.1" ""
.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
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
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
PK�~�\E_�"
"
man1/npm-owner.1nu�[���.TH "NPM-OWNER" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-owner\fR - Manage package owners
.SS "Synopsis"
.P
.RS 2
.nf
npm owner add <user> <package-spec>
npm owner rm <user> <package-spec>
npm owner ls <package-spec>

alias: author
.fi
.RE
.SS "Description"
.P
Manage ownership of published packages.
.RS 0
.IP \(bu 4
ls: List all the users who have access to modify a package and push new versions. Handy when you need to know who to bug for help.
.IP \(bu 4
add: Add a new user as a maintainer of a package. This user is enabled to modify metadata, publish new versions, and add other owners.
.IP \(bu 4
rm: Remove a user from the package owner list. This immediately revokes their privileges.
.RE 0

.P
Note that there is only one level of access. Either you can modify a package, or you can't. Future versions may contain more fine-grained access levels, but that is not implemented at this time.
.P
If you have two-factor authentication enabled with \fBauth-and-writes\fR (see npm help npm-profile) then you'll need to go through a second factor flow when changing ownership or include an otp on the command line with \fB--otp\fR.
.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 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 profile
.IP \(bu 4
npm help publish
.IP \(bu 4
npm help registry
.IP \(bu 4
npm help adduser
.RE 0
PK�~�\[,��qqman1/npm-token.1nu�[���.TH "NPM-TOKEN" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-token\fR - Manage your authentication tokens
.SS "Synopsis"
.P
.RS 2
.nf
npm token list
npm token revoke <id|token>
npm token create \[lB]--read-only\[rB] \[lB]--cidr=list\[rB]
.fi
.RE
.P
Note: This command is unaware of workspaces.
.SS "Description"
.P
This lets you list, create and revoke authentication tokens.
.RS 0
.IP \(bu 4
\fBnpm token list\fR: Shows a table of all active authentication tokens. You can request this as JSON with \fB--json\fR or tab-separated values with \fB--parseable\fR.
.RE 0

.P
.RS 2
.nf
Read only token npm_1f… with id 7f3134 created 2017-10-21

Publish token npm_af…  with id c03241 created 2017-10-02
with IP Whitelist: 192.168.0.1/24

Publish token npm_… with id e0cf92 created 2017-10-02

.fi
.RE
.RS 0
.IP \(bu 4
\fBnpm token create \[lB]--read-only\[rB] \[lB]--cidr=<cidr-ranges>\[rB]\fR: Create a new authentication token. It can be \fB--read-only\fR, or accept a list of \fBCIDR\fR \fI\(lahttps://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing\(ra\fR ranges with which to limit use of this token. This will prompt you for your password, and, if you have two-factor authentication enabled, an otp.
.P
Currently, the cli can not generate automation tokens. Please refer to the \fBdocs website\fR \fI\(lahttps://docs.npmjs.com/creating-and-viewing-access-tokens\(ra\fR for more information on generating automation tokens.
.RE 0

.P
.RS 2
.nf
Created publish token a73c9572-f1b9-8983-983d-ba3ac3cc913d
.fi
.RE
.RS 0
.IP \(bu 4
\fBnpm token revoke <token|id>\fR: Immediately removes an authentication token from the registry. You will no longer be able to use it. This can accept both complete tokens (such as those you get back from \fBnpm token create\fR, and those found in your \fB.npmrc\fR), and ids as seen in the parseable or json output of \fBnpm token list\fR. This will NOT accept the truncated token found in the normal \fBnpm token list\fR output.
.RE 0

.SS "Configuration"
.SS "\fBread-only\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
This is used to mark a token as unable to publish when configuring limited access tokens with the \fBnpm token create\fR command.
.SS "\fBcidr\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String (can be set multiple times)
.RE 0

.P
This is a list of CIDR address to be used when configuring limited access tokens with the \fBnpm token create\fR command.
.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
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

# 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 "See Also"
.RS 0
.IP \(bu 4
npm help adduser
.IP \(bu 4
npm help registry
.IP \(bu 4
npm help config
.IP \(bu 4
npm help whoami
.RE 0
PK�~�\L��2
2
man1/npm-bugs.1nu�[���.TH "NPM-BUGS" "1" "May 2024" "NPM@10.8.1" ""
.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\fB--browser\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: OS X: \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
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

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 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
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
PK�~�\����@@man1/npm-explore.1nu�[���.TH "NPM-EXPLORE" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-explore\fR - Browse an installed package
.SS "Synopsis"
.P
.RS 2
.nf
npm explore <pkg> \[lB] -- <command>\[rB]
.fi
.RE
.P
Note: This command is unaware of workspaces.
.SS "Description"
.P
Spawn a subshell in the directory of the installed package specified.
.P
If a command is specified, then it is run in the subshell, which then immediately terminates.
.P
This is particularly handy in the case of git submodules in the \fBnode_modules\fR folder:
.P
.RS 2
.nf
npm explore some-dependency -- git pull origin master
.fi
.RE
.P
Note that the package is \fInot\fR automatically rebuilt afterwards, so be sure to use \fBnpm rebuild <pkg>\fR if you make any changes.
.SS "Configuration"
.SS "\fBshell\fR"
.RS 0
.IP \(bu 4
Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" on Windows
.IP \(bu 4
Type: String
.RE 0

.P
The shell to run for the \fBnpm explore\fR command.
.SS "See Also"
.RS 0
.IP \(bu 4
npm help folders
.IP \(bu 4
npm help edit
.IP \(bu 4
npm help rebuild
.IP \(bu 4
npm help install
.RE 0
PK�~�\�=�man1/npm-dist-tag.1nu�[���.TH "NPM-DIST-TAG" "1" "May 2024" "NPM@10.8.1" ""
.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\fB--tag\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
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

> npm@x.x.x stop
> node bar.js

(bar.js output would be here)

.fi
.RE
.SS "Configuration"
.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-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
.SS "\fBscript-shell\fR"
.RS 0
.IP \(bu 4
Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
.IP \(bu 4
Type: null or String
.RE 0

.P
The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm
init <package-spec>\fR commands.
.SS "See Also"
.RS 0
.IP \(bu 4
npm help run-script
.IP \(bu 4
npm help scripts
.IP \(bu 4
npm help test
.IP \(bu 4
npm help start
.IP \(bu 4
npm help restart
.RE 0
PK�~�\���,��man1/npm-fund.1nu�[���.TH "NPM-FUND" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-fund\fR - Retrieve funding information
.SS "Synopsis"
.P
.RS 2
.nf
npm fund \[lB]<package-spec>\[rB]
.fi
.RE
.SS "Description"
.P
This command retrieves information on how to fund the dependencies of a given project. If no package name is provided, it will list all dependencies that are looking for funding in a tree structure, listing the type of funding and the url to visit. If a package name is provided then it tries to open its funding url using the \fB\fB--browser\fR config\fR \fI\(la/using-npm/config#browser\(ra\fR param; if there are multiple funding sources for the package, the user will be instructed to pass the \fB--which\fR option to disambiguate.
.P
The list will avoid duplicated entries and will stack all packages that share the same url as a single entry. Thus, the list does not have the same shape of the output from \fBnpm ls\fR.
.SS "Example"
.SS "Workspaces support"
.P
It's possible to filter the results to only include a single workspace and its dependencies using the \fB\fBworkspace\fR config\fR \fI\(la/using-npm/config#workspace\(ra\fR option.
.SS "Example:"
.P
Here's an example running \fBnpm fund\fR in a project with a configured workspace \fBa\fR:
.P
.RS 2
.nf
$ npm fund
test-workspaces-fund@1.0.0
+-- https://example.com/a
| | `-- a@1.0.0
| `-- https://example.com/maintainer
|     `-- foo@1.0.0
+-- https://example.com/npmcli-funding
|   `-- @npmcli/test-funding
`-- https://example.com/org
    `-- bar@2.0.0
.fi
.RE
.P
And here is an example of the expected result when filtering only by a specific workspace \fBa\fR in the same project:
.P
.RS 2
.nf
$ npm fund -w a
test-workspaces-fund@1.0.0
`-- https://example.com/a
  | `-- a@1.0.0
  `-- https://example.com/maintainer
      `-- foo@2.0.0
.fi
.RE
.SS "Configuration"
.SS "\fBjson\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Not supported by all npm commands.
.SS "\fBbrowser\fR"
.RS 0
.IP \(bu 4
Default: OS X: \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 "\fBunicode\fR"
.RS 0
.IP \(bu 4
Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the \fBLC_ALL\fR, \fBLC_CTYPE\fR, or \fBLANG\fR environment variables.
.IP \(bu 4
Type: Boolean
.RE 0

.P
When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
.SS "\fBworkspace\fR"
.RS 0
.IP \(bu 4
Default:
.IP \(bu 4
Type: String (can be set multiple times)
.RE 0

.P
If there are multiple funding sources, which 1-indexed source URL to open.
.SH "SEE ALSO"
.RS 0
.IP \(bu 4
npm help "package spec"
.IP \(bu 4
npm help install
.IP \(bu 4
npm help docs
.IP \(bu 4
npm help ls
.IP \(bu 4
npm help config
.IP \(bu 4
npm help workspaces
.RE 0
PK�~�\z	�'� � man1/npm-run-script.1nu�[���.TH "NPM-RUN-SCRIPT" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-run-script\fR - Run arbitrary package scripts
.SS "Synopsis"
.P
.RS 2
.nf
npm run-script <command> \[lB]-- <args>\[rB]

aliases: run, rum, urn
.fi
.RE
.SS "Description"
.P
This runs an arbitrary command from a package's \fB"scripts"\fR object. If no \fB"command"\fR is provided, it will list the available scripts.
.P
\fBrun\[lB]-script\[rB]\fR is used by the test, start, restart, and stop commands, but can be called directly, as well. When the scripts in the package are printed out, they're separated into lifecycle (test, start, restart) and directly-run scripts.
.P
Any positional arguments are passed to the specified script. Use \fB--\fR to pass \fB-\fR-prefixed flags and options which would otherwise be parsed by npm.
.P
For example:
.P
.RS 2
.nf
npm run test -- --grep="pattern"
.fi
.RE
.P
The arguments will only be passed to the script specified after \fBnpm run\fR and not to any \fBpre\fR or \fBpost\fR script.
.P
The \fBenv\fR script is a special built-in command that can be used to list environment variables that will be available to the script at runtime. If an "env" command is defined in your package, it will take precedence over the built-in.
.P
In addition to the shell's pre-existing \fBPATH\fR, \fBnpm run\fR adds \fBnode_modules/.bin\fR to the \fBPATH\fR provided to scripts. Any binaries provided by locally-installed dependencies can be used without the \fBnode_modules/.bin\fR prefix. For example, if there is a \fBdevDependency\fR on \fBtap\fR in your package, you should write:
.P
.RS 2
.nf
"scripts": {"test": "tap test/*.js"}
.fi
.RE
.P
instead of
.P
.RS 2
.nf
"scripts": {"test": "node_modules/.bin/tap test/*.js"}
.fi
.RE
.P
The actual shell your script is run within is platform dependent. By default, on Unix-like systems it is the \fB/bin/sh\fR command, on Windows it is \fBcmd.exe\fR. The actual shell referred to by \fB/bin/sh\fR also depends on the system. You can customize the shell with the \fB\fBscript-shell\fR config\fR \fI\(la/using-npm/config#script-shell\(ra\fR.
.P
Scripts are run from the root of the package folder, regardless of what the current working directory is when \fBnpm run\fR is called. If you want your script to use different behavior based on what subdirectory you're in, you can use the \fBINIT_CWD\fR environment variable, which holds the full path you were in when you ran \fBnpm run\fR.
.P
\fBnpm run\fR sets the \fBNODE\fR environment variable to the \fBnode\fR executable with which \fBnpm\fR is executed.
.P
If you try to run a script without having a \fBnode_modules\fR directory and it fails, you will be given a warning to run \fBnpm install\fR, just in case you've forgotten.
.SS "Workspaces support"
.P
You may use the \fB\fBworkspace\fR\fR \fI\(la/using-npm/config#workspace\(ra\fR or \fB\fBworkspaces\fR\fR \fI\(la/using-npm/config#workspaces\(ra\fR configs in order to run an arbitrary command from a package's \fB"scripts"\fR object in the context of the specified workspaces. If no \fB"command"\fR is provided, it will list the available scripts for each of these configured workspaces.
.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
And that each of the configured workspaces has a configured \fBtest\fR script, we can run tests in all of them using the \fB\fBworkspaces\fR config\fR \fI\(la/using-npm/config#workspaces\(ra\fR:
.P
.RS 2
.nf
npm test --workspaces
.fi
.RE
.SS "Filtering workspaces"
.P
It's also possible to run a script in a single workspace using the \fBworkspace\fR config along with a name or directory path:
.P
.RS 2
.nf
npm test --workspace=a
.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 test -w a -w b
.fi
.RE
.P
This last command will run \fBtest\fR in both \fB./packages/a\fR and \fB./packages/b\fR packages.
.SS "Configuration"
.SS "\fBworkspace\fR"
.RS 0
.IP \(bu 4
Default:
.IP \(bu 4
Type: String (can be set multiple times)
.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
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-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
.SS "\fBforeground-scripts\fR"
.RS 0
.IP \(bu 4
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 "\fBscript-shell\fR"
.RS 0
.IP \(bu 4
Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
.IP \(bu 4
Type: null or String
.RE 0

.P
The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm
init <package-spec>\fR commands.
.SS "See Also"
.RS 0
.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
.RE 0
PK�~�\4ot t man1/npm-publish.1nu�[���.TH "NPM-PUBLISH" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-publish\fR - Publish a package
.SS "Synopsis"
.P
.RS 2
.nf
npm publish <package-spec>
.fi
.RE
.SS "Description"
.P
Publishes a package to the registry so that it can be installed by name.
.P
By default npm will publish to the public registry. This can be overridden by specifying a different default registry or using a npm help scope in the name, combined with a scope-configured registry (see \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR).
.P
A \fBpackage\fR is interpreted the same way as other commands (like \fBnpm install\fR) and can be:
.RS 0
.IP \(bu 4
a) a folder containing a program described by a \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR file
.IP \(bu 4
b) a gzipped tarball containing (a)
.IP \(bu 4
c) a url that resolves to (b)
.IP \(bu 4
d) a \fB<name>@<version>\fR that is published on the registry (see npm help registry) with (c)
.IP \(bu 4
e) a \fB<name>@<tag>\fR (see npm help dist-tag) that points to (d)
.IP \(bu 4
f) a \fB<name>\fR that has a "latest" tag satisfying (e)
.IP \(bu 4
g) a \fB<git remote url>\fR that resolves to (a)
.RE 0

.P
The publish will fail if the package name and version combination already exists in the specified registry.
.P
Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with npm help unpublish.
.P
As of \fBnpm@5\fR, both a sha1sum and an integrity field with a sha512sum of the tarball will be submitted to the registry during publication. Subsequent installs will use the strongest supported algorithm to verify downloads.
.P
Similar to \fB--dry-run\fR see npm help pack, which figures out the files to be included and packs them into a tarball to be uploaded to the registry.
.SS "Files included in package"
.P
To see what will be included in your package, run \fBnpm pack --dry-run\fR. All files are included by default, with the following exceptions:
.RS 0
.IP \(bu 4
Certain files that are relevant to package installation and distribution are always included. For example, \fBpackage.json\fR, \fBREADME.md\fR, \fBLICENSE\fR, and so on.
.IP \(bu 4
If there is a "files" list in \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR, then only the files specified will be included. (If directories are specified, then they will be walked recursively and their contents included, subject to the same ignore rules.)
.IP \(bu 4
If there is a \fB.gitignore\fR or \fB.npmignore\fR file, then ignored files in that and all child directories will be excluded from the package. If \fIboth\fR files exist, then the \fB.gitignore\fR is ignored, and only the \fB.npmignore\fR is used.
.P
\fB.npmignore\fR files follow the \fBsame pattern rules\fR \fI\(lahttps://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring\(ra\fR as \fB.gitignore\fR files
.IP \(bu 4
If the file matches certain patterns, then it will \fInever\fR be included, unless explicitly added to the \fB"files"\fR list in \fBpackage.json\fR, or un-ignored with a \fB!\fR rule in a \fB.npmignore\fR or \fB.gitignore\fR file.
.IP \(bu 4
Symbolic links are never included in npm packages.
.RE 0

.P
See npm help developers for full details on what's included in the published package, as well as details on how the package is built.
.SS "Configuration"
.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 "\fBaccess\fR"
.RS 0
.IP \(bu 4
Default: 'public' for new packages, existing packages it will not change the current level
.IP \(bu 4
Type: null, "restricted", or "public"
.RE 0

.P
If you do not want your scoped package to be publicly viewable (and installable) set \fB--access=restricted\fR.
.P
Unscoped packages can not be set to \fBrestricted\fR.
.P
Note: This defaults to not changing the current access level for existing packages. Specifying a value of \fBrestricted\fR or \fBpublic\fR during publish will change the access for an existing package the same way that \fBnpm access set
status\fR would.
.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 "\fBotp\fR"
.RS 0
.IP \(bu 4
Default: null
.IP \(bu 4
Type: null or String
.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
When publishing, the provenance bundle at the given path will be used.
.P
This config can not be used with: \fBprovenance\fR
.SS "See Also"
.RS 0
.IP \(bu 4
npm help "package spec"
.IP \(bu 4
\fBnpm-packlist package\fR \fI\(lahttp://npm.im/npm-packlist\(ra\fR
.IP \(bu 4
npm help registry
.IP \(bu 4
npm help scope
.IP \(bu 4
npm help adduser
.IP \(bu 4
npm help owner
.IP \(bu 4
npm help deprecate
.IP \(bu 4
npm help dist-tag
.IP \(bu 4
npm help pack
.IP \(bu 4
npm help profile
.RE 0
PK�~�\����man1/npm-star.1nu�[���.TH "NPM-STAR" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-star\fR - Mark your favorite packages
.SS "Synopsis"
.P
.RS 2
.nf
npm star \[lB]<package-spec>...\[rB]
.fi
.RE
.P
Note: This command is unaware of workspaces.
.SS "Description"
.P
"Starring" a package means that you have some interest in it. It's a vaguely positive way to show that you care.
.P
It's a boolean thing. Starring repeatedly has no additional effect.
.SS "More"
.P
There's also these extra commands to help you manage your favorite packages:
.SS "Unstar"
.P
You can also "unstar" a package using npm help unstar
.P
"Unstarring" is the same thing, but in reverse.
.SS "Listing stars"
.P
You can see all your starred packages using npm help stars
.SS "Configuration"
.SS "\fBregistry\fR"
.RS 0
.IP \(bu 4
Default: "https://registry.npmjs.org/"
.IP \(bu 4
Type: URL
.RE 0

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\fBlocation\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
Not supported by all npm commands.
.SS "\fBglobal\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.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

.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
PK�~�\c�\�man1/npm-stars.1nu�[���.TH "NPM-STARS" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-stars\fR - View packages marked as favorites
.SS "Synopsis"
.P
.RS 2
.nf
npm stars \[lB]<user>\[rB]
.fi
.RE
.P
Note: This command is unaware of workspaces.
.SS "Description"
.P
If you have starred a lot of neat things and want to find them again quickly this command lets you do just that.
.P
You may also want to see your friend's favorite packages, in this case you will most certainly enjoy this command.
.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 star
.IP \(bu 4
npm help unstar
.IP \(bu 4
npm help view
.IP \(bu 4
npm help whoami
.IP \(bu 4
npm help adduser
.RE 0
PK�~�\�_hhman1/npm-whoami.1nu�[���.TH "NPM-WHOAMI" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-whoami\fR - Display npm username
.SS "Synopsis"
.P
.RS 2
.nf
npm whoami
.fi
.RE
.P
Note: This command is unaware of workspaces.
.SS "Description"
.P
Display the npm username of the currently logged-in user.
.P
If logged into a registry that provides token-based authentication, then connect to the \fB/-/whoami\fR registry endpoint to find the username associated with the token, and print to standard output.
.P
If logged into a registry that uses Basic Auth, then simply print the \fBusername\fR portion of the authentication 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 "See Also"
.RS 0
.IP \(bu 4
npm help config
.IP \(bu 4
npm help npmrc
.IP \(bu 4
npm help adduser
.RE 0
PK�~�\O˯�ooman1/npm-search.1nu�[���.TH "NPM-SEARCH" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-search\fR - Search for packages
.SS "Synopsis"
.P
.RS 2
.nf
npm search <search term> \[lB]<search term> ...\[rB]

aliases: find, s, se
.fi
.RE
.P
Note: This command is unaware of workspaces.
.SS "Description"
.P
Search the registry for packages matching the search terms. \fBnpm search\fR performs a linear, incremental, lexically-ordered search through package metadata for all files in the registry. If your terminal has color support, it will further highlight the matches in the results. This can be disabled with the config item \fBcolor\fR
.P
Additionally, using the \fB--searchopts\fR and \fB--searchexclude\fR options paired with more search terms will include and exclude further patterns. The main difference between \fB--searchopts\fR and the standard search terms is that the former does not highlight results in the output and you can use them more fine-grained filtering. Additionally, you can add both of these to your config to change default search filtering behavior.
.P
Search also allows targeting of maintainers in search results, by prefixing their npm username with \fB=\fR.
.P
If a term starts with \fB/\fR, then it's interpreted as a regular expression and supports standard JavaScript RegExp syntax. In this case search will ignore a trailing \fB/\fR . (Note you must escape or quote many regular expression characters in most shells.)
.SS "Configuration"
.SS "\fBjson\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Not supported by all npm commands.
.SS "\fBcolor\fR"
.RS 0
.IP \(bu 4
Default: true unless the NO_COLOR environ is set to something other than '0'
.IP \(bu 4
Type: "always" or Boolean
.RE 0

.P
If false, never shows colors. If \fB"always"\fR then always shows colors. If true, then only prints color codes for tty file descriptors.
.SS "\fBparseable\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
.SS "\fBdescription\fR"
.RS 0
.IP \(bu 4
Default: true
.IP \(bu 4
Type: Boolean
.RE 0

.P
Show the description in \fBnpm search\fR
.SS "\fBsearchlimit\fR"
.RS 0
.IP \(bu 4
Default: 20
.IP \(bu 4
Type: Number
.RE 0

.P
Number of items to limit search results to. Will not apply at all to legacy searches.
.SS "\fBsearchopts\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: String
.RE 0

.P
Space-separated options that are always passed to search.
.SS "\fBsearchexclude\fR"
.RS 0
.IP \(bu 4
Default: ""
.IP \(bu 4
Type: String
.RE 0

.P
Space-separated options that limit the results from search.
.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 "\fBprefer-online\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If true, staleness checks for cached data will be forced, making the CLI look for updates immediately even for fresh package data.
.SS "\fBprefer-offline\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
If true, staleness checks for cached data will be bypassed, but missing data will be requested from the server. To force full offline mode, use \fB--offline\fR.
.SS "\fBoffline\fR"
.RS 0
.IP \(bu 4
Default: false
.IP \(bu 4
Type: Boolean
.RE 0

.P
Force offline mode: no network requests will be done during install. To allow the CLI to fill in missing cache data, see \fB--prefer-offline\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 view
.IP \(bu 4
npm help cache
.IP \(bu 4
https://npm.im/npm-registry-fetch
.RE 0
PK�~�\j,�
man1/npm.1nu�[���.TH "NPM" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm\fR - javascript package manager
.SS "Synopsis"
.P
.RS 2
.nf
npm
.fi
.RE
.P
Note: This command is unaware of workspaces.
.SS "Version"
.P
10.8.1
.SS "Description"
.P
npm is the package manager for the Node JavaScript platform. It puts modules in place so that node can find them, and manages dependency conflicts intelligently.
.P
It is extremely configurable to support a variety of use cases. Most commonly, you use it to publish, discover, install, and develop node programs.
.P
Run \fBnpm help\fR to get a list of available commands.
.SS "Important"
.P
npm comes preconfigured to use npm's public registry at https://registry.npmjs.org by default. Use of the npm public registry is subject to terms of use available at https://docs.npmjs.com/policies/terms.
.P
You can configure npm to use any compatible registry you like, and even run your own registry. Use of someone else's registry is governed by their terms of use.
.SS "Introduction"
.P
You probably got npm because you want to install stuff.
.P
The very first thing you will most likely want to run in any node program is \fBnpm install\fR to install its dependencies.
.P
You can also run \fBnpm install blerg\fR to install the latest version of "blerg". Check out npm help install for more info. It can do a lot of stuff.
.P
Use the \fBnpm search\fR command to show everything that's available in the public registry. Use \fBnpm ls\fR to show everything you've installed.
.SS "Dependencies"
.P
If a package lists a dependency using a git URL, npm will install that dependency using the \fB\fBgit\fR\fR \fI\(lahttps://github.com/git-guides/install-git\(ra\fR command and will generate an error if it is not installed.
.P
If one of the packages npm tries to install is a native node module and requires compiling of C++ Code, npm will use \fBnode-gyp\fR \fI\(lahttps://github.com/nodejs/node-gyp\(ra\fR for that task. For a Unix system, \fBnode-gyp\fR \fI\(lahttps://github.com/nodejs/node-gyp\(ra\fR needs Python, make and a buildchain like GCC. On Windows, Python and Microsoft Visual Studio C++ are needed. For more information visit \fBthe node-gyp repository\fR \fI\(lahttps://github.com/nodejs/node-gyp\(ra\fR and the \fBnode-gyp Wiki\fR \fI\(lahttps://github.com/nodejs/node-gyp/wiki\(ra\fR.
.SS "Directories"
.P
See npm help folders to learn about where npm puts stuff.
.P
In particular, npm has two modes of operation:
.RS 0
.IP \(bu 4
local mode: npm installs packages into the current project directory, which defaults to the current working directory. Packages install to \fB./node_modules\fR, and bins to \fB./node_modules/.bin\fR.
.IP \(bu 4
global mode: npm installs packages into the install prefix at \fB$npm_config_prefix/lib/node_modules\fR and bins to \fB$npm_config_prefix/bin\fR.
.RE 0

.P
Local mode is the default. Use \fB-g\fR or \fB--global\fR on any command to run in global mode instead.
.SS "Developer Usage"
.P
If you're using npm to develop and publish your code, check out the following help topics:
.RS 0
.IP \(bu 4
json: Make a package.json file. See \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR.
.IP \(bu 4
link: Links your current working code into Node's path, so that you don't have to reinstall every time you make a change. Use npm help link to do this.
.IP \(bu 4
install: It's a good idea to install things if you don't need the symbolic link. Especially, installing other peoples code from the registry is done via npm help install
.IP \(bu 4
adduser: Create an account or log in. When you do this, npm will store credentials in the user config file.
.IP \(bu 4
publish: Use the npm help publish command to upload your code to the registry.
.RE 0

.SS "Configuration"
.P
npm is extremely configurable. It reads its configuration options from 5 places.
.RS 0
.IP \(bu 4
Command line switches: Set a config with \fB--key val\fR. All keys take a value, even if they are booleans (the config parser doesn't know what the options are at the time of parsing). If you do not provide a value (\fB--key\fR) then the option is set to boolean \fBtrue\fR.
.IP \(bu 4
Environment Variables: Set any config by prefixing the name in an environment variable with \fBnpm_config_\fR. For example, \fBexport npm_config_key=val\fR.
.IP \(bu 4
User Configs: The file at \fB$HOME/.npmrc\fR is an ini-formatted list of configs. If present, it is parsed. If the \fBuserconfig\fR option is set in the cli or env, that file will be used instead.
.IP \(bu 4
Global Configs: The file found at \fB./etc/npmrc\fR (relative to the global prefix will be parsed if it is found. See npm help prefix for more info on the global prefix. If the \fBglobalconfig\fR option is set in the cli, env, or user config, then that file is parsed instead.
.IP \(bu 4
Defaults: npm's default configuration options are defined in \fBlib/utils/config/definitions.js\fR. These must not be changed.
.RE 0

.P
See npm help config for much much more information.
.SS "Contributions"
.P
Patches welcome!
.P
If you would like to help, but don't know what to work on, read the \fBcontributing guidelines\fR \fI\(lahttps://github.com/npm/cli/blob/latest/CONTRIBUTING.md\(ra\fR and check the issues list.
.SS "Bugs"
.P
When you find issues, please report them: \fI\(lahttps://github.com/npm/cli/issues\(ra\fR
.P
Please be sure to follow the template and bug reporting guidelines.
.SS "Feature Requests"
.P
Discuss new feature ideas on our discussion forum:
.RS 0
.IP \(bu 4
\fI\(lahttps://github.com/npm/feedback\(ra\fR
.RE 0

.P
Or suggest formal RFC proposals:
.RS 0
.IP \(bu 4
\fI\(lahttps://github.com/npm/rfcs\(ra\fR
.RE 0

.SS "See Also"
.RS 0
.IP \(bu 4
npm help help
.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 config
.IP \(bu 4
npm help install
.IP \(bu 4
npm help prefix
.IP \(bu 4
npm help publish
.RE 0
PK�~�\*�*|  man1/npm-install-ci-test.1nu�[���.TH "NPM-INSTALL-CI-TEST" "1" "May 2024" "NPM@10.8.1" ""
.SH "NAME"
\fBnpm-install-ci-test\fR - Install a project with a clean slate and run tests
.SS "Synopsis"
.P
.RS 2
.nf
npm install-ci-test

aliases: cit, clean-install-test, sit
.fi
.RE
.SS "Description"
.P
This command runs \fBnpm ci\fR followed immediately by \fBnpm test\fR.
.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
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-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
.SS "\fBaudit\fR"
.RS 0
.IP \(bu 4
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
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
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
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-test
.IP \(bu 4
npm help ci
.IP \(bu 4
npm help test
.RE 0
PK�~�\Q�S?�'�'
man1/npm-ci.1nu�[���.TH "NPM-CI" "1" "May 2024" "NPM@10.8.1" ""
.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