CLI documentation update from CI
npm CLI robot committed
Dec 17, 2024 at 00:34 UTC
5788b67e3debfdb7749cd919294f2598f4f1e889
91 files changed
+15692
-4
cli-cache.json
+2
-2
@@ -1,6 +1,6 @@
1
{
2
- "v11": "cf52b8be2645ee098ee83ea9981fc32a11932fad",
2
+ "v11": "f7da341322c2f860156e8144b208583596504479",
3
"v9": "64763a341e7aa5b456e696f956759bf9b3440dc1",
4
"v10": "a3041941586b6fb8ed7403fe3c24d81138a96005",
5
"v8": "aa8fff11cdab94fff1a2160ee5241f5f4632e96b"
6
-}
6
+}
\ No newline at end of file
cli/package.json
+1
-1
@@ -40,7 +40,7 @@
40
},
41
"templateOSS": {
42
"//@npmcli/template-oss": "This file is partially managed by @npmcli/template-oss. Edits may be overwritten.",
43
- "version": "4.23.5",
43
+ "version": "4.23.6",
44
"content": "./scripts/template-oss"
45
},
46
"files": [
content/cli/v11/commands/index.mdx
new
+30
@@ -0,0 +1,30 @@
1
+---
2
+title: CLI Commands
3
+shortName: Commands
4
+github_repo: npm/cli
5
+github_branch: latest
6
+github_path: docs/lib/content/nav.yml
7
+redirect_from:
8
+ - /cli-commands
9
+ - /cli-commands/index
10
+ - /cli-documentation/cli
11
+ - /cli-documentation/cli-commands
12
+ - /cli-documentation/cli-commands/index
13
+ - /cli-documentation/commands
14
+ - /cli-documentation/commands/index
15
+ - /cli-documentation/v11/cli-commands
16
+ - /cli-documentation/v11/cli-commands/index
17
+ - /cli-documentation/v11/commands
18
+ - /cli-documentation/v11/commands/index
19
+ - /cli/cli-commands
20
+ - /cli/cli-commands/index
21
+ - /cli/commands
22
+ - /cli/commands/index
23
+ - /cli/v11/cli-commands
24
+ - /cli/v11/cli-commands/index
25
+ - /cli/v11/commands/index
26
+ - /commands
27
+ - /commands/index
28
+---
29
+
30
+<Index depth="1" />
content/cli/v11/commands/npm-access.mdx
new
+125
@@ -0,0 +1,125 @@
1
+---
2
+title: npm-access
3
+section: 1
4
+description: Set access level on published packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-access.md
8
+redirect_from:
9
+ - /cli-commands/access
10
+ - /cli-commands/npm-access
11
+ - /cli-documentation/access
12
+ - /cli-documentation/cli-commands/access
13
+ - /cli-documentation/cli-commands/npm-access
14
+ - /cli-documentation/commands/access
15
+ - /cli-documentation/commands/npm-access
16
+ - /cli-documentation/npm-access
17
+ - /cli-documentation/v11/access
18
+ - /cli-documentation/v11/cli-commands/access
19
+ - /cli-documentation/v11/cli-commands/npm-access
20
+ - /cli-documentation/v11/commands/access
21
+ - /cli-documentation/v11/commands/npm-access
22
+ - /cli-documentation/v11/npm-access
23
+ - /cli/access
24
+ - /cli/cli-commands/access
25
+ - /cli/cli-commands/npm-access
26
+ - /cli/commands/access
27
+ - /cli/commands/npm-access
28
+ - /cli/npm-access
29
+ - /cli/v11/access
30
+ - /cli/v11/cli-commands/access
31
+ - /cli/v11/cli-commands/npm-access
32
+ - /cli/v11/commands/access
33
+ - /cli/v11/npm-access
34
+ - /commands/access
35
+ - /commands/npm-access
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm access list packages [<user>|<scope>|<scope:team>] [<package>]
42
+npm access list collaborators [<package> [<user>]]
43
+npm access get status [<package>]
44
+npm access set status=public|private [<package>]
45
+npm access set mfa=none|publish|automation [<package>]
46
+npm access grant <read-only|read-write> <scope:team> [<package>]
47
+npm access revoke <scope:team> [<package>]
48
+```
49
+
50
+Note: This command is unaware of workspaces.
51
+
52
+### Description
53
+
54
+Used to set access controls on private packages.
55
+
56
+For all of the subcommands, `npm access` will perform actions on the packages in the current working directory if no package name is passed to the subcommand.
57
+
58
+- public / restricted (deprecated): Set a package to be either publicly accessible or restricted.
59
+
60
+- grant / revoke (deprecated): Add or remove the ability of users and teams to have read-only or read-write access to a package.
61
+
62
+- 2fa-required / 2fa-not-required (deprecated): Configure whether a package requires that anyone publishing it have two-factor authentication enabled on their account.
63
+
64
+- ls-packages (deprecated): Show all of the packages a user or a team is able to access, along with the access level, except for read-only public packages (it won't print the whole registry listing)
65
+
66
+- ls-collaborators (deprecated): Show all of the access privileges for a package. Will only show permissions for packages to which you have at least read access. If `<user>` is passed in, the list is filtered only to teams _that_ user happens to belong to.
67
+
68
+- edit (not implemented)
69
+
70
+### Details
71
+
72
+`npm access` always operates directly on the current registry, configurable from the command line using `--registry=<registry url>`.
73
+
74
+Unscoped packages are _always public_.
75
+
76
+Scoped packages _default to restricted_, but you can either publish them as public using `npm publish --access=public`, or set their access as public using `npm access public` after the initial publish.
77
+
78
+You must have privileges to set the access of a package:
79
+
80
+- You are an owner of an unscoped or scoped package.
81
+- You are a member of the team that owns a scope.
82
+- You have been given read-write privileges for a package, either as a member of a team or directly as an owner.
83
+
84
+If you have two-factor authentication enabled then you'll be prompted to provide a second factor, or may use the `--otp=...` option to specify it on the command line.
85
+
86
+If your account is not paid, then attempts to publish scoped packages will fail with an HTTP 402 status code (logically enough), unless you use `--access=public`.
87
+
88
+Management of teams and team memberships is done with the `npm team` command.
89
+
90
+### Configuration
91
+
92
+#### `json`
93
+
94
+- Default: false
95
+- Type: Boolean
96
+
97
+Whether or not to output JSON data, rather than the normal output.
98
+
99
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
100
+
101
+Not supported by all npm commands.
102
+
103
+#### `otp`
104
+
105
+- Default: null
106
+- Type: null or String
107
+
108
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
109
+
110
+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.
111
+
112
+#### `registry`
113
+
114
+- Default: "https://registry.npmjs.org/"
115
+- Type: URL
116
+
117
+The base URL of the npm registry.
118
+
119
+### See Also
120
+
121
+- [`libnpmaccess`](https://npm.im/libnpmaccess)
122
+- [npm team](/cli/v11/commands/npm-team)
123
+- [npm publish](/cli/v11/commands/npm-publish)
124
+- [npm config](/cli/v11/commands/npm-config)
125
+- [npm registry](/cli/v11/using-npm/registry)
content/cli/v11/commands/npm-adduser.mdx
new
+105
@@ -0,0 +1,105 @@
1
+---
2
+title: npm-adduser
3
+section: 1
4
+description: Add a registry user account
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-adduser.md
8
+redirect_from:
9
+ - /cli-commands/adduser
10
+ - /cli-commands/npm-adduser
11
+ - /cli-documentation/adduser
12
+ - /cli-documentation/cli-commands/adduser
13
+ - /cli-documentation/cli-commands/npm-adduser
14
+ - /cli-documentation/commands/adduser
15
+ - /cli-documentation/commands/npm-adduser
16
+ - /cli-documentation/npm-adduser
17
+ - /cli-documentation/v11/adduser
18
+ - /cli-documentation/v11/cli-commands/adduser
19
+ - /cli-documentation/v11/cli-commands/npm-adduser
20
+ - /cli-documentation/v11/commands/adduser
21
+ - /cli-documentation/v11/commands/npm-adduser
22
+ - /cli-documentation/v11/npm-adduser
23
+ - /cli/adduser
24
+ - /cli/cli-commands/adduser
25
+ - /cli/cli-commands/npm-adduser
26
+ - /cli/commands/adduser
27
+ - /cli/commands/npm-adduser
28
+ - /cli/npm-adduser
29
+ - /cli/v11/adduser
30
+ - /cli/v11/cli-commands/adduser
31
+ - /cli/v11/cli-commands/npm-adduser
32
+ - /cli/v11/commands/adduser
33
+ - /cli/v11/npm-adduser
34
+ - /commands/adduser
35
+ - /commands/npm-adduser
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm adduser
42
+
43
+alias: add-user
44
+```
45
+
46
+Note: This command is unaware of workspaces.
47
+
48
+### Description
49
+
50
+Create a new user in the specified registry, and save the credentials to the `.npmrc` file. If no registry is specified, the default registry will be used (see [`registry`](/cli/v11/using-npm/registry)).
51
+
52
+When using `legacy` for your `auth-type`, the username, password, and email are read in from prompts.
53
+
54
+### Configuration
55
+
56
+#### `registry`
57
+
58
+- Default: "https://registry.npmjs.org/"
59
+- Type: URL
60
+
61
+The base URL of the npm registry.
62
+
63
+#### `scope`
64
+
65
+- Default: the scope of the current project, if any, or ""
66
+- Type: String
67
+
68
+Associate an operation with a scope for a scoped registry.
69
+
70
+Useful when logging in to or out of a private registry:
71
+
72
+```
73
+# log in, linking the scope to the custom registry
74
+npm login --scope=@mycorp --registry=https://registry.mycorp.com
75
+
76
+# log out, removing the link and the auth token
77
+npm logout --scope=@mycorp
78
+```
79
+
80
+This will cause `@mycorp` to be mapped to the registry for future installation of packages specified according to the pattern `@mycorp/package`.
81
+
82
+This will also cause `npm init` to create a scoped package.
83
+
84
+```
85
+# accept all defaults, and create a package named "@foo/whatever",
86
+# instead of just named "whatever"
87
+npm init --scope=@foo --yes
88
+```
89
+
90
+#### `auth-type`
91
+
92
+- Default: "web"
93
+- Type: "legacy" or "web"
94
+
95
+What authentication strategy to use with `login`. Note that if an `otp` config is given, this value will always be set to `legacy`.
96
+
97
+### See Also
98
+
99
+- [npm registry](/cli/v11/using-npm/registry)
100
+- [npm config](/cli/v11/commands/npm-config)
101
+- [npmrc](/cli/v11/configuring-npm/npmrc)
102
+- [npm owner](/cli/v11/commands/npm-owner)
103
+- [npm whoami](/cli/v11/commands/npm-whoami)
104
+- [npm token](/cli/v11/commands/npm-token)
105
+- [npm profile](/cli/v11/commands/npm-profile)
content/cli/v11/commands/npm-audit.mdx
new
+379
@@ -0,0 +1,379 @@
1
+---
2
+title: npm-audit
3
+section: 1
4
+description: Run a security audit
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-audit.md
8
+redirect_from:
9
+ - /cli-commands/audit
10
+ - /cli-commands/npm-audit
11
+ - /cli-documentation/audit
12
+ - /cli-documentation/cli-commands/audit
13
+ - /cli-documentation/cli-commands/npm-audit
14
+ - /cli-documentation/commands/audit
15
+ - /cli-documentation/commands/npm-audit
16
+ - /cli-documentation/npm-audit
17
+ - /cli-documentation/v11/audit
18
+ - /cli-documentation/v11/cli-commands/audit
19
+ - /cli-documentation/v11/cli-commands/npm-audit
20
+ - /cli-documentation/v11/commands/audit
21
+ - /cli-documentation/v11/commands/npm-audit
22
+ - /cli-documentation/v11/npm-audit
23
+ - /cli/audit
24
+ - /cli/cli-commands/audit
25
+ - /cli/cli-commands/npm-audit
26
+ - /cli/commands/audit
27
+ - /cli/commands/npm-audit
28
+ - /cli/npm-audit
29
+ - /cli/v11/audit
30
+ - /cli/v11/cli-commands/audit
31
+ - /cli/v11/cli-commands/npm-audit
32
+ - /cli/v11/commands/audit
33
+ - /cli/v11/npm-audit
34
+ - /commands/audit
35
+ - /commands/npm-audit
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm audit [fix|signatures]
42
+```
43
+
44
+### Description
45
+
46
+The audit command submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities. If any vulnerabilities are found, then the impact and appropriate remediation will be calculated. If the `fix` argument is provided, then remediations will be applied to the package tree.
47
+
48
+The command will exit with a 0 exit code if no vulnerabilities were found.
49
+
50
+Note that some vulnerabilities cannot be fixed automatically and will require manual intervention or review. Also note that since `npm audit fix` runs a full-fledged `npm install` under the hood, all configs that apply to the installer will also apply to `npm install` -- so things like `npm audit fix --package-lock-only` will work as expected.
51
+
52
+By default, the audit command will exit with a non-zero code if any vulnerability is found. It may be useful in CI environments to include the `--audit-level` parameter to specify the minimum vulnerability level that will cause the command to fail. This option does not filter the report output, it simply changes the command's failure threshold.
53
+
54
+### Package lock
55
+
56
+By default npm requires a package-lock or shrinkwrap in order to run the audit. You can bypass the package lock with `--no-package-lock` but be aware the results may be different with every run, since npm will re-build the dependency tree each time.
57
+
58
+### Audit Signatures
59
+
60
+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.
61
+
62
+Registry signatures can be verified using the following `audit` command:
63
+
64
+```bash
65
+$ npm audit signatures
66
+```
67
+
68
+The `audit signatures` command will also verify the provenance attestations of downloaded packages. Because provenance attestations are such a new feature, security features may be added to (or changed in) the attestation format over time. To ensure that you're always able to verify attestation signatures check that you're running the latest version of the npm CLI. Please note this often means updating npm beyond the version that ships with Node.js.
69
+
70
+The npm CLI supports registry signatures and signing keys provided by any registry if the following conventions are followed:
71
+
72
+1. Signatures are provided in the package's `packument` in each published version within the `dist` object:
73
+
74
+```json
75
+"dist":{
76
+ "..omitted..": "..omitted..",
77
+ "signatures": [{
78
+ "keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
79
+ "sig": "a312b9c3cb4a1b693e8ebac5ee1ca9cc01f2661c14391917dcb111517f72370809..."
80
+ }]
81
+}
82
+```
83
+
84
+See this [example](https://registry.npmjs.org/light-cycle/1.4.3) of a signed package from the public npm registry.
85
+
86
+The `sig` is generated using the following template: `${package.name}@${package.version}:${package.dist.integrity}` and the `keyid` has to match one of the public signing keys below.
87
+
88
+2. Public signing keys are provided at `registry-host.tld/-/npm/v1/keys` in the following format:
89
+
90
+```
91
+{
92
+ "keys": [{
93
+ "expires": null,
94
+ "keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
95
+ "keytype": "ecdsa-sha2-nistp256",
96
+ "scheme": "ecdsa-sha2-nistp256",
97
+ "key": "{{B64_PUBLIC_KEY}}"
98
+ }]
99
+}
100
+```
101
+
102
+Keys response:
103
+
104
+- `expires`: null or a simplified extended [ISO 8601 format](https://en.wikipedia.org/wiki/ISO_8601): `YYYY-MM-DDTHH:mm:ss.sssZ`
105
+- `keydid`: sha256 fingerprint of the public key
106
+- `keytype`: only `ecdsa-sha2-nistp256` is currently supported by the npm CLI
107
+- `scheme`: only `ecdsa-sha2-nistp256` is currently supported by the npm CLI
108
+- `key`: base64 encoded public key
109
+
110
+See this [example key's response from the public npm registry](https://registry.npmjs.org/-/npm/v1/keys).
111
+
112
+### Audit Endpoints
113
+
114
+There are two audit endpoints that npm may use to fetch vulnerability information: the `Bulk Advisory` endpoint and the `Quick Audit` endpoint.
115
+
116
+#### Bulk Advisory Endpoint
117
+
118
+As of version 7, npm uses the much faster `Bulk Advisory` endpoint to optimize the speed of calculating audit results.
119
+
120
+npm will generate a JSON payload with the name and list of versions of each package in the tree, and POST it to the default configured registry at the path `/-/npm/v1/security/advisories/bulk`.
121
+
122
+Any packages in the tree that do not have a `version` field in their package.json file will be ignored. If any `--omit` options are specified (either via the [`--omit` config](/cli/v11/using-npm/config#omit), or one of the shorthands such as `--production`, `--only=dev`, and so on), then packages will be omitted from the submitted payload as appropriate.
123
+
124
+If the registry responds with an error, or with an invalid response, then npm will attempt to load advisory data from the `Quick Audit` endpoint.
125
+
126
+The expected result will contain a set of advisory objects for each dependency that matches the advisory range. Each advisory object contains a `name`, `url`, `id`, `severity`, `vulnerable_versions`, and `title`.
127
+
128
+npm then uses these advisory objects to calculate vulnerabilities and meta-vulnerabilities of the dependencies within the tree.
129
+
130
+#### Quick Audit Endpoint
131
+
132
+If the `Bulk Advisory` endpoint returns an error, or invalid data, npm will attempt to load advisory data from the `Quick Audit` endpoint, which is considerably slower in most cases.
133
+
134
+The full package tree as found in `package-lock.json` is submitted, along with the following pieces of additional metadata:
135
+
136
+- `npm_version`
137
+- `node_version`
138
+- `platform`
139
+- `arch`
140
+- `node_env`
141
+
142
+All packages in the tree are submitted to the Quick Audit endpoint. Omitted dependency types are skipped when generating the report.
143
+
144
+#### Scrubbing
145
+
146
+Out of an abundance of caution, npm versions 5 and 6 would "scrub" any packages from the submitted report if their name contained a `/` character, so as to avoid leaking the names of potentially private packages or git URLs.
147
+
148
+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.
149
+
150
+This scrubbing has been removed from npm as of version 7.
151
+
152
+#### Calculating Meta-Vulnerabilities and Remediations
153
+
154
+npm uses the [`@npmcli/metavuln-calculator`](http://npm.im/@npmcli/metavuln-calculator) module to turn a set of security advisories into a set of "vulnerability" objects. A "meta-vulnerability" is a dependency that is vulnerable by virtue of dependence on vulnerable versions of a vulnerable package.
155
+
156
+For example, if the package `foo` is vulnerable in the range `>=1.0.2 <2.0.0`, and the package `bar` depends on `foo@^1.1.0`, then that version of `bar` can only be installed by installing a vulnerable version of `foo`. In this case, `bar` is a "metavulnerability".
157
+
158
+Once metavulnerabilities for a given package are calculated, they are cached in the `~/.npm` folder and only re-evaluated if the advisory range changes, or a new version of the package is published (in which case, the new version is checked for metavulnerable status as well).
159
+
160
+If the chain of metavulnerabilities extends all the way to the root project, and it cannot be updated without changing its dependency ranges, then `npm audit fix` will require the `--force` option to apply the remediation. If remediations do not require changes to the dependency ranges, then all vulnerable packages will be updated to a version that does not have an advisory or metavulnerability posted against it.
161
+
162
+### Exit Code
163
+
164
+The `npm audit` command will exit with a 0 exit code if no vulnerabilities were found. The `npm audit fix` command will exit with 0 exit code if no vulnerabilities are found _or_ if the remediation is able to successfully fix all vulnerabilities.
165
+
166
+If vulnerabilities were found the exit code will depend on the [`audit-level` config](/cli/v11/using-npm/config#audit-level).
167
+
168
+### Examples
169
+
170
+Scan your project for vulnerabilities and automatically install any compatible updates to vulnerable dependencies:
171
+
172
+```bash
173
+$ npm audit fix
174
+```
175
+
176
+Run `audit fix` without modifying `node_modules`, but still updating the pkglock:
177
+
178
+```bash
179
+$ npm audit fix --package-lock-only
180
+```
181
+
182
+Skip updating `devDependencies`:
183
+
184
+```bash
185
+$ npm audit fix --only=prod
186
+```
187
+
188
+Have `audit fix` install SemVer-major updates to toplevel dependencies, not just SemVer-compatible ones:
189
+
190
+```bash
191
+$ npm audit fix --force
192
+```
193
+
194
+Do a dry run to get an idea of what `audit fix` will do, and _also_ output install information in JSON format:
195
+
196
+```bash
197
+$ npm audit fix --dry-run --json
198
+```
199
+
200
+Scan your project for vulnerabilities and just show the details, without fixing anything:
201
+
202
+```bash
203
+$ npm audit
204
+```
205
+
206
+Get the detailed audit report in JSON format:
207
+
208
+```bash
209
+$ npm audit --json
210
+```
211
+
212
+Fail an audit only if the results include a vulnerability with a level of moderate or higher:
213
+
214
+```bash
215
+$ npm audit --audit-level=moderate
216
+```
217
+
218
+### Configuration
219
+
220
+#### `audit-level`
221
+
222
+- Default: null
223
+- Type: null, "info", "low", "moderate", "high", "critical", or "none"
224
+
225
+The minimum level of vulnerability for `npm audit` to exit with a non-zero exit code.
226
+
227
+#### `dry-run`
228
+
229
+- Default: false
230
+- Type: Boolean
231
+
232
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
233
+
234
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
235
+
236
+#### `force`
237
+
238
+- Default: false
239
+- Type: Boolean
240
+
241
+Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
242
+
243
+- Allow clobbering non-npm files in global installs.
244
+- Allow the `npm version` command to work on an unclean git repository.
245
+- Allow deleting the cache folder with `npm cache clean`.
246
+- Allow installing packages that have an `engines` declaration requiring a different version of npm.
247
+- Allow installing packages that have an `engines` declaration requiring a different version of `node`, even if `--engine-strict` is enabled.
248
+- Allow `npm audit fix` to install modules outside your stated dependency range (including SemVer-major changes).
249
+- Allow unpublishing all versions of a published package.
250
+- Allow conflicting peerDependencies to be installed in the root project.
251
+- Implicitly set `--yes` during `npm init`.
252
+- Allow clobbering existing values in `npm pkg`
253
+- Allow unpublishing of entire packages (not just a single version).
254
+
255
+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!
256
+
257
+#### `json`
258
+
259
+- Default: false
260
+- Type: Boolean
261
+
262
+Whether or not to output JSON data, rather than the normal output.
263
+
264
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
265
+
266
+Not supported by all npm commands.
267
+
268
+#### `package-lock-only`
269
+
270
+- Default: false
271
+- Type: Boolean
272
+
273
+If set to true, the current operation will only use the `package-lock.json`, ignoring `node_modules`.
274
+
275
+For `update` this means only the `package-lock.json` will be updated, instead of checking `node_modules` and downloading dependencies.
276
+
277
+For `list` this means the output will be based on the tree described by the `package-lock.json`, rather than the contents of `node_modules`.
278
+
279
+#### `package-lock`
280
+
281
+- Default: true
282
+- Type: Boolean
283
+
284
+If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
285
+
286
+#### `omit`
287
+
288
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
289
+- Type: "dev", "optional", or "peer" (can be set multiple times)
290
+
291
+Dependency types to omit from the installation tree on disk.
292
+
293
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
294
+
295
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
296
+
297
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
298
+
299
+#### `include`
300
+
301
+- Default:
302
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
303
+
304
+Option that allows for defining which types of dependencies to install.
305
+
306
+This is the inverse of `--omit=<type>`.
307
+
308
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
309
+
310
+#### `foreground-scripts`
311
+
312
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
313
+- Type: Boolean
314
+
315
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
316
+
317
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
318
+
319
+#### `ignore-scripts`
320
+
321
+- Default: false
322
+- Type: Boolean
323
+
324
+If true, npm does not run scripts specified in package.json files.
325
+
326
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
327
+
328
+#### `workspace`
329
+
330
+- Default:
331
+- Type: String (can be set multiple times)
332
+
333
+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.
334
+
335
+Valid values for the `workspace` config are either:
336
+
337
+- Workspace names
338
+- Path to a workspace directory
339
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
340
+
341
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
342
+
343
+This value is not exported to the environment for child processes.
344
+
345
+#### `workspaces`
346
+
347
+- Default: null
348
+- Type: null or Boolean
349
+
350
+Set to true to run the command in the context of **all** configured workspaces.
351
+
352
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
353
+
354
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
355
+
356
+This value is not exported to the environment for child processes.
357
+
358
+#### `include-workspace-root`
359
+
360
+- Default: false
361
+- Type: Boolean
362
+
363
+Include the workspace root when workspaces are enabled for a command.
364
+
365
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
366
+
367
+This value is not exported to the environment for child processes.
368
+
369
+#### `install-links`
370
+
371
+- Default: false
372
+- Type: Boolean
373
+
374
+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.
375
+
376
+### See Also
377
+
378
+- [npm install](/cli/v11/commands/npm-install)
379
+- [config](/cli/v11/using-npm/config)
content/cli/v11/commands/npm-bugs.mdx
new
+119
@@ -0,0 +1,119 @@
1
+---
2
+title: npm-bugs
3
+section: 1
4
+description: Report bugs for a package in a web browser
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-bugs.md
8
+redirect_from:
9
+ - /cli-commands/bugs
10
+ - /cli-commands/npm-bugs
11
+ - /cli-documentation/bugs
12
+ - /cli-documentation/cli-commands/bugs
13
+ - /cli-documentation/cli-commands/npm-bugs
14
+ - /cli-documentation/commands/bugs
15
+ - /cli-documentation/commands/npm-bugs
16
+ - /cli-documentation/npm-bugs
17
+ - /cli-documentation/v11/bugs
18
+ - /cli-documentation/v11/cli-commands/bugs
19
+ - /cli-documentation/v11/cli-commands/npm-bugs
20
+ - /cli-documentation/v11/commands/bugs
21
+ - /cli-documentation/v11/commands/npm-bugs
22
+ - /cli-documentation/v11/npm-bugs
23
+ - /cli/bugs
24
+ - /cli/cli-commands/bugs
25
+ - /cli/cli-commands/npm-bugs
26
+ - /cli/commands/bugs
27
+ - /cli/commands/npm-bugs
28
+ - /cli/npm-bugs
29
+ - /cli/v11/bugs
30
+ - /cli/v11/cli-commands/bugs
31
+ - /cli/v11/cli-commands/npm-bugs
32
+ - /cli/v11/commands/bugs
33
+ - /cli/v11/npm-bugs
34
+ - /commands/bugs
35
+ - /commands/npm-bugs
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm bugs [<pkgname> [<pkgname> ...]]
42
+
43
+alias: issues
44
+```
45
+
46
+### Description
47
+
48
+This command tries to guess at the likely location of a package's bug tracker URL or the `mailto` URL of the support email, and then tries to open it using the [`--browser` config](/cli/v11/using-npm/config#browser) param. If no package name is provided, it will search for a `package.json` in the current folder and use the `name` property.
49
+
50
+### Configuration
51
+
52
+#### `browser`
53
+
54
+- Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
55
+- Type: null, Boolean, or String
56
+
57
+The browser that is called by npm commands to open websites.
58
+
59
+Set to `false` to suppress browser behavior and instead print urls to terminal.
60
+
61
+Set to `true` to use default system URL opener.
62
+
63
+#### `registry`
64
+
65
+- Default: "https://registry.npmjs.org/"
66
+- Type: URL
67
+
68
+The base URL of the npm registry.
69
+
70
+#### `workspace`
71
+
72
+- Default:
73
+- Type: String (can be set multiple times)
74
+
75
+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.
76
+
77
+Valid values for the `workspace` config are either:
78
+
79
+- Workspace names
80
+- Path to a workspace directory
81
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
82
+
83
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
84
+
85
+This value is not exported to the environment for child processes.
86
+
87
+#### `workspaces`
88
+
89
+- Default: null
90
+- Type: null or Boolean
91
+
92
+Set to true to run the command in the context of **all** configured workspaces.
93
+
94
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
95
+
96
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
97
+
98
+This value is not exported to the environment for child processes.
99
+
100
+#### `include-workspace-root`
101
+
102
+- Default: false
103
+- Type: Boolean
104
+
105
+Include the workspace root when workspaces are enabled for a command.
106
+
107
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
108
+
109
+This value is not exported to the environment for child processes.
110
+
111
+### See Also
112
+
113
+- [npm docs](/cli/v11/commands/npm-docs)
114
+- [npm view](/cli/v11/commands/npm-view)
115
+- [npm publish](/cli/v11/commands/npm-publish)
116
+- [npm registry](/cli/v11/using-npm/registry)
117
+- [npm config](/cli/v11/commands/npm-config)
118
+- [npmrc](/cli/v11/configuring-npm/npmrc)
119
+- [package.json](/cli/v11/configuring-npm/package-json)
content/cli/v11/commands/npm-cache.mdx
new
+96
@@ -0,0 +1,96 @@
1
+---
2
+title: npm-cache
3
+section: 1
4
+description: Manipulates packages cache
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-cache.md
8
+redirect_from:
9
+ - /cli-commands/cache
10
+ - /cli-commands/npm-cache
11
+ - /cli-documentation/cache
12
+ - /cli-documentation/cli-commands/cache
13
+ - /cli-documentation/cli-commands/npm-cache
14
+ - /cli-documentation/commands/cache
15
+ - /cli-documentation/commands/npm-cache
16
+ - /cli-documentation/npm-cache
17
+ - /cli-documentation/v11/cache
18
+ - /cli-documentation/v11/cli-commands/cache
19
+ - /cli-documentation/v11/cli-commands/npm-cache
20
+ - /cli-documentation/v11/commands/cache
21
+ - /cli-documentation/v11/commands/npm-cache
22
+ - /cli-documentation/v11/npm-cache
23
+ - /cli/cache
24
+ - /cli/cli-commands/cache
25
+ - /cli/cli-commands/npm-cache
26
+ - /cli/commands/cache
27
+ - /cli/commands/npm-cache
28
+ - /cli/npm-cache
29
+ - /cli/v11/cache
30
+ - /cli/v11/cli-commands/cache
31
+ - /cli/v11/cli-commands/npm-cache
32
+ - /cli/v11/commands/cache
33
+ - /cli/v11/npm-cache
34
+ - /commands/cache
35
+ - /commands/npm-cache
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm cache add <package-spec>
42
+npm cache clean [<key>]
43
+npm cache ls [<name>@<version>]
44
+npm cache verify
45
+```
46
+
47
+Note: This command is unaware of workspaces.
48
+
49
+### Description
50
+
51
+Used to add, list, or clean the npm cache folder.
52
+
53
+- add: Add the specified packages to the local cache. This command is primarily intended to be used internally by npm, but it can provide a way to add data to the local installation cache explicitly.
54
+
55
+- clean: Delete all data out of the cache folder. Note that this is typically unnecessary, as npm's cache is self-healing and resistant to data corruption issues.
56
+
57
+- verify: Verify the contents of the cache folder, garbage collecting any unneeded data, and verifying the integrity of the cache index and all cached data.
58
+
59
+### Details
60
+
61
+npm stores cache data in an opaque directory within the configured `cache`, named `_cacache`. This directory is a [`cacache`](http://npm.im/cacache)-based content-addressable cache that stores all http request data as well as other package-related data. This directory is primarily accessed through `pacote`, the library responsible for all package fetching as of npm@5.
62
+
63
+All data that passes through the cache is fully verified for integrity on both insertion and extraction. Cache corruption will either trigger an error, or signal to `pacote` that the data must be refetched, which it will do automatically. For this reason, it should never be necessary to clear the cache for any reason other than reclaiming disk space, thus why `clean` now requires `--force` to run.
64
+
65
+There is currently no method exposed through npm to inspect or directly manage the contents of this cache. In order to access it, `cacache` must be used directly.
66
+
67
+npm will not remove data by itself: the cache will grow as new packages are installed.
68
+
69
+### A note about the cache's design
70
+
71
+The npm cache is strictly a cache: it should not be relied upon as a persistent and reliable data store for package data. npm makes no guarantee that a previously-cached piece of data will be available later, and will automatically delete corrupted contents. The primary guarantee that the cache makes is that, if it does return data, that data will be exactly the data that was inserted.
72
+
73
+To run an offline verification of existing cache contents, use `npm cache verify`.
74
+
75
+### Configuration
76
+
77
+#### `cache`
78
+
79
+- Default: Windows: `%LocalAppData%\npm-cache`, Posix: `~/.npm`
80
+- Type: Path
81
+
82
+The location of npm's cache directory.
83
+
84
+### See Also
85
+
86
+- [package spec](/cli/v11/using-npm/package-spec)
87
+- [npm folders](/cli/v11/configuring-npm/folders)
88
+- [npm config](/cli/v11/commands/npm-config)
89
+- [npmrc](/cli/v11/configuring-npm/npmrc)
90
+- [npm install](/cli/v11/commands/npm-install)
91
+- [npm publish](/cli/v11/commands/npm-publish)
92
+- [npm pack](/cli/v11/commands/npm-pack)
93
+- https://npm.im/cacache
94
+- https://npm.im/pacote
95
+- https://npm.im/@npmcli/arborist
96
+- https://npm.im/make-fetch-happen
content/cli/v11/commands/npm-ci.mdx
new
+251
@@ -0,0 +1,251 @@
1
+---
2
+title: npm-ci
3
+section: 1
4
+description: Clean install a project
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-ci.md
8
+redirect_from:
9
+ - /cli-commands/ci
10
+ - /cli-commands/npm-ci
11
+ - /cli-documentation/ci
12
+ - /cli-documentation/cli-commands/ci
13
+ - /cli-documentation/cli-commands/npm-ci
14
+ - /cli-documentation/commands/ci
15
+ - /cli-documentation/commands/npm-ci
16
+ - /cli-documentation/npm-ci
17
+ - /cli-documentation/v11/ci
18
+ - /cli-documentation/v11/cli-commands/ci
19
+ - /cli-documentation/v11/cli-commands/npm-ci
20
+ - /cli-documentation/v11/commands/ci
21
+ - /cli-documentation/v11/commands/npm-ci
22
+ - /cli-documentation/v11/npm-ci
23
+ - /cli/ci
24
+ - /cli/cli-commands/ci
25
+ - /cli/cli-commands/npm-ci
26
+ - /cli/commands/ci
27
+ - /cli/commands/npm-ci
28
+ - /cli/npm-ci
29
+ - /cli/v11/ci
30
+ - /cli/v11/cli-commands/ci
31
+ - /cli/v11/cli-commands/npm-ci
32
+ - /cli/v11/commands/ci
33
+ - /cli/v11/npm-ci
34
+ - /commands/ci
35
+ - /commands/npm-ci
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm ci
42
+
43
+aliases: clean-install, ic, install-clean, isntall-clean
44
+```
45
+
46
+### Description
47
+
48
+This command is similar to [`npm install`](/cli/v11/commands/npm-install), except it's meant to be used in automated environments such as test platforms, continuous integration, and deployment -- or any situation where you want to make sure you're doing a clean install of your dependencies.
49
+
50
+The main differences between using `npm install` and `npm ci` are:
51
+
52
+- The project **must** have an existing `package-lock.json` or `npm-shrinkwrap.json`.
53
+- If dependencies in the package lock do not match those in `package.json`, `npm ci` will exit with an error, instead of updating the package lock.
54
+- `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.
55
+- If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
56
+- It will never write to `package.json` or any of the package-locks: installs are essentially frozen.
57
+
58
+NOTE: If you create your `package-lock.json` file by running `npm install` with flags that can affect the shape of your dependency tree, such as `--legacy-peer-deps` or `--install-links`, you _must_ provide the same flags to `npm ci` or you are likely to encounter errors. An easy way to do this is to run, for example, `npm config set legacy-peer-deps=true --location=project` and commit the `.npmrc` file to your repo.
59
+
60
+### Example
61
+
62
+Make sure you have a package-lock and an up-to-date install:
63
+
64
+```bash
65
+$ cd ./my/npm/project
66
+$ npm install
67
+added 154 packages in 10s
68
+$ ls | grep package-lock
69
+```
70
+
71
+Run `npm ci` in that project
72
+
73
+```bash
74
+$ npm ci
75
+added 154 packages in 5s
76
+```
77
+
78
+Configure Travis CI to build using `npm ci` instead of `npm install`:
79
+
80
+```bash
81
+# .travis.yml
82
+install:
83
+- npm ci
84
+# keep the npm cache around to speed up installs
85
+cache:
86
+ directories:
87
+ - "$HOME/.npm"
88
+```
89
+
90
+### Configuration
91
+
92
+#### `install-strategy`
93
+
94
+- Default: "hoisted"
95
+- Type: "hoisted", "nested", "shallow", or "linked"
96
+
97
+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.
98
+
99
+#### `legacy-bundling`
100
+
101
+- Default: false
102
+- Type: Boolean
103
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
104
+
105
+Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
106
+
107
+#### `global-style`
108
+
109
+- Default: false
110
+- Type: Boolean
111
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
112
+
113
+Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
114
+
115
+#### `omit`
116
+
117
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
118
+- Type: "dev", "optional", or "peer" (can be set multiple times)
119
+
120
+Dependency types to omit from the installation tree on disk.
121
+
122
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
123
+
124
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
125
+
126
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
127
+
128
+#### `include`
129
+
130
+- Default:
131
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
132
+
133
+Option that allows for defining which types of dependencies to install.
134
+
135
+This is the inverse of `--omit=<type>`.
136
+
137
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
138
+
139
+#### `strict-peer-deps`
140
+
141
+- Default: false
142
+- Type: Boolean
143
+
144
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
145
+
146
+By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
147
+
148
+When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
149
+
150
+#### `foreground-scripts`
151
+
152
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
153
+- Type: Boolean
154
+
155
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
156
+
157
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
158
+
159
+#### `ignore-scripts`
160
+
161
+- Default: false
162
+- Type: Boolean
163
+
164
+If true, npm does not run scripts specified in package.json files.
165
+
166
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
167
+
168
+#### `audit`
169
+
170
+- Default: true
171
+- Type: Boolean
172
+
173
+When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
174
+
175
+#### `bin-links`
176
+
177
+- Default: true
178
+- Type: Boolean
179
+
180
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
181
+
182
+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.
183
+
184
+#### `fund`
185
+
186
+- Default: true
187
+- Type: Boolean
188
+
189
+When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
190
+
191
+#### `dry-run`
192
+
193
+- Default: false
194
+- Type: Boolean
195
+
196
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
197
+
198
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
199
+
200
+#### `workspace`
201
+
202
+- Default:
203
+- Type: String (can be set multiple times)
204
+
205
+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.
206
+
207
+Valid values for the `workspace` config are either:
208
+
209
+- Workspace names
210
+- Path to a workspace directory
211
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
212
+
213
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
214
+
215
+This value is not exported to the environment for child processes.
216
+
217
+#### `workspaces`
218
+
219
+- Default: null
220
+- Type: null or Boolean
221
+
222
+Set to true to run the command in the context of **all** configured workspaces.
223
+
224
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
225
+
226
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
227
+
228
+This value is not exported to the environment for child processes.
229
+
230
+#### `include-workspace-root`
231
+
232
+- Default: false
233
+- Type: Boolean
234
+
235
+Include the workspace root when workspaces are enabled for a command.
236
+
237
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
238
+
239
+This value is not exported to the environment for child processes.
240
+
241
+#### `install-links`
242
+
243
+- Default: false
244
+- Type: Boolean
245
+
246
+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.
247
+
248
+### See Also
249
+
250
+- [npm install](/cli/v11/commands/npm-install)
251
+- [package-lock.json](/cli/v11/configuring-npm/package-lock-json)
content/cli/v11/commands/npm-completion.mdx
new
+64
@@ -0,0 +1,64 @@
1
+---
2
+title: npm-completion
3
+section: 1
4
+description: Tab Completion for npm
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-completion.md
8
+redirect_from:
9
+ - /cli-commands/completion
10
+ - /cli-commands/npm-completion
11
+ - /cli-documentation/cli-commands/completion
12
+ - /cli-documentation/cli-commands/npm-completion
13
+ - /cli-documentation/commands/completion
14
+ - /cli-documentation/commands/npm-completion
15
+ - /cli-documentation/completion
16
+ - /cli-documentation/npm-completion
17
+ - /cli-documentation/v11/cli-commands/completion
18
+ - /cli-documentation/v11/cli-commands/npm-completion
19
+ - /cli-documentation/v11/commands/completion
20
+ - /cli-documentation/v11/commands/npm-completion
21
+ - /cli-documentation/v11/completion
22
+ - /cli-documentation/v11/npm-completion
23
+ - /cli/cli-commands/completion
24
+ - /cli/cli-commands/npm-completion
25
+ - /cli/commands/completion
26
+ - /cli/commands/npm-completion
27
+ - /cli/completion
28
+ - /cli/npm-completion
29
+ - /cli/v11/cli-commands/completion
30
+ - /cli/v11/cli-commands/npm-completion
31
+ - /cli/v11/commands/completion
32
+ - /cli/v11/completion
33
+ - /cli/v11/npm-completion
34
+ - /commands/completion
35
+ - /commands/npm-completion
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm completion
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+Enables tab-completion in all npm commands.
49
+
50
+The synopsis above loads the completions into your current shell. Adding it to your ~/.bashrc or ~/.zshrc will make the completions available everywhere:
51
+
52
+```bash
53
+npm completion >> ~/.bashrc
54
+npm completion >> ~/.zshrc
55
+```
56
+
57
+You may of course also pipe the output of `npm completion` to a file such as `/usr/local/etc/bash_completion.d/npm` or `/etc/bash_completion.d/npm` if you have a system that will read that file for you.
58
+
59
+When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the environment, `npm completion` acts in "plumbing mode", and outputs completions based on the arguments.
60
+
61
+### See Also
62
+
63
+- [npm developers](/cli/v11/using-npm/developers)
64
+- [npm](/cli/v11/commands/npm)
content/cli/v11/commands/npm-config.mdx
new
+182
@@ -0,0 +1,182 @@
1
+---
2
+title: npm-config
3
+section: 1
4
+description: Manage the npm configuration files
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-config.md
8
+redirect_from:
9
+ - /cli-commands/config
10
+ - /cli-commands/npm-config
11
+ - /cli-documentation/cli-commands/config
12
+ - /cli-documentation/cli-commands/npm-config
13
+ - /cli-documentation/commands/config
14
+ - /cli-documentation/commands/npm-config
15
+ - /cli-documentation/config
16
+ - /cli-documentation/npm-config
17
+ - /cli-documentation/v11/cli-commands/config
18
+ - /cli-documentation/v11/cli-commands/npm-config
19
+ - /cli-documentation/v11/commands/config
20
+ - /cli-documentation/v11/commands/npm-config
21
+ - /cli-documentation/v11/config
22
+ - /cli-documentation/v11/npm-config
23
+ - /cli/cli-commands/config
24
+ - /cli/cli-commands/npm-config
25
+ - /cli/commands/config
26
+ - /cli/commands/npm-config
27
+ - /cli/config
28
+ - /cli/npm-config
29
+ - /cli/v11/cli-commands/config
30
+ - /cli/v11/cli-commands/npm-config
31
+ - /cli/v11/commands/config
32
+ - /cli/v11/config
33
+ - /cli/v11/npm-config
34
+ - /commands/config
35
+ - /commands/npm-config
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm config set <key>=<value> [<key>=<value> ...]
42
+npm config get [<key> [<key> ...]]
43
+npm config delete <key> [<key> ...]
44
+npm config list [--json]
45
+npm config edit
46
+npm config fix
47
+
48
+alias: c
49
+```
50
+
51
+Note: This command is unaware of workspaces.
52
+
53
+### Description
54
+
55
+npm gets its config settings from the command line, environment variables, `npmrc` files, and in some cases, the `package.json` file.
56
+
57
+See [npmrc](/cli/v11/configuring-npm/npmrc) for more information about the npmrc files.
58
+
59
+See [config](/cli/v11/using-npm/config) for a more thorough explanation of the mechanisms involved, and a full list of config options available.
60
+
61
+The `npm config` command can be used to update and edit the contents of the user and global npmrc files.
62
+
63
+### Sub-commands
64
+
65
+Config supports the following sub-commands:
66
+
67
+#### set
68
+
69
+```bash
70
+npm config set key=value [key=value...]
71
+npm set key=value [key=value...]
72
+```
73
+
74
+Sets each of the config keys to the value provided. Modifies the user configuration file unless [`location`](/cli/v11/commands/npm-config#location) is passed.
75
+
76
+If value is omitted, the key will be removed from your config file entirely.
77
+
78
+Note: for backwards compatibility, `npm config set key value` is supported as an alias for `npm config set key=value`.
79
+
80
+#### get
81
+
82
+```bash
83
+npm config get [key ...]
84
+npm get [key ...]
85
+```
86
+
87
+Echo the config value(s) to stdout.
88
+
89
+If multiple keys are provided, then the values will be prefixed with the key names.
90
+
91
+If no keys are provided, then this command behaves the same as `npm config list`.
92
+
93
+#### list
94
+
95
+```bash
96
+npm config list
97
+```
98
+
99
+Show all the config settings. Use `-l` to also show defaults. Use `--json` to show the settings in json format.
100
+
101
+#### delete
102
+
103
+```bash
104
+npm config delete key [key ...]
105
+```
106
+
107
+Deletes the specified keys from all configuration files.
108
+
109
+#### edit
110
+
111
+```bash
112
+npm config edit
113
+```
114
+
115
+Opens the config file in an editor. Use the `--global` flag to edit the global config.
116
+
117
+#### fix
118
+
119
+```bash
120
+npm config fix
121
+```
122
+
123
+Attempts to repair invalid configuration items. Usually this means attaching authentication config (i.e. `_auth`, `_authToken`) to the configured `registry`.
124
+
125
+### Configuration
126
+
127
+#### `json`
128
+
129
+- Default: false
130
+- Type: Boolean
131
+
132
+Whether or not to output JSON data, rather than the normal output.
133
+
134
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
135
+
136
+Not supported by all npm commands.
137
+
138
+#### `global`
139
+
140
+- Default: false
141
+- Type: Boolean
142
+
143
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
144
+
145
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
146
+- bin files are linked to `{prefix}/bin`
147
+- man pages are linked to `{prefix}/share/man`
148
+
149
+#### `editor`
150
+
151
+- Default: The EDITOR or VISUAL environment variables, or '%SYSTEMROOT%\notepad.exe' on Windows, or 'vi' on Unix systems
152
+- Type: String
153
+
154
+The command to run for `npm edit` and `npm config edit`.
155
+
156
+#### `location`
157
+
158
+- Default: "user" unless `--global` is passed, which will also set this value to "global"
159
+- Type: "global", "user", or "project"
160
+
161
+When passed to `npm config` this refers to which config file to use.
162
+
163
+When set to "global" mode, packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
164
+
165
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
166
+- bin files are linked to `{prefix}/bin`
167
+- man pages are linked to `{prefix}/share/man`
168
+
169
+#### `long`
170
+
171
+- Default: false
172
+- Type: Boolean
173
+
174
+Show extended information in `ls`, `search`, and `help-search`.
175
+
176
+### See Also
177
+
178
+- [npm folders](/cli/v11/configuring-npm/folders)
179
+- [npm config](/cli/v11/commands/npm-config)
180
+- [package.json](/cli/v11/configuring-npm/package-json)
181
+- [npmrc](/cli/v11/configuring-npm/npmrc)
182
+- [npm](/cli/v11/commands/npm)
content/cli/v11/commands/npm-dedupe.mdx
new
+256
@@ -0,0 +1,256 @@
1
+---
2
+title: npm-dedupe
3
+section: 1
4
+description: Reduce duplication in the package tree
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-dedupe.md
8
+redirect_from:
9
+ - /cli-commands/dedupe
10
+ - /cli-commands/npm-dedupe
11
+ - /cli-documentation/cli-commands/dedupe
12
+ - /cli-documentation/cli-commands/npm-dedupe
13
+ - /cli-documentation/commands/dedupe
14
+ - /cli-documentation/commands/npm-dedupe
15
+ - /cli-documentation/dedupe
16
+ - /cli-documentation/npm-dedupe
17
+ - /cli-documentation/v11/cli-commands/dedupe
18
+ - /cli-documentation/v11/cli-commands/npm-dedupe
19
+ - /cli-documentation/v11/commands/dedupe
20
+ - /cli-documentation/v11/commands/npm-dedupe
21
+ - /cli-documentation/v11/dedupe
22
+ - /cli-documentation/v11/npm-dedupe
23
+ - /cli/cli-commands/dedupe
24
+ - /cli/cli-commands/npm-dedupe
25
+ - /cli/commands/dedupe
26
+ - /cli/commands/npm-dedupe
27
+ - /cli/dedupe
28
+ - /cli/npm-dedupe
29
+ - /cli/v11/cli-commands/dedupe
30
+ - /cli/v11/cli-commands/npm-dedupe
31
+ - /cli/v11/commands/dedupe
32
+ - /cli/v11/dedupe
33
+ - /cli/v11/npm-dedupe
34
+ - /commands/dedupe
35
+ - /commands/npm-dedupe
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm dedupe
42
+
43
+alias: ddp
44
+```
45
+
46
+### Description
47
+
48
+Searches the local package tree and attempts to simplify the overall structure by moving dependencies further up the tree, where they can be more effectively shared by multiple dependent packages.
49
+
50
+For example, consider this dependency graph:
51
+
52
+```
53
+a
54
++-- b <-- depends on c@1.0.x
55
+| `-- c@1.0.3
56
+`-- d <-- depends on c@~1.0.9
57
+ `-- c@1.0.10
58
+```
59
+
60
+In this case, `npm dedupe` will transform the tree to:
61
+
62
+```bash
63
+a
64
++-- b
65
++-- d
66
+`-- c@1.0.10
67
+```
68
+
69
+Because of the hierarchical nature of node's module lookup, b and d will both get their dependency met by the single c package at the root level of the tree.
70
+
71
+In some cases, you may have a dependency graph like this:
72
+
73
+```
74
+a
75
++-- b <-- depends on c@1.0.x
76
++-- c@1.0.3
77
+`-- d <-- depends on c@1.x
78
+ `-- c@1.9.9
79
+```
80
+
81
+During the installation process, the `c@1.0.3` dependency for `b` was placed in the root of the tree. Though `d`'s dependency on `c@1.x` could have been satisfied by `c@1.0.3`, the newer `c@1.9.0` dependency was used, because npm favors updates by default, even when doing so causes duplication.
82
+
83
+Running `npm dedupe` will cause npm to note the duplication and re-evaluate, deleting the nested `c` module, because the one in the root is sufficient.
84
+
85
+To prefer deduplication over novelty during the installation process, run `npm install --prefer-dedupe` or `npm config set prefer-dedupe true`.
86
+
87
+Arguments are ignored. Dedupe always acts on the entire tree.
88
+
89
+Note that this operation transforms the dependency tree, but will never result in new modules being installed.
90
+
91
+Using `npm find-dupes` will run the command in `--dry-run` mode.
92
+
93
+Note: `npm dedupe` will never update the semver values of direct dependencies in your project `package.json`, if you want to update values in `package.json` you can run: `npm update --save` instead.
94
+
95
+### Configuration
96
+
97
+#### `install-strategy`
98
+
99
+- Default: "hoisted"
100
+- Type: "hoisted", "nested", "shallow", or "linked"
101
+
102
+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.
103
+
104
+#### `legacy-bundling`
105
+
106
+- Default: false
107
+- Type: Boolean
108
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
109
+
110
+Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
111
+
112
+#### `global-style`
113
+
114
+- Default: false
115
+- Type: Boolean
116
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
117
+
118
+Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
119
+
120
+#### `strict-peer-deps`
121
+
122
+- Default: false
123
+- Type: Boolean
124
+
125
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
126
+
127
+By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
128
+
129
+When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
130
+
131
+#### `package-lock`
132
+
133
+- Default: true
134
+- Type: Boolean
135
+
136
+If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
137
+
138
+#### `omit`
139
+
140
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
141
+- Type: "dev", "optional", or "peer" (can be set multiple times)
142
+
143
+Dependency types to omit from the installation tree on disk.
144
+
145
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
146
+
147
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
148
+
149
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
150
+
151
+#### `include`
152
+
153
+- Default:
154
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
155
+
156
+Option that allows for defining which types of dependencies to install.
157
+
158
+This is the inverse of `--omit=<type>`.
159
+
160
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
161
+
162
+#### `ignore-scripts`
163
+
164
+- Default: false
165
+- Type: Boolean
166
+
167
+If true, npm does not run scripts specified in package.json files.
168
+
169
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
170
+
171
+#### `audit`
172
+
173
+- Default: true
174
+- Type: Boolean
175
+
176
+When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
177
+
178
+#### `bin-links`
179
+
180
+- Default: true
181
+- Type: Boolean
182
+
183
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
184
+
185
+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.
186
+
187
+#### `fund`
188
+
189
+- Default: true
190
+- Type: Boolean
191
+
192
+When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
193
+
194
+#### `dry-run`
195
+
196
+- Default: false
197
+- Type: Boolean
198
+
199
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
200
+
201
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
202
+
203
+#### `workspace`
204
+
205
+- Default:
206
+- Type: String (can be set multiple times)
207
+
208
+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.
209
+
210
+Valid values for the `workspace` config are either:
211
+
212
+- Workspace names
213
+- Path to a workspace directory
214
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
215
+
216
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
217
+
218
+This value is not exported to the environment for child processes.
219
+
220
+#### `workspaces`
221
+
222
+- Default: null
223
+- Type: null or Boolean
224
+
225
+Set to true to run the command in the context of **all** configured workspaces.
226
+
227
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
228
+
229
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
230
+
231
+This value is not exported to the environment for child processes.
232
+
233
+#### `include-workspace-root`
234
+
235
+- Default: false
236
+- Type: Boolean
237
+
238
+Include the workspace root when workspaces are enabled for a command.
239
+
240
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
241
+
242
+This value is not exported to the environment for child processes.
243
+
244
+#### `install-links`
245
+
246
+- Default: false
247
+- Type: Boolean
248
+
249
+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.
250
+
251
+### See Also
252
+
253
+- [npm find-dupes](/cli/v11/commands/npm-find-dupes)
254
+- [npm ls](/cli/v11/commands/npm-ls)
255
+- [npm update](/cli/v11/commands/npm-update)
256
+- [npm install](/cli/v11/commands/npm-install)
content/cli/v11/commands/npm-deprecate.mdx
new
+92
@@ -0,0 +1,92 @@
1
+---
2
+title: npm-deprecate
3
+section: 1
4
+description: Deprecate a version of a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-deprecate.md
8
+redirect_from:
9
+ - /cli-commands/deprecate
10
+ - /cli-commands/npm-deprecate
11
+ - /cli-documentation/cli-commands/deprecate
12
+ - /cli-documentation/cli-commands/npm-deprecate
13
+ - /cli-documentation/commands/deprecate
14
+ - /cli-documentation/commands/npm-deprecate
15
+ - /cli-documentation/deprecate
16
+ - /cli-documentation/npm-deprecate
17
+ - /cli-documentation/v11/cli-commands/deprecate
18
+ - /cli-documentation/v11/cli-commands/npm-deprecate
19
+ - /cli-documentation/v11/commands/deprecate
20
+ - /cli-documentation/v11/commands/npm-deprecate
21
+ - /cli-documentation/v11/deprecate
22
+ - /cli-documentation/v11/npm-deprecate
23
+ - /cli/cli-commands/deprecate
24
+ - /cli/cli-commands/npm-deprecate
25
+ - /cli/commands/deprecate
26
+ - /cli/commands/npm-deprecate
27
+ - /cli/deprecate
28
+ - /cli/npm-deprecate
29
+ - /cli/v11/cli-commands/deprecate
30
+ - /cli/v11/cli-commands/npm-deprecate
31
+ - /cli/v11/commands/deprecate
32
+ - /cli/v11/deprecate
33
+ - /cli/v11/npm-deprecate
34
+ - /commands/deprecate
35
+ - /commands/npm-deprecate
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm deprecate <package-spec> <message>
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+This command will update the npm registry entry for a package, providing a deprecation warning to all who attempt to install it.
49
+
50
+It works on [version ranges](https://semver.npmjs.com/) as well as specific versions, so you can do something like this:
51
+
52
+```bash
53
+npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
54
+```
55
+
56
+SemVer ranges passed to this command are interpreted such that they _do_ include prerelease versions. For example:
57
+
58
+```bash
59
+npm deprecate my-thing@1.x "1.x is no longer supported"
60
+```
61
+
62
+In this case, a version `my-thing@1.0.0-beta.0` will also be deprecated.
63
+
64
+You must be the package owner to deprecate something. See the `owner` and `adduser` help topics.
65
+
66
+To un-deprecate a package, specify an empty string (`""`) for the `message` argument. Note that you must use double quotes with no space between them to format an empty string.
67
+
68
+### Configuration
69
+
70
+#### `registry`
71
+
72
+- Default: "https://registry.npmjs.org/"
73
+- Type: URL
74
+
75
+The base URL of the npm registry.
76
+
77
+#### `otp`
78
+
79
+- Default: null
80
+- Type: null or String
81
+
82
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
83
+
84
+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.
85
+
86
+### See Also
87
+
88
+- [package spec](/cli/v11/using-npm/package-spec)
89
+- [npm publish](/cli/v11/commands/npm-publish)
90
+- [npm registry](/cli/v11/using-npm/registry)
91
+- [npm owner](/cli/v11/commands/npm-owner)
92
+- [npm adduser](/cli/v11/commands/npm-adduser)
content/cli/v11/commands/npm-diff.mdx
new
+271
@@ -0,0 +1,271 @@
1
+---
2
+title: npm-diff
3
+section: 1
4
+description: The registry diff command
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-diff.md
8
+redirect_from:
9
+ - /cli-commands/diff
10
+ - /cli-commands/npm-diff
11
+ - /cli-documentation/cli-commands/diff
12
+ - /cli-documentation/cli-commands/npm-diff
13
+ - /cli-documentation/commands/diff
14
+ - /cli-documentation/commands/npm-diff
15
+ - /cli-documentation/diff
16
+ - /cli-documentation/npm-diff
17
+ - /cli-documentation/v11/cli-commands/diff
18
+ - /cli-documentation/v11/cli-commands/npm-diff
19
+ - /cli-documentation/v11/commands/diff
20
+ - /cli-documentation/v11/commands/npm-diff
21
+ - /cli-documentation/v11/diff
22
+ - /cli-documentation/v11/npm-diff
23
+ - /cli/cli-commands/diff
24
+ - /cli/cli-commands/npm-diff
25
+ - /cli/commands/diff
26
+ - /cli/commands/npm-diff
27
+ - /cli/diff
28
+ - /cli/npm-diff
29
+ - /cli/v11/cli-commands/diff
30
+ - /cli/v11/cli-commands/npm-diff
31
+ - /cli/v11/commands/diff
32
+ - /cli/v11/diff
33
+ - /cli/v11/npm-diff
34
+ - /commands/diff
35
+ - /commands/npm-diff
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm diff [...<paths>]
42
+```
43
+
44
+### Description
45
+
46
+Similar to its `git diff` counterpart, this command will print diff patches of files for packages published to the npm registry.
47
+
48
+- `npm diff --diff=<spec-a> --diff=<spec-b>`
49
+
50
+ Compares two package versions using their registry specifiers, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0`. It's also possible to compare across forks of any package, e.g: `npm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0`.
51
+
52
+ Any valid spec can be used, so that it's also possible to compare directories or git repositories, e.g: `npm diff --diff=pkg@latest --diff=./packages/pkg`
53
+
54
+ Here's an example comparing two different versions of a package named `abbrev` from the registry:
55
+
56
+ ```bash
57
+ npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1
58
+ ```
59
+
60
+ On success, output looks like:
61
+
62
+ ```bash
63
+ diff --git a/package.json b/package.json
64
+ index v1.1.0..v1.1.1 100644
65
+ --- a/package.json
66
+ +++ b/package.json
67
+ @@ -1,6 +1,6 @@
68
+ {
69
+ "name": "abbrev",
70
+ - "version": "1.1.0",
71
+ + "version": "1.1.1",
72
+ "description": "Like ruby's abbrev module, but in js",
73
+ "author": "Isaac Z. Schlueter <i@izs.me>",
74
+ "main": "abbrev.js",
75
+ ```
76
+
77
+ Given the flexible nature of npm specs, you can also target local directories or git repos just like when using `npm install`:
78
+
79
+ ```bash
80
+ npm diff --diff=https://github.com/npm/libnpmdiff --diff=./local-path
81
+ ```
82
+
83
+ In the example above we can compare the contents from the package installed from the git repo at `github.com/npm/libnpmdiff` with the contents of the `./local-path` that contains a valid package, such as a modified copy of the original.
84
+
85
+- `npm diff` (in a package directory, no arguments):
86
+
87
+ If the package is published to the registry, `npm diff` will fetch the tarball version tagged as `latest` (this value can be configured using the `tag` option) and proceed to compare the contents of files present in that tarball, with the current files in your local file system.
88
+
89
+ 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.
90
+
91
+- `npm diff --diff=<pkg-name>` (in a package directory):
92
+
93
+ When using a single package name (with no version or tag specifier) as an argument, `npm diff` will work in a similar way to [`npm-outdated`](npm-outdated) and reach for the registry to figure out what current published version of the package named `<pkg-name>` will satisfy its dependent declared semver-range. Once that specific version is known `npm diff` will print diff patches comparing the current version of `<pkg-name>` found in the local file system with that specific version returned by the registry.
94
+
95
+ Given a package named `abbrev` that is currently installed:
96
+
97
+ ```bash
98
+ npm diff --diff=abbrev
99
+ ```
100
+
101
+ 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.
102
+
103
+- `npm diff --diff=<spec-a>` (in a package directory):
104
+
105
+ Similar to using only a single package name, it's also possible to declare a full registry specifier version if you wish to compare the local version of an installed package with the specific version/tag/semver-range provided in `<spec-a>`.
106
+
107
+ An example: assuming `pkg@1.0.0` is installed in the current `node_modules` folder, running:
108
+
109
+ ```bash
110
+ npm diff --diff=pkg@2.0.0
111
+ ```
112
+
113
+ It will effectively be an alias to `npm diff --diff=pkg@1.0.0 --diff=pkg@2.0.0`.
114
+
115
+- `npm diff --diff=<semver-a> [--diff=<semver-b>]` (in a package directory):
116
+
117
+ Using `npm diff` along with semver-valid version numbers is a shorthand to compare different versions of the current package.
118
+
119
+ It needs to be run from a package directory, such that for a package named `pkg` running `npm diff --diff=1.0.0 --diff=1.0.1` is the same as running `npm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1`.
120
+
121
+ If only a single argument `<version-a>` is provided, then the current local file system is going to be compared against that version.
122
+
123
+ Here's an example comparing two specific versions (published to the configured registry) of the current project directory:
124
+
125
+ ```bash
126
+ npm diff --diff=1.0.0 --diff=1.1.0
127
+ ```
128
+
129
+Note that tag names are not valid `--diff` argument values, if you wish to compare to a published tag, you must use the `pkg@tagname` syntax.
130
+
131
+#### Filtering files
132
+
133
+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:
134
+
135
+```bash
136
+npm diff --diff=pkg@2 ./lib/ CHANGELOG.md
137
+```
138
+
139
+In the example above the diff output is only going to print contents of files located within the folder `./lib/` and changed lines of code within the `CHANGELOG.md` file.
140
+
141
+### Configuration
142
+
143
+#### `diff`
144
+
145
+- Default:
146
+- Type: String (can be set multiple times)
147
+
148
+Define arguments to compare in `npm diff`.
149
+
150
+#### `diff-name-only`
151
+
152
+- Default: false
153
+- Type: Boolean
154
+
155
+Prints only filenames when using `npm diff`.
156
+
157
+#### `diff-unified`
158
+
159
+- Default: 3
160
+- Type: Number
161
+
162
+The number of lines of context to print in `npm diff`.
163
+
164
+#### `diff-ignore-all-space`
165
+
166
+- Default: false
167
+- Type: Boolean
168
+
169
+Ignore whitespace when comparing lines in `npm diff`.
170
+
171
+#### `diff-no-prefix`
172
+
173
+- Default: false
174
+- Type: Boolean
175
+
176
+Do not show any source or destination prefix in `npm diff` output.
177
+
178
+Note: this causes `npm diff` to ignore the `--diff-src-prefix` and `--diff-dst-prefix` configs.
179
+
180
+#### `diff-src-prefix`
181
+
182
+- Default: "a/"
183
+- Type: String
184
+
185
+Source prefix to be used in `npm diff` output.
186
+
187
+#### `diff-dst-prefix`
188
+
189
+- Default: "b/"
190
+- Type: String
191
+
192
+Destination prefix to be used in `npm diff` output.
193
+
194
+#### `diff-text`
195
+
196
+- Default: false
197
+- Type: Boolean
198
+
199
+Treat all files as text in `npm diff`.
200
+
201
+#### `global`
202
+
203
+- Default: false
204
+- Type: Boolean
205
+
206
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
207
+
208
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
209
+- bin files are linked to `{prefix}/bin`
210
+- man pages are linked to `{prefix}/share/man`
211
+
212
+#### `tag`
213
+
214
+- Default: "latest"
215
+- Type: String
216
+
217
+If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag.
218
+
219
+It is the tag added to the package@version specified in the `npm dist-tag add` command, if no explicit tag is given.
220
+
221
+When used by the `npm diff` command, this is the tag used to fetch the tarball that will be compared with the local files by default.
222
+
223
+If used in the `npm publish` command, this is the tag that will be added to the package submitted to the registry.
224
+
225
+#### `workspace`
226
+
227
+- Default:
228
+- Type: String (can be set multiple times)
229
+
230
+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.
231
+
232
+Valid values for the `workspace` config are either:
233
+
234
+- Workspace names
235
+- Path to a workspace directory
236
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
237
+
238
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
239
+
240
+This value is not exported to the environment for child processes.
241
+
242
+#### `workspaces`
243
+
244
+- Default: null
245
+- Type: null or Boolean
246
+
247
+Set to true to run the command in the context of **all** configured workspaces.
248
+
249
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
250
+
251
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
252
+
253
+This value is not exported to the environment for child processes.
254
+
255
+#### `include-workspace-root`
256
+
257
+- Default: false
258
+- Type: Boolean
259
+
260
+Include the workspace root when workspaces are enabled for a command.
261
+
262
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
263
+
264
+This value is not exported to the environment for child processes.
265
+
266
+## See Also
267
+
268
+- [npm outdated](/cli/v11/commands/npm-outdated)
269
+- [npm install](/cli/v11/commands/npm-install)
270
+- [npm config](/cli/v11/commands/npm-config)
271
+- [npm registry](/cli/v11/using-npm/registry)
content/cli/v11/commands/npm-dist-tag.mdx
new
+149
@@ -0,0 +1,149 @@
1
+---
2
+title: npm-dist-tag
3
+section: 1
4
+description: Modify package distribution tags
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-dist-tag.md
8
+redirect_from:
9
+ - /cli-commands/dist-tag
10
+ - /cli-commands/npm-dist-tag
11
+ - /cli-documentation/cli-commands/dist-tag
12
+ - /cli-documentation/cli-commands/npm-dist-tag
13
+ - /cli-documentation/commands/dist-tag
14
+ - /cli-documentation/commands/npm-dist-tag
15
+ - /cli-documentation/dist-tag
16
+ - /cli-documentation/npm-dist-tag
17
+ - /cli-documentation/v11/cli-commands/dist-tag
18
+ - /cli-documentation/v11/cli-commands/npm-dist-tag
19
+ - /cli-documentation/v11/commands/dist-tag
20
+ - /cli-documentation/v11/commands/npm-dist-tag
21
+ - /cli-documentation/v11/dist-tag
22
+ - /cli-documentation/v11/npm-dist-tag
23
+ - /cli/cli-commands/dist-tag
24
+ - /cli/cli-commands/npm-dist-tag
25
+ - /cli/commands/dist-tag
26
+ - /cli/commands/npm-dist-tag
27
+ - /cli/dist-tag
28
+ - /cli/npm-dist-tag
29
+ - /cli/v11/cli-commands/dist-tag
30
+ - /cli/v11/cli-commands/npm-dist-tag
31
+ - /cli/v11/commands/dist-tag
32
+ - /cli/v11/dist-tag
33
+ - /cli/v11/npm-dist-tag
34
+ - /commands/dist-tag
35
+ - /commands/npm-dist-tag
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm dist-tag add <package-spec (with version)> [<tag>]
42
+npm dist-tag rm <package-spec> <tag>
43
+npm dist-tag ls [<package-spec>]
44
+
45
+alias: dist-tags
46
+```
47
+
48
+### Description
49
+
50
+Add, remove, and enumerate distribution tags on a package:
51
+
52
+- add: Tags the specified version of the package with the specified tag, or the [`--tag` config](/cli/v11/using-npm/config#tag) if not specified. If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp <one-time password>`, or go through a second factor flow based on your `authtype`.
53
+
54
+- rm: Clear a tag that is no longer in use from the package. If you have two-factor authentication on auth-and-writes then you’ll need to include a one-time password on the command line with `--otp <one-time password>`, or go through a second factor flow based on your `authtype`
55
+
56
+- 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.
57
+
58
+A tag can be used when installing packages as a reference to a version instead of using a specific version number:
59
+
60
+```bash
61
+npm install <name>@<tag>
62
+```
63
+
64
+When installing dependencies, a preferred tagged version may be specified:
65
+
66
+```bash
67
+npm install --tag <tag>
68
+```
69
+
70
+(This also applies to any other commands that resolve and install dependencies, such as `npm dedupe`, `npm update`, and `npm audit fix`.)
71
+
72
+Publishing a package sets the `latest` tag to the published version unless the `--tag` option is used. For example, `npm publish --tag=beta`.
73
+
74
+By default, `npm install <pkg>` (without any `@<version>` or `@<tag>` specifier) installs the `latest` tag.
75
+
76
+### Purpose
77
+
78
+Tags can be used to provide an alias instead of version numbers.
79
+
80
+For example, a project might choose to have multiple streams of development and use a different tag for each stream, e.g., `stable`, `beta`, `dev`, `canary`.
81
+
82
+By default, the `latest` tag is used by npm to identify the current version of a package, and `npm install <pkg>` (without any `@<version>` or `@<tag>` specifier) installs the `latest` tag. Typically, projects only use the `latest` tag for stable release versions, and use other tags for unstable versions such as prereleases.
83
+
84
+The `next` tag is used by some projects to identify the upcoming version.
85
+
86
+Other than `latest`, no tag has any special significance to npm itself.
87
+
88
+### Caveats
89
+
90
+This command used to be known as `npm tag`, which only created new tags, and so had a different syntax.
91
+
92
+Tags must share a namespace with version numbers, because they are specified in the same slot: `npm install <pkg>@<version>` vs `npm install <pkg>@<tag>`.
93
+
94
+Tags that can be interpreted as valid semver ranges will be rejected. For example, `v1.4` cannot be used as a tag, because it is interpreted by semver as `>=1.4.0 <1.5.0`. See [https://github.com/npm/npm/issues/6082](https://github.com/npm/npm/issues/6082).
95
+
96
+The simplest way to avoid semver problems with tags is to use tags that do not begin with a number or the letter `v`.
97
+
98
+### Configuration
99
+
100
+#### `workspace`
101
+
102
+- Default:
103
+- Type: String (can be set multiple times)
104
+
105
+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.
106
+
107
+Valid values for the `workspace` config are either:
108
+
109
+- Workspace names
110
+- Path to a workspace directory
111
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
112
+
113
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
114
+
115
+This value is not exported to the environment for child processes.
116
+
117
+#### `workspaces`
118
+
119
+- Default: null
120
+- Type: null or Boolean
121
+
122
+Set to true to run the command in the context of **all** configured workspaces.
123
+
124
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
125
+
126
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
127
+
128
+This value is not exported to the environment for child processes.
129
+
130
+#### `include-workspace-root`
131
+
132
+- Default: false
133
+- Type: Boolean
134
+
135
+Include the workspace root when workspaces are enabled for a command.
136
+
137
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
138
+
139
+This value is not exported to the environment for child processes.
140
+
141
+### See Also
142
+
143
+- [package spec](/cli/v11/using-npm/package-spec)
144
+- [npm publish](/cli/v11/commands/npm-publish)
145
+- [npm install](/cli/v11/commands/npm-install)
146
+- [npm dedupe](/cli/v11/commands/npm-dedupe)
147
+- [npm registry](/cli/v11/using-npm/registry)
148
+- [npm config](/cli/v11/commands/npm-config)
149
+- [npmrc](/cli/v11/configuring-npm/npmrc)
content/cli/v11/commands/npm-docs.mdx
new
+118
@@ -0,0 +1,118 @@
1
+---
2
+title: npm-docs
3
+section: 1
4
+description: Open documentation for a package in a web browser
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-docs.md
8
+redirect_from:
9
+ - /cli-commands/docs
10
+ - /cli-commands/npm-docs
11
+ - /cli-documentation/cli-commands/docs
12
+ - /cli-documentation/cli-commands/npm-docs
13
+ - /cli-documentation/commands/docs
14
+ - /cli-documentation/commands/npm-docs
15
+ - /cli-documentation/docs
16
+ - /cli-documentation/npm-docs
17
+ - /cli-documentation/v11/cli-commands/docs
18
+ - /cli-documentation/v11/cli-commands/npm-docs
19
+ - /cli-documentation/v11/commands/docs
20
+ - /cli-documentation/v11/commands/npm-docs
21
+ - /cli-documentation/v11/docs
22
+ - /cli-documentation/v11/npm-docs
23
+ - /cli/cli-commands/docs
24
+ - /cli/cli-commands/npm-docs
25
+ - /cli/commands/docs
26
+ - /cli/commands/npm-docs
27
+ - /cli/docs
28
+ - /cli/npm-docs
29
+ - /cli/v11/cli-commands/docs
30
+ - /cli/v11/cli-commands/npm-docs
31
+ - /cli/v11/commands/docs
32
+ - /cli/v11/docs
33
+ - /cli/v11/npm-docs
34
+ - /commands/docs
35
+ - /commands/npm-docs
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm docs [<pkgname> [<pkgname> ...]]
42
+
43
+alias: home
44
+```
45
+
46
+### Description
47
+
48
+This command tries to guess at the likely location of a package's documentation URL, and then tries to open it using the [`--browser` config](/cli/v11/using-npm/config#browser) param. You can pass multiple package names at once. If no package name is provided, it will search for a `package.json` in the current folder and use the `name` property.
49
+
50
+### Configuration
51
+
52
+#### `browser`
53
+
54
+- Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
55
+- Type: null, Boolean, or String
56
+
57
+The browser that is called by npm commands to open websites.
58
+
59
+Set to `false` to suppress browser behavior and instead print urls to terminal.
60
+
61
+Set to `true` to use default system URL opener.
62
+
63
+#### `registry`
64
+
65
+- Default: "https://registry.npmjs.org/"
66
+- Type: URL
67
+
68
+The base URL of the npm registry.
69
+
70
+#### `workspace`
71
+
72
+- Default:
73
+- Type: String (can be set multiple times)
74
+
75
+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.
76
+
77
+Valid values for the `workspace` config are either:
78
+
79
+- Workspace names
80
+- Path to a workspace directory
81
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
82
+
83
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
84
+
85
+This value is not exported to the environment for child processes.
86
+
87
+#### `workspaces`
88
+
89
+- Default: null
90
+- Type: null or Boolean
91
+
92
+Set to true to run the command in the context of **all** configured workspaces.
93
+
94
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
95
+
96
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
97
+
98
+This value is not exported to the environment for child processes.
99
+
100
+#### `include-workspace-root`
101
+
102
+- Default: false
103
+- Type: Boolean
104
+
105
+Include the workspace root when workspaces are enabled for a command.
106
+
107
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
108
+
109
+This value is not exported to the environment for child processes.
110
+
111
+### See Also
112
+
113
+- [npm view](/cli/v11/commands/npm-view)
114
+- [npm publish](/cli/v11/commands/npm-publish)
115
+- [npm registry](/cli/v11/using-npm/registry)
116
+- [npm config](/cli/v11/commands/npm-config)
117
+- [npmrc](/cli/v11/configuring-npm/npmrc)
118
+- [package.json](/cli/v11/configuring-npm/package-json)
content/cli/v11/commands/npm-doctor.mdx
new
+106
@@ -0,0 +1,106 @@
1
+---
2
+title: npm-doctor
3
+section: 1
4
+description: Check the health of your npm environment
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-doctor.md
8
+redirect_from:
9
+ - /cli-commands/doctor
10
+ - /cli-commands/npm-doctor
11
+ - /cli-documentation/cli-commands/doctor
12
+ - /cli-documentation/cli-commands/npm-doctor
13
+ - /cli-documentation/commands/doctor
14
+ - /cli-documentation/commands/npm-doctor
15
+ - /cli-documentation/doctor
16
+ - /cli-documentation/npm-doctor
17
+ - /cli-documentation/v11/cli-commands/doctor
18
+ - /cli-documentation/v11/cli-commands/npm-doctor
19
+ - /cli-documentation/v11/commands/doctor
20
+ - /cli-documentation/v11/commands/npm-doctor
21
+ - /cli-documentation/v11/doctor
22
+ - /cli-documentation/v11/npm-doctor
23
+ - /cli/cli-commands/doctor
24
+ - /cli/cli-commands/npm-doctor
25
+ - /cli/commands/doctor
26
+ - /cli/commands/npm-doctor
27
+ - /cli/doctor
28
+ - /cli/npm-doctor
29
+ - /cli/v11/cli-commands/doctor
30
+ - /cli/v11/cli-commands/npm-doctor
31
+ - /cli/v11/commands/doctor
32
+ - /cli/v11/doctor
33
+ - /cli/v11/npm-doctor
34
+ - /commands/doctor
35
+ - /commands/npm-doctor
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm doctor [connection] [registry] [versions] [environment] [permissions] [cache]
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+`npm doctor` runs a set of checks to ensure that your npm installation has what it needs to manage your JavaScript packages. npm is mostly a standalone tool, but it does have some basic requirements that must be met:
49
+
50
+- Node.js and git must be executable by npm.
51
+- The primary npm registry, `registry.npmjs.com`, or another service that uses the registry API, is available.
52
+- The directories that npm uses, `node_modules` (both locally and globally), exist and can be written by the current user.
53
+- The npm cache exists, and the package tarballs within it aren't corrupt.
54
+
55
+Without all of these working properly, npm may not work properly. Many issues are often attributable to things that are outside npm's code base, so `npm doctor` confirms that the npm installation is in a good state.
56
+
57
+Also, in addition to this, there are also very many issue reports due to using old versions of npm. Since npm is constantly improving, running `npm@latest` is better than an old version.
58
+
59
+`npm doctor` verifies the following items in your environment, and if there are any recommended changes, it will display them. By default npm runs all of these checks. You can limit what checks are ran by specifying them as extra arguments.
60
+
61
+#### `Connecting to the registry`
62
+
63
+By default, npm installs from the primary npm registry, `registry.npmjs.org`. `npm doctor` hits a special connection testing endpoint within the registry. This can also be checked with `npm ping`. If this check fails, you may be using a proxy that needs to be configured, or may need to talk to your IT staff to get access over HTTPS to `registry.npmjs.org`.
64
+
65
+This check is done against whichever registry you've configured (you can see what that is by running `npm config get registry`), and if you're using a private registry that doesn't support the `/whoami` endpoint supported by the primary registry, this check may fail.
66
+
67
+#### `Checking npm version`
68
+
69
+While Node.js may come bundled with a particular version of npm, it's the policy of the CLI team that we recommend all users run `npm@latest` if they can. As the CLI is maintained by a small team of contributors, there are only resources for a single line of development, so npm's own long-term support releases typically only receive critical security and regression fixes. The team believes that the latest tested version of npm is almost always likely to be the most functional and defect-free version of npm.
70
+
71
+#### `Checking node version`
72
+
73
+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.
74
+
75
+#### `Checking configured npm registry`
76
+
77
+You may be installing from private package registries for your project or company. That's great! Others may be following tutorials or StackOverflow questions in an effort to troubleshoot problems you may be having. Sometimes, this may entail changing the registry you're pointing at. This part of `npm doctor` just lets you, and maybe whoever's helping you with support, know that you're not using the default registry.
78
+
79
+#### `Checking for git executable in PATH`
80
+
81
+While it's documented in the README, it may not be obvious that npm needs Git installed to do many of the things that it does. Also, in some cases – especially on Windows – you may have Git set up in such a way that it's not accessible via your `PATH` so that npm can find it. This check ensures that Git is available.
82
+
83
+#### Permissions checks
84
+
85
+- Your cache must be readable and writable by the user running npm.
86
+- Global package binaries must be writable by the user running npm.
87
+- Your local `node_modules` path, if you're running `npm doctor` with a project directory, must be readable and writable by the user running npm.
88
+
89
+#### Validate the checksums of cached packages
90
+
91
+When an npm package is published, the publishing process generates a checksum that npm uses at install time to verify that the package didn't get corrupted in transit. `npm doctor` uses these checksums to validate the package tarballs in your local cache (you can see where that cache is located with `npm config get cache`). In the event that there are corrupt packages in your cache, you should probably run `npm cache clean -f` and reset the cache.
92
+
93
+### Configuration
94
+
95
+#### `registry`
96
+
97
+- Default: "https://registry.npmjs.org/"
98
+- Type: URL
99
+
100
+The base URL of the npm registry.
101
+
102
+### See Also
103
+
104
+- [npm bugs](/cli/v11/commands/npm-bugs)
105
+- [npm help](/cli/v11/commands/npm-help)
106
+- [npm ping](/cli/v11/commands/npm-ping)
content/cli/v11/commands/npm-edit.mdx
new
+69
@@ -0,0 +1,69 @@
1
+---
2
+title: npm-edit
3
+section: 1
4
+description: Edit an installed package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-edit.md
8
+redirect_from:
9
+ - /cli-commands/edit
10
+ - /cli-commands/npm-edit
11
+ - /cli-documentation/cli-commands/edit
12
+ - /cli-documentation/cli-commands/npm-edit
13
+ - /cli-documentation/commands/edit
14
+ - /cli-documentation/commands/npm-edit
15
+ - /cli-documentation/edit
16
+ - /cli-documentation/npm-edit
17
+ - /cli-documentation/v11/cli-commands/edit
18
+ - /cli-documentation/v11/cli-commands/npm-edit
19
+ - /cli-documentation/v11/commands/edit
20
+ - /cli-documentation/v11/commands/npm-edit
21
+ - /cli-documentation/v11/edit
22
+ - /cli-documentation/v11/npm-edit
23
+ - /cli/cli-commands/edit
24
+ - /cli/cli-commands/npm-edit
25
+ - /cli/commands/edit
26
+ - /cli/commands/npm-edit
27
+ - /cli/edit
28
+ - /cli/npm-edit
29
+ - /cli/v11/cli-commands/edit
30
+ - /cli/v11/cli-commands/npm-edit
31
+ - /cli/v11/commands/edit
32
+ - /cli/v11/edit
33
+ - /cli/v11/npm-edit
34
+ - /commands/edit
35
+ - /commands/npm-edit
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm edit <pkg>[/<subpkg>...]
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+Selects a dependency in the current project and opens the package folder in the default editor (or whatever you've configured as the npm `editor` config -- see [`npm-config`](npm-config).)
49
+
50
+After it has been edited, the package is rebuilt so as to pick up any changes in compiled packages.
51
+
52
+For instance, you can do `npm install connect` to install connect into your package, and then `npm edit connect` to make a few changes to your locally installed copy.
53
+
54
+### Configuration
55
+
56
+#### `editor`
57
+
58
+- Default: The EDITOR or VISUAL environment variables, or '%SYSTEMROOT%\notepad.exe' on Windows, or 'vi' on Unix systems
59
+- Type: String
60
+
61
+The command to run for `npm edit` and `npm config edit`.
62
+
63
+### See Also
64
+
65
+- [npm folders](/cli/v11/configuring-npm/folders)
66
+- [npm explore](/cli/v11/commands/npm-explore)
67
+- [npm install](/cli/v11/commands/npm-install)
68
+- [npm config](/cli/v11/commands/npm-config)
69
+- [npmrc](/cli/v11/configuring-npm/npmrc)
content/cli/v11/commands/npm-exec.mdx
new
+304
@@ -0,0 +1,304 @@
1
+---
2
+title: npm-exec
3
+section: 1
4
+description: Run a command from a local or remote npm package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-exec.md
8
+redirect_from:
9
+ - /cli-commands/exec
10
+ - /cli-commands/npm-exec
11
+ - /cli-documentation/cli-commands/exec
12
+ - /cli-documentation/cli-commands/npm-exec
13
+ - /cli-documentation/commands/exec
14
+ - /cli-documentation/commands/npm-exec
15
+ - /cli-documentation/exec
16
+ - /cli-documentation/npm-exec
17
+ - /cli-documentation/v11/cli-commands/exec
18
+ - /cli-documentation/v11/cli-commands/npm-exec
19
+ - /cli-documentation/v11/commands/exec
20
+ - /cli-documentation/v11/commands/npm-exec
21
+ - /cli-documentation/v11/exec
22
+ - /cli-documentation/v11/npm-exec
23
+ - /cli/cli-commands/exec
24
+ - /cli/cli-commands/npm-exec
25
+ - /cli/commands/exec
26
+ - /cli/commands/npm-exec
27
+ - /cli/exec
28
+ - /cli/npm-exec
29
+ - /cli/v11/cli-commands/exec
30
+ - /cli/v11/cli-commands/npm-exec
31
+ - /cli/v11/commands/exec
32
+ - /cli/v11/exec
33
+ - /cli/v11/npm-exec
34
+ - /commands/exec
35
+ - /commands/npm-exec
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm exec -- <pkg>[@<version>] [args...]
42
+npm exec --package=<pkg>[@<version>] -- <cmd> [args...]
43
+npm exec -c '<cmd> [args...]'
44
+npm exec --package=foo -c '<cmd> [args...]'
45
+
46
+alias: x
47
+```
48
+
49
+### Description
50
+
51
+This command allows you to run an arbitrary command from an npm package (either one installed locally, or fetched remotely), in a similar context as running it via `npm run`.
52
+
53
+Run without positional arguments or `--call`, this allows you to interactively run commands in the same sort of shell environment that `package.json` scripts are run. Interactive mode is not supported in CI environments when standard input is a TTY, to prevent hangs.
54
+
55
+Whatever packages are specified by the `--package` option will be provided in the `PATH` of the executed command, along with any locally installed package executables. The `--package` option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available.
56
+
57
+If any requested packages are not present in the local project dependencies, then a prompt is printed, which can be suppressed by providing either `--yes` or `--no`. When standard input is not a TTY or a CI environment is detected, `--yes` is assumed. The requested packages are installed to a folder in the npm cache, which is added to the `PATH` environment variable in the executed process.
58
+
59
+Package names provided without a specifier will be matched with whatever version exists in the local project. Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency.
60
+
61
+If no `-c` or `--call` option is provided, then the positional arguments are used to generate the command string. If no `--package` options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic:
62
+
63
+- If the package has a single entry in its `bin` field in `package.json`, or if all entries are aliases of the same command, then that command will be used.
64
+- If the package has multiple `bin` entries, and one of them matches the unscoped portion of the `name` field, then that command will be used.
65
+- If this does not result in exactly one option (either because there are no bin entries, or none of them match the `name` of the package), then `npm exec` exits with an error.
66
+
67
+To run a binary _other than_ the named binary, specify one or more `--package` options, which will prevent npm from inferring the package from the first command argument.
68
+
69
+### `npx` vs `npm exec`
70
+
71
+When run via the `npx` binary, all flags and options _must_ be set prior to any positional arguments. When run via `npm exec`, a double-hyphen `--` flag can be used to suppress npm's parsing of switches and options that should be sent to the executed command.
72
+
73
+For example:
74
+
75
+```
76
+$ npx foo@latest bar --package=@npmcli/foo
77
+```
78
+
79
+In this case, npm will resolve the `foo` package name, and run the following command:
80
+
81
+```
82
+$ foo bar --package=@npmcli/foo
83
+```
84
+
85
+Since the `--package` option comes _after_ the positional arguments, it is treated as an argument to the executed command.
86
+
87
+In contrast, due to npm's argument parsing logic, running this command is different:
88
+
89
+```
90
+$ npm exec foo@latest bar --package=@npmcli/foo
91
+```
92
+
93
+In this case, npm will parse the `--package` option first, resolving the `@npmcli/foo` package. Then, it will execute the following command in that context:
94
+
95
+```
96
+$ foo@latest bar
97
+```
98
+
99
+The double-hyphen character is recommended to explicitly tell npm to stop parsing command line options and switches. The following command would thus be equivalent to the `npx` command above:
100
+
101
+```
102
+$ npm exec -- foo@latest bar --package=@npmcli/foo
103
+```
104
+
105
+### Configuration
106
+
107
+#### `package`
108
+
109
+- Default:
110
+- Type: String (can be set multiple times)
111
+
112
+The package or packages to install for [`npm exec`](/cli/v11/commands/npm-exec)
113
+
114
+#### `call`
115
+
116
+- Default: ""
117
+- Type: String
118
+
119
+Optional companion option for `npm exec`, `npx` that allows for specifying a custom command to be run along with the installed packages.
120
+
121
+```bash
122
+npm exec --package yo --package generator-node --call "yo node"
123
+```
124
+
125
+#### `workspace`
126
+
127
+- Default:
128
+- Type: String (can be set multiple times)
129
+
130
+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.
131
+
132
+Valid values for the `workspace` config are either:
133
+
134
+- Workspace names
135
+- Path to a workspace directory
136
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
137
+
138
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
139
+
140
+This value is not exported to the environment for child processes.
141
+
142
+#### `workspaces`
143
+
144
+- Default: null
145
+- Type: null or Boolean
146
+
147
+Set to true to run the command in the context of **all** configured workspaces.
148
+
149
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
150
+
151
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
152
+
153
+This value is not exported to the environment for child processes.
154
+
155
+#### `include-workspace-root`
156
+
157
+- Default: false
158
+- Type: Boolean
159
+
160
+Include the workspace root when workspaces are enabled for a command.
161
+
162
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
163
+
164
+This value is not exported to the environment for child processes.
165
+
166
+### Examples
167
+
168
+Run the version of `tap` in the local dependencies, with the provided arguments:
169
+
170
+```
171
+$ npm exec -- tap --bail test/foo.js
172
+$ npx tap --bail test/foo.js
173
+```
174
+
175
+Run a command _other than_ the command whose name matches the package name by specifying a `--package` option:
176
+
177
+```
178
+$ npm exec --package=foo -- bar --bar-argument
179
+# ~ or ~
180
+$ npx --package=foo bar --bar-argument
181
+```
182
+
183
+Run an arbitrary shell script, in the context of the current project:
184
+
185
+```
186
+$ npm x -c 'eslint && say "hooray, lint passed"'
187
+$ npx -c 'eslint && say "hooray, lint passed"'
188
+```
189
+
190
+### Workspaces support
191
+
192
+You may use the [`workspace`](/cli/v11/using-npm/config#workspace) or [`workspaces`](/cli/v11/using-npm/config#workspaces) configs in order to run an arbitrary command from an npm package (either one installed locally, or fetched remotely) in the context of the specified workspaces. If no positional argument or `--call` option is provided, it will open an interactive subshell in the context of each of these configured workspaces one at a time.
193
+
194
+Given a project with configured workspaces, e.g:
195
+
196
+```
197
+.
198
++-- package.json
199
+`-- packages
200
+ +-- a
201
+ | `-- package.json
202
+ +-- b
203
+ | `-- package.json
204
+ `-- c
205
+ `-- package.json
206
+```
207
+
208
+Assuming the workspace configuration is properly set up at the root level `package.json` file. e.g:
209
+
210
+```
211
+{
212
+ "workspaces": [ "./packages/*" ]
213
+}
214
+```
215
+
216
+You can execute an arbitrary command from a package in the context of each of the configured workspaces when using the [`workspaces` config options](/cli/v11/using-npm/config#workspace), in this example we're using **eslint** to lint any js file found within each workspace folder:
217
+
218
+```
219
+npm exec --ws -- eslint ./*.js
220
+```
221
+
222
+#### Filtering workspaces
223
+
224
+It's also possible to execute a command in a single workspace using the `workspace` config along with a name or directory path:
225
+
226
+```
227
+npm exec --workspace=a -- eslint ./*.js
228
+```
229
+
230
+The `workspace` config can also be specified multiple times in order to run a specific script in the context of multiple workspaces. When defining values for the `workspace` config in the command line, it also possible to use `-w` as a shorthand, e.g:
231
+
232
+```
233
+npm exec -w a -w b -- eslint ./*.js
234
+```
235
+
236
+This last command will run the `eslint` command in both `./packages/a` and `./packages/b` folders.
237
+
238
+### Compatibility with Older npx Versions
239
+
240
+The `npx` binary was rewritten in npm v7.0.0, and the standalone `npx` package deprecated at that time. `npx` uses the `npm exec` command instead of a separate argument parser and install process, with some affordances to maintain backwards compatibility with the arguments it accepted in previous versions.
241
+
242
+This resulted in some shifts in its functionality:
243
+
244
+- Any `npm` config value may be provided.
245
+- To prevent security and user-experience problems from mistyping package names, `npx` prompts before installing anything. Suppress this prompt with the `-y` or `--yes` option.
246
+- The `--no-install` option is deprecated, and will be converted to `--no`.
247
+- Shell fallback functionality is removed, as it is not advisable.
248
+- The `-p` argument is a shorthand for `--parseable` in npm, but shorthand for `--package` in npx. This is maintained, but only for the `npx` executable.
249
+- The `--ignore-existing` option is removed. Locally installed bins are always present in the executed process `PATH`.
250
+- The `--npm` option is removed. `npx` will always use the `npm` it ships with.
251
+- The `--node-arg` and `-n` options are removed.
252
+- The `--always-spawn` option is redundant, and thus removed.
253
+- The `--shell` option is replaced with `--script-shell`, but maintained in the `npx` executable for backwards compatibility.
254
+
255
+### A note on caching
256
+
257
+The npm cli utilizes its internal package cache when using the package name specified. You can use the following to change how and when the cli uses this cache. See [`npm cache`](/cli/v11/commands/npm-cache) for more on how the cache works.
258
+
259
+#### prefer-online
260
+
261
+Forces staleness checks for packages, making the cli look for updates immediately even if the package is already in the cache.
262
+
263
+#### prefer-offline
264
+
265
+Bypasses staleness checks for packages. Missing data will still be requested from the server. To force full offline mode, use `offline`.
266
+
267
+#### offline
268
+
269
+Forces full offline mode. Any packages not locally cached will result in an error.
270
+
271
+#### workspace
272
+
273
+- Default:
274
+- Type: String (can be set multiple times)
275
+
276
+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.
277
+
278
+Valid values for the `workspace` config are either:
279
+
280
+- Workspace names
281
+- Path to a workspace directory
282
+- Path to a parent workspace directory (will result to selecting all of the nested workspaces)
283
+
284
+This value is not exported to the environment for child processes.
285
+
286
+#### workspaces
287
+
288
+- Alias: `--ws`
289
+- Type: Boolean
290
+- Default: `false`
291
+
292
+Run scripts in the context of all configured workspaces for the current project.
293
+
294
+### See Also
295
+
296
+- [npm run-script](/cli/v11/commands/npm-run-script)
297
+- [npm scripts](/cli/v11/using-npm/scripts)
298
+- [npm test](/cli/v11/commands/npm-test)
299
+- [npm start](/cli/v11/commands/npm-start)
300
+- [npm restart](/cli/v11/commands/npm-restart)
301
+- [npm stop](/cli/v11/commands/npm-stop)
302
+- [npm config](/cli/v11/commands/npm-config)
303
+- [npm workspaces](/cli/v11/using-npm/workspaces)
304
+- [npx](/cli/v11/commands/npx)
content/cli/v11/commands/npm-explain.mdx
new
+124
@@ -0,0 +1,124 @@
1
+---
2
+title: npm-explain
3
+section: 1
4
+description: Explain installed packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-explain.md
8
+redirect_from:
9
+ - /cli-commands/explain
10
+ - /cli-commands/npm-explain
11
+ - /cli-documentation/cli-commands/explain
12
+ - /cli-documentation/cli-commands/npm-explain
13
+ - /cli-documentation/commands/explain
14
+ - /cli-documentation/commands/npm-explain
15
+ - /cli-documentation/explain
16
+ - /cli-documentation/npm-explain
17
+ - /cli-documentation/v11/cli-commands/explain
18
+ - /cli-documentation/v11/cli-commands/npm-explain
19
+ - /cli-documentation/v11/commands/explain
20
+ - /cli-documentation/v11/commands/npm-explain
21
+ - /cli-documentation/v11/explain
22
+ - /cli-documentation/v11/npm-explain
23
+ - /cli/cli-commands/explain
24
+ - /cli/cli-commands/npm-explain
25
+ - /cli/commands/explain
26
+ - /cli/commands/npm-explain
27
+ - /cli/explain
28
+ - /cli/npm-explain
29
+ - /cli/v11/cli-commands/explain
30
+ - /cli/v11/cli-commands/npm-explain
31
+ - /cli/v11/commands/explain
32
+ - /cli/v11/explain
33
+ - /cli/v11/npm-explain
34
+ - /commands/explain
35
+ - /commands/npm-explain
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm explain <package-spec>
42
+
43
+alias: why
44
+```
45
+
46
+### Description
47
+
48
+This command will print the chain of dependencies causing a given package to be installed in the current project.
49
+
50
+If one or more package specs are provided, then only packages matching one of the specifiers will have their relationships explained.
51
+
52
+The package spec can also refer to a folder within `./node_modules`
53
+
54
+For example, running `npm explain glob` within npm's source tree will show:
55
+
56
+```bash
57
+glob@7.1.6
58
+node_modules/glob
59
+ glob@"^7.1.4" from the root project
60
+
61
+glob@7.1.1 dev
62
+node_modules/tacks/node_modules/glob
63
+ glob@"^7.0.5" from rimraf@2.6.2
64
+ node_modules/tacks/node_modules/rimraf
65
+ rimraf@"^2.6.2" from tacks@1.3.0
66
+ node_modules/tacks
67
+ dev tacks@"^1.3.0" from the root project
68
+```
69
+
70
+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.
71
+
72
+```bash
73
+$ npm explain node_modules/nyc/node_modules/find-up
74
+find-up@3.0.0 dev
75
+node_modules/nyc/node_modules/find-up
76
+ find-up@"^3.0.0" from nyc@14.1.1
77
+ node_modules/nyc
78
+ nyc@"^14.1.1" from tap@14.10.8
79
+ node_modules/tap
80
+ dev tap@"^14.10.8" from the root project
81
+```
82
+
83
+### Configuration
84
+
85
+#### `json`
86
+
87
+- Default: false
88
+- Type: Boolean
89
+
90
+Whether or not to output JSON data, rather than the normal output.
91
+
92
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
93
+
94
+Not supported by all npm commands.
95
+
96
+#### `workspace`
97
+
98
+- Default:
99
+- Type: String (can be set multiple times)
100
+
101
+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.
102
+
103
+Valid values for the `workspace` config are either:
104
+
105
+- Workspace names
106
+- Path to a workspace directory
107
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
108
+
109
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
110
+
111
+This value is not exported to the environment for child processes.
112
+
113
+### See Also
114
+
115
+- [package spec](/cli/v11/using-npm/package-spec)
116
+- [npm config](/cli/v11/commands/npm-config)
117
+- [npmrc](/cli/v11/configuring-npm/npmrc)
118
+- [npm folders](/cli/v11/configuring-npm/folders)
119
+- [npm ls](/cli/v11/commands/npm-ls)
120
+- [npm install](/cli/v11/commands/npm-install)
121
+- [npm link](/cli/v11/commands/npm-link)
122
+- [npm prune](/cli/v11/commands/npm-prune)
123
+- [npm outdated](/cli/v11/commands/npm-outdated)
124
+- [npm update](/cli/v11/commands/npm-update)
content/cli/v11/commands/npm-explore.mdx
new
+74
@@ -0,0 +1,74 @@
1
+---
2
+title: npm-explore
3
+section: 1
4
+description: Browse an installed package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-explore.md
8
+redirect_from:
9
+ - /cli-commands/explore
10
+ - /cli-commands/npm-explore
11
+ - /cli-documentation/cli-commands/explore
12
+ - /cli-documentation/cli-commands/npm-explore
13
+ - /cli-documentation/commands/explore
14
+ - /cli-documentation/commands/npm-explore
15
+ - /cli-documentation/explore
16
+ - /cli-documentation/npm-explore
17
+ - /cli-documentation/v11/cli-commands/explore
18
+ - /cli-documentation/v11/cli-commands/npm-explore
19
+ - /cli-documentation/v11/commands/explore
20
+ - /cli-documentation/v11/commands/npm-explore
21
+ - /cli-documentation/v11/explore
22
+ - /cli-documentation/v11/npm-explore
23
+ - /cli/cli-commands/explore
24
+ - /cli/cli-commands/npm-explore
25
+ - /cli/commands/explore
26
+ - /cli/commands/npm-explore
27
+ - /cli/explore
28
+ - /cli/npm-explore
29
+ - /cli/v11/cli-commands/explore
30
+ - /cli/v11/cli-commands/npm-explore
31
+ - /cli/v11/commands/explore
32
+ - /cli/v11/explore
33
+ - /cli/v11/npm-explore
34
+ - /commands/explore
35
+ - /commands/npm-explore
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm explore <pkg> [ -- <command>]
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+Spawn a subshell in the directory of the installed package specified.
49
+
50
+If a command is specified, then it is run in the subshell, which then immediately terminates.
51
+
52
+This is particularly handy in the case of git submodules in the `node_modules` folder:
53
+
54
+```bash
55
+npm explore some-dependency -- git pull origin master
56
+```
57
+
58
+Note that the package is _not_ automatically rebuilt afterwards, so be sure to use `npm rebuild <pkg>` if you make any changes.
59
+
60
+### Configuration
61
+
62
+#### `shell`
63
+
64
+- Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" on Windows
65
+- Type: String
66
+
67
+The shell to run for the `npm explore` command.
68
+
69
+### See Also
70
+
71
+- [npm folders](/cli/v11/configuring-npm/folders)
72
+- [npm edit](/cli/v11/commands/npm-edit)
73
+- [npm rebuild](/cli/v11/commands/npm-rebuild)
74
+- [npm install](/cli/v11/commands/npm-install)
content/cli/v11/commands/npm-find-dupes.mdx
new
+200
@@ -0,0 +1,200 @@
1
+---
2
+title: npm-find-dupes
3
+section: 1
4
+description: Find duplication in the package tree
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-find-dupes.md
8
+redirect_from:
9
+ - /cli-commands/find-dupes
10
+ - /cli-commands/npm-find-dupes
11
+ - /cli-documentation/cli-commands/find-dupes
12
+ - /cli-documentation/cli-commands/npm-find-dupes
13
+ - /cli-documentation/commands/find-dupes
14
+ - /cli-documentation/commands/npm-find-dupes
15
+ - /cli-documentation/find-dupes
16
+ - /cli-documentation/npm-find-dupes
17
+ - /cli-documentation/v11/cli-commands/find-dupes
18
+ - /cli-documentation/v11/cli-commands/npm-find-dupes
19
+ - /cli-documentation/v11/commands/find-dupes
20
+ - /cli-documentation/v11/commands/npm-find-dupes
21
+ - /cli-documentation/v11/find-dupes
22
+ - /cli-documentation/v11/npm-find-dupes
23
+ - /cli/cli-commands/find-dupes
24
+ - /cli/cli-commands/npm-find-dupes
25
+ - /cli/commands/find-dupes
26
+ - /cli/commands/npm-find-dupes
27
+ - /cli/find-dupes
28
+ - /cli/npm-find-dupes
29
+ - /cli/v11/cli-commands/find-dupes
30
+ - /cli/v11/cli-commands/npm-find-dupes
31
+ - /cli/v11/commands/find-dupes
32
+ - /cli/v11/find-dupes
33
+ - /cli/v11/npm-find-dupes
34
+ - /commands/find-dupes
35
+ - /commands/npm-find-dupes
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm find-dupes
42
+```
43
+
44
+### Description
45
+
46
+Runs `npm dedupe` in `--dry-run` mode, making npm only output the duplications, without actually changing the package tree.
47
+
48
+### Configuration
49
+
50
+#### `install-strategy`
51
+
52
+- Default: "hoisted"
53
+- Type: "hoisted", "nested", "shallow", or "linked"
54
+
55
+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.
56
+
57
+#### `legacy-bundling`
58
+
59
+- Default: false
60
+- Type: Boolean
61
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
62
+
63
+Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
64
+
65
+#### `global-style`
66
+
67
+- Default: false
68
+- Type: Boolean
69
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
70
+
71
+Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
72
+
73
+#### `strict-peer-deps`
74
+
75
+- Default: false
76
+- Type: Boolean
77
+
78
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
79
+
80
+By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
81
+
82
+When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
83
+
84
+#### `package-lock`
85
+
86
+- Default: true
87
+- Type: Boolean
88
+
89
+If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
90
+
91
+#### `omit`
92
+
93
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
94
+- Type: "dev", "optional", or "peer" (can be set multiple times)
95
+
96
+Dependency types to omit from the installation tree on disk.
97
+
98
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
99
+
100
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
101
+
102
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
103
+
104
+#### `include`
105
+
106
+- Default:
107
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
108
+
109
+Option that allows for defining which types of dependencies to install.
110
+
111
+This is the inverse of `--omit=<type>`.
112
+
113
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
114
+
115
+#### `ignore-scripts`
116
+
117
+- Default: false
118
+- Type: Boolean
119
+
120
+If true, npm does not run scripts specified in package.json files.
121
+
122
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
123
+
124
+#### `audit`
125
+
126
+- Default: true
127
+- Type: Boolean
128
+
129
+When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
130
+
131
+#### `bin-links`
132
+
133
+- Default: true
134
+- Type: Boolean
135
+
136
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
137
+
138
+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.
139
+
140
+#### `fund`
141
+
142
+- Default: true
143
+- Type: Boolean
144
+
145
+When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
146
+
147
+#### `workspace`
148
+
149
+- Default:
150
+- Type: String (can be set multiple times)
151
+
152
+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.
153
+
154
+Valid values for the `workspace` config are either:
155
+
156
+- Workspace names
157
+- Path to a workspace directory
158
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
159
+
160
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
161
+
162
+This value is not exported to the environment for child processes.
163
+
164
+#### `workspaces`
165
+
166
+- Default: null
167
+- Type: null or Boolean
168
+
169
+Set to true to run the command in the context of **all** configured workspaces.
170
+
171
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
172
+
173
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
174
+
175
+This value is not exported to the environment for child processes.
176
+
177
+#### `include-workspace-root`
178
+
179
+- Default: false
180
+- Type: Boolean
181
+
182
+Include the workspace root when workspaces are enabled for a command.
183
+
184
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
185
+
186
+This value is not exported to the environment for child processes.
187
+
188
+#### `install-links`
189
+
190
+- Default: false
191
+- Type: Boolean
192
+
193
+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.
194
+
195
+### See Also
196
+
197
+- [npm dedupe](/cli/v11/commands/npm-dedupe)
198
+- [npm ls](/cli/v11/commands/npm-ls)
199
+- [npm update](/cli/v11/commands/npm-update)
200
+- [npm install](/cli/v11/commands/npm-install)
content/cli/v11/commands/npm-fund.mdx
new
+146
@@ -0,0 +1,146 @@
1
+---
2
+title: npm-fund
3
+section: 1
4
+description: Retrieve funding information
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-fund.md
8
+redirect_from:
9
+ - /cli-commands/fund
10
+ - /cli-commands/npm-fund
11
+ - /cli-documentation/cli-commands/fund
12
+ - /cli-documentation/cli-commands/npm-fund
13
+ - /cli-documentation/commands/fund
14
+ - /cli-documentation/commands/npm-fund
15
+ - /cli-documentation/fund
16
+ - /cli-documentation/npm-fund
17
+ - /cli-documentation/v11/cli-commands/fund
18
+ - /cli-documentation/v11/cli-commands/npm-fund
19
+ - /cli-documentation/v11/commands/fund
20
+ - /cli-documentation/v11/commands/npm-fund
21
+ - /cli-documentation/v11/fund
22
+ - /cli-documentation/v11/npm-fund
23
+ - /cli/cli-commands/fund
24
+ - /cli/cli-commands/npm-fund
25
+ - /cli/commands/fund
26
+ - /cli/commands/npm-fund
27
+ - /cli/fund
28
+ - /cli/npm-fund
29
+ - /cli/v11/cli-commands/fund
30
+ - /cli/v11/cli-commands/npm-fund
31
+ - /cli/v11/commands/fund
32
+ - /cli/v11/fund
33
+ - /cli/v11/npm-fund
34
+ - /commands/fund
35
+ - /commands/npm-fund
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm fund [<package-spec>]
42
+```
43
+
44
+### Description
45
+
46
+This command retrieves information on how to fund the dependencies of a given project. If no package name is provided, it will list all dependencies that are looking for funding in a tree structure, listing the type of funding and the url to visit. If a package name is provided then it tries to open its funding url using the [`--browser` config](/cli/v11/using-npm/config#browser) param; if there are multiple funding sources for the package, the user will be instructed to pass the `--which` option to disambiguate.
47
+
48
+The list will avoid duplicated entries and will stack all packages that share the same url as a single entry. Thus, the list does not have the same shape of the output from `npm ls`.
49
+
50
+#### Example
51
+
52
+### Workspaces support
53
+
54
+It's possible to filter the results to only include a single workspace and its dependencies using the [`workspace` config](/cli/v11/using-npm/config#workspace) option.
55
+
56
+#### Example:
57
+
58
+Here's an example running `npm fund` in a project with a configured workspace `a`:
59
+
60
+```bash
61
+$ npm fund
62
+test-workspaces-fund@1.0.0
63
++-- https://example.com/a
64
+| | `-- a@1.0.0
65
+| `-- https://example.com/maintainer
66
+| `-- foo@1.0.0
67
++-- https://example.com/npmcli-funding
68
+| `-- @npmcli/test-funding
69
+`-- https://example.com/org
70
+ `-- bar@2.0.0
71
+```
72
+
73
+And here is an example of the expected result when filtering only by a specific workspace `a` in the same project:
74
+
75
+```bash
76
+$ npm fund -w a
77
+test-workspaces-fund@1.0.0
78
+`-- https://example.com/a
79
+ | `-- a@1.0.0
80
+ `-- https://example.com/maintainer
81
+ `-- foo@2.0.0
82
+```
83
+
84
+### Configuration
85
+
86
+#### `json`
87
+
88
+- Default: false
89
+- Type: Boolean
90
+
91
+Whether or not to output JSON data, rather than the normal output.
92
+
93
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
94
+
95
+Not supported by all npm commands.
96
+
97
+#### `browser`
98
+
99
+- Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
100
+- Type: null, Boolean, or String
101
+
102
+The browser that is called by npm commands to open websites.
103
+
104
+Set to `false` to suppress browser behavior and instead print urls to terminal.
105
+
106
+Set to `true` to use default system URL opener.
107
+
108
+#### `unicode`
109
+
110
+- Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the `LC_ALL`, `LC_CTYPE`, or `LANG` environment variables.
111
+- Type: Boolean
112
+
113
+When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
114
+
115
+#### `workspace`
116
+
117
+- Default:
118
+- Type: String (can be set multiple times)
119
+
120
+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.
121
+
122
+Valid values for the `workspace` config are either:
123
+
124
+- Workspace names
125
+- Path to a workspace directory
126
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
127
+
128
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
129
+
130
+This value is not exported to the environment for child processes.
131
+
132
+#### `which`
133
+
134
+- Default: null
135
+- Type: null or Number
136
+
137
+If there are multiple funding sources, which 1-indexed source URL to open.
138
+
139
+## See Also
140
+
141
+- [package spec](/cli/v11/using-npm/package-spec)
142
+- [npm install](/cli/v11/commands/npm-install)
143
+- [npm docs](/cli/v11/commands/npm-docs)
144
+- [npm ls](/cli/v11/commands/npm-ls)
145
+- [npm config](/cli/v11/commands/npm-config)
146
+- [npm workspaces](/cli/v11/using-npm/workspaces)
content/cli/v11/commands/npm-help-search.mdx
new
+66
@@ -0,0 +1,66 @@
1
+---
2
+title: npm-help-search
3
+section: 1
4
+description: Search npm help documentation
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-help-search.md
8
+redirect_from:
9
+ - /cli-commands/help-search
10
+ - /cli-commands/npm-help-search
11
+ - /cli-documentation/cli-commands/help-search
12
+ - /cli-documentation/cli-commands/npm-help-search
13
+ - /cli-documentation/commands/help-search
14
+ - /cli-documentation/commands/npm-help-search
15
+ - /cli-documentation/help-search
16
+ - /cli-documentation/npm-help-search
17
+ - /cli-documentation/v11/cli-commands/help-search
18
+ - /cli-documentation/v11/cli-commands/npm-help-search
19
+ - /cli-documentation/v11/commands/help-search
20
+ - /cli-documentation/v11/commands/npm-help-search
21
+ - /cli-documentation/v11/help-search
22
+ - /cli-documentation/v11/npm-help-search
23
+ - /cli/cli-commands/help-search
24
+ - /cli/cli-commands/npm-help-search
25
+ - /cli/commands/help-search
26
+ - /cli/commands/npm-help-search
27
+ - /cli/help-search
28
+ - /cli/npm-help-search
29
+ - /cli/v11/cli-commands/help-search
30
+ - /cli/v11/cli-commands/npm-help-search
31
+ - /cli/v11/commands/help-search
32
+ - /cli/v11/help-search
33
+ - /cli/v11/npm-help-search
34
+ - /commands/help-search
35
+ - /commands/npm-help-search
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm help-search <text>
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+This command will search the npm markdown documentation files for the terms provided, and then list the results, sorted by relevance.
49
+
50
+If only one result is found, then it will show that help topic.
51
+
52
+If the argument to `npm help` is not a known help topic, then it will call `help-search`. It is rarely if ever necessary to call this command directly.
53
+
54
+### Configuration
55
+
56
+#### `long`
57
+
58
+- Default: false
59
+- Type: Boolean
60
+
61
+Show extended information in `ls`, `search`, and `help-search`.
62
+
63
+### See Also
64
+
65
+- [npm](/cli/v11/commands/npm)
66
+- [npm help](/cli/v11/commands/npm-help)
content/cli/v11/commands/npm-help.mdx
new
+72
@@ -0,0 +1,72 @@
1
+---
2
+title: npm-help
3
+section: 1
4
+description: Get help on npm
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-help.md
8
+redirect_from:
9
+ - /cli-commands/help
10
+ - /cli-commands/npm-help
11
+ - /cli-documentation/cli-commands/help
12
+ - /cli-documentation/cli-commands/npm-help
13
+ - /cli-documentation/commands/help
14
+ - /cli-documentation/commands/npm-help
15
+ - /cli-documentation/help
16
+ - /cli-documentation/npm-help
17
+ - /cli-documentation/v11/cli-commands/help
18
+ - /cli-documentation/v11/cli-commands/npm-help
19
+ - /cli-documentation/v11/commands/help
20
+ - /cli-documentation/v11/commands/npm-help
21
+ - /cli-documentation/v11/help
22
+ - /cli-documentation/v11/npm-help
23
+ - /cli/cli-commands/help
24
+ - /cli/cli-commands/npm-help
25
+ - /cli/commands/help
26
+ - /cli/commands/npm-help
27
+ - /cli/help
28
+ - /cli/npm-help
29
+ - /cli/v11/cli-commands/help
30
+ - /cli/v11/cli-commands/npm-help
31
+ - /cli/v11/commands/help
32
+ - /cli/v11/help
33
+ - /cli/v11/npm-help
34
+ - /commands/help
35
+ - /commands/npm-help
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm help <term> [<terms..>]
42
+
43
+alias: hlep
44
+```
45
+
46
+Note: This command is unaware of workspaces.
47
+
48
+### Description
49
+
50
+If supplied a topic, then show the appropriate documentation page.
51
+
52
+If the topic does not exist, or if multiple terms are provided, then npm will run the `help-search` command to find a match. Note that, if `help-search` finds a single subject, then it will run `help` on that topic, so unique matches are equivalent to specifying a topic name.
53
+
54
+### Configuration
55
+
56
+#### `viewer`
57
+
58
+- Default: "man" on Posix, "browser" on Windows
59
+- Type: String
60
+
61
+The program to use to view help content.
62
+
63
+Set to `"browser"` to view html help content in the default web browser.
64
+
65
+### See Also
66
+
67
+- [npm](/cli/v11/commands/npm)
68
+- [npm folders](/cli/v11/configuring-npm/folders)
69
+- [npm config](/cli/v11/commands/npm-config)
70
+- [npmrc](/cli/v11/configuring-npm/npmrc)
71
+- [package.json](/cli/v11/configuring-npm/package-json)
72
+- [npm help-search](/cli/v11/commands/npm-help-search)
content/cli/v11/commands/npm-init.mdx
new
+301
@@ -0,0 +1,301 @@
1
+---
2
+title: npm-init
3
+section: 1
4
+description: Create a package.json file
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-init.md
8
+redirect_from:
9
+ - /cli-commands/init
10
+ - /cli-commands/npm-init
11
+ - /cli-documentation/cli-commands/init
12
+ - /cli-documentation/cli-commands/npm-init
13
+ - /cli-documentation/commands/init
14
+ - /cli-documentation/commands/npm-init
15
+ - /cli-documentation/init
16
+ - /cli-documentation/npm-init
17
+ - /cli-documentation/v11/cli-commands/init
18
+ - /cli-documentation/v11/cli-commands/npm-init
19
+ - /cli-documentation/v11/commands/init
20
+ - /cli-documentation/v11/commands/npm-init
21
+ - /cli-documentation/v11/init
22
+ - /cli-documentation/v11/npm-init
23
+ - /cli/cli-commands/init
24
+ - /cli/cli-commands/npm-init
25
+ - /cli/commands/init
26
+ - /cli/commands/npm-init
27
+ - /cli/init
28
+ - /cli/npm-init
29
+ - /cli/v11/cli-commands/init
30
+ - /cli/v11/cli-commands/npm-init
31
+ - /cli/v11/commands/init
32
+ - /cli/v11/init
33
+ - /cli/v11/npm-init
34
+ - /commands/init
35
+ - /commands/npm-init
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm init <package-spec> (same as `npx create-<package-spec>`)
42
+npm init <@scope> (same as `npx <@scope>/create`)
43
+
44
+aliases: create, innit
45
+```
46
+
47
+### Description
48
+
49
+`npm init <initializer>` can be used to set up a new or existing npm package.
50
+
51
+`initializer` in this case is an npm package named `create-<initializer>`, which will be installed by [`npm-exec`](/cli/v11/commands/npm-exec), and then have its main bin executed -- presumably creating or updating `package.json` and running any other initialization-related operations.
52
+
53
+The init command is transformed to a corresponding `npm exec` operation as follows:
54
+
55
+- `npm init foo` -> `npm exec create-foo`
56
+- `npm init @usr/foo` -> `npm exec @usr/create-foo`
57
+- `npm init @usr` -> `npm exec @usr/create`
58
+- `npm init @usr@2.0.0` -> `npm exec @usr/create@2.0.0`
59
+- `npm init @usr/foo@2.0.0` -> `npm exec @usr/create-foo@2.0.0`
60
+
61
+If the initializer is omitted (by just calling `npm init`), init will fall back to legacy init behavior. It will ask you a bunch of questions, and then write a package.json for you. It will attempt to make reasonable guesses based on existing fields, dependencies, and options selected. It is strictly additive, so it will keep any fields and values that were already set. You can also use `-y`/`--yes` to skip the questionnaire altogether. If you pass `--scope`, it will create a scoped package.
62
+
63
+_Note:_ if a user already has the `create-<initializer>` package globally installed, that will be what `npm init` uses. If you want npm to use the latest version, or another specific version you must specify it:
64
+
65
+- `npm init foo@latest` # fetches and runs the latest `create-foo` from the registry
66
+- `npm init foo@1.2.3` # runs `create-foo@1.2.3` specifically
67
+
68
+#### Forwarding additional options
69
+
70
+Any additional options will be passed directly to the command, so `npm init foo -- --hello` will map to `npm exec -- create-foo --hello`.
71
+
72
+To better illustrate how options are forwarded, here's a more evolved example showing options passed to both the **npm cli** and a create package, both following commands are equivalent:
73
+
74
+- `npm init foo -y --registry=<url> -- --hello -a`
75
+- `npm exec -y --registry=<url> -- create-foo --hello -a`
76
+
77
+### Examples
78
+
79
+Create a new React-based project using [`create-react-app`](https://npm.im/create-react-app):
80
+
81
+```bash
82
+$ npm init react-app ./my-react-app
83
+```
84
+
85
+Create a new `esm`-compatible package using [`create-esm`](https://npm.im/create-esm):
86
+
87
+```bash
88
+$ mkdir my-esm-lib && cd my-esm-lib
89
+$ npm init esm --yes
90
+```
91
+
92
+Generate a plain old package.json using legacy init:
93
+
94
+```bash
95
+$ mkdir my-npm-pkg && cd my-npm-pkg
96
+$ git init
97
+$ npm init
98
+```
99
+
100
+Generate it without having it ask any questions:
101
+
102
+```bash
103
+$ npm init -y
104
+```
105
+
106
+### Workspaces support
107
+
108
+It's possible to create a new workspace within your project by using the `workspace` config option. When using `npm init -w <dir>` the cli will create the folders and boilerplate expected while also adding a reference to your project `package.json` `"workspaces": []` property in order to make sure that new generated **workspace** is properly set up as such.
109
+
110
+Given a project with no workspaces, e.g:
111
+
112
+```
113
+.
114
++-- package.json
115
+```
116
+
117
+You may generate a new workspace using the legacy init:
118
+
119
+```bash
120
+$ npm init -w packages/a
121
+```
122
+
123
+That will generate a new folder and `package.json` file, while also updating your top-level `package.json` to add the reference to this new workspace:
124
+
125
+```
126
+.
127
++-- package.json
128
+`-- packages
129
+ `-- a
130
+ `-- package.json
131
+```
132
+
133
+The workspaces init also supports the `npm init <initializer> -w <dir>` syntax, following the same set of rules explained earlier in the initial **Description** section of this page. Similar to the previous example of creating a new React-based project using [`create-react-app`](https://npm.im/create-react-app), the following syntax will make sure to create the new react app as a nested **workspace** within your project and configure your `package.json` to recognize it as such:
134
+
135
+```bash
136
+npm init -w packages/my-react-app react-app .
137
+```
138
+
139
+This will make sure to generate your react app as expected, one important consideration to have in mind is that `npm exec` is going to be run in the context of the newly created folder for that workspace, and that's the reason why in this example the initializer uses the initializer name followed with a dot to represent the current directory in that context, e.g: `react-app .`:
140
+
141
+```
142
+.
143
++-- package.json
144
+`-- packages
145
+ +-- a
146
+ | `-- package.json
147
+ `-- my-react-app
148
+ +-- README
149
+ +-- package.json
150
+ `-- ...
151
+```
152
+
153
+### Configuration
154
+
155
+#### `init-author-name`
156
+
157
+- Default: ""
158
+- Type: String
159
+
160
+The value `npm init` should use by default for the package author's name.
161
+
162
+#### `init-author-url`
163
+
164
+- Default: ""
165
+- Type: "" or URL
166
+
167
+The value `npm init` should use by default for the package author's homepage.
168
+
169
+#### `init-license`
170
+
171
+- Default: "ISC"
172
+- Type: String
173
+
174
+The value `npm init` should use by default for the package license.
175
+
176
+#### `init-module`
177
+
178
+- Default: "~/.npm-init.js"
179
+- Type: Path
180
+
181
+A module that will be loaded by the `npm init` command. See the documentation for the [init-package-json](https://github.com/npm/init-package-json) module for more information, or [npm init](/cli/v11/commands/npm-init).
182
+
183
+#### `init-version`
184
+
185
+- Default: "1.0.0"
186
+- Type: SemVer string
187
+
188
+The value that `npm init` should use by default for the package version number, if not already set in package.json.
189
+
190
+#### `yes`
191
+
192
+- Default: null
193
+- Type: null or Boolean
194
+
195
+Automatically answer "yes" to any prompts that npm might print on the command line.
196
+
197
+#### `force`
198
+
199
+- Default: false
200
+- Type: Boolean
201
+
202
+Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
203
+
204
+- Allow clobbering non-npm files in global installs.
205
+- Allow the `npm version` command to work on an unclean git repository.
206
+- Allow deleting the cache folder with `npm cache clean`.
207
+- Allow installing packages that have an `engines` declaration requiring a different version of npm.
208
+- Allow installing packages that have an `engines` declaration requiring a different version of `node`, even if `--engine-strict` is enabled.
209
+- Allow `npm audit fix` to install modules outside your stated dependency range (including SemVer-major changes).
210
+- Allow unpublishing all versions of a published package.
211
+- Allow conflicting peerDependencies to be installed in the root project.
212
+- Implicitly set `--yes` during `npm init`.
213
+- Allow clobbering existing values in `npm pkg`
214
+- Allow unpublishing of entire packages (not just a single version).
215
+
216
+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!
217
+
218
+#### `scope`
219
+
220
+- Default: the scope of the current project, if any, or ""
221
+- Type: String
222
+
223
+Associate an operation with a scope for a scoped registry.
224
+
225
+Useful when logging in to or out of a private registry:
226
+
227
+```
228
+# log in, linking the scope to the custom registry
229
+npm login --scope=@mycorp --registry=https://registry.mycorp.com
230
+
231
+# log out, removing the link and the auth token
232
+npm logout --scope=@mycorp
233
+```
234
+
235
+This will cause `@mycorp` to be mapped to the registry for future installation of packages specified according to the pattern `@mycorp/package`.
236
+
237
+This will also cause `npm init` to create a scoped package.
238
+
239
+```
240
+# accept all defaults, and create a package named "@foo/whatever",
241
+# instead of just named "whatever"
242
+npm init --scope=@foo --yes
243
+```
244
+
245
+#### `workspace`
246
+
247
+- Default:
248
+- Type: String (can be set multiple times)
249
+
250
+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.
251
+
252
+Valid values for the `workspace` config are either:
253
+
254
+- Workspace names
255
+- Path to a workspace directory
256
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
257
+
258
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
259
+
260
+This value is not exported to the environment for child processes.
261
+
262
+#### `workspaces`
263
+
264
+- Default: null
265
+- Type: null or Boolean
266
+
267
+Set to true to run the command in the context of **all** configured workspaces.
268
+
269
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
270
+
271
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
272
+
273
+This value is not exported to the environment for child processes.
274
+
275
+#### `workspaces-update`
276
+
277
+- Default: true
278
+- Type: Boolean
279
+
280
+If set to true, the npm cli will run an update after operations that may possibly change the workspaces installed to the `node_modules` folder.
281
+
282
+#### `include-workspace-root`
283
+
284
+- Default: false
285
+- Type: Boolean
286
+
287
+Include the workspace root when workspaces are enabled for a command.
288
+
289
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
290
+
291
+This value is not exported to the environment for child processes.
292
+
293
+### See Also
294
+
295
+- [package spec](/cli/v11/using-npm/package-spec)
296
+- [init-package-json module](http://npm.im/init-package-json)
297
+- [package.json](/cli/v11/configuring-npm/package-json)
298
+- [npm version](/cli/v11/commands/npm-version)
299
+- [npm scope](/cli/v11/using-npm/scope)
300
+- [npm exec](/cli/v11/commands/npm-exec)
301
+- [npm workspaces](/cli/v11/using-npm/workspaces)
content/cli/v11/commands/npm-install-ci-test.mdx
new
+212
@@ -0,0 +1,212 @@
1
+---
2
+title: npm-install-ci-test
3
+section: 1
4
+description: Install a project with a clean slate and run tests
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-install-ci-test.md
8
+redirect_from:
9
+ - /cli-commands/install-ci-test
10
+ - /cli-commands/npm-install-ci-test
11
+ - /cli-documentation/cli-commands/install-ci-test
12
+ - /cli-documentation/cli-commands/npm-install-ci-test
13
+ - /cli-documentation/commands/install-ci-test
14
+ - /cli-documentation/commands/npm-install-ci-test
15
+ - /cli-documentation/install-ci-test
16
+ - /cli-documentation/npm-install-ci-test
17
+ - /cli-documentation/v11/cli-commands/install-ci-test
18
+ - /cli-documentation/v11/cli-commands/npm-install-ci-test
19
+ - /cli-documentation/v11/commands/install-ci-test
20
+ - /cli-documentation/v11/commands/npm-install-ci-test
21
+ - /cli-documentation/v11/install-ci-test
22
+ - /cli-documentation/v11/npm-install-ci-test
23
+ - /cli/cli-commands/install-ci-test
24
+ - /cli/cli-commands/npm-install-ci-test
25
+ - /cli/commands/install-ci-test
26
+ - /cli/commands/npm-install-ci-test
27
+ - /cli/install-ci-test
28
+ - /cli/npm-install-ci-test
29
+ - /cli/v11/cli-commands/install-ci-test
30
+ - /cli/v11/cli-commands/npm-install-ci-test
31
+ - /cli/v11/commands/install-ci-test
32
+ - /cli/v11/install-ci-test
33
+ - /cli/v11/npm-install-ci-test
34
+ - /commands/install-ci-test
35
+ - /commands/npm-install-ci-test
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm install-ci-test
42
+
43
+aliases: cit, clean-install-test, sit
44
+```
45
+
46
+### Description
47
+
48
+This command runs `npm ci` followed immediately by `npm test`.
49
+
50
+### Configuration
51
+
52
+#### `install-strategy`
53
+
54
+- Default: "hoisted"
55
+- Type: "hoisted", "nested", "shallow", or "linked"
56
+
57
+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.
58
+
59
+#### `legacy-bundling`
60
+
61
+- Default: false
62
+- Type: Boolean
63
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
64
+
65
+Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
66
+
67
+#### `global-style`
68
+
69
+- Default: false
70
+- Type: Boolean
71
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
72
+
73
+Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
74
+
75
+#### `omit`
76
+
77
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
78
+- Type: "dev", "optional", or "peer" (can be set multiple times)
79
+
80
+Dependency types to omit from the installation tree on disk.
81
+
82
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
83
+
84
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
85
+
86
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
87
+
88
+#### `include`
89
+
90
+- Default:
91
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
92
+
93
+Option that allows for defining which types of dependencies to install.
94
+
95
+This is the inverse of `--omit=<type>`.
96
+
97
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
98
+
99
+#### `strict-peer-deps`
100
+
101
+- Default: false
102
+- Type: Boolean
103
+
104
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
105
+
106
+By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
107
+
108
+When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
109
+
110
+#### `foreground-scripts`
111
+
112
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
113
+- Type: Boolean
114
+
115
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
116
+
117
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
118
+
119
+#### `ignore-scripts`
120
+
121
+- Default: false
122
+- Type: Boolean
123
+
124
+If true, npm does not run scripts specified in package.json files.
125
+
126
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
127
+
128
+#### `audit`
129
+
130
+- Default: true
131
+- Type: Boolean
132
+
133
+When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
134
+
135
+#### `bin-links`
136
+
137
+- Default: true
138
+- Type: Boolean
139
+
140
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
141
+
142
+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.
143
+
144
+#### `fund`
145
+
146
+- Default: true
147
+- Type: Boolean
148
+
149
+When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
150
+
151
+#### `dry-run`
152
+
153
+- Default: false
154
+- Type: Boolean
155
+
156
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
157
+
158
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
159
+
160
+#### `workspace`
161
+
162
+- Default:
163
+- Type: String (can be set multiple times)
164
+
165
+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.
166
+
167
+Valid values for the `workspace` config are either:
168
+
169
+- Workspace names
170
+- Path to a workspace directory
171
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
172
+
173
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
174
+
175
+This value is not exported to the environment for child processes.
176
+
177
+#### `workspaces`
178
+
179
+- Default: null
180
+- Type: null or Boolean
181
+
182
+Set to true to run the command in the context of **all** configured workspaces.
183
+
184
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
185
+
186
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
187
+
188
+This value is not exported to the environment for child processes.
189
+
190
+#### `include-workspace-root`
191
+
192
+- Default: false
193
+- Type: Boolean
194
+
195
+Include the workspace root when workspaces are enabled for a command.
196
+
197
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
198
+
199
+This value is not exported to the environment for child processes.
200
+
201
+#### `install-links`
202
+
203
+- Default: false
204
+- Type: Boolean
205
+
206
+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.
207
+
208
+### See Also
209
+
210
+- [npm install-test](/cli/v11/commands/npm-install-test)
211
+- [npm ci](/cli/v11/commands/npm-ci)
212
+- [npm test](/cli/v11/commands/npm-test)
content/cli/v11/commands/npm-install-test.mdx
new
+287
@@ -0,0 +1,287 @@
1
+---
2
+title: npm-install-test
3
+section: 1
4
+description: Install package(s) and run tests
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-install-test.md
8
+redirect_from:
9
+ - /cli-commands/install-test
10
+ - /cli-commands/npm-install-test
11
+ - /cli-documentation/cli-commands/install-test
12
+ - /cli-documentation/cli-commands/npm-install-test
13
+ - /cli-documentation/commands/install-test
14
+ - /cli-documentation/commands/npm-install-test
15
+ - /cli-documentation/install-test
16
+ - /cli-documentation/npm-install-test
17
+ - /cli-documentation/v11/cli-commands/install-test
18
+ - /cli-documentation/v11/cli-commands/npm-install-test
19
+ - /cli-documentation/v11/commands/install-test
20
+ - /cli-documentation/v11/commands/npm-install-test
21
+ - /cli-documentation/v11/install-test
22
+ - /cli-documentation/v11/npm-install-test
23
+ - /cli/cli-commands/install-test
24
+ - /cli/cli-commands/npm-install-test
25
+ - /cli/commands/install-test
26
+ - /cli/commands/npm-install-test
27
+ - /cli/install-test
28
+ - /cli/npm-install-test
29
+ - /cli/v11/cli-commands/install-test
30
+ - /cli/v11/cli-commands/npm-install-test
31
+ - /cli/v11/commands/install-test
32
+ - /cli/v11/install-test
33
+ - /cli/v11/npm-install-test
34
+ - /commands/install-test
35
+ - /commands/npm-install-test
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm install-test [<package-spec> ...]
42
+
43
+alias: it
44
+```
45
+
46
+### Description
47
+
48
+This command runs an `npm install` followed immediately by an `npm test`. It takes exactly the same arguments as `npm install`.
49
+
50
+### Configuration
51
+
52
+#### `save`
53
+
54
+- Default: `true` unless when using `npm update` where it defaults to `false`
55
+- Type: Boolean
56
+
57
+Save installed packages to a `package.json` file as dependencies.
58
+
59
+When used with the `npm rm` command, removes the dependency from `package.json`.
60
+
61
+Will also prevent writing to `package-lock.json` if set to `false`.
62
+
63
+#### `save-exact`
64
+
65
+- Default: false
66
+- Type: Boolean
67
+
68
+Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
69
+
70
+#### `global`
71
+
72
+- Default: false
73
+- Type: Boolean
74
+
75
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
76
+
77
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
78
+- bin files are linked to `{prefix}/bin`
79
+- man pages are linked to `{prefix}/share/man`
80
+
81
+#### `install-strategy`
82
+
83
+- Default: "hoisted"
84
+- Type: "hoisted", "nested", "shallow", or "linked"
85
+
86
+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.
87
+
88
+#### `legacy-bundling`
89
+
90
+- Default: false
91
+- Type: Boolean
92
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
93
+
94
+Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
95
+
96
+#### `global-style`
97
+
98
+- Default: false
99
+- Type: Boolean
100
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
101
+
102
+Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
103
+
104
+#### `omit`
105
+
106
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
107
+- Type: "dev", "optional", or "peer" (can be set multiple times)
108
+
109
+Dependency types to omit from the installation tree on disk.
110
+
111
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
112
+
113
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
114
+
115
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
116
+
117
+#### `include`
118
+
119
+- Default:
120
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
121
+
122
+Option that allows for defining which types of dependencies to install.
123
+
124
+This is the inverse of `--omit=<type>`.
125
+
126
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
127
+
128
+#### `strict-peer-deps`
129
+
130
+- Default: false
131
+- Type: Boolean
132
+
133
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
134
+
135
+By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
136
+
137
+When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
138
+
139
+#### `prefer-dedupe`
140
+
141
+- Default: false
142
+- Type: Boolean
143
+
144
+Prefer to deduplicate packages if possible, rather than choosing a newer version of a dependency.
145
+
146
+#### `package-lock`
147
+
148
+- Default: true
149
+- Type: Boolean
150
+
151
+If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
152
+
153
+#### `package-lock-only`
154
+
155
+- Default: false
156
+- Type: Boolean
157
+
158
+If set to true, the current operation will only use the `package-lock.json`, ignoring `node_modules`.
159
+
160
+For `update` this means only the `package-lock.json` will be updated, instead of checking `node_modules` and downloading dependencies.
161
+
162
+For `list` this means the output will be based on the tree described by the `package-lock.json`, rather than the contents of `node_modules`.
163
+
164
+#### `foreground-scripts`
165
+
166
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
167
+- Type: Boolean
168
+
169
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
170
+
171
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
172
+
173
+#### `ignore-scripts`
174
+
175
+- Default: false
176
+- Type: Boolean
177
+
178
+If true, npm does not run scripts specified in package.json files.
179
+
180
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
181
+
182
+#### `audit`
183
+
184
+- Default: true
185
+- Type: Boolean
186
+
187
+When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
188
+
189
+#### `bin-links`
190
+
191
+- Default: true
192
+- Type: Boolean
193
+
194
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
195
+
196
+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.
197
+
198
+#### `fund`
199
+
200
+- Default: true
201
+- Type: Boolean
202
+
203
+When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
204
+
205
+#### `dry-run`
206
+
207
+- Default: false
208
+- Type: Boolean
209
+
210
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
211
+
212
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
213
+
214
+#### `cpu`
215
+
216
+- Default: null
217
+- Type: null or String
218
+
219
+Override CPU architecture of native modules to install. Acceptable values are same as `cpu` field of package.json, which comes from `process.arch`.
220
+
221
+#### `os`
222
+
223
+- Default: null
224
+- Type: null or String
225
+
226
+Override OS of native modules to install. Acceptable values are same as `os` field of package.json, which comes from `process.platform`.
227
+
228
+#### `libc`
229
+
230
+- Default: null
231
+- Type: null or String
232
+
233
+Override libc of native modules to install. Acceptable values are same as `libc` field of package.json
234
+
235
+#### `workspace`
236
+
237
+- Default:
238
+- Type: String (can be set multiple times)
239
+
240
+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.
241
+
242
+Valid values for the `workspace` config are either:
243
+
244
+- Workspace names
245
+- Path to a workspace directory
246
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
247
+
248
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
249
+
250
+This value is not exported to the environment for child processes.
251
+
252
+#### `workspaces`
253
+
254
+- Default: null
255
+- Type: null or Boolean
256
+
257
+Set to true to run the command in the context of **all** configured workspaces.
258
+
259
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
260
+
261
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
262
+
263
+This value is not exported to the environment for child processes.
264
+
265
+#### `include-workspace-root`
266
+
267
+- Default: false
268
+- Type: Boolean
269
+
270
+Include the workspace root when workspaces are enabled for a command.
271
+
272
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
273
+
274
+This value is not exported to the environment for child processes.
275
+
276
+#### `install-links`
277
+
278
+- Default: false
279
+- Type: Boolean
280
+
281
+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.
282
+
283
+### See Also
284
+
285
+- [npm install](/cli/v11/commands/npm-install)
286
+- [npm install-ci-test](/cli/v11/commands/npm-install-ci-test)
287
+- [npm test](/cli/v11/commands/npm-test)
content/cli/v11/commands/npm-install.mdx
new
+609
@@ -0,0 +1,609 @@
1
+---
2
+title: npm-install
3
+section: 1
4
+description: Install a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-install.md
8
+redirect_from:
9
+ - /cli-commands/install
10
+ - /cli-commands/npm-install
11
+ - /cli-documentation/cli-commands/install
12
+ - /cli-documentation/cli-commands/npm-install
13
+ - /cli-documentation/commands/install
14
+ - /cli-documentation/commands/npm-install
15
+ - /cli-documentation/install
16
+ - /cli-documentation/npm-install
17
+ - /cli-documentation/v11/cli-commands/install
18
+ - /cli-documentation/v11/cli-commands/npm-install
19
+ - /cli-documentation/v11/commands/install
20
+ - /cli-documentation/v11/commands/npm-install
21
+ - /cli-documentation/v11/install
22
+ - /cli-documentation/v11/npm-install
23
+ - /cli/cli-commands/install
24
+ - /cli/cli-commands/npm-install
25
+ - /cli/commands/install
26
+ - /cli/commands/npm-install
27
+ - /cli/install
28
+ - /cli/npm-install
29
+ - /cli/v11/cli-commands/install
30
+ - /cli/v11/cli-commands/npm-install
31
+ - /cli/v11/commands/install
32
+ - /cli/v11/install
33
+ - /cli/v11/npm-install
34
+ - /commands/install
35
+ - /commands/npm-install
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm install [<package-spec> ...]
42
+
43
+aliases: add, i, in, ins, inst, insta, instal, isnt, isnta, isntal, isntall
44
+```
45
+
46
+### Description
47
+
48
+This command installs a package and any packages that it depends on. If the package has a package-lock, or an npm shrinkwrap file, or a yarn lock file, the installation of dependencies will be driven by that, respecting the following order of precedence:
49
+
50
+- `npm-shrinkwrap.json`
51
+- `package-lock.json`
52
+- `yarn.lock`
53
+
54
+See [package-lock.json](/cli/v11/configuring-npm/package-lock-json) and [`npm shrinkwrap`](/cli/v11/commands/npm-shrinkwrap).
55
+
56
+A `package` is:
57
+
58
+- a) a folder containing a program described by a [`package.json`](/cli/v11/configuring-npm/package-json) file
59
+- b) a gzipped tarball containing (a)
60
+- c) a url that resolves to (b)
61
+- d) a `<name>@<version>` that is published on the registry (see [`registry`](/cli/v11/using-npm/registry)) with (c)
62
+- e) a `<name>@<tag>` (see [`npm dist-tag`](/cli/v11/commands/npm-dist-tag)) that points to (d)
63
+- f) a `<name>` that has a "latest" tag satisfying (e)
64
+- g) a `<git remote url>` that resolves to (a)
65
+
66
+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).
67
+
68
+- `npm install` (in a package directory, no arguments):
69
+
70
+ Install the dependencies to the local `node_modules` folder.
71
+
72
+ In global mode (ie, with `-g` or `--global` appended to the command), it installs the current package context (ie, the current working directory) as a global package.
73
+
74
+ By default, `npm install` will install all modules listed as dependencies in [`package.json`](/cli/v11/configuring-npm/package-json).
75
+
76
+ With the `--production` flag (or when the `NODE_ENV` environment variable is set to `production`), npm will not install modules listed in `devDependencies`. To install all modules listed in both `dependencies` and `devDependencies` when `NODE_ENV` environment variable is set to `production`, you can use `--production=false`.
77
+
78
+ > NOTE: The `--production` flag has no particular meaning when adding a dependency to a project.
79
+
80
+- `npm install <folder>`:
81
+
82
+ If `<folder>` sits inside the root of your project, its dependencies will be installed and may be hoisted to the top-level `node_modules` as they would for other types of dependencies. If `<folder>` sits outside the root of your project, _npm will not install the package dependencies_ in the directory `<folder>`, but it will create a symlink to `<folder>`.
83
+
84
+ > NOTE: If you want to install the content of a directory like a package from the registry instead of creating a link, you would need to use the `--install-links` option.
85
+
86
+ Example:
87
+
88
+ ```bash
89
+ npm install ../../other-package --install-links
90
+ npm install ./sub-package
91
+ ```
92
+
93
+- `npm install <tarball file>`:
94
+
95
+ Install a package that is sitting on the filesystem. Note: if you just want to link a dev directory into your npm root, you can do this more easily by using [`npm link`](/cli/v11/commands/npm-link).
96
+
97
+ Tarball requirements:
98
+
99
+ - The filename _must_ use `.tar`, `.tar.gz`, or `.tgz` as the extension.
100
+ - The package contents should reside in a subfolder inside the tarball (usually it is called `package/`). npm strips one directory layer when installing the package (an equivalent of `tar x --strip-components=1` is run).
101
+ - The package must contain a `package.json` file with `name` and `version` properties.
102
+
103
+ Example:
104
+
105
+ ```bash
106
+ npm install ./package.tgz
107
+ ```
108
+
109
+- `npm install <tarball url>`:
110
+
111
+ Fetch the tarball url, and then install it. In order to distinguish between this and other options, the argument must start with "http://" or "https://"
112
+
113
+ Example:
114
+
115
+ ```bash
116
+ npm install https://github.com/indexzero/forever/tarball/v0.5.6
117
+ ```
118
+
119
+- `npm install [<@scope>/]<name>`:
120
+
121
+ Do a `<name>@<tag>` install, where `<tag>` is the "tag" config. (See [`config`](/cli/v11/using-npm/config#tag). The config's default value is `latest`.)
122
+
123
+ In most cases, this will install the version of the modules tagged as `latest` on the npm registry.
124
+
125
+ Example:
126
+
127
+ ```bash
128
+ npm install sax
129
+ ```
130
+
131
+ `npm install` saves any specified packages into `dependencies` by default. Additionally, you can control where and how they get saved with some additional flags:
132
+
133
+ - `-P, --save-prod`: Package will appear in your `dependencies`. This is the default unless `-D` or `-O` are present.
134
+
135
+ - `-D, --save-dev`: Package will appear in your `devDependencies`.
136
+
137
+ - `--save-peer`: Package will appear in your `peerDependencies`.
138
+
139
+ - `-O, --save-optional`: Package will appear in your `optionalDependencies`.
140
+
141
+ - `--no-save`: Prevents saving to `dependencies`.
142
+
143
+ When using any of the above options to save dependencies to your package.json, there are two additional, optional flags:
144
+
145
+ - `-E, --save-exact`: Saved dependencies will be configured with an exact version rather than using npm's default semver range operator.
146
+
147
+ - `-B, --save-bundle`: Saved dependencies will also be added to your `bundleDependencies` list.
148
+
149
+ Further, if you have an `npm-shrinkwrap.json` or `package-lock.json` then it will be updated as well.
150
+
151
+ `<scope>` is optional. The package will be downloaded from the registry associated with the specified scope. If no registry is associated with the given scope the default registry is assumed. See [`scope`](/cli/v11/using-npm/scope).
152
+
153
+ Note: if you do not include the @-symbol on your scope name, npm will interpret this as a GitHub repository instead, see below. Scopes names must also be followed by a slash.
154
+
155
+ Examples:
156
+
157
+ ```bash
158
+ npm install sax
159
+ npm install githubname/reponame
160
+ npm install @myorg/privatepackage
161
+ npm install node-tap --save-dev
162
+ npm install dtrace-provider --save-optional
163
+ npm install readable-stream --save-exact
164
+ npm install ansi-regex --save-bundle
165
+ ```
166
+
167
+- `npm install <alias>@npm:<name>`:
168
+
169
+ Install a package under a custom alias. Allows multiple versions of a same-name package side-by-side, more convenient import names for packages with otherwise long ones, and using git forks replacements or forked npm packages as replacements. Aliasing works only on your project and does not rename packages in transitive dependencies. Aliases should follow the naming conventions stated in [`validate-npm-package-name`](https://www.npmjs.com/package/validate-npm-package-name#naming-rules).
170
+
171
+ Examples:
172
+
173
+ ```bash
174
+ npm install my-react@npm:react
175
+ npm install jquery2@npm:jquery@2
176
+ npm install jquery3@npm:jquery@3
177
+ npm install npa@npm:npm-package-arg
178
+ ```
179
+
180
+- `npm install [<@scope>/]<name>@<tag>`:
181
+
182
+ Install the version of the package that is referenced by the specified tag. If the tag does not exist in the registry data for that package, then this will fail.
183
+
184
+ Example:
185
+
186
+ ```bash
187
+ npm install sax@latest
188
+ npm install @myorg/mypackage@latest
189
+ ```
190
+
191
+- `npm install [<@scope>/]<name>@<version>`:
192
+
193
+ Install the specified version of the package. This will fail if the version has not been published to the registry.
194
+
195
+ Example:
196
+
197
+ ```bash
198
+ npm install sax@0.1.1
199
+ npm install @myorg/privatepackage@1.5.0
200
+ ```
201
+
202
+- `npm install [<@scope>/]<name>@<version range>`:
203
+
204
+ Install a version of the package matching the specified version range. This will follow the same rules for resolving dependencies described in [`package.json`](/cli/v11/configuring-npm/package-json).
205
+
206
+ Note that most version ranges must be put in quotes so that your shell will treat it as a single argument.
207
+
208
+ Example:
209
+
210
+ ```bash
211
+ npm install sax@">=0.1.0 <0.2.0"
212
+ npm install @myorg/privatepackage@"16 - 17"
213
+ ```
214
+
215
+- `npm install <git remote url>`:
216
+
217
+ Installs the package from the hosted git provider, cloning it with `git`. For a full git remote url, only that URL will be attempted.
218
+
219
+ ```bash
220
+ <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
221
+ ```
222
+
223
+ `<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or `git+file`.
224
+
225
+ If `#<commit-ish>` is provided, it will be used to clone exactly that commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is specified, then the default branch of the repository is used.
226
+
227
+ If the repository makes use of submodules, those submodules will be cloned as well.
228
+
229
+ If the package being installed contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.
230
+
231
+ The following git environment variables are recognized by npm and will be added to the environment when running git:
232
+
233
+ - `GIT_ASKPASS`
234
+ - `GIT_EXEC_PATH`
235
+ - `GIT_PROXY_COMMAND`
236
+ - `GIT_SSH`
237
+ - `GIT_SSH_COMMAND`
238
+ - `GIT_SSL_CAINFO`
239
+ - `GIT_SSL_NO_VERIFY`
240
+
241
+ See the git man page for details.
242
+
243
+ Examples:
244
+
245
+ ```bash
246
+ npm install git+ssh://git@github.com:npm/cli.git#v1.0.27
247
+ npm install git+ssh://git@github.com:npm/cli#pull/273
248
+ npm install git+ssh://git@github.com:npm/cli#semver:^5.0
249
+ npm install git+https://isaacs@github.com/npm/cli.git
250
+ npm install git://github.com/npm/cli.git#v1.0.27
251
+ GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://git@github.com:npm/cli.git
252
+ ```
253
+
254
+- `npm install <githubname>/<githubrepo>[#<commit-ish>]`:
255
+- `npm install github:<githubname>/<githubrepo>[#<commit-ish>]`:
256
+
257
+ Install the package at `https://github.com/githubname/githubrepo` by attempting to clone it using `git`.
258
+
259
+ If `#<commit-ish>` is provided, it will be used to clone exactly that commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is specified, then the default branch is used.
260
+
261
+ As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing.
262
+
263
+ Examples:
264
+
265
+ ```bash
266
+ npm install mygithubuser/myproject
267
+ npm install github:mygithubuser/myproject
268
+ ```
269
+
270
+- `npm install gist:[<githubname>/]<gistID>[#<commit-ish>|#semver:<semver>]`:
271
+
272
+ Install the package at `https://gist.github.com/gistID` by attempting to clone it using `git`. The GitHub username associated with the gist is optional and will not be saved in `package.json`.
273
+
274
+ As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing.
275
+
276
+ Example:
277
+
278
+ ```bash
279
+ npm install gist:101a11beef
280
+ ```
281
+
282
+- `npm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit-ish>]`:
283
+
284
+ Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo` by attempting to clone it using `git`.
285
+
286
+ If `#<commit-ish>` is provided, it will be used to clone exactly that commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is specified, then `master` is used.
287
+
288
+ As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing.
289
+
290
+ Example:
291
+
292
+ ```bash
293
+ npm install bitbucket:mybitbucketuser/myproject
294
+ ```
295
+
296
+- `npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]`:
297
+
298
+ Install the package at `https://gitlab.com/gitlabname/gitlabrepo` by attempting to clone it using `git`.
299
+
300
+ If `#<commit-ish>` is provided, it will be used to clone exactly that commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is specified, then `master` is used.
301
+
302
+ As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing.
303
+
304
+ Example:
305
+
306
+ ```bash
307
+ npm install gitlab:mygitlabuser/myproject
308
+ npm install gitlab:myusr/myproj#semver:^5.0
309
+ ```
310
+
311
+You may combine multiple arguments and even multiple types of arguments. For example:
312
+
313
+```bash
314
+npm install sax@">=0.1.0 <0.2.0" bench supervisor
315
+```
316
+
317
+The `--tag` argument will apply to all of the specified install targets. If a tag with the given name exists, the tagged version is preferred over newer versions.
318
+
319
+The `--dry-run` argument will report in the usual way what the install would have done without actually installing anything.
320
+
321
+The `--package-lock-only` argument will only update the `package-lock.json`, instead of checking `node_modules` and downloading dependencies.
322
+
323
+The `-f` or `--force` argument will force npm to fetch remote resources even if a local copy exists on disk.
324
+
325
+```bash
326
+npm install sax --force
327
+```
328
+
329
+### Configuration
330
+
331
+See the [`config`](/cli/v11/using-npm/config) help doc. Many of the configuration params have some effect on installation, since that's most of what npm does.
332
+
333
+These are some of the most common options related to installation.
334
+
335
+#### `save`
336
+
337
+- Default: `true` unless when using `npm update` where it defaults to `false`
338
+- Type: Boolean
339
+
340
+Save installed packages to a `package.json` file as dependencies.
341
+
342
+When used with the `npm rm` command, removes the dependency from `package.json`.
343
+
344
+Will also prevent writing to `package-lock.json` if set to `false`.
345
+
346
+#### `save-exact`
347
+
348
+- Default: false
349
+- Type: Boolean
350
+
351
+Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
352
+
353
+#### `global`
354
+
355
+- Default: false
356
+- Type: Boolean
357
+
358
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
359
+
360
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
361
+- bin files are linked to `{prefix}/bin`
362
+- man pages are linked to `{prefix}/share/man`
363
+
364
+#### `install-strategy`
365
+
366
+- Default: "hoisted"
367
+- Type: "hoisted", "nested", "shallow", or "linked"
368
+
369
+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.
370
+
371
+#### `legacy-bundling`
372
+
373
+- Default: false
374
+- Type: Boolean
375
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
376
+
377
+Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
378
+
379
+#### `global-style`
380
+
381
+- Default: false
382
+- Type: Boolean
383
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
384
+
385
+Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
386
+
387
+#### `omit`
388
+
389
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
390
+- Type: "dev", "optional", or "peer" (can be set multiple times)
391
+
392
+Dependency types to omit from the installation tree on disk.
393
+
394
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
395
+
396
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
397
+
398
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
399
+
400
+#### `include`
401
+
402
+- Default:
403
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
404
+
405
+Option that allows for defining which types of dependencies to install.
406
+
407
+This is the inverse of `--omit=<type>`.
408
+
409
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
410
+
411
+#### `strict-peer-deps`
412
+
413
+- Default: false
414
+- Type: Boolean
415
+
416
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
417
+
418
+By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
419
+
420
+When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
421
+
422
+#### `prefer-dedupe`
423
+
424
+- Default: false
425
+- Type: Boolean
426
+
427
+Prefer to deduplicate packages if possible, rather than choosing a newer version of a dependency.
428
+
429
+#### `package-lock`
430
+
431
+- Default: true
432
+- Type: Boolean
433
+
434
+If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
435
+
436
+#### `package-lock-only`
437
+
438
+- Default: false
439
+- Type: Boolean
440
+
441
+If set to true, the current operation will only use the `package-lock.json`, ignoring `node_modules`.
442
+
443
+For `update` this means only the `package-lock.json` will be updated, instead of checking `node_modules` and downloading dependencies.
444
+
445
+For `list` this means the output will be based on the tree described by the `package-lock.json`, rather than the contents of `node_modules`.
446
+
447
+#### `foreground-scripts`
448
+
449
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
450
+- Type: Boolean
451
+
452
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
453
+
454
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
455
+
456
+#### `ignore-scripts`
457
+
458
+- Default: false
459
+- Type: Boolean
460
+
461
+If true, npm does not run scripts specified in package.json files.
462
+
463
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
464
+
465
+#### `audit`
466
+
467
+- Default: true
468
+- Type: Boolean
469
+
470
+When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
471
+
472
+#### `bin-links`
473
+
474
+- Default: true
475
+- Type: Boolean
476
+
477
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
478
+
479
+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.
480
+
481
+#### `fund`
482
+
483
+- Default: true
484
+- Type: Boolean
485
+
486
+When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
487
+
488
+#### `dry-run`
489
+
490
+- Default: false
491
+- Type: Boolean
492
+
493
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
494
+
495
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
496
+
497
+#### `cpu`
498
+
499
+- Default: null
500
+- Type: null or String
501
+
502
+Override CPU architecture of native modules to install. Acceptable values are same as `cpu` field of package.json, which comes from `process.arch`.
503
+
504
+#### `os`
505
+
506
+- Default: null
507
+- Type: null or String
508
+
509
+Override OS of native modules to install. Acceptable values are same as `os` field of package.json, which comes from `process.platform`.
510
+
511
+#### `libc`
512
+
513
+- Default: null
514
+- Type: null or String
515
+
516
+Override libc of native modules to install. Acceptable values are same as `libc` field of package.json
517
+
518
+#### `workspace`
519
+
520
+- Default:
521
+- Type: String (can be set multiple times)
522
+
523
+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.
524
+
525
+Valid values for the `workspace` config are either:
526
+
527
+- Workspace names
528
+- Path to a workspace directory
529
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
530
+
531
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
532
+
533
+This value is not exported to the environment for child processes.
534
+
535
+#### `workspaces`
536
+
537
+- Default: null
538
+- Type: null or Boolean
539
+
540
+Set to true to run the command in the context of **all** configured workspaces.
541
+
542
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
543
+
544
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
545
+
546
+This value is not exported to the environment for child processes.
547
+
548
+#### `include-workspace-root`
549
+
550
+- Default: false
551
+- Type: Boolean
552
+
553
+Include the workspace root when workspaces are enabled for a command.
554
+
555
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
556
+
557
+This value is not exported to the environment for child processes.
558
+
559
+#### `install-links`
560
+
561
+- Default: false
562
+- Type: Boolean
563
+
564
+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.
565
+
566
+### Algorithm
567
+
568
+Given a `package{dep}` structure: `A{B,C}, B{C}, C{D}`, the npm install algorithm produces:
569
+
570
+```bash
571
+A
572
++-- B
573
++-- C
574
++-- D
575
+```
576
+
577
+That is, the dependency from B to C is satisfied by the fact that A already caused C to be installed at a higher level. D is still installed at the top level because nothing conflicts with it.
578
+
579
+For `A{B,C}, B{C,D@1}, C{D@2}`, this algorithm produces:
580
+
581
+```bash
582
+A
583
++-- B
584
++-- C
585
+ `-- D@2
586
++-- D@1
587
+```
588
+
589
+Because B's D@1 will be installed in the top-level, C now has to install D@2 privately for itself. This algorithm is deterministic, but different trees may be produced if two dependencies are requested for installation in a different order.
590
+
591
+See [folders](/cli/v11/configuring-npm/folders) for a more detailed description of the specific folder structures that npm creates.
592
+
593
+### See Also
594
+
595
+- [npm folders](/cli/v11/configuring-npm/folders)
596
+- [npm update](/cli/v11/commands/npm-update)
597
+- [npm audit](/cli/v11/commands/npm-audit)
598
+- [npm fund](/cli/v11/commands/npm-fund)
599
+- [npm link](/cli/v11/commands/npm-link)
600
+- [npm rebuild](/cli/v11/commands/npm-rebuild)
601
+- [npm scripts](/cli/v11/using-npm/scripts)
602
+- [npm config](/cli/v11/commands/npm-config)
603
+- [npmrc](/cli/v11/configuring-npm/npmrc)
604
+- [npm registry](/cli/v11/using-npm/registry)
605
+- [npm dist-tag](/cli/v11/commands/npm-dist-tag)
606
+- [npm uninstall](/cli/v11/commands/npm-uninstall)
607
+- [npm shrinkwrap](/cli/v11/commands/npm-shrinkwrap)
608
+- [package.json](/cli/v11/configuring-npm/package-json)
609
+- [workspaces](/cli/v11/using-npm/workspaces)
content/cli/v11/commands/npm-link.mdx
new
+304
@@ -0,0 +1,304 @@
1
+---
2
+title: npm-link
3
+section: 1
4
+description: Symlink a package folder
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-link.md
8
+redirect_from:
9
+ - /cli-commands/link
10
+ - /cli-commands/npm-link
11
+ - /cli-documentation/cli-commands/link
12
+ - /cli-documentation/cli-commands/npm-link
13
+ - /cli-documentation/commands/link
14
+ - /cli-documentation/commands/npm-link
15
+ - /cli-documentation/link
16
+ - /cli-documentation/npm-link
17
+ - /cli-documentation/v11/cli-commands/link
18
+ - /cli-documentation/v11/cli-commands/npm-link
19
+ - /cli-documentation/v11/commands/link
20
+ - /cli-documentation/v11/commands/npm-link
21
+ - /cli-documentation/v11/link
22
+ - /cli-documentation/v11/npm-link
23
+ - /cli/cli-commands/link
24
+ - /cli/cli-commands/npm-link
25
+ - /cli/commands/link
26
+ - /cli/commands/npm-link
27
+ - /cli/link
28
+ - /cli/npm-link
29
+ - /cli/v11/cli-commands/link
30
+ - /cli/v11/cli-commands/npm-link
31
+ - /cli/v11/commands/link
32
+ - /cli/v11/link
33
+ - /cli/v11/npm-link
34
+ - /commands/link
35
+ - /commands/npm-link
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm link [<package-spec>]
42
+
43
+alias: ln
44
+```
45
+
46
+### Description
47
+
48
+This is handy for installing your own stuff, so that you can work on it and test iteratively without having to continually rebuild.
49
+
50
+Package linking is a two-step process.
51
+
52
+First, `npm link` in a package folder with no arguments will create a symlink in the global folder `{prefix}/lib/node_modules/<package>` that links to the package where the `npm link` command was executed. It will also link any bins in the package to `{prefix}/bin/{name}`. Note that `npm link` uses the global prefix (see `npm prefix -g` for its value).
53
+
54
+Next, in some other location, `npm link package-name` will create a symbolic link from globally-installed `package-name` to `node_modules/` of the current folder.
55
+
56
+Note that `package-name` is taken from `package.json`, _not_ from the directory name.
57
+
58
+The package name can be optionally prefixed with a scope. See [`scope`](/cli/v11/using-npm/scope). The scope must be preceded by an @-symbol and followed by a slash.
59
+
60
+When creating tarballs for `npm publish`, the linked packages are "snapshotted" to their current state by resolving the symbolic links, if they are included in `bundleDependencies`.
61
+
62
+For example:
63
+
64
+```bash
65
+cd ~/projects/node-redis # go into the package directory
66
+npm link # creates global link
67
+cd ~/projects/node-bloggy # go into some other package directory.
68
+npm link redis # link-install the package
69
+```
70
+
71
+Now, any changes to `~/projects/node-redis` will be reflected in `~/projects/node-bloggy/node_modules/node-redis/`. Note that the link should be to the package name, not the directory name for that package.
72
+
73
+You may also shortcut the two steps in one. For example, to do the above use-case in a shorter way:
74
+
75
+```bash
76
+cd ~/projects/node-bloggy # go into the dir of your main project
77
+npm link ../node-redis # link the dir of your dependency
78
+```
79
+
80
+The second line is the equivalent of doing:
81
+
82
+```bash
83
+(cd ../node-redis; npm link)
84
+npm link redis
85
+```
86
+
87
+That is, it first creates a global link, and then links the global installation target into your project's `node_modules` folder.
88
+
89
+Note that in this case, you are referring to the directory name, `node-redis`, rather than the package name `redis`.
90
+
91
+If your linked package is scoped (see [`scope`](/cli/v11/using-npm/scope)) your link command must include that scope, e.g.
92
+
93
+```bash
94
+npm link @myorg/privatepackage
95
+```
96
+
97
+### Caveat
98
+
99
+Note that package dependencies linked in this way are _not_ saved to `package.json` by default, on the assumption that the intention is to have a link stand in for a regular non-link dependency. Otherwise, for example, if you depend on `redis@^3.0.1`, and ran `npm link redis`, it would replace the `^3.0.1` dependency with `file:../path/to/node-redis`, which you probably don't want! Additionally, other users or developers on your project would run into issues if they do not have their folders set up exactly the same as yours.
100
+
101
+If you are adding a _new_ dependency as a link, you should add it to the relevant metadata by running `npm install <dep> --package-lock-only`.
102
+
103
+If you _want_ to save the `file:` reference in your `package.json` and `package-lock.json` files, you can use `npm link <dep> --save` to do so.
104
+
105
+### Workspace Usage
106
+
107
+`npm link <pkg> --workspace <name>` will link the relevant package as a dependency of the specified workspace(s). Note that It may actually be linked into the parent project's `node_modules` folder, if there are no conflicting dependencies.
108
+
109
+`npm link --workspace <name>` will create a global link to the specified workspace(s).
110
+
111
+### Configuration
112
+
113
+#### `save`
114
+
115
+- Default: `true` unless when using `npm update` where it defaults to `false`
116
+- Type: Boolean
117
+
118
+Save installed packages to a `package.json` file as dependencies.
119
+
120
+When used with the `npm rm` command, removes the dependency from `package.json`.
121
+
122
+Will also prevent writing to `package-lock.json` if set to `false`.
123
+
124
+#### `save-exact`
125
+
126
+- Default: false
127
+- Type: Boolean
128
+
129
+Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
130
+
131
+#### `global`
132
+
133
+- Default: false
134
+- Type: Boolean
135
+
136
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
137
+
138
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
139
+- bin files are linked to `{prefix}/bin`
140
+- man pages are linked to `{prefix}/share/man`
141
+
142
+#### `install-strategy`
143
+
144
+- Default: "hoisted"
145
+- Type: "hoisted", "nested", "shallow", or "linked"
146
+
147
+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.
148
+
149
+#### `legacy-bundling`
150
+
151
+- Default: false
152
+- Type: Boolean
153
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
154
+
155
+Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
156
+
157
+#### `global-style`
158
+
159
+- Default: false
160
+- Type: Boolean
161
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
162
+
163
+Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
164
+
165
+#### `strict-peer-deps`
166
+
167
+- Default: false
168
+- Type: Boolean
169
+
170
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
171
+
172
+By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
173
+
174
+When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
175
+
176
+#### `package-lock`
177
+
178
+- Default: true
179
+- Type: Boolean
180
+
181
+If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
182
+
183
+#### `omit`
184
+
185
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
186
+- Type: "dev", "optional", or "peer" (can be set multiple times)
187
+
188
+Dependency types to omit from the installation tree on disk.
189
+
190
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
191
+
192
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
193
+
194
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
195
+
196
+#### `include`
197
+
198
+- Default:
199
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
200
+
201
+Option that allows for defining which types of dependencies to install.
202
+
203
+This is the inverse of `--omit=<type>`.
204
+
205
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
206
+
207
+#### `ignore-scripts`
208
+
209
+- Default: false
210
+- Type: Boolean
211
+
212
+If true, npm does not run scripts specified in package.json files.
213
+
214
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
215
+
216
+#### `audit`
217
+
218
+- Default: true
219
+- Type: Boolean
220
+
221
+When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
222
+
223
+#### `bin-links`
224
+
225
+- Default: true
226
+- Type: Boolean
227
+
228
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
229
+
230
+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.
231
+
232
+#### `fund`
233
+
234
+- Default: true
235
+- Type: Boolean
236
+
237
+When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
238
+
239
+#### `dry-run`
240
+
241
+- Default: false
242
+- Type: Boolean
243
+
244
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
245
+
246
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
247
+
248
+#### `workspace`
249
+
250
+- Default:
251
+- Type: String (can be set multiple times)
252
+
253
+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.
254
+
255
+Valid values for the `workspace` config are either:
256
+
257
+- Workspace names
258
+- Path to a workspace directory
259
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
260
+
261
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
262
+
263
+This value is not exported to the environment for child processes.
264
+
265
+#### `workspaces`
266
+
267
+- Default: null
268
+- Type: null or Boolean
269
+
270
+Set to true to run the command in the context of **all** configured workspaces.
271
+
272
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
273
+
274
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
275
+
276
+This value is not exported to the environment for child processes.
277
+
278
+#### `include-workspace-root`
279
+
280
+- Default: false
281
+- Type: Boolean
282
+
283
+Include the workspace root when workspaces are enabled for a command.
284
+
285
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
286
+
287
+This value is not exported to the environment for child processes.
288
+
289
+#### `install-links`
290
+
291
+- Default: false
292
+- Type: Boolean
293
+
294
+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.
295
+
296
+### See Also
297
+
298
+- [package spec](/cli/v11/using-npm/package-spec)
299
+- [npm developers](/cli/v11/using-npm/developers)
300
+- [package.json](/cli/v11/configuring-npm/package-json)
301
+- [npm install](/cli/v11/commands/npm-install)
302
+- [npm folders](/cli/v11/configuring-npm/folders)
303
+- [npm config](/cli/v11/commands/npm-config)
304
+- [npmrc](/cli/v11/configuring-npm/npmrc)
content/cli/v11/commands/npm-login.mdx
new
+109
@@ -0,0 +1,109 @@
1
+---
2
+title: npm-login
3
+section: 1
4
+description: Login to a registry user account
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-login.md
8
+redirect_from:
9
+ - /cli-commands/login
10
+ - /cli-commands/npm-login
11
+ - /cli-documentation/cli-commands/login
12
+ - /cli-documentation/cli-commands/npm-login
13
+ - /cli-documentation/commands/login
14
+ - /cli-documentation/commands/npm-login
15
+ - /cli-documentation/login
16
+ - /cli-documentation/npm-login
17
+ - /cli-documentation/v11/cli-commands/login
18
+ - /cli-documentation/v11/cli-commands/npm-login
19
+ - /cli-documentation/v11/commands/login
20
+ - /cli-documentation/v11/commands/npm-login
21
+ - /cli-documentation/v11/login
22
+ - /cli-documentation/v11/npm-login
23
+ - /cli/cli-commands/login
24
+ - /cli/cli-commands/npm-login
25
+ - /cli/commands/login
26
+ - /cli/commands/npm-login
27
+ - /cli/login
28
+ - /cli/npm-login
29
+ - /cli/v11/cli-commands/login
30
+ - /cli/v11/cli-commands/npm-login
31
+ - /cli/v11/commands/login
32
+ - /cli/v11/login
33
+ - /cli/v11/npm-login
34
+ - /commands/login
35
+ - /commands/npm-login
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm login
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+Verify a user in the specified registry, and save the credentials to the `.npmrc` file. If no registry is specified, the default registry will be used (see [`config`](/cli/v11/using-npm/config)).
49
+
50
+When using `legacy` for your `auth-type`, the username and password, are read in from prompts.
51
+
52
+To reset your password, go to [https://www.npmjs.com/forgot](https://www.npmjs.com/forgot)
53
+
54
+To change your email address, go to [https://www.npmjs.com/email-edit](https://www.npmjs.com/email-edit)
55
+
56
+You may use this command multiple times with the same user account to authorize on a new machine. When authenticating on a new machine, the username, password and email address must all match with your existing record.
57
+
58
+### Configuration
59
+
60
+#### `registry`
61
+
62
+- Default: "https://registry.npmjs.org/"
63
+- Type: URL
64
+
65
+The base URL of the npm registry.
66
+
67
+#### `scope`
68
+
69
+- Default: the scope of the current project, if any, or ""
70
+- Type: String
71
+
72
+Associate an operation with a scope for a scoped registry.
73
+
74
+Useful when logging in to or out of a private registry:
75
+
76
+```
77
+# log in, linking the scope to the custom registry
78
+npm login --scope=@mycorp --registry=https://registry.mycorp.com
79
+
80
+# log out, removing the link and the auth token
81
+npm logout --scope=@mycorp
82
+```
83
+
84
+This will cause `@mycorp` to be mapped to the registry for future installation of packages specified according to the pattern `@mycorp/package`.
85
+
86
+This will also cause `npm init` to create a scoped package.
87
+
88
+```
89
+# accept all defaults, and create a package named "@foo/whatever",
90
+# instead of just named "whatever"
91
+npm init --scope=@foo --yes
92
+```
93
+
94
+#### `auth-type`
95
+
96
+- Default: "web"
97
+- Type: "legacy" or "web"
98
+
99
+What authentication strategy to use with `login`. Note that if an `otp` config is given, this value will always be set to `legacy`.
100
+
101
+### See Also
102
+
103
+- [npm registry](/cli/v11/using-npm/registry)
104
+- [npm config](/cli/v11/commands/npm-config)
105
+- [npmrc](/cli/v11/configuring-npm/npmrc)
106
+- [npm owner](/cli/v11/commands/npm-owner)
107
+- [npm whoami](/cli/v11/commands/npm-whoami)
108
+- [npm token](/cli/v11/commands/npm-token)
109
+- [npm profile](/cli/v11/commands/npm-profile)
content/cli/v11/commands/npm-logout.mdx
new
+95
@@ -0,0 +1,95 @@
1
+---
2
+title: npm-logout
3
+section: 1
4
+description: Log out of the registry
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-logout.md
8
+redirect_from:
9
+ - /cli-commands/logout
10
+ - /cli-commands/npm-logout
11
+ - /cli-documentation/cli-commands/logout
12
+ - /cli-documentation/cli-commands/npm-logout
13
+ - /cli-documentation/commands/logout
14
+ - /cli-documentation/commands/npm-logout
15
+ - /cli-documentation/logout
16
+ - /cli-documentation/npm-logout
17
+ - /cli-documentation/v11/cli-commands/logout
18
+ - /cli-documentation/v11/cli-commands/npm-logout
19
+ - /cli-documentation/v11/commands/logout
20
+ - /cli-documentation/v11/commands/npm-logout
21
+ - /cli-documentation/v11/logout
22
+ - /cli-documentation/v11/npm-logout
23
+ - /cli/cli-commands/logout
24
+ - /cli/cli-commands/npm-logout
25
+ - /cli/commands/logout
26
+ - /cli/commands/npm-logout
27
+ - /cli/logout
28
+ - /cli/npm-logout
29
+ - /cli/v11/cli-commands/logout
30
+ - /cli/v11/cli-commands/npm-logout
31
+ - /cli/v11/commands/logout
32
+ - /cli/v11/logout
33
+ - /cli/v11/npm-logout
34
+ - /commands/logout
35
+ - /commands/npm-logout
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm logout
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+When logged into a registry that supports token-based authentication, tell the server to end this token's session. This will invalidate the token everywhere you're using it, not just for the current environment.
49
+
50
+When logged into a legacy registry that uses username and password authentication, this will clear the credentials in your user configuration. In this case, it will _only_ affect the current environment.
51
+
52
+If `--scope` is provided, this will find the credentials for the registry connected to that scope, if set.
53
+
54
+### Configuration
55
+
56
+#### `registry`
57
+
58
+- Default: "https://registry.npmjs.org/"
59
+- Type: URL
60
+
61
+The base URL of the npm registry.
62
+
63
+#### `scope`
64
+
65
+- Default: the scope of the current project, if any, or ""
66
+- Type: String
67
+
68
+Associate an operation with a scope for a scoped registry.
69
+
70
+Useful when logging in to or out of a private registry:
71
+
72
+```
73
+# log in, linking the scope to the custom registry
74
+npm login --scope=@mycorp --registry=https://registry.mycorp.com
75
+
76
+# log out, removing the link and the auth token
77
+npm logout --scope=@mycorp
78
+```
79
+
80
+This will cause `@mycorp` to be mapped to the registry for future installation of packages specified according to the pattern `@mycorp/package`.
81
+
82
+This will also cause `npm init` to create a scoped package.
83
+
84
+```
85
+# accept all defaults, and create a package named "@foo/whatever",
86
+# instead of just named "whatever"
87
+npm init --scope=@foo --yes
88
+```
89
+
90
+### See Also
91
+
92
+- [npm adduser](/cli/v11/commands/npm-adduser)
93
+- [npm registry](/cli/v11/using-npm/registry)
94
+- [npm config](/cli/v11/commands/npm-config)
95
+- [npm whoami](/cli/v11/commands/npm-whoami)
content/cli/v11/commands/npm-ls.mdx
new
+231
@@ -0,0 +1,231 @@
1
+---
2
+title: npm-ls
3
+section: 1
4
+description: List installed packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-ls.md
8
+redirect_from:
9
+ - /cli-commands/ls
10
+ - /cli-commands/npm-ls
11
+ - /cli-documentation/cli-commands/ls
12
+ - /cli-documentation/cli-commands/npm-ls
13
+ - /cli-documentation/commands/ls
14
+ - /cli-documentation/commands/npm-ls
15
+ - /cli-documentation/ls
16
+ - /cli-documentation/npm-ls
17
+ - /cli-documentation/v11/cli-commands/ls
18
+ - /cli-documentation/v11/cli-commands/npm-ls
19
+ - /cli-documentation/v11/commands/ls
20
+ - /cli-documentation/v11/commands/npm-ls
21
+ - /cli-documentation/v11/ls
22
+ - /cli-documentation/v11/npm-ls
23
+ - /cli/cli-commands/ls
24
+ - /cli/cli-commands/npm-ls
25
+ - /cli/commands/ls
26
+ - /cli/commands/npm-ls
27
+ - /cli/ls
28
+ - /cli/npm-ls
29
+ - /cli/v11/cli-commands/ls
30
+ - /cli/v11/cli-commands/npm-ls
31
+ - /cli/v11/commands/ls
32
+ - /cli/v11/ls
33
+ - /cli/v11/npm-ls
34
+ - /commands/ls
35
+ - /commands/npm-ls
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm ls <package-spec>
42
+
43
+alias: list
44
+```
45
+
46
+### Description
47
+
48
+This command will print to stdout all the versions of packages that are installed, as well as their dependencies when `--all` is specified, in a tree structure.
49
+
50
+Note: to get a "bottoms up" view of why a given package is included in the tree at all, use [`npm explain`](/cli/v11/commands/npm-explain).
51
+
52
+Positional arguments are `name@version-range` identifiers, which will limit the results to only the paths to the packages named. Note that nested packages will _also_ show the paths to the specified packages. For example, running `npm ls promzard` in npm's source tree will show:
53
+
54
+```bash
55
+npm@11.0.0 /path/to/npm
56
+└─┬ init-package-json@0.0.4
57
+ └── promzard@0.1.5
58
+```
59
+
60
+It will print out extraneous, missing, and invalid packages.
61
+
62
+If a project specifies git urls for dependencies these are shown in parentheses after the `name@version` to make it easier for users to recognize potential forks of a project.
63
+
64
+The tree shown is the logical dependency tree, based on package dependencies, not the physical layout of your `node_modules` folder.
65
+
66
+When run as `ll` or `la`, it shows extended information by default.
67
+
68
+### Configuration
69
+
70
+#### `all`
71
+
72
+- Default: false
73
+- Type: Boolean
74
+
75
+When running `npm outdated` and `npm ls`, setting `--all` will show all outdated or installed packages, rather than only those directly depended upon by the current project.
76
+
77
+#### `json`
78
+
79
+- Default: false
80
+- Type: Boolean
81
+
82
+Whether or not to output JSON data, rather than the normal output.
83
+
84
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
85
+
86
+Not supported by all npm commands.
87
+
88
+#### `long`
89
+
90
+- Default: false
91
+- Type: Boolean
92
+
93
+Show extended information in `ls`, `search`, and `help-search`.
94
+
95
+#### `parseable`
96
+
97
+- Default: false
98
+- Type: Boolean
99
+
100
+Output parseable results from commands that write to standard output. For `npm search`, this will be tab-separated table format.
101
+
102
+#### `global`
103
+
104
+- Default: false
105
+- Type: Boolean
106
+
107
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
108
+
109
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
110
+- bin files are linked to `{prefix}/bin`
111
+- man pages are linked to `{prefix}/share/man`
112
+
113
+#### `depth`
114
+
115
+- Default: `Infinity` if `--all` is set, otherwise `1`
116
+- Type: null or Number
117
+
118
+The depth to go when recursing packages for `npm ls`.
119
+
120
+If not set, `npm ls` will show only the immediate dependencies of the root project. If `--all` is set, then npm will show all dependencies by default.
121
+
122
+#### `omit`
123
+
124
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
125
+- Type: "dev", "optional", or "peer" (can be set multiple times)
126
+
127
+Dependency types to omit from the installation tree on disk.
128
+
129
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
130
+
131
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
132
+
133
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
134
+
135
+#### `include`
136
+
137
+- Default:
138
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
139
+
140
+Option that allows for defining which types of dependencies to install.
141
+
142
+This is the inverse of `--omit=<type>`.
143
+
144
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
145
+
146
+#### `link`
147
+
148
+- Default: false
149
+- Type: Boolean
150
+
151
+Used with `npm ls`, limiting output to only those packages that are linked.
152
+
153
+#### `package-lock-only`
154
+
155
+- Default: false
156
+- Type: Boolean
157
+
158
+If set to true, the current operation will only use the `package-lock.json`, ignoring `node_modules`.
159
+
160
+For `update` this means only the `package-lock.json` will be updated, instead of checking `node_modules` and downloading dependencies.
161
+
162
+For `list` this means the output will be based on the tree described by the `package-lock.json`, rather than the contents of `node_modules`.
163
+
164
+#### `unicode`
165
+
166
+- Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the `LC_ALL`, `LC_CTYPE`, or `LANG` environment variables.
167
+- Type: Boolean
168
+
169
+When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
170
+
171
+#### `workspace`
172
+
173
+- Default:
174
+- Type: String (can be set multiple times)
175
+
176
+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.
177
+
178
+Valid values for the `workspace` config are either:
179
+
180
+- Workspace names
181
+- Path to a workspace directory
182
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
183
+
184
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
185
+
186
+This value is not exported to the environment for child processes.
187
+
188
+#### `workspaces`
189
+
190
+- Default: null
191
+- Type: null or Boolean
192
+
193
+Set to true to run the command in the context of **all** configured workspaces.
194
+
195
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
196
+
197
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
198
+
199
+This value is not exported to the environment for child processes.
200
+
201
+#### `include-workspace-root`
202
+
203
+- Default: false
204
+- Type: Boolean
205
+
206
+Include the workspace root when workspaces are enabled for a command.
207
+
208
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
209
+
210
+This value is not exported to the environment for child processes.
211
+
212
+#### `install-links`
213
+
214
+- Default: false
215
+- Type: Boolean
216
+
217
+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.
218
+
219
+### See Also
220
+
221
+- [package spec](/cli/v11/using-npm/package-spec)
222
+- [npm explain](/cli/v11/commands/npm-explain)
223
+- [npm config](/cli/v11/commands/npm-config)
224
+- [npmrc](/cli/v11/configuring-npm/npmrc)
225
+- [npm folders](/cli/v11/configuring-npm/folders)
226
+- [npm explain](/cli/v11/commands/npm-explain)
227
+- [npm install](/cli/v11/commands/npm-install)
228
+- [npm link](/cli/v11/commands/npm-link)
229
+- [npm prune](/cli/v11/commands/npm-prune)
230
+- [npm outdated](/cli/v11/commands/npm-outdated)
231
+- [npm update](/cli/v11/commands/npm-update)
content/cli/v11/commands/npm-org.mdx
new
+131
@@ -0,0 +1,131 @@
1
+---
2
+title: npm-org
3
+section: 1
4
+description: Manage orgs
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-org.md
8
+redirect_from:
9
+ - /cli-commands/npm-org
10
+ - /cli-commands/org
11
+ - /cli-documentation/cli-commands/npm-org
12
+ - /cli-documentation/cli-commands/org
13
+ - /cli-documentation/commands/npm-org
14
+ - /cli-documentation/commands/org
15
+ - /cli-documentation/npm-org
16
+ - /cli-documentation/org
17
+ - /cli-documentation/v11/cli-commands/npm-org
18
+ - /cli-documentation/v11/cli-commands/org
19
+ - /cli-documentation/v11/commands/npm-org
20
+ - /cli-documentation/v11/commands/org
21
+ - /cli-documentation/v11/npm-org
22
+ - /cli-documentation/v11/org
23
+ - /cli/cli-commands/npm-org
24
+ - /cli/cli-commands/org
25
+ - /cli/commands/npm-org
26
+ - /cli/commands/org
27
+ - /cli/npm-org
28
+ - /cli/org
29
+ - /cli/v11/cli-commands/npm-org
30
+ - /cli/v11/cli-commands/org
31
+ - /cli/v11/commands/org
32
+ - /cli/v11/npm-org
33
+ - /cli/v11/org
34
+ - /commands/npm-org
35
+ - /commands/org
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm org set orgname username [developer | admin | owner]
42
+npm org rm orgname username
43
+npm org ls orgname [<username>]
44
+
45
+alias: ogr
46
+```
47
+
48
+Note: This command is unaware of workspaces.
49
+
50
+### Example
51
+
52
+Add a new developer to an org:
53
+
54
+```bash
55
+$ npm org set my-org @mx-smith
56
+```
57
+
58
+Add a new admin to an org (or change a developer to an admin):
59
+
60
+```bash
61
+$ npm org set my-org @mx-santos admin
62
+```
63
+
64
+Remove a user from an org:
65
+
66
+```bash
67
+$ npm org rm my-org mx-santos
68
+```
69
+
70
+List all users in an org:
71
+
72
+```bash
73
+$ npm org ls my-org
74
+```
75
+
76
+List all users in JSON format:
77
+
78
+```bash
79
+$ npm org ls my-org --json
80
+```
81
+
82
+See what role a user has in an org:
83
+
84
+```bash
85
+$ npm org ls my-org @mx-santos
86
+```
87
+
88
+### Description
89
+
90
+You can use the `npm org` commands to manage and view users of an organization. It supports adding and removing users, changing their roles, listing them, and finding specific ones and their roles.
91
+
92
+### Configuration
93
+
94
+#### `registry`
95
+
96
+- Default: "https://registry.npmjs.org/"
97
+- Type: URL
98
+
99
+The base URL of the npm registry.
100
+
101
+#### `otp`
102
+
103
+- Default: null
104
+- Type: null or String
105
+
106
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
107
+
108
+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.
109
+
110
+#### `json`
111
+
112
+- Default: false
113
+- Type: Boolean
114
+
115
+Whether or not to output JSON data, rather than the normal output.
116
+
117
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
118
+
119
+Not supported by all npm commands.
120
+
121
+#### `parseable`
122
+
123
+- Default: false
124
+- Type: Boolean
125
+
126
+Output parseable results from commands that write to standard output. For `npm search`, this will be tab-separated table format.
127
+
128
+### See Also
129
+
130
+- [using orgs](/cli/v11/using-npm/orgs)
131
+- [Documentation on npm Orgs](https://docs.npmjs.com/orgs/)
content/cli/v11/commands/npm-outdated.mdx
new
+160
@@ -0,0 +1,160 @@
1
+---
2
+title: npm-outdated
3
+section: 1
4
+description: Check for outdated packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-outdated.md
8
+redirect_from:
9
+ - /cli-commands/npm-outdated
10
+ - /cli-commands/outdated
11
+ - /cli-documentation/cli-commands/npm-outdated
12
+ - /cli-documentation/cli-commands/outdated
13
+ - /cli-documentation/commands/npm-outdated
14
+ - /cli-documentation/commands/outdated
15
+ - /cli-documentation/npm-outdated
16
+ - /cli-documentation/outdated
17
+ - /cli-documentation/v11/cli-commands/npm-outdated
18
+ - /cli-documentation/v11/cli-commands/outdated
19
+ - /cli-documentation/v11/commands/npm-outdated
20
+ - /cli-documentation/v11/commands/outdated
21
+ - /cli-documentation/v11/npm-outdated
22
+ - /cli-documentation/v11/outdated
23
+ - /cli/cli-commands/npm-outdated
24
+ - /cli/cli-commands/outdated
25
+ - /cli/commands/npm-outdated
26
+ - /cli/commands/outdated
27
+ - /cli/npm-outdated
28
+ - /cli/outdated
29
+ - /cli/v11/cli-commands/npm-outdated
30
+ - /cli/v11/cli-commands/outdated
31
+ - /cli/v11/commands/outdated
32
+ - /cli/v11/npm-outdated
33
+ - /cli/v11/outdated
34
+ - /commands/npm-outdated
35
+ - /commands/outdated
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm outdated [<package-spec> ...]
42
+```
43
+
44
+### Description
45
+
46
+This command will check the registry to see if any (or, specific) installed packages are currently outdated.
47
+
48
+By default, only the direct dependencies of the root project and direct dependencies of your configured _workspaces_ are shown. Use `--all` to find all outdated meta-dependencies as well.
49
+
50
+In the output:
51
+
52
+- `wanted` is the maximum version of the package that satisfies the semver range specified in `package.json`. If there's no available semver range (i.e. you're running `npm outdated --global`, or the package isn't included in `package.json`), then `wanted` shows the currently-installed version.
53
+- `latest` is the version of the package tagged as latest in the registry. Running `npm publish` with no special configuration will publish the package with a dist-tag of `latest`. This may or may not be the maximum version of the package, or the most-recently published version of the package, depending on how the package's developer manages the latest [dist-tag](/cli/v11/commands/npm-dist-tag).
54
+- `location` is where in the physical tree the package is located.
55
+- `depended by` shows which package depends on the displayed dependency
56
+- `package type` (when using `--long` / `-l`) tells you whether this package is a `dependency` or a dev/peer/optional dependency. Packages not included in `package.json` are always marked `dependencies`.
57
+- `homepage` (when using `--long` / `-l`) is the `homepage` value contained in the package's packument
58
+- Red means there's a newer version matching your semver requirements, so you should update now.
59
+- Yellow indicates that there's a newer version _above_ your semver requirements (usually new major, or new 0.x minor) so proceed with caution.
60
+
61
+### An example
62
+
63
+```bash
64
+$ npm outdated
65
+Package Current Wanted Latest Location Depended by
66
+glob 5.0.15 5.0.15 6.0.1 node_modules/glob dependent-package-name
67
+nothingness 0.0.3 git git node_modules/nothingness dependent-package-name
68
+npm 3.5.1 3.5.2 3.5.1 node_modules/npm dependent-package-name
69
+local-dev 0.0.3 linked linked local-dev dependent-package-name
70
+once 1.3.2 1.3.3 1.3.3 node_modules/once dependent-package-name
71
+```
72
+
73
+With these `dependencies`:
74
+
75
+```json
76
+{
77
+ "glob": "^5.0.15",
78
+ "nothingness": "github:othiym23/nothingness#master",
79
+ "npm": "^3.5.1",
80
+ "once": "^1.3.1"
81
+}
82
+```
83
+
84
+A few things to note:
85
+
86
+- `glob` requires `^5`, which prevents npm from installing `glob@6`, which is outside the semver range.
87
+- Git dependencies will always be reinstalled, because of how they're specified. The installed committish might satisfy the dependency specifier (if it's something immutable, like a commit SHA), or it might not, so `npm outdated` and `npm update` have to fetch Git repos to check. This is why currently doing a reinstall of a Git dependency always forces a new clone and install.
88
+- `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because npm uses dist-tags to manage its `latest` and `next` release channels. `npm update` will install the _newest_ version, but `npm install npm` (with no semver range) will install whatever's tagged as `latest`.
89
+- `once` is just plain out of date. Reinstalling `node_modules` from scratch or running `npm update` will bring it up to spec.
90
+
91
+### Configuration
92
+
93
+#### `all`
94
+
95
+- Default: false
96
+- Type: Boolean
97
+
98
+When running `npm outdated` and `npm ls`, setting `--all` will show all outdated or installed packages, rather than only those directly depended upon by the current project.
99
+
100
+#### `json`
101
+
102
+- Default: false
103
+- Type: Boolean
104
+
105
+Whether or not to output JSON data, rather than the normal output.
106
+
107
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
108
+
109
+Not supported by all npm commands.
110
+
111
+#### `long`
112
+
113
+- Default: false
114
+- Type: Boolean
115
+
116
+Show extended information in `ls`, `search`, and `help-search`.
117
+
118
+#### `parseable`
119
+
120
+- Default: false
121
+- Type: Boolean
122
+
123
+Output parseable results from commands that write to standard output. For `npm search`, this will be tab-separated table format.
124
+
125
+#### `global`
126
+
127
+- Default: false
128
+- Type: Boolean
129
+
130
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
131
+
132
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
133
+- bin files are linked to `{prefix}/bin`
134
+- man pages are linked to `{prefix}/share/man`
135
+
136
+#### `workspace`
137
+
138
+- Default:
139
+- Type: String (can be set multiple times)
140
+
141
+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.
142
+
143
+Valid values for the `workspace` config are either:
144
+
145
+- Workspace names
146
+- Path to a workspace directory
147
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
148
+
149
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
150
+
151
+This value is not exported to the environment for child processes.
152
+
153
+### See Also
154
+
155
+- [package spec](/cli/v11/using-npm/package-spec)
156
+- [npm update](/cli/v11/commands/npm-update)
157
+- [npm dist-tag](/cli/v11/commands/npm-dist-tag)
158
+- [npm registry](/cli/v11/using-npm/registry)
159
+- [npm folders](/cli/v11/configuring-npm/folders)
160
+- [npm workspaces](/cli/v11/using-npm/workspaces)
content/cli/v11/commands/npm-owner.mdx
new
+114
@@ -0,0 +1,114 @@
1
+---
2
+title: npm-owner
3
+section: 1
4
+description: Manage package owners
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-owner.md
8
+redirect_from:
9
+ - /cli-commands/npm-owner
10
+ - /cli-commands/owner
11
+ - /cli-documentation/cli-commands/npm-owner
12
+ - /cli-documentation/cli-commands/owner
13
+ - /cli-documentation/commands/npm-owner
14
+ - /cli-documentation/commands/owner
15
+ - /cli-documentation/npm-owner
16
+ - /cli-documentation/owner
17
+ - /cli-documentation/v11/cli-commands/npm-owner
18
+ - /cli-documentation/v11/cli-commands/owner
19
+ - /cli-documentation/v11/commands/npm-owner
20
+ - /cli-documentation/v11/commands/owner
21
+ - /cli-documentation/v11/npm-owner
22
+ - /cli-documentation/v11/owner
23
+ - /cli/cli-commands/npm-owner
24
+ - /cli/cli-commands/owner
25
+ - /cli/commands/npm-owner
26
+ - /cli/commands/owner
27
+ - /cli/npm-owner
28
+ - /cli/owner
29
+ - /cli/v11/cli-commands/npm-owner
30
+ - /cli/v11/cli-commands/owner
31
+ - /cli/v11/commands/owner
32
+ - /cli/v11/npm-owner
33
+ - /cli/v11/owner
34
+ - /commands/npm-owner
35
+ - /commands/owner
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm owner add <user> <package-spec>
42
+npm owner rm <user> <package-spec>
43
+npm owner ls <package-spec>
44
+
45
+alias: author
46
+```
47
+
48
+### Description
49
+
50
+Manage ownership of published packages.
51
+
52
+- 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.
53
+- 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.
54
+- rm: Remove a user from the package owner list. This immediately revokes their privileges.
55
+
56
+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.
57
+
58
+If you have two-factor authentication enabled with `auth-and-writes` (see [`npm-profile`](/cli/v11/commands/npm-profile)) then you'll need to go through a second factor flow when changing ownership or include an otp on the command line with `--otp`.
59
+
60
+### Configuration
61
+
62
+#### `registry`
63
+
64
+- Default: "https://registry.npmjs.org/"
65
+- Type: URL
66
+
67
+The base URL of the npm registry.
68
+
69
+#### `otp`
70
+
71
+- Default: null
72
+- Type: null or String
73
+
74
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
75
+
76
+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.
77
+
78
+#### `workspace`
79
+
80
+- Default:
81
+- Type: String (can be set multiple times)
82
+
83
+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.
84
+
85
+Valid values for the `workspace` config are either:
86
+
87
+- Workspace names
88
+- Path to a workspace directory
89
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
90
+
91
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
92
+
93
+This value is not exported to the environment for child processes.
94
+
95
+#### `workspaces`
96
+
97
+- Default: null
98
+- Type: null or Boolean
99
+
100
+Set to true to run the command in the context of **all** configured workspaces.
101
+
102
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
103
+
104
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
105
+
106
+This value is not exported to the environment for child processes.
107
+
108
+### See Also
109
+
110
+- [package spec](/cli/v11/using-npm/package-spec)
111
+- [npm profile](/cli/v11/commands/npm-profile)
112
+- [npm publish](/cli/v11/commands/npm-publish)
113
+- [npm registry](/cli/v11/using-npm/registry)
114
+- [npm adduser](/cli/v11/commands/npm-adduser)
content/cli/v11/commands/npm-pack.mdx
new
+138
@@ -0,0 +1,138 @@
1
+---
2
+title: npm-pack
3
+section: 1
4
+description: Create a tarball from a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-pack.md
8
+redirect_from:
9
+ - /cli-commands/npm-pack
10
+ - /cli-commands/pack
11
+ - /cli-documentation/cli-commands/npm-pack
12
+ - /cli-documentation/cli-commands/pack
13
+ - /cli-documentation/commands/npm-pack
14
+ - /cli-documentation/commands/pack
15
+ - /cli-documentation/npm-pack
16
+ - /cli-documentation/pack
17
+ - /cli-documentation/v11/cli-commands/npm-pack
18
+ - /cli-documentation/v11/cli-commands/pack
19
+ - /cli-documentation/v11/commands/npm-pack
20
+ - /cli-documentation/v11/commands/pack
21
+ - /cli-documentation/v11/npm-pack
22
+ - /cli-documentation/v11/pack
23
+ - /cli/cli-commands/npm-pack
24
+ - /cli/cli-commands/pack
25
+ - /cli/commands/npm-pack
26
+ - /cli/commands/pack
27
+ - /cli/npm-pack
28
+ - /cli/pack
29
+ - /cli/v11/cli-commands/npm-pack
30
+ - /cli/v11/cli-commands/pack
31
+ - /cli/v11/commands/pack
32
+ - /cli/v11/npm-pack
33
+ - /cli/v11/pack
34
+ - /commands/npm-pack
35
+ - /commands/pack
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm pack <package-spec>
42
+```
43
+
44
+### Configuration
45
+
46
+#### `dry-run`
47
+
48
+- Default: false
49
+- Type: Boolean
50
+
51
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
52
+
53
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
54
+
55
+#### `json`
56
+
57
+- Default: false
58
+- Type: Boolean
59
+
60
+Whether or not to output JSON data, rather than the normal output.
61
+
62
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
63
+
64
+Not supported by all npm commands.
65
+
66
+#### `pack-destination`
67
+
68
+- Default: "."
69
+- Type: String
70
+
71
+Directory in which `npm pack` will save tarballs.
72
+
73
+#### `workspace`
74
+
75
+- Default:
76
+- Type: String (can be set multiple times)
77
+
78
+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.
79
+
80
+Valid values for the `workspace` config are either:
81
+
82
+- Workspace names
83
+- Path to a workspace directory
84
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
85
+
86
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
87
+
88
+This value is not exported to the environment for child processes.
89
+
90
+#### `workspaces`
91
+
92
+- Default: null
93
+- Type: null or Boolean
94
+
95
+Set to true to run the command in the context of **all** configured workspaces.
96
+
97
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
98
+
99
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
100
+
101
+This value is not exported to the environment for child processes.
102
+
103
+#### `include-workspace-root`
104
+
105
+- Default: false
106
+- Type: Boolean
107
+
108
+Include the workspace root when workspaces are enabled for a command.
109
+
110
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
111
+
112
+This value is not exported to the environment for child processes.
113
+
114
+#### `ignore-scripts`
115
+
116
+- Default: false
117
+- Type: Boolean
118
+
119
+If true, npm does not run scripts specified in package.json files.
120
+
121
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
122
+
123
+### Description
124
+
125
+For anything that's installable (that is, a package folder, tarball, tarball url, git url, name@tag, name@version, name, or scoped name), this command will fetch it to the cache, copy the tarball to the current working directory as `<name>-<version>.tgz`, and then write the filenames out to stdout.
126
+
127
+If the same package is specified multiple times, then the file will be overwritten the second time.
128
+
129
+If no arguments are supplied, then npm packs the current package folder.
130
+
131
+### See Also
132
+
133
+- [package spec](/cli/v11/using-npm/package-spec)
134
+- [npm-packlist package](http://npm.im/npm-packlist)
135
+- [npm cache](/cli/v11/commands/npm-cache)
136
+- [npm publish](/cli/v11/commands/npm-publish)
137
+- [npm config](/cli/v11/commands/npm-config)
138
+- [npmrc](/cli/v11/configuring-npm/npmrc)
content/cli/v11/commands/npm-ping.mdx
new
+76
@@ -0,0 +1,76 @@
1
+---
2
+title: npm-ping
3
+section: 1
4
+description: Ping npm registry
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-ping.md
8
+redirect_from:
9
+ - /cli-commands/npm-ping
10
+ - /cli-commands/ping
11
+ - /cli-documentation/cli-commands/npm-ping
12
+ - /cli-documentation/cli-commands/ping
13
+ - /cli-documentation/commands/npm-ping
14
+ - /cli-documentation/commands/ping
15
+ - /cli-documentation/npm-ping
16
+ - /cli-documentation/ping
17
+ - /cli-documentation/v11/cli-commands/npm-ping
18
+ - /cli-documentation/v11/cli-commands/ping
19
+ - /cli-documentation/v11/commands/npm-ping
20
+ - /cli-documentation/v11/commands/ping
21
+ - /cli-documentation/v11/npm-ping
22
+ - /cli-documentation/v11/ping
23
+ - /cli/cli-commands/npm-ping
24
+ - /cli/cli-commands/ping
25
+ - /cli/commands/npm-ping
26
+ - /cli/commands/ping
27
+ - /cli/npm-ping
28
+ - /cli/ping
29
+ - /cli/v11/cli-commands/npm-ping
30
+ - /cli/v11/cli-commands/ping
31
+ - /cli/v11/commands/ping
32
+ - /cli/v11/npm-ping
33
+ - /cli/v11/ping
34
+ - /commands/npm-ping
35
+ - /commands/ping
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm ping
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+Ping the configured or given npm registry and verify authentication. If it works it will output something like:
49
+
50
+```bash
51
+npm notice PING https://registry.npmjs.org/
52
+npm notice PONG 255ms
53
+```
54
+
55
+otherwise you will get an error:
56
+
57
+```bash
58
+npm notice PING http://foo.com/
59
+npm ERR! code E404
60
+npm ERR! 404 Not Found - GET http://www.foo.com/-/ping?write=true
61
+```
62
+
63
+### Configuration
64
+
65
+#### `registry`
66
+
67
+- Default: "https://registry.npmjs.org/"
68
+- Type: URL
69
+
70
+The base URL of the npm registry.
71
+
72
+### See Also
73
+
74
+- [npm doctor](/cli/v11/commands/npm-doctor)
75
+- [npm config](/cli/v11/commands/npm-config)
76
+- [npmrc](/cli/v11/configuring-npm/npmrc)
content/cli/v11/commands/npm-pkg.mdx
new
+248
@@ -0,0 +1,248 @@
1
+---
2
+title: npm-pkg
3
+section: 1
4
+description: Manages your package.json
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-pkg.md
8
+redirect_from:
9
+ - /cli-commands/npm-pkg
10
+ - /cli-commands/pkg
11
+ - /cli-documentation/cli-commands/npm-pkg
12
+ - /cli-documentation/cli-commands/pkg
13
+ - /cli-documentation/commands/npm-pkg
14
+ - /cli-documentation/commands/pkg
15
+ - /cli-documentation/npm-pkg
16
+ - /cli-documentation/pkg
17
+ - /cli-documentation/v11/cli-commands/npm-pkg
18
+ - /cli-documentation/v11/cli-commands/pkg
19
+ - /cli-documentation/v11/commands/npm-pkg
20
+ - /cli-documentation/v11/commands/pkg
21
+ - /cli-documentation/v11/npm-pkg
22
+ - /cli-documentation/v11/pkg
23
+ - /cli/cli-commands/npm-pkg
24
+ - /cli/cli-commands/pkg
25
+ - /cli/commands/npm-pkg
26
+ - /cli/commands/pkg
27
+ - /cli/npm-pkg
28
+ - /cli/pkg
29
+ - /cli/v11/cli-commands/npm-pkg
30
+ - /cli/v11/cli-commands/pkg
31
+ - /cli/v11/commands/pkg
32
+ - /cli/v11/npm-pkg
33
+ - /cli/v11/pkg
34
+ - /commands/npm-pkg
35
+ - /commands/pkg
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm pkg set <key>=<value> [<key>=<value> ...]
42
+npm pkg get [<key> [<key> ...]]
43
+npm pkg delete <key> [<key> ...]
44
+npm pkg set [<array>[<index>].<key>=<value> ...]
45
+npm pkg set [<array>[].<key>=<value> ...]
46
+npm pkg fix
47
+```
48
+
49
+### Description
50
+
51
+A command that automates the management of `package.json` files. `npm pkg` provide 3 different sub commands that allow you to modify or retrieve values for given object keys in your `package.json`.
52
+
53
+The syntax to retrieve and set fields is a dot separated representation of the nested object properties to be found within your `package.json`, it's the same notation used in [`npm view`](/cli/v11/commands/npm-view) to retrieve information from the registry manifest, below you can find more examples on how to use it.
54
+
55
+Returned values are always in **json** format.
56
+
57
+- `npm pkg get <field>`
58
+
59
+ Retrieves a value `key`, defined in your `package.json` file.
60
+
61
+ For example, in order to retrieve the name of the current package, you can run:
62
+
63
+ ```bash
64
+ npm pkg get name
65
+ ```
66
+
67
+ It's also possible to retrieve multiple values at once:
68
+
69
+ ```bash
70
+ npm pkg get name version
71
+ ```
72
+
73
+ You can view child fields by separating them with a period. To retrieve the value of a test `script` value, you would run the following command:
74
+
75
+ ```bash
76
+ npm pkg get scripts.test
77
+ ```
78
+
79
+ For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list. For example, to get all the contributor emails for a package, you would run:
80
+
81
+ ```bash
82
+ npm pkg get contributors.email
83
+ ```
84
+
85
+ You may also use numeric indices in square braces to specifically select an item in an array field. To just get the email address of the first contributor in the list, you can run:
86
+
87
+ ```bash
88
+ npm pkg get contributors[0].email
89
+ ```
90
+
91
+ For complex fields you can also name a property in square brackets to specifically select a child field. This is especially helpful with the exports object:
92
+
93
+ ```bash
94
+ npm pkg get "exports[.].require"
95
+ ```
96
+
97
+- `npm pkg set <field>=<value>`
98
+
99
+ Sets a `value` in your `package.json` based on the `field` value. When saving to your `package.json` file the same set of rules used during `npm install` and other cli commands that touches the `package.json` file are used, making sure to respect the existing indentation and possibly applying some validation prior to saving values to the file.
100
+
101
+ The same syntax used to retrieve values from your package can also be used to define new properties or overriding existing ones, below are some examples of how the dot separated syntax can be used to edit your `package.json` file.
102
+
103
+ Defining a new bin named `mynewcommand` in your `package.json` that points to a file `cli.js`:
104
+
105
+ ```bash
106
+ npm pkg set bin.mynewcommand=cli.js
107
+ ```
108
+
109
+ Setting multiple fields at once is also possible:
110
+
111
+ ```bash
112
+ npm pkg set description='Awesome package' engines.node='>=10'
113
+ ```
114
+
115
+ It's also possible to add to array values, for example to add a new contributor entry:
116
+
117
+ ```bash
118
+ npm pkg set contributors[0].name='Foo' contributors[0].email='foo@bar.ca'
119
+ ```
120
+
121
+ You may also append items to the end of an array using the special empty bracket notation:
122
+
123
+ ```bash
124
+ npm pkg set contributors[].name='Foo' contributors[].name='Bar'
125
+ ```
126
+
127
+ It's also possible to parse values as json prior to saving them to your `package.json` file, for example in order to set a `"private": true` property:
128
+
129
+ ```bash
130
+ npm pkg set private=true --json
131
+ ```
132
+
133
+ It also enables saving values as numbers:
134
+
135
+ ```bash
136
+ npm pkg set tap.timeout=60 --json
137
+ ```
138
+
139
+- `npm pkg delete <key>`
140
+
141
+ Deletes a `key` from your `package.json`
142
+
143
+ The same syntax used to set values from your package can also be used to remove existing ones. For example, in order to remove a script named build:
144
+
145
+ ```bash
146
+ npm pkg delete scripts.build
147
+ ```
148
+
149
+- `npm pkg fix`
150
+
151
+ Auto corrects common errors in your `package.json`. npm already does this during `publish`, which leads to subtle (mostly harmless) differences between the contents of your `package.json` file and the manifest that npm uses during installation.
152
+
153
+### Workspaces support
154
+
155
+You can set/get/delete items across your configured workspaces by using the [`workspace`](/cli/v11/using-npm/config#workspace) or [`workspaces`](/cli/v11/using-npm/config#workspaces) config options.
156
+
157
+For example, setting a `funding` value across all configured workspaces of a project:
158
+
159
+```bash
160
+npm pkg set funding=https://example.com --ws
161
+```
162
+
163
+When using `npm pkg get` to retrieve info from your configured workspaces, the returned result will be in a json format in which top level keys are the names of each workspace, the values of these keys will be the result values returned from each of the configured workspaces, e.g:
164
+
165
+```
166
+npm pkg get name version --ws
167
+{
168
+ "a": {
169
+ "name": "a",
170
+ "version": "1.0.0"
171
+ },
172
+ "b": {
173
+ "name": "b",
174
+ "version": "1.0.0"
175
+ }
176
+}
177
+```
178
+
179
+### Configuration
180
+
181
+#### `force`
182
+
183
+- Default: false
184
+- Type: Boolean
185
+
186
+Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
187
+
188
+- Allow clobbering non-npm files in global installs.
189
+- Allow the `npm version` command to work on an unclean git repository.
190
+- Allow deleting the cache folder with `npm cache clean`.
191
+- Allow installing packages that have an `engines` declaration requiring a different version of npm.
192
+- Allow installing packages that have an `engines` declaration requiring a different version of `node`, even if `--engine-strict` is enabled.
193
+- Allow `npm audit fix` to install modules outside your stated dependency range (including SemVer-major changes).
194
+- Allow unpublishing all versions of a published package.
195
+- Allow conflicting peerDependencies to be installed in the root project.
196
+- Implicitly set `--yes` during `npm init`.
197
+- Allow clobbering existing values in `npm pkg`
198
+- Allow unpublishing of entire packages (not just a single version).
199
+
200
+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!
201
+
202
+#### `json`
203
+
204
+- Default: false
205
+- Type: Boolean
206
+
207
+Whether or not to output JSON data, rather than the normal output.
208
+
209
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
210
+
211
+Not supported by all npm commands.
212
+
213
+#### `workspace`
214
+
215
+- Default:
216
+- Type: String (can be set multiple times)
217
+
218
+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.
219
+
220
+Valid values for the `workspace` config are either:
221
+
222
+- Workspace names
223
+- Path to a workspace directory
224
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
225
+
226
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
227
+
228
+This value is not exported to the environment for child processes.
229
+
230
+#### `workspaces`
231
+
232
+- Default: null
233
+- Type: null or Boolean
234
+
235
+Set to true to run the command in the context of **all** configured workspaces.
236
+
237
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
238
+
239
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
240
+
241
+This value is not exported to the environment for child processes.
242
+
243
+## See Also
244
+
245
+- [npm install](/cli/v11/commands/npm-install)
246
+- [npm init](/cli/v11/commands/npm-init)
247
+- [npm config](/cli/v11/commands/npm-config)
248
+- [workspaces](/cli/v11/using-npm/workspaces)
content/cli/v11/commands/npm-prefix.mdx
new
+82
@@ -0,0 +1,82 @@
1
+---
2
+title: npm-prefix
3
+section: 1
4
+description: Display prefix
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-prefix.md
8
+redirect_from:
9
+ - /cli-commands/npm-prefix
10
+ - /cli-commands/prefix
11
+ - /cli-documentation/cli-commands/npm-prefix
12
+ - /cli-documentation/cli-commands/prefix
13
+ - /cli-documentation/commands/npm-prefix
14
+ - /cli-documentation/commands/prefix
15
+ - /cli-documentation/npm-prefix
16
+ - /cli-documentation/prefix
17
+ - /cli-documentation/v11/cli-commands/npm-prefix
18
+ - /cli-documentation/v11/cli-commands/prefix
19
+ - /cli-documentation/v11/commands/npm-prefix
20
+ - /cli-documentation/v11/commands/prefix
21
+ - /cli-documentation/v11/npm-prefix
22
+ - /cli-documentation/v11/prefix
23
+ - /cli/cli-commands/npm-prefix
24
+ - /cli/cli-commands/prefix
25
+ - /cli/commands/npm-prefix
26
+ - /cli/commands/prefix
27
+ - /cli/npm-prefix
28
+ - /cli/prefix
29
+ - /cli/v11/cli-commands/npm-prefix
30
+ - /cli/v11/cli-commands/prefix
31
+ - /cli/v11/commands/prefix
32
+ - /cli/v11/npm-prefix
33
+ - /cli/v11/prefix
34
+ - /commands/npm-prefix
35
+ - /commands/prefix
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm prefix
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+Print the local prefix to standard output. This is the closest parent directory to contain a `package.json` file or `node_modules` directory, unless `-g` is also specified.
49
+
50
+If `-g` is specified, this will be the value of the global prefix. See [`npm config`](/cli/v11/commands/npm-config) for more detail.
51
+
52
+### Example
53
+
54
+```bash
55
+npm prefix
56
+/usr/local/projects/foo
57
+```
58
+
59
+```bash
60
+npm prefix -g
61
+/usr/local
62
+```
63
+
64
+### Configuration
65
+
66
+#### `global`
67
+
68
+- Default: false
69
+- Type: Boolean
70
+
71
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
72
+
73
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
74
+- bin files are linked to `{prefix}/bin`
75
+- man pages are linked to `{prefix}/share/man`
76
+
77
+### See Also
78
+
79
+- [npm root](/cli/v11/commands/npm-root)
80
+- [npm folders](/cli/v11/configuring-npm/folders)
81
+- [npm config](/cli/v11/commands/npm-config)
82
+- [npmrc](/cli/v11/configuring-npm/npmrc)
content/cli/v11/commands/npm-profile.mdx
new
+127
@@ -0,0 +1,127 @@
1
+---
2
+title: npm-profile
3
+section: 1
4
+description: Change settings on your registry profile
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-profile.md
8
+redirect_from:
9
+ - /cli-commands/npm-profile
10
+ - /cli-commands/profile
11
+ - /cli-documentation/cli-commands/npm-profile
12
+ - /cli-documentation/cli-commands/profile
13
+ - /cli-documentation/commands/npm-profile
14
+ - /cli-documentation/commands/profile
15
+ - /cli-documentation/npm-profile
16
+ - /cli-documentation/profile
17
+ - /cli-documentation/v11/cli-commands/npm-profile
18
+ - /cli-documentation/v11/cli-commands/profile
19
+ - /cli-documentation/v11/commands/npm-profile
20
+ - /cli-documentation/v11/commands/profile
21
+ - /cli-documentation/v11/npm-profile
22
+ - /cli-documentation/v11/profile
23
+ - /cli/cli-commands/npm-profile
24
+ - /cli/cli-commands/profile
25
+ - /cli/commands/npm-profile
26
+ - /cli/commands/profile
27
+ - /cli/npm-profile
28
+ - /cli/profile
29
+ - /cli/v11/cli-commands/npm-profile
30
+ - /cli/v11/cli-commands/profile
31
+ - /cli/v11/commands/profile
32
+ - /cli/v11/npm-profile
33
+ - /cli/v11/profile
34
+ - /commands/npm-profile
35
+ - /commands/profile
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm profile enable-2fa [auth-only|auth-and-writes]
42
+npm profile disable-2fa
43
+npm profile get [<key>]
44
+npm profile set <key> <value>
45
+```
46
+
47
+Note: This command is unaware of workspaces.
48
+
49
+### Description
50
+
51
+Change your profile information on the registry. Note that this command depends on the registry implementation, so third-party registries may not support this interface.
52
+
53
+- `npm profile get [<property>]`: Display all of the properties of your profile, or one or more specific properties. It looks like:
54
+
55
+```
56
+name: example
57
+email: e@example.com (verified)
58
+two-factor auth: auth-and-writes
59
+fullname: Example User
60
+homepage:
61
+freenode:
62
+twitter:
63
+github:
64
+created: 2015-02-26T01:38:35.892Z
65
+updated: 2017-10-02T21:29:45.922Z
66
+```
67
+
68
+- `npm profile set <property> <value>`: Set the value of a profile property. You can set the following properties this way: email, fullname, homepage, freenode, twitter, github
69
+
70
+- `npm profile set password`: Change your password. This is interactive, you'll be prompted for your current password and a new password. You'll also be prompted for an OTP if you have two-factor authentication enabled.
71
+
72
+- `npm profile enable-2fa [auth-and-writes|auth-only]`: Enables two-factor authentication. Defaults to `auth-and-writes` mode. Modes are:
73
+
74
+ - `auth-only`: Require an OTP when logging in or making changes to your account's authentication. The OTP will be required on both the website and the command line.
75
+ - `auth-and-writes`: Requires an OTP at all the times `auth-only` does, and also requires one when publishing a module, setting the `latest` dist-tag, or changing access via `npm access` and `npm owner`.
76
+
77
+- `npm profile disable-2fa`: Disables two-factor authentication.
78
+
79
+### Details
80
+
81
+Some of these commands may not be available on non npmjs.com registries.
82
+
83
+### Configuration
84
+
85
+#### `registry`
86
+
87
+- Default: "https://registry.npmjs.org/"
88
+- Type: URL
89
+
90
+The base URL of the npm registry.
91
+
92
+#### `json`
93
+
94
+- Default: false
95
+- Type: Boolean
96
+
97
+Whether or not to output JSON data, rather than the normal output.
98
+
99
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
100
+
101
+Not supported by all npm commands.
102
+
103
+#### `parseable`
104
+
105
+- Default: false
106
+- Type: Boolean
107
+
108
+Output parseable results from commands that write to standard output. For `npm search`, this will be tab-separated table format.
109
+
110
+#### `otp`
111
+
112
+- Default: null
113
+- Type: null or String
114
+
115
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
116
+
117
+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.
118
+
119
+### See Also
120
+
121
+- [npm adduser](/cli/v11/commands/npm-adduser)
122
+- [npm registry](/cli/v11/using-npm/registry)
123
+- [npm config](/cli/v11/commands/npm-config)
124
+- [npmrc](/cli/v11/configuring-npm/npmrc)
125
+- [npm owner](/cli/v11/commands/npm-owner)
126
+- [npm whoami](/cli/v11/commands/npm-whoami)
127
+- [npm token](/cli/v11/commands/npm-token)
content/cli/v11/commands/npm-prune.mdx
new
+174
@@ -0,0 +1,174 @@
1
+---
2
+title: npm-prune
3
+section: 1
4
+description: Remove extraneous packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-prune.md
8
+redirect_from:
9
+ - /cli-commands/npm-prune
10
+ - /cli-commands/prune
11
+ - /cli-documentation/cli-commands/npm-prune
12
+ - /cli-documentation/cli-commands/prune
13
+ - /cli-documentation/commands/npm-prune
14
+ - /cli-documentation/commands/prune
15
+ - /cli-documentation/npm-prune
16
+ - /cli-documentation/prune
17
+ - /cli-documentation/v11/cli-commands/npm-prune
18
+ - /cli-documentation/v11/cli-commands/prune
19
+ - /cli-documentation/v11/commands/npm-prune
20
+ - /cli-documentation/v11/commands/prune
21
+ - /cli-documentation/v11/npm-prune
22
+ - /cli-documentation/v11/prune
23
+ - /cli/cli-commands/npm-prune
24
+ - /cli/cli-commands/prune
25
+ - /cli/commands/npm-prune
26
+ - /cli/commands/prune
27
+ - /cli/npm-prune
28
+ - /cli/prune
29
+ - /cli/v11/cli-commands/npm-prune
30
+ - /cli/v11/cli-commands/prune
31
+ - /cli/v11/commands/prune
32
+ - /cli/v11/npm-prune
33
+ - /cli/v11/prune
34
+ - /commands/npm-prune
35
+ - /commands/prune
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm prune [[<@scope>/]<pkg>...]
42
+```
43
+
44
+### Description
45
+
46
+This command removes "extraneous" packages. If a package name is provided, then only packages matching one of the supplied names are removed.
47
+
48
+Extraneous packages are those present in the `node_modules` folder that are not listed as any package's dependency list.
49
+
50
+If the `--omit=dev` flag is specified or the `NODE_ENV` environment variable is set to `production`, this command will remove the packages specified in your `devDependencies`.
51
+
52
+If the `--dry-run` flag is used then no changes will actually be made.
53
+
54
+If the `--json` flag is used, then the changes `npm prune` made (or would have made with `--dry-run`) are printed as a JSON object.
55
+
56
+In normal operation, extraneous modules are pruned automatically, so you'll only need this command with the `--production` flag. However, in the real world, operation is not always "normal". When crashes or mistakes happen, this command can help clean up any resulting garbage.
57
+
58
+### Configuration
59
+
60
+#### `omit`
61
+
62
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
63
+- Type: "dev", "optional", or "peer" (can be set multiple times)
64
+
65
+Dependency types to omit from the installation tree on disk.
66
+
67
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
68
+
69
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
70
+
71
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
72
+
73
+#### `include`
74
+
75
+- Default:
76
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
77
+
78
+Option that allows for defining which types of dependencies to install.
79
+
80
+This is the inverse of `--omit=<type>`.
81
+
82
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
83
+
84
+#### `dry-run`
85
+
86
+- Default: false
87
+- Type: Boolean
88
+
89
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
90
+
91
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
92
+
93
+#### `json`
94
+
95
+- Default: false
96
+- Type: Boolean
97
+
98
+Whether or not to output JSON data, rather than the normal output.
99
+
100
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
101
+
102
+Not supported by all npm commands.
103
+
104
+#### `foreground-scripts`
105
+
106
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
107
+- Type: Boolean
108
+
109
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
110
+
111
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
112
+
113
+#### `ignore-scripts`
114
+
115
+- Default: false
116
+- Type: Boolean
117
+
118
+If true, npm does not run scripts specified in package.json files.
119
+
120
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
121
+
122
+#### `workspace`
123
+
124
+- Default:
125
+- Type: String (can be set multiple times)
126
+
127
+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.
128
+
129
+Valid values for the `workspace` config are either:
130
+
131
+- Workspace names
132
+- Path to a workspace directory
133
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
134
+
135
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
136
+
137
+This value is not exported to the environment for child processes.
138
+
139
+#### `workspaces`
140
+
141
+- Default: null
142
+- Type: null or Boolean
143
+
144
+Set to true to run the command in the context of **all** configured workspaces.
145
+
146
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
147
+
148
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
149
+
150
+This value is not exported to the environment for child processes.
151
+
152
+#### `include-workspace-root`
153
+
154
+- Default: false
155
+- Type: Boolean
156
+
157
+Include the workspace root when workspaces are enabled for a command.
158
+
159
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
160
+
161
+This value is not exported to the environment for child processes.
162
+
163
+#### `install-links`
164
+
165
+- Default: false
166
+- Type: Boolean
167
+
168
+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.
169
+
170
+### See Also
171
+
172
+- [npm uninstall](/cli/v11/commands/npm-uninstall)
173
+- [npm folders](/cli/v11/configuring-npm/folders)
174
+- [npm ls](/cli/v11/commands/npm-ls)
content/cli/v11/commands/npm-publish.mdx
new
+202
@@ -0,0 +1,202 @@
1
+---
2
+title: npm-publish
3
+section: 1
4
+description: Publish a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-publish.md
8
+redirect_from:
9
+ - /cli-commands/npm-publish
10
+ - /cli-commands/publish
11
+ - /cli-documentation/cli-commands/npm-publish
12
+ - /cli-documentation/cli-commands/publish
13
+ - /cli-documentation/commands/npm-publish
14
+ - /cli-documentation/commands/publish
15
+ - /cli-documentation/npm-publish
16
+ - /cli-documentation/publish
17
+ - /cli-documentation/v11/cli-commands/npm-publish
18
+ - /cli-documentation/v11/cli-commands/publish
19
+ - /cli-documentation/v11/commands/npm-publish
20
+ - /cli-documentation/v11/commands/publish
21
+ - /cli-documentation/v11/npm-publish
22
+ - /cli-documentation/v11/publish
23
+ - /cli/cli-commands/npm-publish
24
+ - /cli/cli-commands/publish
25
+ - /cli/commands/npm-publish
26
+ - /cli/commands/publish
27
+ - /cli/npm-publish
28
+ - /cli/publish
29
+ - /cli/v11/cli-commands/npm-publish
30
+ - /cli/v11/cli-commands/publish
31
+ - /cli/v11/commands/publish
32
+ - /cli/v11/npm-publish
33
+ - /cli/v11/publish
34
+ - /commands/npm-publish
35
+ - /commands/publish
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm publish <package-spec>
42
+```
43
+
44
+### Description
45
+
46
+Publishes a package to the registry so that it can be installed by name.
47
+
48
+By default npm will publish to the public registry. This can be overridden by specifying a different default registry or using a [`scope`](/cli/v11/using-npm/scope) in the name, combined with a scope-configured registry (see [`package.json`](/cli/v11/configuring-npm/package-json)).
49
+
50
+A `package` is interpreted the same way as other commands (like `npm install`) and can be:
51
+
52
+- a) a folder containing a program described by a [`package.json`](/cli/v11/configuring-npm/package-json) file
53
+- b) a gzipped tarball containing (a)
54
+- c) a url that resolves to (b)
55
+- d) a `<name>@<version>` that is published on the registry (see [`registry`](/cli/v11/using-npm/registry)) with (c)
56
+- e) a `<name>@<tag>` (see [`npm dist-tag`](/cli/v11/commands/npm-dist-tag)) that points to (d)
57
+- f) a `<name>` that has a "latest" tag satisfying (e)
58
+- g) a `<git remote url>` that resolves to (a)
59
+
60
+The publish will fail if the package name and version combination already exists in the specified registry.
61
+
62
+Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with [`npm unpublish`](/cli/v11/commands/npm-unpublish).
63
+
64
+As of `npm@5`, both a sha1sum and an integrity field with a sha512sum of the tarball will be submitted to the registry during publication. Subsequent installs will use the strongest supported algorithm to verify downloads.
65
+
66
+Similar to `--dry-run` see [`npm pack`](/cli/v11/commands/npm-pack), which figures out the files to be included and packs them into a tarball to be uploaded to the registry.
67
+
68
+### Files included in package
69
+
70
+To see what will be included in your package, run `npm pack --dry-run`. All files are included by default, with the following exceptions:
71
+
72
+- Certain files that are relevant to package installation and distribution are always included. For example, `package.json`, `README.md`, `LICENSE`, and so on.
73
+
74
+- If there is a "files" list in [`package.json`](/cli/v11/configuring-npm/package-json), then only the files specified will be included. (If directories are specified, then they will be walked recursively and their contents included, subject to the same ignore rules.)
75
+
76
+- If there is a `.gitignore` or `.npmignore` file, then ignored files in that and all child directories will be excluded from the package. If _both_ files exist, then the `.gitignore` is ignored, and only the `.npmignore` is used.
77
+
78
+ `.npmignore` files follow the [same pattern rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring) as `.gitignore` files
79
+
80
+- If the file matches certain patterns, then it will _never_ be included, unless explicitly added to the `"files"` list in `package.json`, or un-ignored with a `!` rule in a `.npmignore` or `.gitignore` file.
81
+
82
+- Symbolic links are never included in npm packages.
83
+
84
+See [`developers`](/cli/v11/using-npm/developers) for full details on what's included in the published package, as well as details on how the package is built.
85
+
86
+See [`package.json`](/cli/v11/configuring-npm/package-json) for more info on what can and can't be ignored.
87
+
88
+### Configuration
89
+
90
+#### `tag`
91
+
92
+- Default: "latest"
93
+- Type: String
94
+
95
+If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag.
96
+
97
+It is the tag added to the package@version specified in the `npm dist-tag add` command, if no explicit tag is given.
98
+
99
+When used by the `npm diff` command, this is the tag used to fetch the tarball that will be compared with the local files by default.
100
+
101
+If used in the `npm publish` command, this is the tag that will be added to the package submitted to the registry.
102
+
103
+#### `access`
104
+
105
+- Default: 'public' for new packages, existing packages it will not change the current level
106
+- Type: null, "restricted", or "public"
107
+
108
+If you do not want your scoped package to be publicly viewable (and installable) set `--access=restricted`.
109
+
110
+Unscoped packages can not be set to `restricted`.
111
+
112
+Note: This defaults to not changing the current access level for existing packages. Specifying a value of `restricted` or `public` during publish will change the access for an existing package the same way that `npm access set status` would.
113
+
114
+#### `dry-run`
115
+
116
+- Default: false
117
+- Type: Boolean
118
+
119
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
120
+
121
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
122
+
123
+#### `otp`
124
+
125
+- Default: null
126
+- Type: null or String
127
+
128
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
129
+
130
+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.
131
+
132
+#### `workspace`
133
+
134
+- Default:
135
+- Type: String (can be set multiple times)
136
+
137
+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.
138
+
139
+Valid values for the `workspace` config are either:
140
+
141
+- Workspace names
142
+- Path to a workspace directory
143
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
144
+
145
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
146
+
147
+This value is not exported to the environment for child processes.
148
+
149
+#### `workspaces`
150
+
151
+- Default: null
152
+- Type: null or Boolean
153
+
154
+Set to true to run the command in the context of **all** configured workspaces.
155
+
156
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
157
+
158
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
159
+
160
+This value is not exported to the environment for child processes.
161
+
162
+#### `include-workspace-root`
163
+
164
+- Default: false
165
+- Type: Boolean
166
+
167
+Include the workspace root when workspaces are enabled for a command.
168
+
169
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
170
+
171
+This value is not exported to the environment for child processes.
172
+
173
+#### `provenance`
174
+
175
+- Default: false
176
+- Type: Boolean
177
+
178
+When publishing from a supported cloud CI/CD system, the package will be publicly linked to where it was built and published from.
179
+
180
+This config can not be used with: `provenance-file`
181
+
182
+#### `provenance-file`
183
+
184
+- Default: null
185
+- Type: Path
186
+
187
+When publishing, the provenance bundle at the given path will be used.
188
+
189
+This config can not be used with: `provenance`
190
+
191
+### See Also
192
+
193
+- [package spec](/cli/v11/using-npm/package-spec)
194
+- [npm-packlist package](http://npm.im/npm-packlist)
195
+- [npm registry](/cli/v11/using-npm/registry)
196
+- [npm scope](/cli/v11/using-npm/scope)
197
+- [npm adduser](/cli/v11/commands/npm-adduser)
198
+- [npm owner](/cli/v11/commands/npm-owner)
199
+- [npm deprecate](/cli/v11/commands/npm-deprecate)
200
+- [npm dist-tag](/cli/v11/commands/npm-dist-tag)
201
+- [npm pack](/cli/v11/commands/npm-pack)
202
+- [npm profile](/cli/v11/commands/npm-profile)
content/cli/v11/commands/npm-query.mdx
new
+272
@@ -0,0 +1,272 @@
1
+---
2
+title: npm-query
3
+section: 1
4
+description: Dependency selector query
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-query.md
8
+redirect_from:
9
+ - /cli-commands/npm-query
10
+ - /cli-commands/query
11
+ - /cli-documentation/cli-commands/npm-query
12
+ - /cli-documentation/cli-commands/query
13
+ - /cli-documentation/commands/npm-query
14
+ - /cli-documentation/commands/query
15
+ - /cli-documentation/npm-query
16
+ - /cli-documentation/query
17
+ - /cli-documentation/v11/cli-commands/npm-query
18
+ - /cli-documentation/v11/cli-commands/query
19
+ - /cli-documentation/v11/commands/npm-query
20
+ - /cli-documentation/v11/commands/query
21
+ - /cli-documentation/v11/npm-query
22
+ - /cli-documentation/v11/query
23
+ - /cli/cli-commands/npm-query
24
+ - /cli/cli-commands/query
25
+ - /cli/commands/npm-query
26
+ - /cli/commands/query
27
+ - /cli/npm-query
28
+ - /cli/query
29
+ - /cli/v11/cli-commands/npm-query
30
+ - /cli/v11/cli-commands/query
31
+ - /cli/v11/commands/query
32
+ - /cli/v11/npm-query
33
+ - /cli/v11/query
34
+ - /commands/npm-query
35
+ - /commands/query
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm query <selector>
42
+```
43
+
44
+### Description
45
+
46
+The `npm query` command allows for usage of css selectors in order to retrieve an array of dependency objects.
47
+
48
+### Piping npm query to other commands
49
+
50
+```bash
51
+# find all dependencies with postinstall scripts & uninstall them
52
+npm query ":attr(scripts, [postinstall])" | jq 'map(.name)|join("\n")' -r | xargs -I {} npm uninstall {}
53
+
54
+# find all git dependencies & explain who requires them
55
+npm query ":type(git)" | jq 'map(.name)' | xargs -I {} npm why {}
56
+```
57
+
58
+### Extended Use Cases & Queries
59
+
60
+```stylus
61
+// all deps
62
+*
63
+
64
+// all direct deps
65
+:root > *
66
+
67
+// direct production deps
68
+:root > .prod
69
+
70
+// direct development deps
71
+:root > .dev
72
+
73
+// any peer dep of a direct deps
74
+:root > * > .peer
75
+
76
+// any workspace dep
77
+.workspace
78
+
79
+// all workspaces that depend on another workspace
80
+.workspace > .workspace
81
+
82
+// all workspaces that have peer deps
83
+.workspace:has(.peer)
84
+
85
+// any dep named "lodash"
86
+// equivalent to [name="lodash"]
87
+#lodash
88
+
89
+// any deps named "lodash" & within semver range ^"1.2.3"
90
+#lodash@^1.2.3
91
+// equivalent to...
92
+[name="lodash"]:semver(^1.2.3)
93
+
94
+// get the hoisted node for a given semver range
95
+#lodash@^1.2.3:not(:deduped)
96
+
97
+// querying deps with a specific version
98
+#lodash@2.1.5
99
+// equivalent to...
100
+[name="lodash"][version="2.1.5"]
101
+
102
+// has any deps
103
+:has(*)
104
+
105
+// deps with no other deps (ie. "leaf" nodes)
106
+:empty
107
+
108
+// manually querying git dependencies
109
+[repository^=github:],
110
+[repository^=git:],
111
+[repository^=https://github.com],
112
+[repository^=http://github.com],
113
+[repository^=https://github.com],
114
+[repository^=+git:...]
115
+
116
+// querying for all git dependencies
117
+:type(git)
118
+
119
+// get production dependencies that aren't also dev deps
120
+.prod:not(.dev)
121
+
122
+// get dependencies with specific licenses
123
+[license=MIT], [license=ISC]
124
+
125
+// find all packages that have @ruyadorno as a contributor
126
+:attr(contributors, [email=ruyadorno@github.com])
127
+```
128
+
129
+### Example Response Output
130
+
131
+- an array of dependency objects is returned which can contain multiple copies of the same package which may or may not have been linked or deduped
132
+
133
+```json
134
+[
135
+ {
136
+ "name": "",
137
+ "version": "",
138
+ "description": "",
139
+ "homepage": "",
140
+ "bugs": {},
141
+ "author": {},
142
+ "license": {},
143
+ "funding": {},
144
+ "files": [],
145
+ "main": "",
146
+ "browser": "",
147
+ "bin": {},
148
+ "man": [],
149
+ "directories": {},
150
+ "repository": {},
151
+ "scripts": {},
152
+ "config": {},
153
+ "dependencies": {},
154
+ "devDependencies": {},
155
+ "optionalDependencies": {},
156
+ "bundledDependencies": {},
157
+ "peerDependencies": {},
158
+ "peerDependenciesMeta": {},
159
+ "engines": {},
160
+ "os": [],
161
+ "cpu": [],
162
+ "workspaces": {},
163
+ "keywords": [],
164
+ ...
165
+ },
166
+ ...
167
+```
168
+
169
+### Expecting a certain number of results
170
+
171
+One common use of `npm query` is to make sure there is only one version of a certain dependency in your tree. This is especially common for ecosystems like that rely on `typescript` where having state split across two different but identically-named packages causes bugs. You can use the `--expect-results` or `--expect-result-count` in your setup to ensure that npm will exit with an exit code if your tree doesn't look like you want it to.
172
+
173
+```sh
174
+$ npm query '#react' --expect-result-count=1
175
+```
176
+
177
+Perhaps you want to quickly check if there are any production dependencies that could be updated:
178
+
179
+```sh
180
+$ npm query ':root>:outdated(in-range).prod' --no-expect-results
181
+```
182
+
183
+### Package lock only mode
184
+
185
+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).
186
+
187
+### Configuration
188
+
189
+#### `global`
190
+
191
+- Default: false
192
+- Type: Boolean
193
+
194
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
195
+
196
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
197
+- bin files are linked to `{prefix}/bin`
198
+- man pages are linked to `{prefix}/share/man`
199
+
200
+#### `workspace`
201
+
202
+- Default:
203
+- Type: String (can be set multiple times)
204
+
205
+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.
206
+
207
+Valid values for the `workspace` config are either:
208
+
209
+- Workspace names
210
+- Path to a workspace directory
211
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
212
+
213
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
214
+
215
+This value is not exported to the environment for child processes.
216
+
217
+#### `workspaces`
218
+
219
+- Default: null
220
+- Type: null or Boolean
221
+
222
+Set to true to run the command in the context of **all** configured workspaces.
223
+
224
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
225
+
226
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
227
+
228
+This value is not exported to the environment for child processes.
229
+
230
+#### `include-workspace-root`
231
+
232
+- Default: false
233
+- Type: Boolean
234
+
235
+Include the workspace root when workspaces are enabled for a command.
236
+
237
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
238
+
239
+This value is not exported to the environment for child processes.
240
+
241
+#### `package-lock-only`
242
+
243
+- Default: false
244
+- Type: Boolean
245
+
246
+If set to true, the current operation will only use the `package-lock.json`, ignoring `node_modules`.
247
+
248
+For `update` this means only the `package-lock.json` will be updated, instead of checking `node_modules` and downloading dependencies.
249
+
250
+For `list` this means the output will be based on the tree described by the `package-lock.json`, rather than the contents of `node_modules`.
251
+
252
+#### `expect-results`
253
+
254
+- Default: null
255
+- Type: null or Boolean
256
+
257
+Tells npm whether or not to expect results from the command. Can be either true (expect some results) or false (expect no results).
258
+
259
+This config can not be used with: `expect-result-count`
260
+
261
+#### `expect-result-count`
262
+
263
+- Default: null
264
+- Type: null or Number
265
+
266
+Tells to expect a specific number of results from the command.
267
+
268
+This config can not be used with: `expect-results`
269
+
270
+## See Also
271
+
272
+- [dependency selectors](/cli/v11/using-npm/dependency-selectors)
content/cli/v11/commands/npm-rebuild.mdx
new
+163
@@ -0,0 +1,163 @@
1
+---
2
+title: npm-rebuild
3
+section: 1
4
+description: Rebuild a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-rebuild.md
8
+redirect_from:
9
+ - /cli-commands/npm-rebuild
10
+ - /cli-commands/rebuild
11
+ - /cli-documentation/cli-commands/npm-rebuild
12
+ - /cli-documentation/cli-commands/rebuild
13
+ - /cli-documentation/commands/npm-rebuild
14
+ - /cli-documentation/commands/rebuild
15
+ - /cli-documentation/npm-rebuild
16
+ - /cli-documentation/rebuild
17
+ - /cli-documentation/v11/cli-commands/npm-rebuild
18
+ - /cli-documentation/v11/cli-commands/rebuild
19
+ - /cli-documentation/v11/commands/npm-rebuild
20
+ - /cli-documentation/v11/commands/rebuild
21
+ - /cli-documentation/v11/npm-rebuild
22
+ - /cli-documentation/v11/rebuild
23
+ - /cli/cli-commands/npm-rebuild
24
+ - /cli/cli-commands/rebuild
25
+ - /cli/commands/npm-rebuild
26
+ - /cli/commands/rebuild
27
+ - /cli/npm-rebuild
28
+ - /cli/rebuild
29
+ - /cli/v11/cli-commands/npm-rebuild
30
+ - /cli/v11/cli-commands/rebuild
31
+ - /cli/v11/commands/rebuild
32
+ - /cli/v11/npm-rebuild
33
+ - /cli/v11/rebuild
34
+ - /commands/npm-rebuild
35
+ - /commands/rebuild
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm rebuild [<package-spec>] ...]
42
+
43
+alias: rb
44
+```
45
+
46
+### Description
47
+
48
+This command does the following:
49
+
50
+1. Execute lifecycle scripts (`preinstall`, `install`, `postinstall`, `prepare`)
51
+2. Links bins depending on whether bin links are enabled
52
+
53
+This command is particularly useful in scenarios including but not limited to:
54
+
55
+1. Installing a new version of **node.js**, where you need to recompile all your C++ add-ons with the updated binary.
56
+2. Installing with `--ignore-scripts` and `--no-bin-links`, to explicitly choose which packages to build and/or link bins.
57
+
58
+If one or more package specs are provided, then only packages with a name and version matching one of the specifiers will be rebuilt.
59
+
60
+Usually, you should not need to run `npm rebuild` as it is already done for you as part of npm install (unless you suppressed these steps with `--ignore-scripts` or `--no-bin-links`).
61
+
62
+If there is a `binding.gyp` file in the root of your package, then npm will use a default install hook:
63
+
64
+```
65
+"scripts": {
66
+ "install": "node-gyp rebuild"
67
+}
68
+```
69
+
70
+This default behavior is suppressed if the `package.json` has its own `install` or `preinstall` scripts. It is also suppressed if the package specifies `"gypfile": false`
71
+
72
+### Configuration
73
+
74
+#### `global`
75
+
76
+- Default: false
77
+- Type: Boolean
78
+
79
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
80
+
81
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
82
+- bin files are linked to `{prefix}/bin`
83
+- man pages are linked to `{prefix}/share/man`
84
+
85
+#### `bin-links`
86
+
87
+- Default: true
88
+- Type: Boolean
89
+
90
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
91
+
92
+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.
93
+
94
+#### `foreground-scripts`
95
+
96
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
97
+- Type: Boolean
98
+
99
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
100
+
101
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
102
+
103
+#### `ignore-scripts`
104
+
105
+- Default: false
106
+- Type: Boolean
107
+
108
+If true, npm does not run scripts specified in package.json files.
109
+
110
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
111
+
112
+#### `workspace`
113
+
114
+- Default:
115
+- Type: String (can be set multiple times)
116
+
117
+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.
118
+
119
+Valid values for the `workspace` config are either:
120
+
121
+- Workspace names
122
+- Path to a workspace directory
123
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
124
+
125
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
126
+
127
+This value is not exported to the environment for child processes.
128
+
129
+#### `workspaces`
130
+
131
+- Default: null
132
+- Type: null or Boolean
133
+
134
+Set to true to run the command in the context of **all** configured workspaces.
135
+
136
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
137
+
138
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
139
+
140
+This value is not exported to the environment for child processes.
141
+
142
+#### `include-workspace-root`
143
+
144
+- Default: false
145
+- Type: Boolean
146
+
147
+Include the workspace root when workspaces are enabled for a command.
148
+
149
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
150
+
151
+This value is not exported to the environment for child processes.
152
+
153
+#### `install-links`
154
+
155
+- Default: false
156
+- Type: Boolean
157
+
158
+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.
159
+
160
+### See Also
161
+
162
+- [package spec](/cli/v11/using-npm/package-spec)
163
+- [npm install](/cli/v11/commands/npm-install)
content/cli/v11/commands/npm-repo.mdx
new
+112
@@ -0,0 +1,112 @@
1
+---
2
+title: npm-repo
3
+section: 1
4
+description: Open package repository page in the browser
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-repo.md
8
+redirect_from:
9
+ - /cli-commands/npm-repo
10
+ - /cli-commands/repo
11
+ - /cli-documentation/cli-commands/npm-repo
12
+ - /cli-documentation/cli-commands/repo
13
+ - /cli-documentation/commands/npm-repo
14
+ - /cli-documentation/commands/repo
15
+ - /cli-documentation/npm-repo
16
+ - /cli-documentation/repo
17
+ - /cli-documentation/v11/cli-commands/npm-repo
18
+ - /cli-documentation/v11/cli-commands/repo
19
+ - /cli-documentation/v11/commands/npm-repo
20
+ - /cli-documentation/v11/commands/repo
21
+ - /cli-documentation/v11/npm-repo
22
+ - /cli-documentation/v11/repo
23
+ - /cli/cli-commands/npm-repo
24
+ - /cli/cli-commands/repo
25
+ - /cli/commands/npm-repo
26
+ - /cli/commands/repo
27
+ - /cli/npm-repo
28
+ - /cli/repo
29
+ - /cli/v11/cli-commands/npm-repo
30
+ - /cli/v11/cli-commands/repo
31
+ - /cli/v11/commands/repo
32
+ - /cli/v11/npm-repo
33
+ - /cli/v11/repo
34
+ - /commands/npm-repo
35
+ - /commands/repo
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm repo [<pkgname> [<pkgname> ...]]
42
+```
43
+
44
+### Description
45
+
46
+This command tries to guess at the likely location of a package's repository URL, and then tries to open it using the [`--browser` config](/cli/v11/using-npm/config#browser) param. If no package name is provided, it will search for a `package.json` in the current folder and use the `repository` property.
47
+
48
+### Configuration
49
+
50
+#### `browser`
51
+
52
+- Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
53
+- Type: null, Boolean, or String
54
+
55
+The browser that is called by npm commands to open websites.
56
+
57
+Set to `false` to suppress browser behavior and instead print urls to terminal.
58
+
59
+Set to `true` to use default system URL opener.
60
+
61
+#### `registry`
62
+
63
+- Default: "https://registry.npmjs.org/"
64
+- Type: URL
65
+
66
+The base URL of the npm registry.
67
+
68
+#### `workspace`
69
+
70
+- Default:
71
+- Type: String (can be set multiple times)
72
+
73
+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.
74
+
75
+Valid values for the `workspace` config are either:
76
+
77
+- Workspace names
78
+- Path to a workspace directory
79
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
80
+
81
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
82
+
83
+This value is not exported to the environment for child processes.
84
+
85
+#### `workspaces`
86
+
87
+- Default: null
88
+- Type: null or Boolean
89
+
90
+Set to true to run the command in the context of **all** configured workspaces.
91
+
92
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
93
+
94
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
95
+
96
+This value is not exported to the environment for child processes.
97
+
98
+#### `include-workspace-root`
99
+
100
+- Default: false
101
+- Type: Boolean
102
+
103
+Include the workspace root when workspaces are enabled for a command.
104
+
105
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
106
+
107
+This value is not exported to the environment for child processes.
108
+
109
+### See Also
110
+
111
+- [npm docs](/cli/v11/commands/npm-docs)
112
+- [npm config](/cli/v11/commands/npm-config)
content/cli/v11/commands/npm-restart.mdx
new
+90
@@ -0,0 +1,90 @@
1
+---
2
+title: npm-restart
3
+section: 1
4
+description: Restart a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-restart.md
8
+redirect_from:
9
+ - /cli-commands/npm-restart
10
+ - /cli-commands/restart
11
+ - /cli-documentation/cli-commands/npm-restart
12
+ - /cli-documentation/cli-commands/restart
13
+ - /cli-documentation/commands/npm-restart
14
+ - /cli-documentation/commands/restart
15
+ - /cli-documentation/npm-restart
16
+ - /cli-documentation/restart
17
+ - /cli-documentation/v11/cli-commands/npm-restart
18
+ - /cli-documentation/v11/cli-commands/restart
19
+ - /cli-documentation/v11/commands/npm-restart
20
+ - /cli-documentation/v11/commands/restart
21
+ - /cli-documentation/v11/npm-restart
22
+ - /cli-documentation/v11/restart
23
+ - /cli/cli-commands/npm-restart
24
+ - /cli/cli-commands/restart
25
+ - /cli/commands/npm-restart
26
+ - /cli/commands/restart
27
+ - /cli/npm-restart
28
+ - /cli/restart
29
+ - /cli/v11/cli-commands/npm-restart
30
+ - /cli/v11/cli-commands/restart
31
+ - /cli/v11/commands/restart
32
+ - /cli/v11/npm-restart
33
+ - /cli/v11/restart
34
+ - /commands/npm-restart
35
+ - /commands/restart
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm restart [-- <args>]
42
+```
43
+
44
+### Description
45
+
46
+This restarts a project. It is equivalent to running `npm run-script restart`.
47
+
48
+If the current project has a `"restart"` script specified in `package.json`, then the following scripts will be run:
49
+
50
+1. prerestart
51
+2. restart
52
+3. postrestart
53
+
54
+If it does _not_ have a `"restart"` script specified, but it does have `stop` and/or `start` scripts, then the following scripts will be run:
55
+
56
+1. prerestart
57
+2. prestop
58
+3. stop
59
+4. poststop
60
+5. prestart
61
+6. start
62
+7. poststart
63
+8. postrestart
64
+
65
+### Configuration
66
+
67
+#### `ignore-scripts`
68
+
69
+- Default: false
70
+- Type: Boolean
71
+
72
+If true, npm does not run scripts specified in package.json files.
73
+
74
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
75
+
76
+#### `script-shell`
77
+
78
+- Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
79
+- Type: null or String
80
+
81
+The shell to use for scripts run with the `npm exec`, `npm run` and `npm init <package-spec>` commands.
82
+
83
+### See Also
84
+
85
+- [npm run-script](/cli/v11/commands/npm-run-script)
86
+- [npm scripts](/cli/v11/using-npm/scripts)
87
+- [npm test](/cli/v11/commands/npm-test)
88
+- [npm start](/cli/v11/commands/npm-start)
89
+- [npm stop](/cli/v11/commands/npm-stop)
90
+- [npm restart](/cli/v11/commands/npm-restart)
content/cli/v11/commands/npm-root.mdx
new
+76
@@ -0,0 +1,76 @@
1
+---
2
+title: npm-root
3
+section: 1
4
+description: Display npm root
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-root.md
8
+redirect_from:
9
+ - /cli-commands/npm-root
10
+ - /cli-commands/root
11
+ - /cli-documentation/cli-commands/npm-root
12
+ - /cli-documentation/cli-commands/root
13
+ - /cli-documentation/commands/npm-root
14
+ - /cli-documentation/commands/root
15
+ - /cli-documentation/npm-root
16
+ - /cli-documentation/root
17
+ - /cli-documentation/v11/cli-commands/npm-root
18
+ - /cli-documentation/v11/cli-commands/root
19
+ - /cli-documentation/v11/commands/npm-root
20
+ - /cli-documentation/v11/commands/root
21
+ - /cli-documentation/v11/npm-root
22
+ - /cli-documentation/v11/root
23
+ - /cli/cli-commands/npm-root
24
+ - /cli/cli-commands/root
25
+ - /cli/commands/npm-root
26
+ - /cli/commands/root
27
+ - /cli/npm-root
28
+ - /cli/root
29
+ - /cli/v11/cli-commands/npm-root
30
+ - /cli/v11/cli-commands/root
31
+ - /cli/v11/commands/root
32
+ - /cli/v11/npm-root
33
+ - /cli/v11/root
34
+ - /commands/npm-root
35
+ - /commands/root
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm root
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+Print the effective `node_modules` folder to standard out.
49
+
50
+Useful for using npm in shell scripts that do things with the `node_modules` folder. For example:
51
+
52
+```bash
53
+#!/bin/bash
54
+global_node_modules="$(npm root --global)"
55
+echo "Global packages installed in: ${global_node_modules}"
56
+```
57
+
58
+### Configuration
59
+
60
+#### `global`
61
+
62
+- Default: false
63
+- Type: Boolean
64
+
65
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
66
+
67
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
68
+- bin files are linked to `{prefix}/bin`
69
+- man pages are linked to `{prefix}/share/man`
70
+
71
+### See Also
72
+
73
+- [npm prefix](/cli/v11/commands/npm-prefix)
74
+- [npm folders](/cli/v11/configuring-npm/folders)
75
+- [npm config](/cli/v11/commands/npm-config)
76
+- [npmrc](/cli/v11/configuring-npm/npmrc)
content/cli/v11/commands/npm-run-script.mdx
new
+217
@@ -0,0 +1,217 @@
1
+---
2
+title: npm-run-script
3
+section: 1
4
+description: Run arbitrary package scripts
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-run-script.md
8
+redirect_from:
9
+ - /cli-commands/npm-run-script
10
+ - /cli-commands/run-script
11
+ - /cli-documentation/cli-commands/npm-run-script
12
+ - /cli-documentation/cli-commands/run-script
13
+ - /cli-documentation/commands/npm-run-script
14
+ - /cli-documentation/commands/run-script
15
+ - /cli-documentation/npm-run-script
16
+ - /cli-documentation/run-script
17
+ - /cli-documentation/v11/cli-commands/npm-run-script
18
+ - /cli-documentation/v11/cli-commands/run-script
19
+ - /cli-documentation/v11/commands/npm-run-script
20
+ - /cli-documentation/v11/commands/run-script
21
+ - /cli-documentation/v11/npm-run-script
22
+ - /cli-documentation/v11/run-script
23
+ - /cli/cli-commands/npm-run-script
24
+ - /cli/cli-commands/run-script
25
+ - /cli/commands/npm-run-script
26
+ - /cli/commands/run-script
27
+ - /cli/npm-run-script
28
+ - /cli/run-script
29
+ - /cli/v11/cli-commands/npm-run-script
30
+ - /cli/v11/cli-commands/run-script
31
+ - /cli/v11/commands/run-script
32
+ - /cli/v11/npm-run-script
33
+ - /cli/v11/run-script
34
+ - /commands/npm-run-script
35
+ - /commands/run-script
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm run-script <command> [-- <args>]
42
+
43
+aliases: run, rum, urn
44
+```
45
+
46
+### Description
47
+
48
+This runs an arbitrary command from a package's `"scripts"` object. If no `"command"` is provided, it will list the available scripts.
49
+
50
+`run[-script]` is used by the test, start, restart, and stop commands, but can be called directly, as well. When the scripts in the package are printed out, they're separated into lifecycle (test, start, restart) and directly-run scripts.
51
+
52
+Any positional arguments are passed to the specified script. Use `--` to pass `-`-prefixed flags and options which would otherwise be parsed by npm.
53
+
54
+For example:
55
+
56
+```bash
57
+npm run test -- --grep="pattern"
58
+```
59
+
60
+The arguments will only be passed to the script specified after `npm run` and not to any `pre` or `post` script.
61
+
62
+The `env` script is a special built-in command that can be used to list environment variables that will be available to the script at runtime. If an "env" command is defined in your package, it will take precedence over the built-in.
63
+
64
+In addition to the shell's pre-existing `PATH`, `npm run` adds `node_modules/.bin` to the `PATH` provided to scripts. Any binaries provided by locally-installed dependencies can be used without the `node_modules/.bin` prefix. For example, if there is a `devDependency` on `tap` in your package, you should write:
65
+
66
+```bash
67
+"scripts": {"test": "tap test/*.js"}
68
+```
69
+
70
+instead of
71
+
72
+```bash
73
+"scripts": {"test": "node_modules/.bin/tap test/*.js"}
74
+```
75
+
76
+The actual shell your script is run within is platform dependent. By default, on Unix-like systems it is the `/bin/sh` command, on Windows it is `cmd.exe`. The actual shell referred to by `/bin/sh` also depends on the system. You can customize the shell with the [`script-shell` config](/cli/v11/using-npm/config#script-shell).
77
+
78
+Scripts are run from the root of the package folder, regardless of what the current working directory is when `npm run` is called. If you want your script to use different behavior based on what subdirectory you're in, you can use the `INIT_CWD` environment variable, which holds the full path you were in when you ran `npm run`.
79
+
80
+`npm run` sets the `NODE` environment variable to the `node` executable with which `npm` is executed.
81
+
82
+If you try to run a script without having a `node_modules` directory and it fails, you will be given a warning to run `npm install`, just in case you've forgotten.
83
+
84
+### Workspaces support
85
+
86
+You may use the [`workspace`](/cli/v11/using-npm/config#workspace) or [`workspaces`](/cli/v11/using-npm/config#workspaces) configs in order to run an arbitrary command from a package's `"scripts"` object in the context of the specified workspaces. If no `"command"` is provided, it will list the available scripts for each of these configured workspaces.
87
+
88
+Given a project with configured workspaces, e.g:
89
+
90
+```
91
+.
92
++-- package.json
93
+`-- packages
94
+ +-- a
95
+ | `-- package.json
96
+ +-- b
97
+ | `-- package.json
98
+ `-- c
99
+ `-- package.json
100
+```
101
+
102
+Assuming the workspace configuration is properly set up at the root level `package.json` file. e.g:
103
+
104
+```
105
+{
106
+ "workspaces": [ "./packages/*" ]
107
+}
108
+```
109
+
110
+And that each of the configured workspaces has a configured `test` script, we can run tests in all of them using the [`workspaces` config](/cli/v11/using-npm/config#workspaces):
111
+
112
+```
113
+npm test --workspaces
114
+```
115
+
116
+#### Filtering workspaces
117
+
118
+It's also possible to run a script in a single workspace using the `workspace` config along with a name or directory path:
119
+
120
+```
121
+npm test --workspace=a
122
+```
123
+
124
+The `workspace` config can also be specified multiple times in order to run a specific script in the context of multiple workspaces. When defining values for the `workspace` config in the command line, it also possible to use `-w` as a shorthand, e.g:
125
+
126
+```
127
+npm test -w a -w b
128
+```
129
+
130
+This last command will run `test` in both `./packages/a` and `./packages/b` packages.
131
+
132
+### Configuration
133
+
134
+#### `workspace`
135
+
136
+- Default:
137
+- Type: String (can be set multiple times)
138
+
139
+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.
140
+
141
+Valid values for the `workspace` config are either:
142
+
143
+- Workspace names
144
+- Path to a workspace directory
145
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
146
+
147
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
148
+
149
+This value is not exported to the environment for child processes.
150
+
151
+#### `workspaces`
152
+
153
+- Default: null
154
+- Type: null or Boolean
155
+
156
+Set to true to run the command in the context of **all** configured workspaces.
157
+
158
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
159
+
160
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
161
+
162
+This value is not exported to the environment for child processes.
163
+
164
+#### `include-workspace-root`
165
+
166
+- Default: false
167
+- Type: Boolean
168
+
169
+Include the workspace root when workspaces are enabled for a command.
170
+
171
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
172
+
173
+This value is not exported to the environment for child processes.
174
+
175
+#### `if-present`
176
+
177
+- Default: false
178
+- Type: Boolean
179
+
180
+If true, npm will not exit with an error code when `run-script` is invoked for a script that isn't defined in the `scripts` section of `package.json`. This option can be used when it's desirable to optionally run a script when it's present and fail if the script fails. This is useful, for example, when running scripts that may only apply for some builds in an otherwise generic CI setup.
181
+
182
+This value is not exported to the environment for child processes.
183
+
184
+#### `ignore-scripts`
185
+
186
+- Default: false
187
+- Type: Boolean
188
+
189
+If true, npm does not run scripts specified in package.json files.
190
+
191
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
192
+
193
+#### `foreground-scripts`
194
+
195
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
196
+- Type: Boolean
197
+
198
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
199
+
200
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
201
+
202
+#### `script-shell`
203
+
204
+- Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
205
+- Type: null or String
206
+
207
+The shell to use for scripts run with the `npm exec`, `npm run` and `npm init <package-spec>` commands.
208
+
209
+### See Also
210
+
211
+- [npm scripts](/cli/v11/using-npm/scripts)
212
+- [npm test](/cli/v11/commands/npm-test)
213
+- [npm start](/cli/v11/commands/npm-start)
214
+- [npm restart](/cli/v11/commands/npm-restart)
215
+- [npm stop](/cli/v11/commands/npm-stop)
216
+- [npm config](/cli/v11/commands/npm-config)
217
+- [npm workspaces](/cli/v11/using-npm/workspaces)
content/cli/v11/commands/npm-sbom.mdx
new
+311
@@ -0,0 +1,311 @@
1
+---
2
+title: npm-sbom
3
+section: 1
4
+description: Generate a Software Bill of Materials (SBOM)
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-sbom.md
8
+redirect_from:
9
+ - /cli-commands/npm-sbom
10
+ - /cli-commands/sbom
11
+ - /cli-documentation/cli-commands/npm-sbom
12
+ - /cli-documentation/cli-commands/sbom
13
+ - /cli-documentation/commands/npm-sbom
14
+ - /cli-documentation/commands/sbom
15
+ - /cli-documentation/npm-sbom
16
+ - /cli-documentation/sbom
17
+ - /cli-documentation/v11/cli-commands/npm-sbom
18
+ - /cli-documentation/v11/cli-commands/sbom
19
+ - /cli-documentation/v11/commands/npm-sbom
20
+ - /cli-documentation/v11/commands/sbom
21
+ - /cli-documentation/v11/npm-sbom
22
+ - /cli-documentation/v11/sbom
23
+ - /cli/cli-commands/npm-sbom
24
+ - /cli/cli-commands/sbom
25
+ - /cli/commands/npm-sbom
26
+ - /cli/commands/sbom
27
+ - /cli/npm-sbom
28
+ - /cli/sbom
29
+ - /cli/v11/cli-commands/npm-sbom
30
+ - /cli/v11/cli-commands/sbom
31
+ - /cli/v11/commands/sbom
32
+ - /cli/v11/npm-sbom
33
+ - /cli/v11/sbom
34
+ - /commands/npm-sbom
35
+ - /commands/sbom
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm sbom
42
+```
43
+
44
+### Description
45
+
46
+The `npm sbom` command generates a Software Bill of Materials (SBOM) listing the dependencies for the current project. SBOMs can be generated in either [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/) format.
47
+
48
+### Example CycloneDX SBOM
49
+
50
+```json
51
+{
52
+ "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
53
+ "bomFormat": "CycloneDX",
54
+ "specVersion": "1.5",
55
+ "serialNumber": "urn:uuid:09f55116-97e1-49cf-b3b8-44d0207e7730",
56
+ "version": 1,
57
+ "metadata": {
58
+ "timestamp": "2023-09-01T00:00:00.001Z",
59
+ "lifecycles": [
60
+ {
61
+ "phase": "build"
62
+ }
63
+ ],
64
+ "tools": [
65
+ {
66
+ "vendor": "npm",
67
+ "name": "cli",
68
+ "version": "10.1.0"
69
+ }
70
+ ],
71
+ "component": {
72
+ "bom-ref": "simple@1.0.0",
73
+ "type": "library",
74
+ "name": "simple",
75
+ "version": "1.0.0",
76
+ "scope": "required",
77
+ "author": "John Doe",
78
+ "description": "simple react app",
79
+ "purl": "pkg:npm/simple@1.0.0",
80
+ "properties": [
81
+ {
82
+ "name": "cdx:npm:package:path",
83
+ "value": ""
84
+ }
85
+ ],
86
+ "externalReferences": [],
87
+ "licenses": [
88
+ {
89
+ "license": {
90
+ "id": "MIT"
91
+ }
92
+ }
93
+ ]
94
+ }
95
+ },
96
+ "components": [
97
+ {
98
+ "bom-ref": "lodash@4.17.21",
99
+ "type": "library",
100
+ "name": "lodash",
101
+ "version": "4.17.21",
102
+ "scope": "required",
103
+ "author": "John-David Dalton",
104
+ "description": "Lodash modular utilities.",
105
+ "purl": "pkg:npm/lodash@4.17.21",
106
+ "properties": [
107
+ {
108
+ "name": "cdx:npm:package:path",
109
+ "value": "node_modules/lodash"
110
+ }
111
+ ],
112
+ "externalReferences": [
113
+ {
114
+ "type": "distribution",
115
+ "url": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz"
116
+ },
117
+ {
118
+ "type": "vcs",
119
+ "url": "git+https://github.com/lodash/lodash.git"
120
+ },
121
+ {
122
+ "type": "website",
123
+ "url": "https://lodash.com/"
124
+ },
125
+ {
126
+ "type": "issue-tracker",
127
+ "url": "https://github.com/lodash/lodash/issues"
128
+ }
129
+ ],
130
+ "hashes": [
131
+ {
132
+ "alg": "SHA-512",
133
+ "content": "bf690311ee7b95e713ba568322e3533f2dd1cb880b189e99d4edef13592b81764daec43e2c54c61d5c558dc5cfb35ecb85b65519e74026ff17675b6f8f916f4a"
134
+ }
135
+ ],
136
+ "licenses": [
137
+ {
138
+ "license": {
139
+ "id": "MIT"
140
+ }
141
+ }
142
+ ]
143
+ }
144
+ ],
145
+ "dependencies": [
146
+ {
147
+ "ref": "simple@1.0.0",
148
+ "dependsOn": ["lodash@4.17.21"]
149
+ },
150
+ {
151
+ "ref": "lodash@4.17.21",
152
+ "dependsOn": []
153
+ }
154
+ ]
155
+}
156
+```
157
+
158
+### Example SPDX SBOM
159
+
160
+```json
161
+{
162
+ "spdxVersion": "SPDX-2.3",
163
+ "dataLicense": "CC0-1.0",
164
+ "SPDXID": "SPDXRef-DOCUMENT",
165
+ "name": "simple@1.0.0",
166
+ "documentNamespace": "http://spdx.org/spdxdocs/simple-1.0.0-bf81090e-8bbc-459d-bec9-abeb794e096a",
167
+ "creationInfo": {
168
+ "created": "2023-09-01T00:00:00.001Z",
169
+ "creators": ["Tool: npm/cli-10.1.0"]
170
+ },
171
+ "documentDescribes": ["SPDXRef-Package-simple-1.0.0"],
172
+ "packages": [
173
+ {
174
+ "name": "simple",
175
+ "SPDXID": "SPDXRef-Package-simple-1.0.0",
176
+ "versionInfo": "1.0.0",
177
+ "packageFileName": "",
178
+ "description": "simple react app",
179
+ "primaryPackagePurpose": "LIBRARY",
180
+ "downloadLocation": "NOASSERTION",
181
+ "filesAnalyzed": false,
182
+ "homepage": "NOASSERTION",
183
+ "licenseDeclared": "MIT",
184
+ "externalRefs": [
185
+ {
186
+ "referenceCategory": "PACKAGE-MANAGER",
187
+ "referenceType": "purl",
188
+ "referenceLocator": "pkg:npm/simple@1.0.0"
189
+ }
190
+ ]
191
+ },
192
+ {
193
+ "name": "lodash",
194
+ "SPDXID": "SPDXRef-Package-lodash-4.17.21",
195
+ "versionInfo": "4.17.21",
196
+ "packageFileName": "node_modules/lodash",
197
+ "description": "Lodash modular utilities.",
198
+ "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
199
+ "filesAnalyzed": false,
200
+ "homepage": "https://lodash.com/",
201
+ "licenseDeclared": "MIT",
202
+ "externalRefs": [
203
+ {
204
+ "referenceCategory": "PACKAGE-MANAGER",
205
+ "referenceType": "purl",
206
+ "referenceLocator": "pkg:npm/lodash@4.17.21"
207
+ }
208
+ ],
209
+ "checksums": [
210
+ {
211
+ "algorithm": "SHA512",
212
+ "checksumValue": "bf690311ee7b95e713ba568322e3533f2dd1cb880b189e99d4edef13592b81764daec43e2c54c61d5c558dc5cfb35ecb85b65519e74026ff17675b6f8f916f4a"
213
+ }
214
+ ]
215
+ }
216
+ ],
217
+ "relationships": [
218
+ {
219
+ "spdxElementId": "SPDXRef-DOCUMENT",
220
+ "relatedSpdxElement": "SPDXRef-Package-simple-1.0.0",
221
+ "relationshipType": "DESCRIBES"
222
+ },
223
+ {
224
+ "spdxElementId": "SPDXRef-Package-simple-1.0.0",
225
+ "relatedSpdxElement": "SPDXRef-Package-lodash-4.17.21",
226
+ "relationshipType": "DEPENDS_ON"
227
+ }
228
+ ]
229
+}
230
+```
231
+
232
+### Package lock only mode
233
+
234
+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).
235
+
236
+### Configuration
237
+
238
+#### `omit`
239
+
240
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
241
+- Type: "dev", "optional", or "peer" (can be set multiple times)
242
+
243
+Dependency types to omit from the installation tree on disk.
244
+
245
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
246
+
247
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
248
+
249
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
250
+
251
+#### `package-lock-only`
252
+
253
+- Default: false
254
+- Type: Boolean
255
+
256
+If set to true, the current operation will only use the `package-lock.json`, ignoring `node_modules`.
257
+
258
+For `update` this means only the `package-lock.json` will be updated, instead of checking `node_modules` and downloading dependencies.
259
+
260
+For `list` this means the output will be based on the tree described by the `package-lock.json`, rather than the contents of `node_modules`.
261
+
262
+#### `sbom-format`
263
+
264
+- Default: null
265
+- Type: "cyclonedx" or "spdx"
266
+
267
+SBOM format to use when generating SBOMs.
268
+
269
+#### `sbom-type`
270
+
271
+- Default: "library"
272
+- Type: "library", "application", or "framework"
273
+
274
+The type of package described by the generated SBOM. For SPDX, this is the value for the `primaryPackagePurpose` field. For CycloneDX, this is the value for the `type` field.
275
+
276
+#### `workspace`
277
+
278
+- Default:
279
+- Type: String (can be set multiple times)
280
+
281
+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.
282
+
283
+Valid values for the `workspace` config are either:
284
+
285
+- Workspace names
286
+- Path to a workspace directory
287
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
288
+
289
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
290
+
291
+This value is not exported to the environment for child processes.
292
+
293
+#### `workspaces`
294
+
295
+- Default: null
296
+- Type: null or Boolean
297
+
298
+Set to true to run the command in the context of **all** configured workspaces.
299
+
300
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
301
+
302
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
303
+
304
+This value is not exported to the environment for child processes.
305
+
306
+## See Also
307
+
308
+- [package spec](/cli/v11/using-npm/package-spec)
309
+- [dependency selectors](/cli/v11/using-npm/dependency-selectors)
310
+- [package.json](/cli/v11/configuring-npm/package-json)
311
+- [workspaces](/cli/v11/using-npm/workspaces)
content/cli/v11/commands/npm-search.mdx
new
+148
@@ -0,0 +1,148 @@
1
+---
2
+title: npm-search
3
+section: 1
4
+description: Search for packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-search.md
8
+redirect_from:
9
+ - /cli-commands/npm-search
10
+ - /cli-commands/search
11
+ - /cli-documentation/cli-commands/npm-search
12
+ - /cli-documentation/cli-commands/search
13
+ - /cli-documentation/commands/npm-search
14
+ - /cli-documentation/commands/search
15
+ - /cli-documentation/npm-search
16
+ - /cli-documentation/search
17
+ - /cli-documentation/v11/cli-commands/npm-search
18
+ - /cli-documentation/v11/cli-commands/search
19
+ - /cli-documentation/v11/commands/npm-search
20
+ - /cli-documentation/v11/commands/search
21
+ - /cli-documentation/v11/npm-search
22
+ - /cli-documentation/v11/search
23
+ - /cli/cli-commands/npm-search
24
+ - /cli/cli-commands/search
25
+ - /cli/commands/npm-search
26
+ - /cli/commands/search
27
+ - /cli/npm-search
28
+ - /cli/search
29
+ - /cli/v11/cli-commands/npm-search
30
+ - /cli/v11/cli-commands/search
31
+ - /cli/v11/commands/search
32
+ - /cli/v11/npm-search
33
+ - /cli/v11/search
34
+ - /commands/npm-search
35
+ - /commands/search
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm search <search term> [<search term> ...]
42
+
43
+aliases: find, s, se
44
+```
45
+
46
+Note: This command is unaware of workspaces.
47
+
48
+### Description
49
+
50
+Search the registry for packages matching the search terms. `npm search` performs a linear, incremental, lexically-ordered search through package metadata for all files in the registry. If your terminal has color support, it will further highlight the matches in the results. This can be disabled with the config item `color`
51
+
52
+Additionally, using the `--searchopts` and `--searchexclude` options paired with more search terms will include and exclude further patterns. The main difference between `--searchopts` and the standard search terms is that the former does not highlight results in the output and you can use them more fine-grained filtering. Additionally, you can add both of these to your config to change default search filtering behavior.
53
+
54
+Search also allows targeting of maintainers in search results, by prefixing their npm username with `=`.
55
+
56
+If a term starts with `/`, then it's interpreted as a regular expression and supports standard JavaScript RegExp syntax. In this case search will ignore a trailing `/` . (Note you must escape or quote many regular expression characters in most shells.)
57
+
58
+### Configuration
59
+
60
+#### `json`
61
+
62
+- Default: false
63
+- Type: Boolean
64
+
65
+Whether or not to output JSON data, rather than the normal output.
66
+
67
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
68
+
69
+Not supported by all npm commands.
70
+
71
+#### `color`
72
+
73
+- Default: true unless the NO_COLOR environ is set to something other than '0'
74
+- Type: "always" or Boolean
75
+
76
+If false, never shows colors. If `"always"` then always shows colors. If true, then only prints color codes for tty file descriptors.
77
+
78
+#### `parseable`
79
+
80
+- Default: false
81
+- Type: Boolean
82
+
83
+Output parseable results from commands that write to standard output. For `npm search`, this will be tab-separated table format.
84
+
85
+#### `description`
86
+
87
+- Default: true
88
+- Type: Boolean
89
+
90
+Show the description in `npm search`
91
+
92
+#### `searchlimit`
93
+
94
+- Default: 20
95
+- Type: Number
96
+
97
+Number of items to limit search results to. Will not apply at all to legacy searches.
98
+
99
+#### `searchopts`
100
+
101
+- Default: ""
102
+- Type: String
103
+
104
+Space-separated options that are always passed to search.
105
+
106
+#### `searchexclude`
107
+
108
+- Default: ""
109
+- Type: String
110
+
111
+Space-separated options that limit the results from search.
112
+
113
+#### `registry`
114
+
115
+- Default: "https://registry.npmjs.org/"
116
+- Type: URL
117
+
118
+The base URL of the npm registry.
119
+
120
+#### `prefer-online`
121
+
122
+- Default: false
123
+- Type: Boolean
124
+
125
+If true, staleness checks for cached data will be forced, making the CLI look for updates immediately even for fresh package data.
126
+
127
+#### `prefer-offline`
128
+
129
+- Default: false
130
+- Type: Boolean
131
+
132
+If true, staleness checks for cached data will be bypassed, but missing data will be requested from the server. To force full offline mode, use `--offline`.
133
+
134
+#### `offline`
135
+
136
+- Default: false
137
+- Type: Boolean
138
+
139
+Force offline mode: no network requests will be done during install. To allow the CLI to fill in missing cache data, see `--prefer-offline`.
140
+
141
+### See Also
142
+
143
+- [npm registry](/cli/v11/using-npm/registry)
144
+- [npm config](/cli/v11/commands/npm-config)
145
+- [npmrc](/cli/v11/configuring-npm/npmrc)
146
+- [npm view](/cli/v11/commands/npm-view)
147
+- [npm cache](/cli/v11/commands/npm-cache)
148
+- https://npm.im/npm-registry-fetch
content/cli/v11/commands/npm-shrinkwrap.mdx
new
+58
@@ -0,0 +1,58 @@
1
+---
2
+title: npm-shrinkwrap
3
+section: 1
4
+description: Lock down dependency versions for publication
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-shrinkwrap.md
8
+redirect_from:
9
+ - /cli-commands/npm-shrinkwrap
10
+ - /cli-commands/shrinkwrap
11
+ - /cli-documentation/cli-commands/npm-shrinkwrap
12
+ - /cli-documentation/cli-commands/shrinkwrap
13
+ - /cli-documentation/commands/npm-shrinkwrap
14
+ - /cli-documentation/commands/shrinkwrap
15
+ - /cli-documentation/npm-shrinkwrap
16
+ - /cli-documentation/shrinkwrap
17
+ - /cli-documentation/v11/cli-commands/npm-shrinkwrap
18
+ - /cli-documentation/v11/cli-commands/shrinkwrap
19
+ - /cli-documentation/v11/commands/npm-shrinkwrap
20
+ - /cli-documentation/v11/commands/shrinkwrap
21
+ - /cli-documentation/v11/npm-shrinkwrap
22
+ - /cli-documentation/v11/shrinkwrap
23
+ - /cli/cli-commands/npm-shrinkwrap
24
+ - /cli/cli-commands/shrinkwrap
25
+ - /cli/commands/npm-shrinkwrap
26
+ - /cli/commands/shrinkwrap
27
+ - /cli/npm-shrinkwrap
28
+ - /cli/shrinkwrap
29
+ - /cli/v11/cli-commands/npm-shrinkwrap
30
+ - /cli/v11/cli-commands/shrinkwrap
31
+ - /cli/v11/commands/shrinkwrap
32
+ - /cli/v11/npm-shrinkwrap
33
+ - /cli/v11/shrinkwrap
34
+ - /commands/npm-shrinkwrap
35
+ - /commands/shrinkwrap
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm shrinkwrap
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+This command repurposes `package-lock.json` into a publishable `npm-shrinkwrap.json` or simply creates a new one. The file created and updated by this command will then take precedence over any other existing or future `package-lock.json` files. For a detailed explanation of the design and purpose of package locks in npm, see [package-lock-json](/cli/v11/configuring-npm/package-lock-json).
49
+
50
+### See Also
51
+
52
+- [npm install](/cli/v11/commands/npm-install)
53
+- [npm run-script](/cli/v11/commands/npm-run-script)
54
+- [npm scripts](/cli/v11/using-npm/scripts)
55
+- [package.json](/cli/v11/configuring-npm/package-json)
56
+- [package-lock.json](/cli/v11/configuring-npm/package-lock-json)
57
+- [npm-shrinkwrap.json](/cli/v11/configuring-npm/npm-shrinkwrap-json)
58
+- [npm ls](/cli/v11/commands/npm-ls)
content/cli/v11/commands/npm-star.mdx
new
+98
@@ -0,0 +1,98 @@
1
+---
2
+title: npm-star
3
+section: 1
4
+description: Mark your favorite packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-star.md
8
+redirect_from:
9
+ - /cli-commands/npm-star
10
+ - /cli-commands/star
11
+ - /cli-documentation/cli-commands/npm-star
12
+ - /cli-documentation/cli-commands/star
13
+ - /cli-documentation/commands/npm-star
14
+ - /cli-documentation/commands/star
15
+ - /cli-documentation/npm-star
16
+ - /cli-documentation/star
17
+ - /cli-documentation/v11/cli-commands/npm-star
18
+ - /cli-documentation/v11/cli-commands/star
19
+ - /cli-documentation/v11/commands/npm-star
20
+ - /cli-documentation/v11/commands/star
21
+ - /cli-documentation/v11/npm-star
22
+ - /cli-documentation/v11/star
23
+ - /cli/cli-commands/npm-star
24
+ - /cli/cli-commands/star
25
+ - /cli/commands/npm-star
26
+ - /cli/commands/star
27
+ - /cli/npm-star
28
+ - /cli/star
29
+ - /cli/v11/cli-commands/npm-star
30
+ - /cli/v11/cli-commands/star
31
+ - /cli/v11/commands/star
32
+ - /cli/v11/npm-star
33
+ - /cli/v11/star
34
+ - /commands/npm-star
35
+ - /commands/star
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm star [<package-spec>...]
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+"Starring" a package means that you have some interest in it. It's a vaguely positive way to show that you care.
49
+
50
+It's a boolean thing. Starring repeatedly has no additional effect.
51
+
52
+### More
53
+
54
+There's also these extra commands to help you manage your favorite packages:
55
+
56
+#### Unstar
57
+
58
+You can also "unstar" a package using [`npm unstar`](/cli/v11/commands/npm-unstar)
59
+
60
+"Unstarring" is the same thing, but in reverse.
61
+
62
+#### Listing stars
63
+
64
+You can see all your starred packages using [`npm stars`](/cli/v11/commands/npm-stars)
65
+
66
+### Configuration
67
+
68
+#### `registry`
69
+
70
+- Default: "https://registry.npmjs.org/"
71
+- Type: URL
72
+
73
+The base URL of the npm registry.
74
+
75
+#### `unicode`
76
+
77
+- Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the `LC_ALL`, `LC_CTYPE`, or `LANG` environment variables.
78
+- Type: Boolean
79
+
80
+When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
81
+
82
+#### `otp`
83
+
84
+- Default: null
85
+- Type: null or String
86
+
87
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
88
+
89
+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.
90
+
91
+### See Also
92
+
93
+- [package spec](/cli/v11/using-npm/package-spec)
94
+- [npm unstar](/cli/v11/commands/npm-unstar)
95
+- [npm stars](/cli/v11/commands/npm-stars)
96
+- [npm view](/cli/v11/commands/npm-view)
97
+- [npm whoami](/cli/v11/commands/npm-whoami)
98
+- [npm adduser](/cli/v11/commands/npm-adduser)
content/cli/v11/commands/npm-stars.mdx
new
+67
@@ -0,0 +1,67 @@
1
+---
2
+title: npm-stars
3
+section: 1
4
+description: View packages marked as favorites
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-stars.md
8
+redirect_from:
9
+ - /cli-commands/npm-stars
10
+ - /cli-commands/stars
11
+ - /cli-documentation/cli-commands/npm-stars
12
+ - /cli-documentation/cli-commands/stars
13
+ - /cli-documentation/commands/npm-stars
14
+ - /cli-documentation/commands/stars
15
+ - /cli-documentation/npm-stars
16
+ - /cli-documentation/stars
17
+ - /cli-documentation/v11/cli-commands/npm-stars
18
+ - /cli-documentation/v11/cli-commands/stars
19
+ - /cli-documentation/v11/commands/npm-stars
20
+ - /cli-documentation/v11/commands/stars
21
+ - /cli-documentation/v11/npm-stars
22
+ - /cli-documentation/v11/stars
23
+ - /cli/cli-commands/npm-stars
24
+ - /cli/cli-commands/stars
25
+ - /cli/commands/npm-stars
26
+ - /cli/commands/stars
27
+ - /cli/npm-stars
28
+ - /cli/stars
29
+ - /cli/v11/cli-commands/npm-stars
30
+ - /cli/v11/cli-commands/stars
31
+ - /cli/v11/commands/stars
32
+ - /cli/v11/npm-stars
33
+ - /cli/v11/stars
34
+ - /commands/npm-stars
35
+ - /commands/stars
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm stars [<user>]
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+If you have starred a lot of neat things and want to find them again quickly this command lets you do just that.
49
+
50
+You may also want to see your friend's favorite packages, in this case you will most certainly enjoy this command.
51
+
52
+### Configuration
53
+
54
+#### `registry`
55
+
56
+- Default: "https://registry.npmjs.org/"
57
+- Type: URL
58
+
59
+The base URL of the npm registry.
60
+
61
+### See Also
62
+
63
+- [npm star](/cli/v11/commands/npm-star)
64
+- [npm unstar](/cli/v11/commands/npm-unstar)
65
+- [npm view](/cli/v11/commands/npm-view)
66
+- [npm whoami](/cli/v11/commands/npm-whoami)
67
+- [npm adduser](/cli/v11/commands/npm-adduser)
content/cli/v11/commands/npm-start.mdx
new
+98
@@ -0,0 +1,98 @@
1
+---
2
+title: npm-start
3
+section: 1
4
+description: Start a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-start.md
8
+redirect_from:
9
+ - /cli-commands/npm-start
10
+ - /cli-commands/start
11
+ - /cli-documentation/cli-commands/npm-start
12
+ - /cli-documentation/cli-commands/start
13
+ - /cli-documentation/commands/npm-start
14
+ - /cli-documentation/commands/start
15
+ - /cli-documentation/npm-start
16
+ - /cli-documentation/start
17
+ - /cli-documentation/v11/cli-commands/npm-start
18
+ - /cli-documentation/v11/cli-commands/start
19
+ - /cli-documentation/v11/commands/npm-start
20
+ - /cli-documentation/v11/commands/start
21
+ - /cli-documentation/v11/npm-start
22
+ - /cli-documentation/v11/start
23
+ - /cli/cli-commands/npm-start
24
+ - /cli/cli-commands/start
25
+ - /cli/commands/npm-start
26
+ - /cli/commands/start
27
+ - /cli/npm-start
28
+ - /cli/start
29
+ - /cli/v11/cli-commands/npm-start
30
+ - /cli/v11/cli-commands/start
31
+ - /cli/v11/commands/start
32
+ - /cli/v11/npm-start
33
+ - /cli/v11/start
34
+ - /commands/npm-start
35
+ - /commands/start
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm start [-- <args>]
42
+```
43
+
44
+### Description
45
+
46
+This runs a predefined command specified in the `"start"` property of a package's `"scripts"` object.
47
+
48
+If the `"scripts"` object does not define a `"start"` property, npm will run `node server.js`.
49
+
50
+Note that this is different from the default node behavior of running the file specified in a package's `"main"` attribute when evoking with `node .`
51
+
52
+As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can use custom arguments when executing scripts. Refer to [`npm run-script`](/cli/v11/commands/npm-run-script) for more details.
53
+
54
+### Example
55
+
56
+```json
57
+{
58
+ "scripts": {
59
+ "start": "node foo.js"
60
+ }
61
+}
62
+```
63
+
64
+```bash
65
+npm start
66
+
67
+> npm@x.x.x start
68
+> node foo.js
69
+
70
+(foo.js output would be here)
71
+
72
+```
73
+
74
+### Configuration
75
+
76
+#### `ignore-scripts`
77
+
78
+- Default: false
79
+- Type: Boolean
80
+
81
+If true, npm does not run scripts specified in package.json files.
82
+
83
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
84
+
85
+#### `script-shell`
86
+
87
+- Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
88
+- Type: null or String
89
+
90
+The shell to use for scripts run with the `npm exec`, `npm run` and `npm init <package-spec>` commands.
91
+
92
+### See Also
93
+
94
+- [npm run-script](/cli/v11/commands/npm-run-script)
95
+- [npm scripts](/cli/v11/using-npm/scripts)
96
+- [npm test](/cli/v11/commands/npm-test)
97
+- [npm restart](/cli/v11/commands/npm-restart)
98
+- [npm stop](/cli/v11/commands/npm-stop)
content/cli/v11/commands/npm-stop.mdx
new
+94
@@ -0,0 +1,94 @@
1
+---
2
+title: npm-stop
3
+section: 1
4
+description: Stop a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-stop.md
8
+redirect_from:
9
+ - /cli-commands/npm-stop
10
+ - /cli-commands/stop
11
+ - /cli-documentation/cli-commands/npm-stop
12
+ - /cli-documentation/cli-commands/stop
13
+ - /cli-documentation/commands/npm-stop
14
+ - /cli-documentation/commands/stop
15
+ - /cli-documentation/npm-stop
16
+ - /cli-documentation/stop
17
+ - /cli-documentation/v11/cli-commands/npm-stop
18
+ - /cli-documentation/v11/cli-commands/stop
19
+ - /cli-documentation/v11/commands/npm-stop
20
+ - /cli-documentation/v11/commands/stop
21
+ - /cli-documentation/v11/npm-stop
22
+ - /cli-documentation/v11/stop
23
+ - /cli/cli-commands/npm-stop
24
+ - /cli/cli-commands/stop
25
+ - /cli/commands/npm-stop
26
+ - /cli/commands/stop
27
+ - /cli/npm-stop
28
+ - /cli/stop
29
+ - /cli/v11/cli-commands/npm-stop
30
+ - /cli/v11/cli-commands/stop
31
+ - /cli/v11/commands/stop
32
+ - /cli/v11/npm-stop
33
+ - /cli/v11/stop
34
+ - /commands/npm-stop
35
+ - /commands/stop
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm stop [-- <args>]
42
+```
43
+
44
+### Description
45
+
46
+This runs a predefined command specified in the "stop" property of a package's "scripts" object.
47
+
48
+Unlike with [npm start](/cli/v11/commands/npm-start), there is no default script that will run if the `"stop"` property is not defined.
49
+
50
+### Example
51
+
52
+```json
53
+{
54
+ "scripts": {
55
+ "stop": "node bar.js"
56
+ }
57
+}
58
+```
59
+
60
+```bash
61
+npm stop
62
+
63
+> npm@x.x.x stop
64
+> node bar.js
65
+
66
+(bar.js output would be here)
67
+
68
+```
69
+
70
+### Configuration
71
+
72
+#### `ignore-scripts`
73
+
74
+- Default: false
75
+- Type: Boolean
76
+
77
+If true, npm does not run scripts specified in package.json files.
78
+
79
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
80
+
81
+#### `script-shell`
82
+
83
+- Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
84
+- Type: null or String
85
+
86
+The shell to use for scripts run with the `npm exec`, `npm run` and `npm init <package-spec>` commands.
87
+
88
+### See Also
89
+
90
+- [npm run-script](/cli/v11/commands/npm-run-script)
91
+- [npm scripts](/cli/v11/using-npm/scripts)
92
+- [npm test](/cli/v11/commands/npm-test)
93
+- [npm start](/cli/v11/commands/npm-start)
94
+- [npm restart](/cli/v11/commands/npm-restart)
content/cli/v11/commands/npm-team.mdx
new
+152
@@ -0,0 +1,152 @@
1
+---
2
+title: npm-team
3
+section: 1
4
+description: Manage organization teams and team memberships
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-team.md
8
+redirect_from:
9
+ - /cli-commands/npm-team
10
+ - /cli-commands/team
11
+ - /cli-documentation/cli-commands/npm-team
12
+ - /cli-documentation/cli-commands/team
13
+ - /cli-documentation/commands/npm-team
14
+ - /cli-documentation/commands/team
15
+ - /cli-documentation/npm-team
16
+ - /cli-documentation/team
17
+ - /cli-documentation/v11/cli-commands/npm-team
18
+ - /cli-documentation/v11/cli-commands/team
19
+ - /cli-documentation/v11/commands/npm-team
20
+ - /cli-documentation/v11/commands/team
21
+ - /cli-documentation/v11/npm-team
22
+ - /cli-documentation/v11/team
23
+ - /cli/cli-commands/npm-team
24
+ - /cli/cli-commands/team
25
+ - /cli/commands/npm-team
26
+ - /cli/commands/team
27
+ - /cli/npm-team
28
+ - /cli/team
29
+ - /cli/v11/cli-commands/npm-team
30
+ - /cli/v11/cli-commands/team
31
+ - /cli/v11/commands/team
32
+ - /cli/v11/npm-team
33
+ - /cli/v11/team
34
+ - /commands/npm-team
35
+ - /commands/team
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm team create <scope:team> [--otp <otpcode>]
42
+npm team destroy <scope:team> [--otp <otpcode>]
43
+npm team add <scope:team> <user> [--otp <otpcode>]
44
+npm team rm <scope:team> <user> [--otp <otpcode>]
45
+npm team ls <scope>|<scope:team>
46
+```
47
+
48
+Note: This command is unaware of workspaces.
49
+
50
+### Description
51
+
52
+Used to manage teams in organizations, and change team memberships. Does not handle permissions for packages.
53
+
54
+Teams must always be fully qualified with the organization/scope they belong to when operating on them, separated by a colon (`:`). That is, if you have a `newteam` team in an `org` organization, you must always refer to that team as `@org:newteam` in these commands.
55
+
56
+If you have two-factor authentication enabled in `auth-and-writes` mode, then you can provide a code from your authenticator with `[--otp <otpcode>]`. If you don't include this then you will be taken through a second factor flow based on your `authtype`.
57
+
58
+- create / destroy: Create a new team, or destroy an existing one. Note: You cannot remove the `developers` team, [learn more.](https://docs.npmjs.com/about-developers-team)
59
+
60
+ Here's how to create a new team `newteam` under the `org` org:
61
+
62
+ ```bash
63
+ npm team create @org:newteam
64
+ ```
65
+
66
+ You should see a confirming message such as: `+@org:newteam` once the new team has been created.
67
+
68
+- add: Add a user to an existing team.
69
+
70
+ Adding a new user `username` to a team named `newteam` under the `org` org:
71
+
72
+ ```bash
73
+ npm team add @org:newteam username
74
+ ```
75
+
76
+ On success, you should see a message: `username added to @org:newteam`
77
+
78
+- rm: Using `npm team rm` you can also remove users from a team they belong to.
79
+
80
+ Here's an example removing user `username` from `newteam` team in `org` organization:
81
+
82
+ ```bash
83
+ npm team rm @org:newteam username
84
+ ```
85
+
86
+ Once the user is removed a confirmation message is displayed: `username removed from @org:newteam`
87
+
88
+- ls: If performed on an organization name, will return a list of existing teams under that organization. If performed on a team, it will instead return a list of all users belonging to that particular team.
89
+
90
+ Here's an example of how to list all teams from an org named `org`:
91
+
92
+ ```bash
93
+ npm team ls @org
94
+ ```
95
+
96
+ Example listing all members of a team named `newteam`:
97
+
98
+ ```bash
99
+ npm team ls @org:newteam
100
+ ```
101
+
102
+### Details
103
+
104
+`npm team` always operates directly on the current registry, configurable from the command line using `--registry=<registry url>`.
105
+
106
+You must be a _team admin_ to create teams and manage team membership, under the given organization. Listing teams and team memberships may be done by any member of the organization.
107
+
108
+Organization creation and management of team admins and _organization_ members is done through the website, not the npm CLI.
109
+
110
+To use teams to manage permissions on packages belonging to your organization, use the `npm access` command to grant or revoke the appropriate permissions.
111
+
112
+### Configuration
113
+
114
+#### `registry`
115
+
116
+- Default: "https://registry.npmjs.org/"
117
+- Type: URL
118
+
119
+The base URL of the npm registry.
120
+
121
+#### `otp`
122
+
123
+- Default: null
124
+- Type: null or String
125
+
126
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
127
+
128
+If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
129
+
130
+#### `parseable`
131
+
132
+- Default: false
133
+- Type: Boolean
134
+
135
+Output parseable results from commands that write to standard output. For `npm search`, this will be tab-separated table format.
136
+
137
+#### `json`
138
+
139
+- Default: false
140
+- Type: Boolean
141
+
142
+Whether or not to output JSON data, rather than the normal output.
143
+
144
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
145
+
146
+Not supported by all npm commands.
147
+
148
+### See Also
149
+
150
+- [npm access](/cli/v11/commands/npm-access)
151
+- [npm config](/cli/v11/commands/npm-config)
152
+- [npm registry](/cli/v11/using-npm/registry)
content/cli/v11/commands/npm-test.mdx
new
+92
@@ -0,0 +1,92 @@
1
+---
2
+title: npm-test
3
+section: 1
4
+description: Test a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-test.md
8
+redirect_from:
9
+ - /cli-commands/npm-test
10
+ - /cli-commands/test
11
+ - /cli-documentation/cli-commands/npm-test
12
+ - /cli-documentation/cli-commands/test
13
+ - /cli-documentation/commands/npm-test
14
+ - /cli-documentation/commands/test
15
+ - /cli-documentation/npm-test
16
+ - /cli-documentation/test
17
+ - /cli-documentation/v11/cli-commands/npm-test
18
+ - /cli-documentation/v11/cli-commands/test
19
+ - /cli-documentation/v11/commands/npm-test
20
+ - /cli-documentation/v11/commands/test
21
+ - /cli-documentation/v11/npm-test
22
+ - /cli-documentation/v11/test
23
+ - /cli/cli-commands/npm-test
24
+ - /cli/cli-commands/test
25
+ - /cli/commands/npm-test
26
+ - /cli/commands/test
27
+ - /cli/npm-test
28
+ - /cli/test
29
+ - /cli/v11/cli-commands/npm-test
30
+ - /cli/v11/cli-commands/test
31
+ - /cli/v11/commands/test
32
+ - /cli/v11/npm-test
33
+ - /cli/v11/test
34
+ - /commands/npm-test
35
+ - /commands/test
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm test [-- <args>]
42
+
43
+aliases: tst, t
44
+```
45
+
46
+### Description
47
+
48
+This runs a predefined command specified in the `"test"` property of a package's `"scripts"` object.
49
+
50
+### Example
51
+
52
+```json
53
+{
54
+ "scripts": {
55
+ "test": "node test.js"
56
+ }
57
+}
58
+```
59
+
60
+```bash
61
+npm test
62
+> npm@x.x.x test
63
+> node test.js
64
+
65
+(test.js output would be here)
66
+```
67
+
68
+### Configuration
69
+
70
+#### `ignore-scripts`
71
+
72
+- Default: false
73
+- Type: Boolean
74
+
75
+If true, npm does not run scripts specified in package.json files.
76
+
77
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
78
+
79
+#### `script-shell`
80
+
81
+- Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
82
+- Type: null or String
83
+
84
+The shell to use for scripts run with the `npm exec`, `npm run` and `npm init <package-spec>` commands.
85
+
86
+### See Also
87
+
88
+- [npm run-script](/cli/v11/commands/npm-run-script)
89
+- [npm scripts](/cli/v11/using-npm/scripts)
90
+- [npm start](/cli/v11/commands/npm-start)
91
+- [npm restart](/cli/v11/commands/npm-restart)
92
+- [npm stop](/cli/v11/commands/npm-stop)
content/cli/v11/commands/npm-token.mdx
new
+114
@@ -0,0 +1,114 @@
1
+---
2
+title: npm-token
3
+section: 1
4
+description: Manage your authentication tokens
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-token.md
8
+redirect_from:
9
+ - /cli-commands/npm-token
10
+ - /cli-commands/token
11
+ - /cli-documentation/cli-commands/npm-token
12
+ - /cli-documentation/cli-commands/token
13
+ - /cli-documentation/commands/npm-token
14
+ - /cli-documentation/commands/token
15
+ - /cli-documentation/npm-token
16
+ - /cli-documentation/token
17
+ - /cli-documentation/v11/cli-commands/npm-token
18
+ - /cli-documentation/v11/cli-commands/token
19
+ - /cli-documentation/v11/commands/npm-token
20
+ - /cli-documentation/v11/commands/token
21
+ - /cli-documentation/v11/npm-token
22
+ - /cli-documentation/v11/token
23
+ - /cli/cli-commands/npm-token
24
+ - /cli/cli-commands/token
25
+ - /cli/commands/npm-token
26
+ - /cli/commands/token
27
+ - /cli/npm-token
28
+ - /cli/token
29
+ - /cli/v11/cli-commands/npm-token
30
+ - /cli/v11/cli-commands/token
31
+ - /cli/v11/commands/token
32
+ - /cli/v11/npm-token
33
+ - /cli/v11/token
34
+ - /commands/npm-token
35
+ - /commands/token
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm token list
42
+npm token revoke <id|token>
43
+npm token create [--read-only] [--cidr=list]
44
+```
45
+
46
+Note: This command is unaware of workspaces.
47
+
48
+### Description
49
+
50
+This lets you list, create and revoke authentication tokens.
51
+
52
+- `npm token list`: Shows a table of all active authentication tokens. You can request this as JSON with `--json` or tab-separated values with `--parseable`.
53
+
54
+```
55
+Read only token npm_1f… with id 7f3134 created 2017-10-21
56
+
57
+Publish token npm_af… with id c03241 created 2017-10-02
58
+with IP Whitelist: 192.168.0.1/24
59
+
60
+Publish token npm_… with id e0cf92 created 2017-10-02
61
+
62
+```
63
+
64
+- `npm token create [--read-only] [--cidr=<cidr-ranges>]`: Create a new authentication token. It can be `--read-only`, or accept a list of [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) ranges with which to limit use of this token. This will prompt you for your password, and, if you have two-factor authentication enabled, an otp.
65
+
66
+ Currently, the cli can not generate automation tokens. Please refer to the [docs website](https://docs.npmjs.com/creating-and-viewing-access-tokens) for more information on generating automation tokens.
67
+
68
+```
69
+Created publish token a73c9572-f1b9-8983-983d-ba3ac3cc913d
70
+```
71
+
72
+- `npm token revoke <token|id>`: Immediately removes an authentication token from the registry. You will no longer be able to use it. This can accept both complete tokens (such as those you get back from `npm token create`, and those found in your `.npmrc`), and ids as seen in the parseable or json output of `npm token list`. This will NOT accept the truncated token found in the normal `npm token list` output.
73
+
74
+### Configuration
75
+
76
+#### `read-only`
77
+
78
+- Default: false
79
+- Type: Boolean
80
+
81
+This is used to mark a token as unable to publish when configuring limited access tokens with the `npm token create` command.
82
+
83
+#### `cidr`
84
+
85
+- Default: null
86
+- Type: null or String (can be set multiple times)
87
+
88
+This is a list of CIDR address to be used when configuring limited access tokens with the `npm token create` command.
89
+
90
+#### `registry`
91
+
92
+- Default: "https://registry.npmjs.org/"
93
+- Type: URL
94
+
95
+The base URL of the npm registry.
96
+
97
+#### `otp`
98
+
99
+- Default: null
100
+- Type: null or String
101
+
102
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
103
+
104
+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.
105
+
106
+### See Also
107
+
108
+- [npm adduser](/cli/v11/commands/npm-adduser)
109
+- [npm registry](/cli/v11/using-npm/registry)
110
+- [npm config](/cli/v11/commands/npm-config)
111
+- [npmrc](/cli/v11/configuring-npm/npmrc)
112
+- [npm owner](/cli/v11/commands/npm-owner)
113
+- [npm whoami](/cli/v11/commands/npm-whoami)
114
+- [npm profile](/cli/v11/commands/npm-profile)
content/cli/v11/commands/npm-uninstall.mdx
new
+154
@@ -0,0 +1,154 @@
1
+---
2
+title: npm-uninstall
3
+section: 1
4
+description: Remove a package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-uninstall.md
8
+redirect_from:
9
+ - /cli-commands/npm-uninstall
10
+ - /cli-commands/uninstall
11
+ - /cli-documentation/cli-commands/npm-uninstall
12
+ - /cli-documentation/cli-commands/uninstall
13
+ - /cli-documentation/commands/npm-uninstall
14
+ - /cli-documentation/commands/uninstall
15
+ - /cli-documentation/npm-uninstall
16
+ - /cli-documentation/uninstall
17
+ - /cli-documentation/v11/cli-commands/npm-uninstall
18
+ - /cli-documentation/v11/cli-commands/uninstall
19
+ - /cli-documentation/v11/commands/npm-uninstall
20
+ - /cli-documentation/v11/commands/uninstall
21
+ - /cli-documentation/v11/npm-uninstall
22
+ - /cli-documentation/v11/uninstall
23
+ - /cli/cli-commands/npm-uninstall
24
+ - /cli/cli-commands/uninstall
25
+ - /cli/commands/npm-uninstall
26
+ - /cli/commands/uninstall
27
+ - /cli/npm-uninstall
28
+ - /cli/uninstall
29
+ - /cli/v11/cli-commands/npm-uninstall
30
+ - /cli/v11/cli-commands/uninstall
31
+ - /cli/v11/commands/uninstall
32
+ - /cli/v11/npm-uninstall
33
+ - /cli/v11/uninstall
34
+ - /commands/npm-uninstall
35
+ - /commands/uninstall
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm uninstall [<@scope>/]<pkg>...
42
+
43
+aliases: unlink, remove, rm, r, un
44
+```
45
+
46
+### Description
47
+
48
+This uninstalls a package, completely removing everything npm installed on its behalf.
49
+
50
+It also removes the package from the `dependencies`, `devDependencies`, `optionalDependencies`, and `peerDependencies` objects in your `package.json`.
51
+
52
+Further, if you have an `npm-shrinkwrap.json` or `package-lock.json`, npm will update those files as well.
53
+
54
+`--no-save` will tell npm not to remove the package from your `package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files.
55
+
56
+`--save` or `-S` will tell npm to remove the package from your `package.json`, `npm-shrinkwrap.json`, and `package-lock.json` files. This is the default, but you may need to use this if you have for instance `save=false` in your `npmrc` file
57
+
58
+In global mode (ie, with `-g` or `--global` appended to the command), it uninstalls the current package context as a global package. `--no-save` is ignored in this case.
59
+
60
+Scope is optional and follows the usual rules for [`scope`](/cli/v11/using-npm/scope).
61
+
62
+### Examples
63
+
64
+```bash
65
+npm uninstall sax
66
+```
67
+
68
+`sax` will no longer be in your `package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files.
69
+
70
+```bash
71
+npm uninstall lodash --no-save
72
+```
73
+
74
+`lodash` will not be removed from your `package.json`, `npm-shrinkwrap.json`, or `package-lock.json` files.
75
+
76
+### Configuration
77
+
78
+#### `save`
79
+
80
+- Default: `true` unless when using `npm update` where it defaults to `false`
81
+- Type: Boolean
82
+
83
+Save installed packages to a `package.json` file as dependencies.
84
+
85
+When used with the `npm rm` command, removes the dependency from `package.json`.
86
+
87
+Will also prevent writing to `package-lock.json` if set to `false`.
88
+
89
+#### `global`
90
+
91
+- Default: false
92
+- Type: Boolean
93
+
94
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
95
+
96
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
97
+- bin files are linked to `{prefix}/bin`
98
+- man pages are linked to `{prefix}/share/man`
99
+
100
+#### `workspace`
101
+
102
+- Default:
103
+- Type: String (can be set multiple times)
104
+
105
+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.
106
+
107
+Valid values for the `workspace` config are either:
108
+
109
+- Workspace names
110
+- Path to a workspace directory
111
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
112
+
113
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
114
+
115
+This value is not exported to the environment for child processes.
116
+
117
+#### `workspaces`
118
+
119
+- Default: null
120
+- Type: null or Boolean
121
+
122
+Set to true to run the command in the context of **all** configured workspaces.
123
+
124
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
125
+
126
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
127
+
128
+This value is not exported to the environment for child processes.
129
+
130
+#### `include-workspace-root`
131
+
132
+- Default: false
133
+- Type: Boolean
134
+
135
+Include the workspace root when workspaces are enabled for a command.
136
+
137
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
138
+
139
+This value is not exported to the environment for child processes.
140
+
141
+#### `install-links`
142
+
143
+- Default: false
144
+- Type: Boolean
145
+
146
+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.
147
+
148
+### See Also
149
+
150
+- [npm prune](/cli/v11/commands/npm-prune)
151
+- [npm install](/cli/v11/commands/npm-install)
152
+- [npm folders](/cli/v11/configuring-npm/folders)
153
+- [npm config](/cli/v11/commands/npm-config)
154
+- [npmrc](/cli/v11/configuring-npm/npmrc)
content/cli/v11/commands/npm-unpublish.mdx
new
+132
@@ -0,0 +1,132 @@
1
+---
2
+title: npm-unpublish
3
+section: 1
4
+description: Remove a package from the registry
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-unpublish.md
8
+redirect_from:
9
+ - /cli-commands/npm-unpublish
10
+ - /cli-commands/unpublish
11
+ - /cli-documentation/cli-commands/npm-unpublish
12
+ - /cli-documentation/cli-commands/unpublish
13
+ - /cli-documentation/commands/npm-unpublish
14
+ - /cli-documentation/commands/unpublish
15
+ - /cli-documentation/npm-unpublish
16
+ - /cli-documentation/unpublish
17
+ - /cli-documentation/v11/cli-commands/npm-unpublish
18
+ - /cli-documentation/v11/cli-commands/unpublish
19
+ - /cli-documentation/v11/commands/npm-unpublish
20
+ - /cli-documentation/v11/commands/unpublish
21
+ - /cli-documentation/v11/npm-unpublish
22
+ - /cli-documentation/v11/unpublish
23
+ - /cli/cli-commands/npm-unpublish
24
+ - /cli/cli-commands/unpublish
25
+ - /cli/commands/npm-unpublish
26
+ - /cli/commands/unpublish
27
+ - /cli/npm-unpublish
28
+ - /cli/unpublish
29
+ - /cli/v11/cli-commands/npm-unpublish
30
+ - /cli/v11/cli-commands/unpublish
31
+ - /cli/v11/commands/unpublish
32
+ - /cli/v11/npm-unpublish
33
+ - /cli/v11/unpublish
34
+ - /commands/npm-unpublish
35
+ - /commands/unpublish
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm unpublish [<package-spec>]
42
+```
43
+
44
+To learn more about how the npm registry treats unpublish, see our [unpublish policies](https://docs.npmjs.com/policies/unpublish).
45
+
46
+### Warning
47
+
48
+Consider using the [`deprecate`](/cli/v11/commands/npm-deprecate) command instead, if your intent is to encourage users to upgrade, or if you no longer want to maintain a package.
49
+
50
+### Description
51
+
52
+This removes a package version from the registry, deleting its entry and removing the tarball.
53
+
54
+The npm registry will return an error if you are not [logged in](/cli/v11/commands/npm-adduser).
55
+
56
+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.
57
+
58
+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.
59
+
60
+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.
61
+
62
+### Configuration
63
+
64
+#### `dry-run`
65
+
66
+- Default: false
67
+- Type: Boolean
68
+
69
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
70
+
71
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
72
+
73
+#### `force`
74
+
75
+- Default: false
76
+- Type: Boolean
77
+
78
+Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
79
+
80
+- Allow clobbering non-npm files in global installs.
81
+- Allow the `npm version` command to work on an unclean git repository.
82
+- Allow deleting the cache folder with `npm cache clean`.
83
+- Allow installing packages that have an `engines` declaration requiring a different version of npm.
84
+- Allow installing packages that have an `engines` declaration requiring a different version of `node`, even if `--engine-strict` is enabled.
85
+- Allow `npm audit fix` to install modules outside your stated dependency range (including SemVer-major changes).
86
+- Allow unpublishing all versions of a published package.
87
+- Allow conflicting peerDependencies to be installed in the root project.
88
+- Implicitly set `--yes` during `npm init`.
89
+- Allow clobbering existing values in `npm pkg`
90
+- Allow unpublishing of entire packages (not just a single version).
91
+
92
+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!
93
+
94
+#### `workspace`
95
+
96
+- Default:
97
+- Type: String (can be set multiple times)
98
+
99
+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.
100
+
101
+Valid values for the `workspace` config are either:
102
+
103
+- Workspace names
104
+- Path to a workspace directory
105
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
106
+
107
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
108
+
109
+This value is not exported to the environment for child processes.
110
+
111
+#### `workspaces`
112
+
113
+- Default: null
114
+- Type: null or Boolean
115
+
116
+Set to true to run the command in the context of **all** configured workspaces.
117
+
118
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
119
+
120
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
121
+
122
+This value is not exported to the environment for child processes.
123
+
124
+### See Also
125
+
126
+- [package spec](/cli/v11/using-npm/package-spec)
127
+- [npm deprecate](/cli/v11/commands/npm-deprecate)
128
+- [npm publish](/cli/v11/commands/npm-publish)
129
+- [npm registry](/cli/v11/using-npm/registry)
130
+- [npm adduser](/cli/v11/commands/npm-adduser)
131
+- [npm owner](/cli/v11/commands/npm-owner)
132
+- [npm login](/cli/v11/commands/npm-adduser)
content/cli/v11/commands/npm-unstar.mdx
new
+93
@@ -0,0 +1,93 @@
1
+---
2
+title: npm-unstar
3
+section: 1
4
+description: Remove an item from your favorite packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-unstar.md
8
+redirect_from:
9
+ - /cli-commands/npm-unstar
10
+ - /cli-commands/unstar
11
+ - /cli-documentation/cli-commands/npm-unstar
12
+ - /cli-documentation/cli-commands/unstar
13
+ - /cli-documentation/commands/npm-unstar
14
+ - /cli-documentation/commands/unstar
15
+ - /cli-documentation/npm-unstar
16
+ - /cli-documentation/unstar
17
+ - /cli-documentation/v11/cli-commands/npm-unstar
18
+ - /cli-documentation/v11/cli-commands/unstar
19
+ - /cli-documentation/v11/commands/npm-unstar
20
+ - /cli-documentation/v11/commands/unstar
21
+ - /cli-documentation/v11/npm-unstar
22
+ - /cli-documentation/v11/unstar
23
+ - /cli/cli-commands/npm-unstar
24
+ - /cli/cli-commands/unstar
25
+ - /cli/commands/npm-unstar
26
+ - /cli/commands/unstar
27
+ - /cli/npm-unstar
28
+ - /cli/unstar
29
+ - /cli/v11/cli-commands/npm-unstar
30
+ - /cli/v11/cli-commands/unstar
31
+ - /cli/v11/commands/unstar
32
+ - /cli/v11/npm-unstar
33
+ - /cli/v11/unstar
34
+ - /commands/npm-unstar
35
+ - /commands/unstar
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm unstar [<package-spec>...]
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+"Unstarring" a package is the opposite of [`npm star`](/cli/v11/commands/npm-star), it removes an item from your list of favorite packages.
49
+
50
+### More
51
+
52
+There's also these extra commands to help you manage your favorite packages:
53
+
54
+#### Star
55
+
56
+You can "star" a package using [`npm star`](/cli/v11/commands/npm-star)
57
+
58
+#### Listing stars
59
+
60
+You can see all your starred packages using [`npm stars`](/cli/v11/commands/npm-stars)
61
+
62
+### Configuration
63
+
64
+#### `registry`
65
+
66
+- Default: "https://registry.npmjs.org/"
67
+- Type: URL
68
+
69
+The base URL of the npm registry.
70
+
71
+#### `unicode`
72
+
73
+- Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the `LC_ALL`, `LC_CTYPE`, or `LANG` environment variables.
74
+- Type: Boolean
75
+
76
+When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
77
+
78
+#### `otp`
79
+
80
+- Default: null
81
+- Type: null or String
82
+
83
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
84
+
85
+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.
86
+
87
+### See Also
88
+
89
+- [npm star](/cli/v11/commands/npm-star)
90
+- [npm stars](/cli/v11/commands/npm-stars)
91
+- [npm view](/cli/v11/commands/npm-view)
92
+- [npm whoami](/cli/v11/commands/npm-whoami)
93
+- [npm adduser](/cli/v11/commands/npm-adduser)
content/cli/v11/commands/npm-update.mdx
new
+354
@@ -0,0 +1,354 @@
1
+---
2
+title: npm-update
3
+section: 1
4
+description: Update packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-update.md
8
+redirect_from:
9
+ - /cli-commands/npm-update
10
+ - /cli-commands/update
11
+ - /cli-documentation/cli-commands/npm-update
12
+ - /cli-documentation/cli-commands/update
13
+ - /cli-documentation/commands/npm-update
14
+ - /cli-documentation/commands/update
15
+ - /cli-documentation/npm-update
16
+ - /cli-documentation/update
17
+ - /cli-documentation/v11/cli-commands/npm-update
18
+ - /cli-documentation/v11/cli-commands/update
19
+ - /cli-documentation/v11/commands/npm-update
20
+ - /cli-documentation/v11/commands/update
21
+ - /cli-documentation/v11/npm-update
22
+ - /cli-documentation/v11/update
23
+ - /cli/cli-commands/npm-update
24
+ - /cli/cli-commands/update
25
+ - /cli/commands/npm-update
26
+ - /cli/commands/update
27
+ - /cli/npm-update
28
+ - /cli/update
29
+ - /cli/v11/cli-commands/npm-update
30
+ - /cli/v11/cli-commands/update
31
+ - /cli/v11/commands/update
32
+ - /cli/v11/npm-update
33
+ - /cli/v11/update
34
+ - /commands/npm-update
35
+ - /commands/update
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm update [<pkg>...]
42
+
43
+aliases: up, upgrade, udpate
44
+```
45
+
46
+### Description
47
+
48
+This command will update all the packages listed to the latest version (specified by the [`tag` config](/cli/v11/using-npm/config#tag)), respecting the semver constraints of both your package and its dependencies (if they also require the same package).
49
+
50
+It will also install missing packages.
51
+
52
+If the `-g` flag is specified, this command will update globally installed packages.
53
+
54
+If no package name is specified, all packages in the specified location (global or local) will be updated.
55
+
56
+Note that by default `npm update` will not update the semver values of direct dependencies in your project `package.json`. If you want to also update values in `package.json` you can run: `npm update --save` (or add the `save=true` option to a [configuration file](/cli/v11/configuring-npm/npmrc) to make that the default behavior).
57
+
58
+### Example
59
+
60
+For the examples below, assume that the current package is `app` and it depends on dependencies, `dep1` (`dep2`, .. etc.). The published versions of `dep1` are:
61
+
62
+```json
63
+{
64
+ "dist-tags": { "latest": "1.2.2" },
65
+ "versions": [
66
+ "1.2.2",
67
+ "1.2.1",
68
+ "1.2.0",
69
+ "1.1.2",
70
+ "1.1.1",
71
+ "1.0.0",
72
+ "0.4.1",
73
+ "0.4.0",
74
+ "0.2.0"
75
+ ]
76
+}
77
+```
78
+
79
+#### Caret Dependencies
80
+
81
+If `app`'s `package.json` contains:
82
+
83
+```json
84
+"dependencies": {
85
+ "dep1": "^1.1.1"
86
+}
87
+```
88
+
89
+Then `npm update` will install `dep1@1.2.2`, because `1.2.2` is `latest` and `1.2.2` satisfies `^1.1.1`.
90
+
91
+#### Tilde Dependencies
92
+
93
+However, if `app`'s `package.json` contains:
94
+
95
+```json
96
+"dependencies": {
97
+ "dep1": "~1.1.1"
98
+}
99
+```
100
+
101
+In this case, running `npm update` will install `dep1@1.1.2`. Even though the `latest` tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is equivalent to `>=1.1.1 <1.2.0`. So the highest-sorting version that satisfies `~1.1.1` is used, which is `1.1.2`.
102
+
103
+#### Caret Dependencies below 1.0.0
104
+
105
+Suppose `app` has a caret dependency on a version below `1.0.0`, for example:
106
+
107
+```json
108
+"dependencies": {
109
+ "dep1": "^0.2.0"
110
+}
111
+```
112
+
113
+`npm update` will install `dep1@0.2.0`.
114
+
115
+If the dependence were on `^0.4.0`:
116
+
117
+```json
118
+"dependencies": {
119
+ "dep1": "^0.4.0"
120
+}
121
+```
122
+
123
+Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`)
124
+
125
+#### Subdependencies
126
+
127
+Suppose your app now also has a dependency on `dep2`
128
+
129
+```json
130
+{
131
+ "name": "my-app",
132
+ "dependencies": {
133
+ "dep1": "^1.0.0",
134
+ "dep2": "1.0.0"
135
+ }
136
+}
137
+```
138
+
139
+and `dep2` itself depends on this limited range of `dep1`
140
+
141
+```json
142
+{
143
+ "name": "dep2",
144
+ "dependencies": {
145
+ "dep1": "~1.1.1"
146
+ }
147
+}
148
+```
149
+
150
+Then `npm update` will install `dep1@1.1.2` because that is the highest version that `dep2` allows. npm will prioritize having a single version of `dep1` in your tree rather than two when that single version can satisfy the semver requirements of multiple dependencies in your tree. In this case if you really did need your package to use a newer version you would need to use `npm install`.
151
+
152
+#### Updating Globally-Installed Packages
153
+
154
+`npm update -g` will apply the `update` action to each globally installed package that is `outdated` -- that is, has a version that is different from `wanted`.
155
+
156
+Note: Globally installed packages are treated as if they are installed with a caret semver range specified. So if you require to update to `latest` you may need to run `npm install -g [<pkg>...]`
157
+
158
+NOTE: If a package has been upgraded to a version newer than `latest`, it will be _downgraded_.
159
+
160
+### Configuration
161
+
162
+#### `save`
163
+
164
+- Default: `true` unless when using `npm update` where it defaults to `false`
165
+- Type: Boolean
166
+
167
+Save installed packages to a `package.json` file as dependencies.
168
+
169
+When used with the `npm rm` command, removes the dependency from `package.json`.
170
+
171
+Will also prevent writing to `package-lock.json` if set to `false`.
172
+
173
+#### `global`
174
+
175
+- Default: false
176
+- Type: Boolean
177
+
178
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
179
+
180
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
181
+- bin files are linked to `{prefix}/bin`
182
+- man pages are linked to `{prefix}/share/man`
183
+
184
+#### `install-strategy`
185
+
186
+- Default: "hoisted"
187
+- Type: "hoisted", "nested", "shallow", or "linked"
188
+
189
+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.
190
+
191
+#### `legacy-bundling`
192
+
193
+- Default: false
194
+- Type: Boolean
195
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
196
+
197
+Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
198
+
199
+#### `global-style`
200
+
201
+- Default: false
202
+- Type: Boolean
203
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
204
+
205
+Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
206
+
207
+#### `omit`
208
+
209
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
210
+- Type: "dev", "optional", or "peer" (can be set multiple times)
211
+
212
+Dependency types to omit from the installation tree on disk.
213
+
214
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
215
+
216
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
217
+
218
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
219
+
220
+#### `include`
221
+
222
+- Default:
223
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
224
+
225
+Option that allows for defining which types of dependencies to install.
226
+
227
+This is the inverse of `--omit=<type>`.
228
+
229
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
230
+
231
+#### `strict-peer-deps`
232
+
233
+- Default: false
234
+- Type: Boolean
235
+
236
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
237
+
238
+By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
239
+
240
+When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
241
+
242
+#### `package-lock`
243
+
244
+- Default: true
245
+- Type: Boolean
246
+
247
+If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
248
+
249
+#### `foreground-scripts`
250
+
251
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
252
+- Type: Boolean
253
+
254
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
255
+
256
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
257
+
258
+#### `ignore-scripts`
259
+
260
+- Default: false
261
+- Type: Boolean
262
+
263
+If true, npm does not run scripts specified in package.json files.
264
+
265
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
266
+
267
+#### `audit`
268
+
269
+- Default: true
270
+- Type: Boolean
271
+
272
+When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
273
+
274
+#### `bin-links`
275
+
276
+- Default: true
277
+- Type: Boolean
278
+
279
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
280
+
281
+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.
282
+
283
+#### `fund`
284
+
285
+- Default: true
286
+- Type: Boolean
287
+
288
+When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
289
+
290
+#### `dry-run`
291
+
292
+- Default: false
293
+- Type: Boolean
294
+
295
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
296
+
297
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
298
+
299
+#### `workspace`
300
+
301
+- Default:
302
+- Type: String (can be set multiple times)
303
+
304
+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.
305
+
306
+Valid values for the `workspace` config are either:
307
+
308
+- Workspace names
309
+- Path to a workspace directory
310
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
311
+
312
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
313
+
314
+This value is not exported to the environment for child processes.
315
+
316
+#### `workspaces`
317
+
318
+- Default: null
319
+- Type: null or Boolean
320
+
321
+Set to true to run the command in the context of **all** configured workspaces.
322
+
323
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
324
+
325
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
326
+
327
+This value is not exported to the environment for child processes.
328
+
329
+#### `include-workspace-root`
330
+
331
+- Default: false
332
+- Type: Boolean
333
+
334
+Include the workspace root when workspaces are enabled for a command.
335
+
336
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
337
+
338
+This value is not exported to the environment for child processes.
339
+
340
+#### `install-links`
341
+
342
+- Default: false
343
+- Type: Boolean
344
+
345
+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.
346
+
347
+### See Also
348
+
349
+- [npm install](/cli/v11/commands/npm-install)
350
+- [npm outdated](/cli/v11/commands/npm-outdated)
351
+- [npm shrinkwrap](/cli/v11/commands/npm-shrinkwrap)
352
+- [npm registry](/cli/v11/using-npm/registry)
353
+- [npm folders](/cli/v11/configuring-npm/folders)
354
+- [npm ls](/cli/v11/commands/npm-ls)
content/cli/v11/commands/npm-version.mdx
new
+202
@@ -0,0 +1,202 @@
1
+---
2
+title: npm-version
3
+section: 1
4
+description: Bump a package version
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-version.md
8
+redirect_from:
9
+ - /cli-commands/npm-version
10
+ - /cli-commands/version
11
+ - /cli-documentation/cli-commands/npm-version
12
+ - /cli-documentation/cli-commands/version
13
+ - /cli-documentation/commands/npm-version
14
+ - /cli-documentation/commands/version
15
+ - /cli-documentation/npm-version
16
+ - /cli-documentation/v11/cli-commands/npm-version
17
+ - /cli-documentation/v11/cli-commands/version
18
+ - /cli-documentation/v11/commands/npm-version
19
+ - /cli-documentation/v11/commands/version
20
+ - /cli-documentation/v11/npm-version
21
+ - /cli-documentation/v11/version
22
+ - /cli-documentation/version
23
+ - /cli/cli-commands/npm-version
24
+ - /cli/cli-commands/version
25
+ - /cli/commands/npm-version
26
+ - /cli/commands/version
27
+ - /cli/npm-version
28
+ - /cli/v11/cli-commands/npm-version
29
+ - /cli/v11/cli-commands/version
30
+ - /cli/v11/commands/version
31
+ - /cli/v11/npm-version
32
+ - /cli/v11/version
33
+ - /cli/version
34
+ - /commands/npm-version
35
+ - /commands/version
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease | from-git]
42
+
43
+alias: verison
44
+```
45
+
46
+### Configuration
47
+
48
+#### `allow-same-version`
49
+
50
+- Default: false
51
+- Type: Boolean
52
+
53
+Prevents throwing an error when `npm version` is used to set the new version to the same value as the current version.
54
+
55
+#### `commit-hooks`
56
+
57
+- Default: true
58
+- Type: Boolean
59
+
60
+Run git commit hooks when using the `npm version` command.
61
+
62
+#### `git-tag-version`
63
+
64
+- Default: true
65
+- Type: Boolean
66
+
67
+Tag the commit when using the `npm version` command. Setting this to false results in no commit being made at all.
68
+
69
+#### `json`
70
+
71
+- Default: false
72
+- Type: Boolean
73
+
74
+Whether or not to output JSON data, rather than the normal output.
75
+
76
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
77
+
78
+Not supported by all npm commands.
79
+
80
+#### `preid`
81
+
82
+- Default: ""
83
+- Type: String
84
+
85
+The "prerelease identifier" to use as a prefix for the "prerelease" part of a semver. Like the `rc` in `1.2.0-rc.8`.
86
+
87
+#### `sign-git-tag`
88
+
89
+- Default: false
90
+- Type: Boolean
91
+
92
+If set to true, then the `npm version` command will tag the version using `-s` to add a signature.
93
+
94
+Note that git requires you to have set up GPG keys in your git configs for this to work properly.
95
+
96
+#### `workspace`
97
+
98
+- Default:
99
+- Type: String (can be set multiple times)
100
+
101
+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.
102
+
103
+Valid values for the `workspace` config are either:
104
+
105
+- Workspace names
106
+- Path to a workspace directory
107
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
108
+
109
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
110
+
111
+This value is not exported to the environment for child processes.
112
+
113
+#### `workspaces`
114
+
115
+- Default: null
116
+- Type: null or Boolean
117
+
118
+Set to true to run the command in the context of **all** configured workspaces.
119
+
120
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
121
+
122
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
123
+
124
+This value is not exported to the environment for child processes.
125
+
126
+#### `workspaces-update`
127
+
128
+- Default: true
129
+- Type: Boolean
130
+
131
+If set to true, the npm cli will run an update after operations that may possibly change the workspaces installed to the `node_modules` folder.
132
+
133
+#### `include-workspace-root`
134
+
135
+- Default: false
136
+- Type: Boolean
137
+
138
+Include the workspace root when workspaces are enabled for a command.
139
+
140
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
141
+
142
+This value is not exported to the environment for child processes.
143
+
144
+### Description
145
+
146
+Run this in a package directory to bump the version and write the new data back to `package.json`, `package-lock.json`, and, if present, `npm-shrinkwrap.json`.
147
+
148
+The `newversion` argument should be a valid semver string, a valid second argument to [semver.inc](https://github.com/npm/node-semver#functions) (one of `patch`, `minor`, `major`, `prepatch`, `preminor`, `premajor`, `prerelease`), or `from-git`. In the second case, the existing version will be incremented by 1 in the specified field. `from-git` will try to read the latest git tag, and use that as the new npm version.
149
+
150
+If run in a git repo, it will also create a version commit and tag. This behavior is controlled by `git-tag-version` (see below), and can be disabled on the command line by running `npm --no-git-tag-version version`. It will fail if the working directory is not clean, unless the `-f` or `--force` flag is set.
151
+
152
+If supplied with `-m` or [`--message` config](/cli/v11/using-npm/config#message) option, npm will use it as a commit message when creating a version commit. If the `message` config contains `%s` then that will be replaced with the resulting version number. For example:
153
+
154
+```bash
155
+npm version patch -m "Upgrade to %s for reasons"
156
+```
157
+
158
+If the [`sign-git-tag` config](/cli/v11/using-npm/config#sign-git-tag) is set, then the tag will be signed using the `-s` flag to git. Note that you must have a default GPG key set up in your git config for this to work properly. For example:
159
+
160
+```bash
161
+$ npm config set sign-git-tag true
162
+$ npm version patch
163
+
164
+You need a passphrase to unlock the secret key for
165
+user: "isaacs (http://blog.izs.me/) <i@izs.me>"
166
+2048-bit RSA key, ID 6C481CF6, created 2010-08-31
167
+
168
+Enter passphrase:
169
+```
170
+
171
+If `preversion`, `version`, or `postversion` are in the `scripts` property of the package.json, they will be executed as part of running `npm version`.
172
+
173
+The exact order of execution is as follows:
174
+
175
+1. Check to make sure the git working directory is clean before we get started. Your scripts may add files to the commit in future steps. This step is skipped if the `--force` flag is set.
176
+2. Run the `preversion` script. These scripts have access to the old `version` in package.json. A typical use would be running your full test suite before deploying. Any files you want added to the commit should be explicitly added using `git add`.
177
+3. Bump `version` in `package.json` as requested (`patch`, `minor`, `major`, etc).
178
+4. Run the `version` script. These scripts have access to the new `version` in package.json (so they can incorporate it into file headers in generated files for example). Again, scripts should explicitly add generated files to the commit using `git add`.
179
+5. Commit and tag.
180
+6. Run the `postversion` script. Use it to clean up the file system or automatically push the commit and/or tag.
181
+
182
+Take the following example:
183
+
184
+```json
185
+{
186
+ "scripts": {
187
+ "preversion": "npm test",
188
+ "version": "npm run build && git add -A dist",
189
+ "postversion": "git push && git push --tags && rm -rf build/temp"
190
+ }
191
+}
192
+```
193
+
194
+This runs all your tests and proceeds only if they pass. Then runs your `build` script, and adds everything in the `dist` directory to the commit. After the commit, it pushes the new commit and tag up to the server, and deletes the `build/temp` directory.
195
+
196
+### See Also
197
+
198
+- [npm init](/cli/v11/commands/npm-init)
199
+- [npm run-script](/cli/v11/commands/npm-run-script)
200
+- [npm scripts](/cli/v11/using-npm/scripts)
201
+- [package.json](/cli/v11/configuring-npm/package-json)
202
+- [config](/cli/v11/using-npm/config)
content/cli/v11/commands/npm-view.mdx
new
+195
@@ -0,0 +1,195 @@
1
+---
2
+title: npm-view
3
+section: 1
4
+description: View registry info
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-view.md
8
+redirect_from:
9
+ - /cli-commands/npm-view
10
+ - /cli-commands/view
11
+ - /cli-documentation/cli-commands/npm-view
12
+ - /cli-documentation/cli-commands/view
13
+ - /cli-documentation/commands/npm-view
14
+ - /cli-documentation/commands/view
15
+ - /cli-documentation/npm-view
16
+ - /cli-documentation/v11/cli-commands/npm-view
17
+ - /cli-documentation/v11/cli-commands/view
18
+ - /cli-documentation/v11/commands/npm-view
19
+ - /cli-documentation/v11/commands/view
20
+ - /cli-documentation/v11/npm-view
21
+ - /cli-documentation/v11/view
22
+ - /cli-documentation/view
23
+ - /cli/cli-commands/npm-view
24
+ - /cli/cli-commands/view
25
+ - /cli/commands/npm-view
26
+ - /cli/commands/view
27
+ - /cli/npm-view
28
+ - /cli/v11/cli-commands/npm-view
29
+ - /cli/v11/cli-commands/view
30
+ - /cli/v11/commands/view
31
+ - /cli/v11/npm-view
32
+ - /cli/v11/view
33
+ - /cli/view
34
+ - /commands/npm-view
35
+ - /commands/view
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm view [<package-spec>] [<field>[.subfield]...]
42
+
43
+aliases: info, show, v
44
+```
45
+
46
+### Description
47
+
48
+This command shows data about a package and prints it to stdout.
49
+
50
+As an example, to view information about the `connect` package from the registry, you would run:
51
+
52
+```bash
53
+npm view connect
54
+```
55
+
56
+The default version is `"latest"` if unspecified.
57
+
58
+Field names can be specified after the package descriptor. For example, to show the dependencies of the `ronn` package at version `0.3.5`, you could do the following:
59
+
60
+```bash
61
+npm view ronn@0.3.5 dependencies
62
+```
63
+
64
+By default, `npm view` shows data about the current project context (by looking for a `package.json`). To show field data for the current project use a file path (i.e. `.`):
65
+
66
+```bash
67
+npm view . dependencies
68
+```
69
+
70
+You can view child fields by separating them with a period. To view the git repository URL for the latest version of `npm`, you would run the following command:
71
+
72
+```bash
73
+npm view npm repository.url
74
+```
75
+
76
+This makes it easy to view information about a dependency with a bit of shell scripting. For example, to view all the data about the version of `opts` that `ronn` depends on, you could write the following:
77
+
78
+```bash
79
+npm view opts@$(npm view ronn dependencies.opts)
80
+```
81
+
82
+For fields that are arrays, requesting a non-numeric field will return all of the values from the objects in the list. For example, to get all the contributor email addresses for the `express` package, you would run:
83
+
84
+```bash
85
+npm view express contributors.email
86
+```
87
+
88
+You may also use numeric indices in square braces to specifically select an item in an array field. To just get the email address of the first contributor in the list, you can run:
89
+
90
+```bash
91
+npm view express contributors[0].email
92
+```
93
+
94
+If the field value you are querying for is a property of an object, you should run:
95
+
96
+```bash
97
+npm view express time'[4.8.0]'
98
+```
99
+
100
+Multiple fields may be specified, and will be printed one after another. For example, to get all the contributor names and email addresses, you can do this:
101
+
102
+```bash
103
+npm view express contributors.name contributors.email
104
+```
105
+
106
+"Person" fields are shown as a string if they would be shown as an object. So, for example, this will show the list of `npm` contributors in the shortened string format. (See [`package.json`](/cli/v11/configuring-npm/package-json) for more on this.)
107
+
108
+```bash
109
+npm view npm contributors
110
+```
111
+
112
+If a version range is provided, then data will be printed for every matching version of the package. This will show which version of `jsdom` was required by each matching version of `yui3`:
113
+
114
+```bash
115
+npm view yui3@'>0.5.4' dependencies.jsdom
116
+```
117
+
118
+To show the `connect` package version history, you can do this:
119
+
120
+```bash
121
+npm view connect versions
122
+```
123
+
124
+### Configuration
125
+
126
+#### `json`
127
+
128
+- Default: false
129
+- Type: Boolean
130
+
131
+Whether or not to output JSON data, rather than the normal output.
132
+
133
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
134
+
135
+Not supported by all npm commands.
136
+
137
+#### `workspace`
138
+
139
+- Default:
140
+- Type: String (can be set multiple times)
141
+
142
+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.
143
+
144
+Valid values for the `workspace` config are either:
145
+
146
+- Workspace names
147
+- Path to a workspace directory
148
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
149
+
150
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
151
+
152
+This value is not exported to the environment for child processes.
153
+
154
+#### `workspaces`
155
+
156
+- Default: null
157
+- Type: null or Boolean
158
+
159
+Set to true to run the command in the context of **all** configured workspaces.
160
+
161
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
162
+
163
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
164
+
165
+This value is not exported to the environment for child processes.
166
+
167
+#### `include-workspace-root`
168
+
169
+- Default: false
170
+- Type: Boolean
171
+
172
+Include the workspace root when workspaces are enabled for a command.
173
+
174
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
175
+
176
+This value is not exported to the environment for child processes.
177
+
178
+### Output
179
+
180
+If only a single string field for a single version is output, then it will not be colorized or quoted, to enable piping the output to another command. If the field is an object, it will be output as a JavaScript object literal.
181
+
182
+If the `--json` flag is given, the outputted fields will be JSON.
183
+
184
+If the version range matches multiple versions then each printed value will be prefixed with the version it applies to.
185
+
186
+If multiple fields are requested, then each of them is prefixed with the field name.
187
+
188
+### See Also
189
+
190
+- [package spec](/cli/v11/using-npm/package-spec)
191
+- [npm search](/cli/v11/commands/npm-search)
192
+- [npm registry](/cli/v11/using-npm/registry)
193
+- [npm config](/cli/v11/commands/npm-config)
194
+- [npmrc](/cli/v11/configuring-npm/npmrc)
195
+- [npm docs](/cli/v11/commands/npm-docs)
content/cli/v11/commands/npm-whoami.mdx
new
+67
@@ -0,0 +1,67 @@
1
+---
2
+title: npm-whoami
3
+section: 1
4
+description: Display npm username
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm-whoami.md
8
+redirect_from:
9
+ - /cli-commands/npm-whoami
10
+ - /cli-commands/whoami
11
+ - /cli-documentation/cli-commands/npm-whoami
12
+ - /cli-documentation/cli-commands/whoami
13
+ - /cli-documentation/commands/npm-whoami
14
+ - /cli-documentation/commands/whoami
15
+ - /cli-documentation/npm-whoami
16
+ - /cli-documentation/v11/cli-commands/npm-whoami
17
+ - /cli-documentation/v11/cli-commands/whoami
18
+ - /cli-documentation/v11/commands/npm-whoami
19
+ - /cli-documentation/v11/commands/whoami
20
+ - /cli-documentation/v11/npm-whoami
21
+ - /cli-documentation/v11/whoami
22
+ - /cli-documentation/whoami
23
+ - /cli/cli-commands/npm-whoami
24
+ - /cli/cli-commands/whoami
25
+ - /cli/commands/npm-whoami
26
+ - /cli/commands/whoami
27
+ - /cli/npm-whoami
28
+ - /cli/v11/cli-commands/npm-whoami
29
+ - /cli/v11/cli-commands/whoami
30
+ - /cli/v11/commands/whoami
31
+ - /cli/v11/npm-whoami
32
+ - /cli/v11/whoami
33
+ - /cli/whoami
34
+ - /commands/npm-whoami
35
+ - /commands/whoami
36
+---
37
+
38
+### Synopsis
39
+
40
+```bash
41
+npm whoami
42
+```
43
+
44
+Note: This command is unaware of workspaces.
45
+
46
+### Description
47
+
48
+Display the npm username of the currently logged-in user.
49
+
50
+If logged into a registry that provides token-based authentication, then connect to the `/-/whoami` registry endpoint to find the username associated with the token, and print to standard output.
51
+
52
+If logged into a registry that uses Basic Auth, then simply print the `username` portion of the authentication string.
53
+
54
+### Configuration
55
+
56
+#### `registry`
57
+
58
+- Default: "https://registry.npmjs.org/"
59
+- Type: URL
60
+
61
+The base URL of the npm registry.
62
+
63
+### See Also
64
+
65
+- [npm config](/cli/v11/commands/npm-config)
66
+- [npmrc](/cli/v11/configuring-npm/npmrc)
67
+- [npm adduser](/cli/v11/commands/npm-adduser)
content/cli/v11/commands/npm.mdx
new
+129
@@ -0,0 +1,129 @@
1
+---
2
+title: npm
3
+section: 1
4
+description: javascript package manager
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npm.md
8
+redirect_from:
9
+ - /cli-commands/npm
10
+ - /cli-documentation/cli-commands/npm
11
+ - /cli-documentation/commands/npm
12
+ - /cli-documentation/npm
13
+ - /cli-documentation/v11/cli-commands/npm
14
+ - /cli-documentation/v11/commands/npm
15
+ - /cli-documentation/v11/npm
16
+ - /cli/cli-commands/npm
17
+ - /cli/commands/npm
18
+ - /cli/npm
19
+ - /cli/v11/cli-commands/npm
20
+ - /cli/v11/npm
21
+ - /commands/npm
22
+---
23
+
24
+### Synopsis
25
+
26
+```bash
27
+npm
28
+```
29
+
30
+Note: This command is unaware of workspaces.
31
+
32
+### Version
33
+
34
+11.0.0
35
+
36
+### Description
37
+
38
+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.
39
+
40
+It is extremely configurable to support a variety of use cases. Most commonly, you use it to publish, discover, install, and develop node programs.
41
+
42
+Run `npm help` to get a list of available commands.
43
+
44
+### Important
45
+
46
+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.
47
+
48
+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.
49
+
50
+### Introduction
51
+
52
+You probably got npm because you want to install stuff.
53
+
54
+The very first thing you will most likely want to run in any node program is `npm install` to install its dependencies.
55
+
56
+You can also run `npm install blerg` to install the latest version of "blerg". Check out [`npm install`](/cli/v11/commands/npm-install) for more info. It can do a lot of stuff.
57
+
58
+Use the `npm search` command to show everything that's available in the public registry. Use `npm ls` to show everything you've installed.
59
+
60
+### Dependencies
61
+
62
+If a package lists a dependency using a git URL, npm will install that dependency using the [`git`](https://github.com/git-guides/install-git) command and will generate an error if it is not installed.
63
+
64
+If one of the packages npm tries to install is a native node module and requires compiling of C++ Code, npm will use [node-gyp](https://github.com/nodejs/node-gyp) for that task. For a Unix system, [node-gyp](https://github.com/nodejs/node-gyp) needs Python, make and a buildchain like GCC. On Windows, Python and Microsoft Visual Studio C++ are needed. For more information visit [the node-gyp repository](https://github.com/nodejs/node-gyp) and the [node-gyp Wiki](https://github.com/nodejs/node-gyp/wiki).
65
+
66
+### Directories
67
+
68
+See [`folders`](/cli/v11/configuring-npm/folders) to learn about where npm puts stuff.
69
+
70
+In particular, npm has two modes of operation:
71
+
72
+- local mode: npm installs packages into the current project directory, which defaults to the current working directory. Packages install to `./node_modules`, and bins to `./node_modules/.bin`.
73
+- global mode: npm installs packages into the install prefix at `$npm_config_prefix/lib/node_modules` and bins to `$npm_config_prefix/bin`.
74
+
75
+Local mode is the default. Use `-g` or `--global` on any command to run in global mode instead.
76
+
77
+### Developer Usage
78
+
79
+If you're using npm to develop and publish your code, check out the following help topics:
80
+
81
+- json: Make a package.json file. See [`package.json`](/cli/v11/configuring-npm/package-json).
82
+- link: Links your current working code into Node's path, so that you don't have to reinstall every time you make a change. Use [`npm link`](/cli/v11/commands/npm-link) to do this.
83
+- install: It's a good idea to install things if you don't need the symbolic link. Especially, installing other peoples code from the registry is done via [`npm install`](/cli/v11/commands/npm-install)
84
+- adduser: Create an account or log in. When you do this, npm will store credentials in the user config file.
85
+- publish: Use the [`npm publish`](/cli/v11/commands/npm-publish) command to upload your code to the registry.
86
+
87
+#### Configuration
88
+
89
+npm is extremely configurable. It reads its configuration options from 5 places.
90
+
91
+- Command line switches: Set a config with `--key val`. All keys take a value, even if they are booleans (the config parser doesn't know what the options are at the time of parsing). If you do not provide a value (`--key`) then the option is set to boolean `true`.
92
+- Environment Variables: Set any config by prefixing the name in an environment variable with `npm_config_`. For example, `export npm_config_key=val`.
93
+- User Configs: The file at `$HOME/.npmrc` is an ini-formatted list of configs. If present, it is parsed. If the `userconfig` option is set in the cli or env, that file will be used instead.
94
+- Global Configs: The file found at `./etc/npmrc` (relative to the global prefix will be parsed if it is found. See [`npm prefix`](/cli/v11/commands/npm-prefix) for more info on the global prefix. If the `globalconfig` option is set in the cli, env, or user config, then that file is parsed instead.
95
+- Defaults: npm's default configuration options are defined in `lib/utils/config/definitions.js`. These must not be changed.
96
+
97
+See [`config`](/cli/v11/using-npm/config) for much much more information.
98
+
99
+### Contributions
100
+
101
+Patches welcome!
102
+
103
+If you would like to help, but don't know what to work on, read the [contributing guidelines](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md) and check the issues list.
104
+
105
+### Bugs
106
+
107
+When you find issues, please report them: [https://github.com/npm/cli/issues](https://github.com/npm/cli/issues)
108
+
109
+Please be sure to follow the template and bug reporting guidelines.
110
+
111
+### Feature Requests
112
+
113
+Discuss new feature ideas on our discussion forum:
114
+
115
+- [https://github.com/orgs/community/discussions/categories/npm](https://github.com/orgs/community/discussions/categories/npm)
116
+
117
+Or suggest formal RFC proposals:
118
+
119
+- [https://github.com/npm/rfcs](https://github.com/npm/rfcs)
120
+
121
+### See Also
122
+
123
+- [npm help](/cli/v11/commands/npm-help)
124
+- [package.json](/cli/v11/configuring-npm/package-json)
125
+- [npmrc](/cli/v11/configuring-npm/npmrc)
126
+- [npm config](/cli/v11/commands/npm-config)
127
+- [npm install](/cli/v11/commands/npm-install)
128
+- [npm prefix](/cli/v11/commands/npm-prefix)
129
+- [npm publish](/cli/v11/commands/npm-publish)
content/cli/v11/commands/npx.mdx
new
+137
@@ -0,0 +1,137 @@
1
+---
2
+title: npx
3
+section: 1
4
+description: Run a command from a local or remote npm package
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/commands/npx.md
8
+redirect_from:
9
+ - /cli-commands/npx
10
+ - /cli-documentation/cli-commands/npx
11
+ - /cli-documentation/commands/npx
12
+ - /cli-documentation/npx
13
+ - /cli-documentation/v11/cli-commands/npx
14
+ - /cli-documentation/v11/commands/npx
15
+ - /cli-documentation/v11/npx
16
+ - /cli/cli-commands/npx
17
+ - /cli/commands/npx
18
+ - /cli/npx
19
+ - /cli/v11/cli-commands/npx
20
+ - /cli/v11/npx
21
+ - /commands/npx
22
+---
23
+
24
+### Synopsis
25
+
26
+```bash
27
+npx -- <pkg>[@<version>] [args...]
28
+npx --package=<pkg>[@<version>] -- <cmd> [args...]
29
+npx -c '<cmd> [args...]'
30
+npx --package=foo -c '<cmd> [args...]'
31
+```
32
+
33
+### Description
34
+
35
+This command allows you to run an arbitrary command from an npm package (either one installed locally, or fetched remotely), in a similar context as running it via `npm run`.
36
+
37
+Whatever packages are specified by the `--package` option will be provided in the `PATH` of the executed command, along with any locally installed package executables. The `--package` option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available.
38
+
39
+If any requested packages are not present in the local project dependencies, then they are installed to a folder in the npm cache, which is added to the `PATH` environment variable in the executed process. A prompt is printed (which can be suppressed by providing either `--yes` or `--no`).
40
+
41
+Package names provided without a specifier will be matched with whatever version exists in the local project. Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency.
42
+
43
+If no `-c` or `--call` option is provided, then the positional arguments are used to generate the command string. If no `--package` options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic:
44
+
45
+- If the package has a single entry in its `bin` field in `package.json`, or if all entries are aliases of the same command, then that command will be used.
46
+- If the package has multiple `bin` entries, and one of them matches the unscoped portion of the `name` field, then that command will be used.
47
+- If this does not result in exactly one option (either because there are no bin entries, or none of them match the `name` of the package), then `npm exec` exits with an error.
48
+
49
+To run a binary _other than_ the named binary, specify one or more `--package` options, which will prevent npm from inferring the package from the first command argument.
50
+
51
+### `npx` vs `npm exec`
52
+
53
+When run via the `npx` binary, all flags and options _must_ be set prior to any positional arguments. When run via `npm exec`, a double-hyphen `--` flag can be used to suppress npm's parsing of switches and options that should be sent to the executed command.
54
+
55
+For example:
56
+
57
+```
58
+$ npx foo@latest bar --package=@npmcli/foo
59
+```
60
+
61
+In this case, npm will resolve the `foo` package name, and run the following command:
62
+
63
+```
64
+$ foo bar --package=@npmcli/foo
65
+```
66
+
67
+Since the `--package` option comes _after_ the positional arguments, it is treated as an argument to the executed command.
68
+
69
+In contrast, due to npm's argument parsing logic, running this command is different:
70
+
71
+```
72
+$ npm exec foo@latest bar --package=@npmcli/foo
73
+```
74
+
75
+In this case, npm will parse the `--package` option first, resolving the `@npmcli/foo` package. Then, it will execute the following command in that context:
76
+
77
+```
78
+$ foo@latest bar
79
+```
80
+
81
+The double-hyphen character is recommended to explicitly tell npm to stop parsing command line options and switches. The following command would thus be equivalent to the `npx` command above:
82
+
83
+```
84
+$ npm exec -- foo@latest bar --package=@npmcli/foo
85
+```
86
+
87
+### Examples
88
+
89
+Run the version of `tap` in the local dependencies, with the provided arguments:
90
+
91
+```
92
+$ npm exec -- tap --bail test/foo.js
93
+$ npx tap --bail test/foo.js
94
+```
95
+
96
+Run a command _other than_ the command whose name matches the package name by specifying a `--package` option:
97
+
98
+```
99
+$ npm exec --package=foo -- bar --bar-argument
100
+# ~ or ~
101
+$ npx --package=foo bar --bar-argument
102
+```
103
+
104
+Run an arbitrary shell script, in the context of the current project:
105
+
106
+```
107
+$ npm x -c 'eslint && say "hooray, lint passed"'
108
+$ npx -c 'eslint && say "hooray, lint passed"'
109
+```
110
+
111
+### Compatibility with Older npx Versions
112
+
113
+The `npx` binary was rewritten in npm v7.0.0, and the standalone `npx` package deprecated at that time. `npx` uses the `npm exec` command instead of a separate argument parser and install process, with some affordances to maintain backwards compatibility with the arguments it accepted in previous versions.
114
+
115
+This resulted in some shifts in its functionality:
116
+
117
+- Any `npm` config value may be provided.
118
+- To prevent security and user-experience problems from mistyping package names, `npx` prompts before installing anything. Suppress this prompt with the `-y` or `--yes` option.
119
+- The `--no-install` option is deprecated, and will be converted to `--no`.
120
+- Shell fallback functionality is removed, as it is not advisable.
121
+- The `-p` argument is a shorthand for `--parseable` in npm, but shorthand for `--package` in npx. This is maintained, but only for the `npx` executable.
122
+- The `--ignore-existing` option is removed. Locally installed bins are always present in the executed process `PATH`.
123
+- The `--npm` option is removed. `npx` will always use the `npm` it ships with.
124
+- The `--node-arg` and `-n` options have been removed. Use [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions) instead: e.g., `NODE_OPTIONS="--trace-warnings --trace-exit" npx foo --random=true`
125
+- The `--always-spawn` option is redundant, and thus removed.
126
+- The `--shell` option is replaced with `--script-shell`, but maintained in the `npx` executable for backwards compatibility.
127
+
128
+### See Also
129
+
130
+- [npm run-script](/cli/v11/commands/npm-run-script)
131
+- [npm scripts](/cli/v11/using-npm/scripts)
132
+- [npm test](/cli/v11/commands/npm-test)
133
+- [npm start](/cli/v11/commands/npm-start)
134
+- [npm restart](/cli/v11/commands/npm-restart)
135
+- [npm stop](/cli/v11/commands/npm-stop)
136
+- [npm config](/cli/v11/commands/npm-config)
137
+- [npm exec](/cli/v11/commands/npm-exec)
content/cli/v11/configuring-npm/folders.mdx
new
+161
@@ -0,0 +1,161 @@
1
+---
2
+title: folders
3
+section: 5
4
+description: Folder Structures Used by npm
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/configuring-npm/folders.md
8
+redirect_from:
9
+ - /cli-documentation/configuring-npm/folders
10
+ - /cli-documentation/files/folders
11
+ - /cli-documentation/v11/configuring-npm/folders
12
+ - /cli-documentation/v11/files/folders
13
+ - /cli/configuring-npm/folders
14
+ - /cli/files/folders
15
+ - /cli/v11/files/folders
16
+ - /configuring-npm/folders
17
+ - /files/folders
18
+---
19
+
20
+### Description
21
+
22
+npm puts various things on your computer. That's its job.
23
+
24
+This document will tell you what it puts where.
25
+
26
+#### tl;dr
27
+
28
+- Local install (default): puts stuff in `./node_modules` of the current package root.
29
+- Global install (with `-g`): puts stuff in /usr/local or wherever node is installed.
30
+- Install it **locally** if you're going to `require()` it.
31
+- Install it **globally** if you're going to run it on the command line.
32
+- If you need both, then install it in both places, or use `npm link`.
33
+
34
+#### prefix Configuration
35
+
36
+The [`prefix` config](/cli/v11/using-npm/config#prefix) defaults to the location where node is installed. On most systems, this is `/usr/local`. On Windows, it's `%AppData%\npm`. On Unix systems, it's one level up, since node is typically installed at `{prefix}/bin/node` rather than `{prefix}/node.exe`.
37
+
38
+When the `global` flag is set, npm installs things into this prefix. When it is not set, it uses the root of the current package, or the current working directory if not in a package already.
39
+
40
+#### Node Modules
41
+
42
+Packages are dropped into the `node_modules` folder under the `prefix`. When installing locally, this means that you can `require("packagename")` to load its main module, or `require("packagename/lib/path/to/sub/module")` to load other modules.
43
+
44
+Global installs on Unix systems go to `{prefix}/lib/node_modules`. Global installs on Windows go to `{prefix}/node_modules` (that is, no `lib` folder.)
45
+
46
+Scoped packages are installed the same way, except they are grouped together in a sub-folder of the relevant `node_modules` folder with the name of that scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place the package in `{prefix}/node_modules/@myorg/package`. See [`scope`](/cli/v11/using-npm/scope) for more details.
47
+
48
+If you wish to `require()` a package, then install it locally.
49
+
50
+#### Executables
51
+
52
+When in global mode, executables are linked into `{prefix}/bin` on Unix, or directly into `{prefix}` on Windows. Ensure that path is in your terminal's `PATH` environment to run them.
53
+
54
+When in local mode, executables are linked into `./node_modules/.bin` so that they can be made available to scripts run through npm. (For example, so that a test runner will be in the path when you run `npm test`.)
55
+
56
+#### Man Pages
57
+
58
+When in global mode, man pages are linked into `{prefix}/share/man`.
59
+
60
+When in local mode, man pages are not installed.
61
+
62
+Man pages are not installed on Windows systems.
63
+
64
+#### Cache
65
+
66
+See [`npm cache`](/cli/v11/commands/npm-cache). Cache files are stored in `~/.npm` on Posix, or `%LocalAppData%/npm-cache` on Windows.
67
+
68
+This is controlled by the [`cache` config](/cli/v11/using-npm/config#cache) param.
69
+
70
+#### Temp Files
71
+
72
+Temporary files are stored by default in the folder specified by the [`tmp` config](/cli/v11/using-npm/config#tmp), which defaults to the TMPDIR, TMP, or TEMP environment variables, or `/tmp` on Unix and `c:\windows\temp` on Windows.
73
+
74
+Temp files are given a unique folder under this root for each run of the program, and are deleted upon successful exit.
75
+
76
+### More Information
77
+
78
+When installing locally, npm first tries to find an appropriate `prefix` folder. This is so that `npm install foo@1.2.3` will install to the sensible root of your package, even if you happen to have `cd`ed into some other folder.
79
+
80
+Starting at the $PWD, npm will walk up the folder tree checking for a folder that contains either a `package.json` file, or a `node_modules` folder. If such a thing is found, then that is treated as the effective "current directory" for the purpose of running npm commands. (This behavior is inspired by and similar to git's .git-folder seeking logic when running git commands in a working dir.)
81
+
82
+If no package root is found, then the current folder is used.
83
+
84
+When you run `npm install foo@1.2.3`, then the package is loaded into the cache, and then unpacked into `./node_modules/foo`. Then, any of foo's dependencies are similarly unpacked into `./node_modules/foo/node_modules/...`.
85
+
86
+Any bin files are symlinked to `./node_modules/.bin/`, so that they may be found by npm scripts when necessary.
87
+
88
+#### Global Installation
89
+
90
+If the [`global` config](/cli/v11/using-npm/config#global) is set to true, then npm will install packages "globally".
91
+
92
+For global installation, packages are installed roughly the same way, but using the folders described above.
93
+
94
+#### Cycles, Conflicts, and Folder Parsimony
95
+
96
+Cycles are handled using the property of node's module system that it walks up the directories looking for `node_modules` folders. So, at every stage, if a package is already installed in an ancestor `node_modules` folder, then it is not installed at the current location.
97
+
98
+Consider the case above, where `foo -> bar -> baz`. Imagine if, in addition to that, baz depended on bar, so you'd have: `foo -> bar -> baz -> bar -> baz ...`. However, since the folder structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to put another copy of bar into `.../baz/node_modules`, since when baz calls `require("bar")`, it will get the copy that is installed in `foo/node_modules/bar`.
99
+
100
+This shortcut is only used if the exact same version would be installed in multiple nested `node_modules` folders. It is still possible to have `a/node_modules/b/node_modules/a` if the two "a" packages are different versions. However, without repeating the exact same package multiple times, an infinite regress will always be prevented.
101
+
102
+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.
103
+
104
+#### Example
105
+
106
+Consider this dependency graph:
107
+
108
+```bash
109
+foo
110
++-- blerg@1.2.5
111
++-- bar@1.2.3
112
+| +-- blerg@1.x (latest=1.3.7)
113
+| +-- baz@2.x
114
+| | `-- quux@3.x
115
+| | `-- bar@1.2.3 (cycle)
116
+| `-- asdf@*
117
+`-- baz@1.2.3
118
+ `-- quux@3.x
119
+ `-- bar
120
+```
121
+
122
+In this case, we might expect a folder structure like this (with all dependencies hoisted to the highest level possible):
123
+
124
+```bash
125
+foo
126
++-- node_modules
127
+ +-- blerg (1.2.5) <---[A]
128
+ +-- bar (1.2.3) <---[B]
129
+ | +-- node_modules
130
+ | +-- baz (2.0.2) <---[C]
131
+ +-- asdf (2.3.4)
132
+ +-- baz (1.2.3) <---[D]
133
+ +-- quux (3.2.0) <---[E]
134
+```
135
+
136
+Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are installed in foo's `node_modules` folder.
137
+
138
+Even though the latest copy of blerg is 1.3.7, foo has a specific dependency on version 1.2.5. So, that gets installed at [A]. Since the parent installation of blerg satisfies bar's dependency on `blerg@1.x`, it does not install another copy under [B].
139
+
140
+Bar [B] also has dependencies on baz and asdf. Because it depends on `baz@2.x`, it cannot re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D], and must install its own copy [C]. In order to minimize duplication, npm hoists dependencies to the top level by default, so asdf is installed under [A].
141
+
142
+Underneath bar, the `baz -> quux -> bar` dependency creates a cycle. However, because bar is already in quux's ancestry [B], it does not unpack another copy of bar into that folder. Likewise, quux's [E] folder tree is empty, because its dependency on bar is satisfied by the parent folder copy installed at [B].
143
+
144
+For a graphical breakdown of what is installed where, use `npm ls`.
145
+
146
+#### Publishing
147
+
148
+Upon publishing, npm will look in the `node_modules` folder. If any of the items there are not in the `bundleDependencies` array, then they will not be included in the package tarball.
149
+
150
+This allows a package maintainer to install all of their dependencies (and dev dependencies) locally, but only re-publish those items that cannot be found elsewhere. See [`package.json`](/cli/v11/configuring-npm/package-json) for more information.
151
+
152
+### See also
153
+
154
+- [package.json](/cli/v11/configuring-npm/package-json)
155
+- [npm install](/cli/v11/commands/npm-install)
156
+- [npm pack](/cli/v11/commands/npm-pack)
157
+- [npm cache](/cli/v11/commands/npm-cache)
158
+- [npm config](/cli/v11/commands/npm-config)
159
+- [npmrc](/cli/v11/configuring-npm/npmrc)
160
+- [config](/cli/v11/using-npm/config)
161
+- [npm publish](/cli/v11/commands/npm-publish)
content/cli/v11/configuring-npm/index.mdx
new
+29
@@ -0,0 +1,29 @@
1
+---
2
+title: Configuring npm
3
+shortName: Configuring
4
+github_repo: npm/cli
5
+github_branch: latest
6
+github_path: docs/lib/content/nav.yml
7
+redirect_from:
8
+ - /cli-documentation/configuring-npm
9
+ - /cli-documentation/configuring-npm/index
10
+ - /cli-documentation/files
11
+ - /cli-documentation/files/index
12
+ - /cli-documentation/v11/configuring-npm
13
+ - /cli-documentation/v11/configuring-npm/index
14
+ - /cli-documentation/v11/files
15
+ - /cli-documentation/v11/files/index
16
+ - /cli/configuring-npm
17
+ - /cli/configuring-npm/index
18
+ - /cli/files
19
+ - /cli/files/index
20
+ - /cli/v11/configuring-npm/index
21
+ - /cli/v11/files
22
+ - /cli/v11/files/index
23
+ - /configuring-npm
24
+ - /configuring-npm/index
25
+ - /files
26
+ - /files/index
27
+---
28
+
29
+<Index depth="1" />
content/cli/v11/configuring-npm/install.mdx
new
+67
@@ -0,0 +1,67 @@
1
+---
2
+title: install
3
+section: 5
4
+description: Download and install node and npm
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/configuring-npm/install.md
8
+redirect_from:
9
+ - /cli-documentation/configuring-npm/install
10
+ - /cli-documentation/files/install
11
+ - /cli-documentation/v11/configuring-npm/install
12
+ - /cli-documentation/v11/files/install
13
+ - /cli/configuring-npm/install
14
+ - /cli/files/install
15
+ - /cli/v11/files/install
16
+ - /configuring-npm/install
17
+ - /files/install
18
+---
19
+
20
+### Description
21
+
22
+To publish and install packages to and from the public npm registry, you must install Node.js and the npm command line interface using either a Node version manager or a Node installer. **We strongly recommend using a Node version manager to install Node.js and npm.** We do not recommend using a Node installer, since the Node installation process installs npm in a directory with local permissions and can cause permissions errors when you run npm packages globally.
23
+
24
+### Overview
25
+
26
+- [Checking your version of npm and Node.js](#checking-your-version-of-npm-and-nodejs)
27
+- [Using a Node version manager to install Node.js and npm](#using-a-node-version-manager-to-install-nodejs-and-npm)
28
+- [Using a Node installer to install Node.js and npm](#using-a-node-installer-to-install-nodejs-and-npm)
29
+
30
+### Checking your version of npm and Node.js
31
+
32
+To see if you already have Node.js and npm installed and check the installed version, run the following commands:
33
+
34
+```
35
+node -v
36
+npm -v
37
+```
38
+
39
+### Using a Node version manager to install Node.js and npm
40
+
41
+Node version managers allow you to install and switch between multiple versions of Node.js and npm on your system so you can test your applications on multiple versions of npm to ensure they work for users on different versions. You can [search for them on GitHub](https://github.com/search?q=node+version+manager+archived%3Afalse&type=repositories&ref=advsearch).
42
+
43
+### Using a Node installer to install Node.js and npm
44
+
45
+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.
46
+
47
+- [Node.js installer](https://nodejs.org/en/download/)
48
+- [NodeSource installer](https://github.com/nodesource/distributions). If you use Linux, we recommend that you use a NodeSource installer.
49
+
50
+#### OS X or Windows Node installers
51
+
52
+If you're using OS X or Windows, use one of the installers from the [Node.js download page](https://nodejs.org/en/download/). Be sure to install the version labeled **LTS**. Other versions have not yet been tested with npm.
53
+
54
+#### Linux or other operating systems Node installers
55
+
56
+If you're using Linux or another operating system, use one of the following installers:
57
+
58
+- [NodeSource installer](https://github.com/nodesource/distributions) (recommended)
59
+- One of the installers on the [Node.js download page](https://nodejs.org/en/download/)
60
+
61
+Or see [this page](https://nodejs.org/en/download/package-manager/) to install npm for Linux in the way many Linux developers prefer.
62
+
63
+#### Less-common operating systems
64
+
65
+For more information on installing Node.js on a variety of operating systems, see [this page][pkg-mgr].
66
+
67
+[pkg-mgr]: https://nodejs.org/en/download/package-manager/
content/cli/v11/configuring-npm/npm-shrinkwrap-json.mdx
new
+45
@@ -0,0 +1,45 @@
1
+---
2
+title: npm-shrinkwrap.json
3
+section: 5
4
+description: A publishable lockfile
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/configuring-npm/npm-shrinkwrap-json.md
8
+redirect_from:
9
+ - /cli-documentation/configuring-npm/npm-shrinkwrap-json
10
+ - /cli-documentation/configuring-npm/npm-shrinkwrap.json
11
+ - /cli-documentation/files/npm-shrinkwrap-json
12
+ - /cli-documentation/files/npm-shrinkwrap.json
13
+ - /cli-documentation/v11/configuring-npm/npm-shrinkwrap-json
14
+ - /cli-documentation/v11/configuring-npm/npm-shrinkwrap.json
15
+ - /cli-documentation/v11/files/npm-shrinkwrap-json
16
+ - /cli-documentation/v11/files/npm-shrinkwrap.json
17
+ - /cli/configuring-npm/npm-shrinkwrap-json
18
+ - /cli/configuring-npm/npm-shrinkwrap.json
19
+ - /cli/files/npm-shrinkwrap-json
20
+ - /cli/files/npm-shrinkwrap.json
21
+ - /cli/v11/configuring-npm/npm-shrinkwrap.json
22
+ - /cli/v11/files/npm-shrinkwrap-json
23
+ - /cli/v11/files/npm-shrinkwrap.json
24
+ - /configuring-npm/npm-shrinkwrap-json
25
+ - /configuring-npm/npm-shrinkwrap.json
26
+ - /files/npm-shrinkwrap-json
27
+ - /files/npm-shrinkwrap.json
28
+---
29
+
30
+### Description
31
+
32
+`npm-shrinkwrap.json` is a file created by [`npm shrinkwrap`](/cli/v11/commands/npm-shrinkwrap). It is identical to `package-lock.json`, with one major caveat: Unlike `package-lock.json`, `npm-shrinkwrap.json` may be included when publishing a package.
33
+
34
+The recommended use-case for `npm-shrinkwrap.json` is applications deployed through the publishing process on the registry: for example, daemons and command-line tools intended as global installs or `devDependencies`. It's strongly discouraged for library authors to publish this file, since that would prevent end users from having control over transitive dependency updates.
35
+
36
+If both `package-lock.json` and `npm-shrinkwrap.json` are present in a package root, `npm-shrinkwrap.json` will be preferred over the `package-lock.json` file.
37
+
38
+For full details and description of the `npm-shrinkwrap.json` file format, refer to the manual page for [package-lock.json](/cli/v11/configuring-npm/package-lock-json).
39
+
40
+### See also
41
+
42
+- [npm shrinkwrap](/cli/v11/commands/npm-shrinkwrap)
43
+- [package-lock.json](/cli/v11/configuring-npm/package-lock-json)
44
+- [package.json](/cli/v11/configuring-npm/package-json)
45
+- [npm install](/cli/v11/commands/npm-install)
content/cli/v11/configuring-npm/npmrc.mdx
new
+127
@@ -0,0 +1,127 @@
1
+---
2
+title: npmrc
3
+section: 5
4
+description: The npm config files
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/configuring-npm/npmrc.md
8
+redirect_from:
9
+ - /cli-documentation/configuring-npm/npmrc
10
+ - /cli-documentation/files/npmrc
11
+ - /cli-documentation/v11/configuring-npm/npmrc
12
+ - /cli-documentation/v11/files/npmrc
13
+ - /cli/configuring-npm/npmrc
14
+ - /cli/files/npmrc
15
+ - /cli/v11/files/npmrc
16
+ - /configuring-npm/npmrc
17
+ - /files/npmrc
18
+---
19
+
20
+### Description
21
+
22
+npm gets its config settings from the command line, environment variables, and `npmrc` files.
23
+
24
+The `npm config` command can be used to update and edit the contents of the user and global npmrc files.
25
+
26
+For a list of available configuration options, see [config](/cli/v11/using-npm/config).
27
+
28
+### Files
29
+
30
+The four relevant files are:
31
+
32
+- per-project config file (`/path/to/my/project/.npmrc`)
33
+- per-user config file (`~/.npmrc`)
34
+- global config file (`$PREFIX/etc/npmrc`)
35
+- npm builtin config file (`/path/to/npm/npmrc`)
36
+
37
+All npm config files are an ini-formatted list of `key = value` parameters. Environment variables can be replaced using `${VARIABLE_NAME}`. For example:
38
+
39
+```bash
40
+cache = ${HOME}/.npm-packages
41
+```
42
+
43
+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.
44
+
45
+Array values are specified by adding "[]" after the key name. For example:
46
+
47
+```bash
48
+key[] = "first value"
49
+key[] = "second value"
50
+```
51
+
52
+#### Comments
53
+
54
+Lines in `.npmrc` files are interpreted as comments when they begin with a `;` or `#` character. `.npmrc` files are parsed by [npm/ini](https://github.com/npm/ini), which specifies this comment syntax.
55
+
56
+For example:
57
+
58
+```bash
59
+# last modified: 01 Jan 2016
60
+; Set a new registry for a scoped package
61
+@myscope:registry=https://mycustomregistry.example.org
62
+```
63
+
64
+#### Per-project config file
65
+
66
+When working locally in a project, a `.npmrc` file in the root of the project (ie, a sibling of `node_modules` and `package.json`) will set config values specific to this project.
67
+
68
+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.
69
+
70
+Additionally, this file is not read in global mode, such as when running `npm install -g`.
71
+
72
+#### Per-user config file
73
+
74
+`$HOME/.npmrc` (or the `userconfig` param, if set in the environment or on the command line)
75
+
76
+#### Global config file
77
+
78
+`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above): This file is an ini-file formatted list of `key = value` parameters. Environment variables can be replaced as above.
79
+
80
+#### Built-in config file
81
+
82
+`path/to/npm/itself/npmrc`
83
+
84
+This is an unchangeable "builtin" configuration file that npm keeps consistent across updates. Set fields in here using the `./configure` script that comes with npm. This is primarily for distribution maintainers to override default configs in a standard and consistent manner.
85
+
86
+### Auth related configuration
87
+
88
+The settings `_auth`, `_authToken`, `username` and `_password` must all be scoped to a specific registry. This ensures that `npm` will never send credentials to the wrong host.
89
+
90
+The full list is:
91
+
92
+- `_auth` (base64 authentication string)
93
+- `_authToken` (authentication token)
94
+- `username`
95
+- `_password`
96
+- `email`
97
+- `cafile` (path to certificate authority file)
98
+- `keyfile` (path to key file)
99
+
100
+In order to scope these values, they must be prefixed by a URI fragment. If the credential is meant for any request to a registry on a single host, the scope may look like `//registry.npmjs.org/:`. If it must be scoped to a specific path on the host that path may also be provided, such as `//my-custom-registry.org/unique/path:`.
101
+
102
+```
103
+; bad config
104
+_authToken=MYTOKEN
105
+
106
+; good config
107
+@myorg:registry=https://somewhere-else.com/myorg
108
+@another:registry=https://somewhere-else.com/another
109
+//registry.npmjs.org/:_authToken=MYTOKEN
110
+
111
+; would apply to both @myorg and @another
112
+//somewhere-else.com/:_authToken=MYTOKEN
113
+
114
+; would apply only to @myorg
115
+//somewhere-else.com/myorg/:_authToken=MYTOKEN1
116
+
117
+; would apply only to @another
118
+//somewhere-else.com/another/:_authToken=MYTOKEN2
119
+```
120
+
121
+### See also
122
+
123
+- [npm folders](/cli/v11/configuring-npm/folders)
124
+- [npm config](/cli/v11/commands/npm-config)
125
+- [config](/cli/v11/using-npm/config)
126
+- [package.json](/cli/v11/configuring-npm/package-json)
127
+- [npm](/cli/v11/commands/npm)
content/cli/v11/configuring-npm/package-json.mdx
new
+1005
@@ -0,0 +1,1005 @@
1
+---
2
+title: package.json
3
+section: 5
4
+description: Specifics of npm's package.json handling
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/configuring-npm/package-json.md
8
+redirect_from:
9
+ - /cli-documentation/configuring-npm/package-json
10
+ - /cli-documentation/configuring-npm/package.json
11
+ - /cli-documentation/files/package-json
12
+ - /cli-documentation/files/package.json
13
+ - /cli-documentation/v11/configuring-npm/package-json
14
+ - /cli-documentation/v11/configuring-npm/package.json
15
+ - /cli-documentation/v11/files/package-json
16
+ - /cli-documentation/v11/files/package.json
17
+ - /cli/configuring-npm/package-json
18
+ - /cli/configuring-npm/package.json
19
+ - /cli/files/package-json
20
+ - /cli/files/package.json
21
+ - /cli/v11/configuring-npm/package.json
22
+ - /cli/v11/files/package-json
23
+ - /cli/v11/files/package.json
24
+ - /configuring-npm/package-json
25
+ - /configuring-npm/package.json
26
+ - /files/package-json
27
+ - /files/package.json
28
+---
29
+
30
+### Description
31
+
32
+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.
33
+
34
+A lot of the behavior described in this document is affected by the config settings described in [`config`](/cli/v11/using-npm/config).
35
+
36
+### name
37
+
38
+If you plan to publish your package, the _most_ important things in your package.json are the name and version fields as they will be required. The name and version together form an identifier that is assumed to be completely unique. Changes to the package should come along with changes to the version. If you don't plan to publish your package, the name and version fields are optional.
39
+
40
+The name is what your thing is called.
41
+
42
+Some rules:
43
+
44
+- The name must be less than or equal to 214 characters. This includes the scope for scoped packages.
45
+- The names of scoped packages can begin with a dot or an underscore. This is not permitted without a scope.
46
+- New packages must not have uppercase letters in the name.
47
+- 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.
48
+
49
+Some tips:
50
+
51
+- Don't use the same name as a core Node module.
52
+- Don't put "js" or "node" in the name. It's assumed that it's js, since you're writing a package.json file, and you can specify the engine using the "[engines](#engines)" field. (See below.)
53
+- The name will probably be passed as an argument to require(), so it should be something short, but also reasonably descriptive.
54
+- You may want to check the npm registry to see if there's something by that name already, before you get too attached to it. [https://www.npmjs.com/](https://www.npmjs.com/)
55
+
56
+A name can be optionally prefixed by a scope, e.g. `@myorg/mypackage`. See [`scope`](/cli/v11/using-npm/scope) for more detail.
57
+
58
+### version
59
+
60
+If you plan to publish your package, the _most_ important things in your package.json are the name and version fields as they will be required. The name and version together form an identifier that is assumed to be completely unique. Changes to the package should come along with changes to the version. If you don't plan to publish your package, the name and version fields are optional.
61
+
62
+Version must be parseable by [node-semver](https://github.com/npm/node-semver), which is bundled with npm as a dependency. (`npm install semver` to use it yourself.)
63
+
64
+### description
65
+
66
+Put a description in it. It's a string. This helps people discover your package, as it's listed in `npm search`.
67
+
68
+### keywords
69
+
70
+Put keywords in it. It's an array of strings. This helps people discover your package as it's listed in `npm search`.
71
+
72
+### homepage
73
+
74
+The URL to the project homepage.
75
+
76
+Example:
77
+
78
+```json
79
+"homepage": "https://github.com/owner/project#readme"
80
+```
81
+
82
+### bugs
83
+
84
+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.
85
+
86
+It should look like this:
87
+
88
+```json
89
+{
90
+ "bugs": {
91
+ "url": "https://github.com/owner/project/issues",
92
+ "email": "project@hostname.com"
93
+ }
94
+}
95
+```
96
+
97
+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.
98
+
99
+If a URL is provided, it will be used by the `npm bugs` command.
100
+
101
+### license
102
+
103
+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.
104
+
105
+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:
106
+
107
+```json
108
+{
109
+ "license": "BSD-3-Clause"
110
+}
111
+```
112
+
113
+You can check [the full list of SPDX license IDs](https://spdx.org/licenses/). Ideally you should pick one that is [OSI](https://opensource.org/licenses/) approved.
114
+
115
+If your package is licensed under multiple common licenses, use an [SPDX license expression syntax version 2.0 string](https://spdx.dev/specifications/), like this:
116
+
117
+```json
118
+{
119
+ "license": "(ISC OR GPL-3.0)"
120
+}
121
+```
122
+
123
+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:
124
+
125
+```json
126
+{
127
+ "license": "SEE LICENSE IN <filename>"
128
+}
129
+```
130
+
131
+Then include a file named `<filename>` at the top level of the package.
132
+
133
+Some old packages used license objects or a "licenses" property containing an array of license objects:
134
+
135
+```json
136
+// Not valid metadata
137
+{
138
+ "license" : {
139
+ "type" : "ISC",
140
+ "url" : "https://opensource.org/licenses/ISC"
141
+ }
142
+}
143
+
144
+// Not valid metadata
145
+{
146
+ "licenses" : [
147
+ {
148
+ "type": "MIT",
149
+ "url": "https://www.opensource.org/licenses/mit-license.php"
150
+ },
151
+ {
152
+ "type": "Apache-2.0",
153
+ "url": "https://opensource.org/licenses/apache2.0.php"
154
+ }
155
+ ]
156
+}
157
+```
158
+
159
+Those styles are now deprecated. Instead, use SPDX expressions, like this:
160
+
161
+```json
162
+{
163
+ "license": "ISC"
164
+}
165
+```
166
+
167
+```json
168
+{
169
+ "license": "(MIT OR Apache-2.0)"
170
+}
171
+```
172
+
173
+Finally, if you do not wish to grant others the right to use a private or unpublished package under any terms:
174
+
175
+```json
176
+{
177
+ "license": "UNLICENSED"
178
+}
179
+```
180
+
181
+Consider also setting `"private": true` to prevent accidental publication.
182
+
183
+### people fields: author, contributors
184
+
185
+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:
186
+
187
+```json
188
+{
189
+ "name": "Barney Rubble",
190
+ "email": "b@rubble.com",
191
+ "url": "http://barnyrubble.tumblr.com/"
192
+}
193
+```
194
+
195
+Or you can shorten that all into a single string, and npm will parse it for you:
196
+
197
+```json
198
+{
199
+ "author": "Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
200
+}
201
+```
202
+
203
+Both email and url are optional either way.
204
+
205
+npm also sets a top-level "maintainers" field with your npm user info.
206
+
207
+### funding
208
+
209
+You can specify an object containing a URL that provides up-to-date information about ways to help fund development of your package, a string URL, or an array of objects and string URLs:
210
+
211
+```json
212
+{
213
+ "funding": {
214
+ "type": "individual",
215
+ "url": "http://example.com/donate"
216
+ }
217
+}
218
+```
219
+
220
+```json
221
+{
222
+ "funding": {
223
+ "type": "patreon",
224
+ "url": "https://www.patreon.com/my-account"
225
+ }
226
+}
227
+```
228
+
229
+```json
230
+{
231
+ "funding": "http://example.com/donate"
232
+}
233
+```
234
+
235
+```json
236
+{
237
+ "funding": [
238
+ {
239
+ "type": "individual",
240
+ "url": "http://example.com/donate"
241
+ },
242
+ "http://example.com/donateAlso",
243
+ {
244
+ "type": "patreon",
245
+ "url": "https://www.patreon.com/my-account"
246
+ }
247
+ ]
248
+}
249
+```
250
+
251
+Users can use the `npm fund` subcommand to list the `funding` URLs of all dependencies of their project, direct and indirect. A shortcut to visit each funding URL is also available when providing the project name such as: `npm fund <projectname>` (when there are multiple URLs, the first one will be visited)
252
+
253
+### files
254
+
255
+The optional `files` field is an array of file patterns that describes the entries to be included when your package is installed as a dependency. File patterns follow a similar syntax to `.gitignore`, but reversed: including a file, directory, or glob pattern (`*`, `**/*`, and such) will make it so that file is included in the tarball when it's packed. Omitting the field will make it default to `["*"]`, which means it will include all files.
256
+
257
+Some special files and directories are also included or excluded regardless of whether they exist in the `files` array (see below).
258
+
259
+You can also provide a `.npmignore` file in the root of your package or in subdirectories, which will keep files from being included. At the root of your package it will not override the "files" field, but in subdirectories it will. The `.npmignore` file works just like a `.gitignore`. If there is a `.gitignore` file, and `.npmignore` is missing, `.gitignore`'s contents will be used instead.
260
+
261
+Certain files are always included, regardless of settings:
262
+
263
+- `package.json`
264
+- `README`
265
+- `LICENSE` / `LICENCE`
266
+- The file in the "main" field
267
+- The file(s) in the "bin" field
268
+
269
+`README` & `LICENSE` can have any case and extension.
270
+
271
+Some files are always ignored by default:
272
+
273
+- `*.orig`
274
+- `.*.swp`
275
+- `.DS_Store`
276
+- `._*`
277
+- `.git`
278
+- `.hg`
279
+- `.lock-wscript`
280
+- `.npmrc`
281
+- `.svn`
282
+- `.wafpickle-N`
283
+- `CVS`
284
+- `config.gypi`
285
+- `node_modules`
286
+- `npm-debug.log`
287
+- `package-lock.json` (use [`npm-shrinkwrap.json`](/cli/v11/configuring-npm/npm-shrinkwrap-json) if you wish it to be published)
288
+- `pnpm-lock.yaml`
289
+- `yarn.lock`
290
+- `bun.lockb`
291
+
292
+Most of these ignored files can be included specifically if included in the `files` globs. Exceptions to this are:
293
+
294
+- `.git`
295
+- `.npmrc`
296
+- `node_modules`
297
+- `package-lock.json`
298
+- `pnpm-lock.yaml`
299
+- `yarn.lock`
300
+- `bun.lockb`
301
+
302
+These can not be included.
303
+
304
+### exports
305
+
306
+The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to clearly define the public interface for their package. For more details see the [node.js documentation on package entry points](https://nodejs.org/api/packages.html#package-entry-points)
307
+
308
+### main
309
+
310
+The main field is a module ID that is the primary entry point to your program. That is, if your package is named `foo`, and a user installs it, and then does `require("foo")`, then your main module's exports object will be returned.
311
+
312
+This should be a module relative to the root of your package folder.
313
+
314
+For most modules, it makes the most sense to have a main script and often not much else.
315
+
316
+If `main` is not set, it defaults to `index.js` in the package's root folder.
317
+
318
+### browser
319
+
320
+If your module is meant to be used client-side the browser field should be used instead of the main field. This is helpful to hint users that it might rely on primitives that aren't available in Node.js modules. (e.g. `window`)
321
+
322
+### bin
323
+
324
+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.)
325
+
326
+To use this, supply a `bin` field in your package.json which is a map of command name to local file name. When this package is installed globally, that file will be either linked inside the global bins directory or a cmd (Windows Command File) will be created which executes the specified file in the `bin` field, so it is available to run by `name` or `name.cmd` (on Windows PowerShell). When this package is installed as a dependency in another package, the file will be linked where it will be available to that package either directly by `npm exec` or by name in other scripts when invoking them via `npm run-script`.
327
+
328
+For example, myapp could have this:
329
+
330
+```json
331
+{
332
+ "bin": {
333
+ "myapp": "bin/cli.js"
334
+ }
335
+}
336
+```
337
+
338
+So, when you install myapp, in case of unix-like OS it'll create a symlink from the `cli.js` script to `/usr/local/bin/myapp` and in case of windows it will create a cmd file usually at `C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd` which runs the `cli.js` script.
339
+
340
+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:
341
+
342
+```json
343
+{
344
+ "name": "my-program",
345
+ "version": "1.2.5",
346
+ "bin": "path/to/program"
347
+}
348
+```
349
+
350
+would be the same as this:
351
+
352
+```json
353
+{
354
+ "name": "my-program",
355
+ "version": "1.2.5",
356
+ "bin": {
357
+ "my-program": "path/to/program"
358
+ }
359
+}
360
+```
361
+
362
+Please make sure that your file(s) referenced in `bin` starts with `#!/usr/bin/env node`, otherwise the scripts are started without the node executable!
363
+
364
+Note that you can also set the executable files using [directories.bin](#directoriesbin).
365
+
366
+See [folders](/cli/v11/configuring-npm/folders#executables) for more info on executables.
367
+
368
+### man
369
+
370
+Specify either a single file or an array of filenames to put in place for the `man` program to find.
371
+
372
+If only a single file is provided, then it's installed such that it is the result from `man <pkgname>`, regardless of its actual filename. For example:
373
+
374
+```json
375
+{
376
+ "name": "foo",
377
+ "version": "1.2.3",
378
+ "description": "A packaged foo fooer for fooing foos",
379
+ "main": "foo.js",
380
+ "man": "./man/doc.1"
381
+}
382
+```
383
+
384
+would link the `./man/doc.1` file in such that it is the target for `man foo`
385
+
386
+If the filename doesn't start with the package name, then it's prefixed. So, this:
387
+
388
+```json
389
+{
390
+ "name": "foo",
391
+ "version": "1.2.3",
392
+ "description": "A packaged foo fooer for fooing foos",
393
+ "main": "foo.js",
394
+ "man": ["./man/foo.1", "./man/bar.1"]
395
+}
396
+```
397
+
398
+will create files to do `man foo` and `man foo-bar`.
399
+
400
+Man files must end with a number, and optionally a `.gz` suffix if they are compressed. The number dictates which man section the file is installed into.
401
+
402
+```json
403
+{
404
+ "name": "foo",
405
+ "version": "1.2.3",
406
+ "description": "A packaged foo fooer for fooing foos",
407
+ "main": "foo.js",
408
+ "man": ["./man/foo.1", "./man/foo.2"]
409
+}
410
+```
411
+
412
+will create entries for `man foo` and `man 2 foo`
413
+
414
+### directories
415
+
416
+The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec details a few ways that you can indicate the structure of your package using a `directories` object. If you look at [npm's package.json](https://registry.npmjs.org/npm/latest), you'll see that it has directories for doc, lib, and man.
417
+
418
+In the future, this information may be used in other creative ways.
419
+
420
+#### directories.bin
421
+
422
+If you specify a `bin` directory in `directories.bin`, all the files in that folder will be added.
423
+
424
+Because of the way the `bin` directive works, specifying both a `bin` path and setting `directories.bin` is an error. If you want to specify individual files, use `bin`, and for all the files in an existing `bin` directory, use `directories.bin`.
425
+
426
+#### directories.man
427
+
428
+A folder that is full of man pages. Sugar to generate a "man" array by walking the folder.
429
+
430
+### repository
431
+
432
+Specify the place where your code lives. This is helpful for people who want to contribute. If the git repo is on GitHub, then the `npm repo` command will be able to find you.
433
+
434
+Do it like this:
435
+
436
+```json
437
+{
438
+ "repository": {
439
+ "type": "git",
440
+ "url": "git+https://github.com/npm/cli.git"
441
+ }
442
+}
443
+```
444
+
445
+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.
446
+
447
+For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same shortcut syntax you use for `npm install`:
448
+
449
+```json
450
+{
451
+ "repository": "npm/npm",
452
+
453
+ "repository": "github:user/repo",
454
+
455
+ "repository": "gist:11081aaa281",
456
+
457
+ "repository": "bitbucket:user/repo",
458
+
459
+ "repository": "gitlab:user/repo"
460
+}
461
+```
462
+
463
+If the `package.json` for your package is not in the root directory (for example if it is part of a monorepo), you can specify the directory in which it lives:
464
+
465
+```json
466
+{
467
+ "repository": {
468
+ "type": "git",
469
+ "url": "git+https://github.com/npm/cli.git",
470
+ "directory": "workspaces/libnpmpublish"
471
+ }
472
+}
473
+```
474
+
475
+### scripts
476
+
477
+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.
478
+
479
+See [`scripts`](/cli/v11/using-npm/scripts) to find out more about writing package scripts.
480
+
481
+### config
482
+
483
+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:
484
+
485
+```json
486
+{
487
+ "name": "foo",
488
+ "config": {
489
+ "port": "8080"
490
+ }
491
+}
492
+```
493
+
494
+It could also have a "start" command that referenced the `npm_package_config_port` environment variable.
495
+
496
+### dependencies
497
+
498
+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.
499
+
500
+**Please do not put test harnesses or transpilers or other "development" time tools in your `dependencies` object.** See `devDependencies`, below.
501
+
502
+See [semver](https://github.com/npm/node-semver#versions) for more details about specifying version ranges.
503
+
504
+- `version` Must match `version` exactly
505
+- `>version` Must be greater than `version`
506
+- `>=version` etc
507
+- `<version`
508
+- `<=version`
509
+- `~version` "Approximately equivalent to version" See [semver](https://github.com/npm/node-semver#versions)
510
+- `^version` "Compatible with version" See [semver](https://github.com/npm/node-semver#versions)
511
+- `1.2.x` 1.2.0, 1.2.1, etc., but not 1.3.0
512
+- `http://...` See 'URLs as Dependencies' below
513
+- `*` Matches any version
514
+- `""` (just an empty string) Same as `*`
515
+- `version1 - version2` Same as `>=version1 <=version2`.
516
+- `range1 || range2` Passes if either range1 or range2 are satisfied.
517
+- `git...` See 'Git URLs as Dependencies' below
518
+- `user/repo` See 'GitHub URLs' below
519
+- `tag` A specific version tagged and published as `tag` See [`npm dist-tag`](/cli/v11/commands/npm-dist-tag)
520
+- `path/path/path` See [Local Paths](#local-paths) below
521
+- `npm:@scope/pkg@version` Custom alias for a pacakge See [`package-spec`](/cli/v11/using-npm/package-spec#aliases)
522
+
523
+For example, these are all valid:
524
+
525
+```json
526
+{
527
+ "dependencies": {
528
+ "foo": "1.0.0 - 2.9999.9999",
529
+ "bar": ">=1.0.2 <2.1.2",
530
+ "baz": ">1.0.2 <=2.3.4",
531
+ "boo": "2.0.1",
532
+ "qux": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0",
533
+ "asd": "http://asdf.com/asdf.tar.gz",
534
+ "til": "~1.2",
535
+ "elf": "~1.2.3",
536
+ "two": "2.x",
537
+ "thr": "3.3.x",
538
+ "lat": "latest",
539
+ "dyl": "file:../dyl",
540
+ "kpg": "npm:pkg@1.0.0"
541
+ }
542
+}
543
+```
544
+
545
+#### URLs as Dependencies
546
+
547
+You may specify a tarball URL in place of a version range.
548
+
549
+This tarball will be downloaded and installed locally to your package at install time.
550
+
551
+#### Git URLs as Dependencies
552
+
553
+Git URLs are of the form:
554
+
555
+```bash
556
+<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
557
+```
558
+
559
+`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or `git+file`.
560
+
561
+If `#<commit-ish>` is provided, it will be used to clone exactly that commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can be any valid semver range or exact version, and npm will look for any tags or refs matching that range in the remote repository, much as it would for a registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is specified, then the default branch is used.
562
+
563
+Examples:
564
+
565
+```bash
566
+git+ssh://git@github.com:npm/cli.git#v1.0.27
567
+git+ssh://git@github.com:npm/cli#semver:^5.0
568
+git+https://isaacs@github.com/npm/cli.git
569
+git://github.com/npm/cli.git#v1.0.27
570
+```
571
+
572
+When installing from a `git` repository, the presence of certain fields in the `package.json` will cause npm to believe it needs to perform a build. To do so your repository will be cloned into a temporary directory, all of its deps installed, relevant scripts run, and the resulting directory packed and installed.
573
+
574
+This flow will occur if your git dependency uses `workspaces`, or if any of the following scripts are present:
575
+
576
+- `build`
577
+- `prepare`
578
+- `prepack`
579
+- `preinstall`
580
+- `install`
581
+- `postinstall`
582
+
583
+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.
584
+
585
+#### GitHub URLs
586
+
587
+As of version 1.1.65, you can refer to GitHub URLs as just "foo": "user/foo-project". Just as with git URLs, a `commit-ish` suffix can be included. For example:
588
+
589
+```json
590
+{
591
+ "name": "foo",
592
+ "version": "0.0.0",
593
+ "dependencies": {
594
+ "express": "expressjs/express",
595
+ "mocha": "mochajs/mocha#4727d357ea",
596
+ "module": "user/repo#feature\/branch"
597
+ }
598
+}
599
+```
600
+
601
+#### Local Paths
602
+
603
+As of version 2.0.0 you can provide a path to a local directory that contains a package. Local paths can be saved using `npm install -S` or `npm install --save`, using any of these forms:
604
+
605
+```bash
606
+../foo/bar
607
+~/foo/bar
608
+./foo/bar
609
+/foo/bar
610
+```
611
+
612
+in which case they will be normalized to a relative path and added to your `package.json`. For example:
613
+
614
+```json
615
+{
616
+ "name": "baz",
617
+ "dependencies": {
618
+ "bar": "file:../foo/bar"
619
+ }
620
+}
621
+```
622
+
623
+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.
624
+
625
+_note_: Packages linked by local path will not have their own dependencies installed when `npm install` is ran in this case. You must run `npm install` from inside the local path itself.
626
+
627
+### devDependencies
628
+
629
+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.
630
+
631
+In this case, it's best to map these additional items in a `devDependencies` object.
632
+
633
+These things will be installed when doing `npm link` or `npm install` from the root of a package, and can be managed like any other npm configuration param. See [`config`](/cli/v11/using-npm/config) for more on the topic.
634
+
635
+For build steps that are not platform-specific, such as compiling CoffeeScript or other languages to JavaScript, use the `prepare` script to do this, and make the required package a devDependency.
636
+
637
+For example:
638
+
639
+```json
640
+{
641
+ "name": "ethopia-waza",
642
+ "description": "a delightfully fruity coffee varietal",
643
+ "version": "1.2.3",
644
+ "devDependencies": {
645
+ "coffee-script": "~1.6.3"
646
+ },
647
+ "scripts": {
648
+ "prepare": "coffee -o lib/ -c src/waza.coffee"
649
+ },
650
+ "main": "lib/waza.js"
651
+}
652
+```
653
+
654
+The `prepare` script will be run before publishing, so that users can consume the functionality without requiring them to compile it themselves. In dev mode (ie, locally running `npm install`), it'll run this script as well, so that you can test it easily.
655
+
656
+### peerDependencies
657
+
658
+In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a `require` of this host. This is usually referred to as a _plugin_. Notably, your module may be exposing a specific interface, expected and specified by the host documentation.
659
+
660
+For example:
661
+
662
+```json
663
+{
664
+ "name": "tea-latte",
665
+ "version": "1.3.5",
666
+ "peerDependencies": {
667
+ "tea": "2.x"
668
+ }
669
+}
670
+```
671
+
672
+This ensures your package `tea-latte` can be installed _along_ with the second major version of the host package `tea` only. `npm install tea-latte` could possibly yield the following dependency graph:
673
+
674
+```bash
675
+├── tea-latte@1.3.5
676
+└── tea@2.2.0
677
+```
678
+
679
+In npm versions 3 through 6, `peerDependencies` were not automatically installed, and would raise a warning if an invalid version of the peer dependency was found in the tree. As of npm v7, peerDependencies _are_ installed by default.
680
+
681
+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.
682
+
683
+Assuming the host complies with [semver](https://semver.org/), only changes in the host package's major version will break your plugin. Thus, if you've worked with every 1.x version of the host package, use `"^1.0"` or `"1.x"` to express this. If you depend on features introduced in 1.5.2, use `"^1.5.2"`.
684
+
685
+### peerDependenciesMeta
686
+
687
+The `peerDependenciesMeta` field serves to provide npm more information on how your peer dependencies are to be used. Specifically, it allows peer dependencies to be marked as optional. Npm will not automatically install optional peer dependencies. This allows you to integrate and interact with a variety of host packages without requiring all of them to be installed.
688
+
689
+For example:
690
+
691
+```json
692
+{
693
+ "name": "tea-latte",
694
+ "version": "1.3.5",
695
+ "peerDependencies": {
696
+ "tea": "2.x",
697
+ "soy-milk": "1.2"
698
+ },
699
+ "peerDependenciesMeta": {
700
+ "soy-milk": {
701
+ "optional": true
702
+ }
703
+ }
704
+}
705
+```
706
+
707
+### bundleDependencies
708
+
709
+This defines an array of package names that will be bundled when publishing the package.
710
+
711
+In cases where you need to preserve npm packages locally or have them available through a single file download, you can bundle the packages in a tarball file by specifying the package names in the `bundleDependencies` array and executing `npm pack`.
712
+
713
+For example:
714
+
715
+If we define a package.json like this:
716
+
717
+```json
718
+{
719
+ "name": "awesome-web-framework",
720
+ "version": "1.0.0",
721
+ "bundleDependencies": ["renderized", "super-streams"]
722
+}
723
+```
724
+
725
+we can obtain `awesome-web-framework-1.0.0.tgz` file by running `npm pack`. This file contains the dependencies `renderized` and `super-streams` which can be installed in a new project by executing `npm install awesome-web-framework-1.0.0.tgz`. Note that the package names do not include any versions, as that information is specified in `dependencies`.
726
+
727
+If this is spelled `"bundledDependencies"`, then that is also honored.
728
+
729
+Alternatively, `"bundleDependencies"` can be defined as a boolean value. A value of `true` will bundle all dependencies, a value of `false` will bundle none.
730
+
731
+### optionalDependencies
732
+
733
+If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the `optionalDependencies` object. This is a map of package name to version or URL, just like the `dependencies` object. The difference is that build failures do not cause installation to fail. Running `npm install --omit=optional` will prevent these dependencies from being installed.
734
+
735
+It is still your program's responsibility to handle the lack of the dependency. For example, something like this:
736
+
737
+```js
738
+try {
739
+ var foo = require("foo");
740
+ var fooVersion = require("foo/package.json").version;
741
+} catch (er) {
742
+ foo = null;
743
+}
744
+if (notGoodFooVersion(fooVersion)) {
745
+ foo = null;
746
+}
747
+
748
+// .. then later in your program ..
749
+
750
+if (foo) {
751
+ foo.doFooThings();
752
+}
753
+```
754
+
755
+Entries in `optionalDependencies` will override entries of the same name in `dependencies`, so it's usually best to only put in one place.
756
+
757
+### overrides
758
+
759
+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.
760
+
761
+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.
762
+
763
+Overrides are only considered in the root `package.json` file for a project. Overrides in installed dependencies (including [workspaces](/cli/v11/using-npm/workspaces)) are not considered in dependency tree resolution. Published packages may dictate their resolutions by pinning dependencies or using an [`npm-shrinkwrap.json`](/cli/v11/configuring-npm/npm-shrinkwrap-json) file.
764
+
765
+To make sure the package `foo` is always installed as version `1.0.0` no matter what version your dependencies rely on:
766
+
767
+```json
768
+{
769
+ "overrides": {
770
+ "foo": "1.0.0"
771
+ }
772
+}
773
+```
774
+
775
+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 `foo` to always be `1.0.0` while also making `bar` at any depth beyond `foo` also `1.0.0`:
776
+
777
+```json
778
+{
779
+ "overrides": {
780
+ "foo": {
781
+ ".": "1.0.0",
782
+ "bar": "1.0.0"
783
+ }
784
+ }
785
+}
786
+```
787
+
788
+To only override `foo` to be `1.0.0` when it's a child (or grandchild, or great grandchild, etc) of the package `bar`:
789
+
790
+```json
791
+{
792
+ "overrides": {
793
+ "bar": {
794
+ "foo": "1.0.0"
795
+ }
796
+ }
797
+}
798
+```
799
+
800
+Keys can be nested to any arbitrary length. To override `foo` only when it's a child of `bar` and only when `bar` is a child of `baz`:
801
+
802
+```json
803
+{
804
+ "overrides": {
805
+ "baz": {
806
+ "bar": {
807
+ "foo": "1.0.0"
808
+ }
809
+ }
810
+ }
811
+}
812
+```
813
+
814
+The key of an override can also include a version, or range of versions. To override `foo` to `1.0.0`, but only when it's a child of `bar@2.0.0`:
815
+
816
+```json
817
+{
818
+ "overrides": {
819
+ "bar@2.0.0": {
820
+ "foo": "1.0.0"
821
+ }
822
+ }
823
+}
824
+```
825
+
826
+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 `$`.
827
+
828
+```json
829
+{
830
+ "dependencies": {
831
+ "foo": "^1.0.0"
832
+ },
833
+ "overrides": {
834
+ // BAD, will throw an EOVERRIDE error
835
+ // "foo": "^2.0.0"
836
+ // GOOD, specs match so override is allowed
837
+ // "foo": "^1.0.0"
838
+ // BEST, the override is defined as a reference to the dependency
839
+ "foo": "$foo",
840
+ // the referenced package does not need to match the overridden one
841
+ "bar": "$foo"
842
+ }
843
+}
844
+```
845
+
846
+### engines
847
+
848
+You can specify the version of node that your stuff works on:
849
+
850
+```json
851
+{
852
+ "engines": {
853
+ "node": ">=0.10.3 <15"
854
+ }
855
+}
856
+```
857
+
858
+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.
859
+
860
+You can also use the "engines" field to specify which versions of npm are capable of properly installing your program. For example:
861
+
862
+```json
863
+{
864
+ "engines": {
865
+ "npm": "~1.0.20"
866
+ }
867
+}
868
+```
869
+
870
+Unless the user has set the [`engine-strict` config](/cli/v11/using-npm/config#engine-strict) flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.
871
+
872
+### os
873
+
874
+You can specify which operating systems your module will run on:
875
+
876
+```json
877
+{
878
+ "os": ["darwin", "linux"]
879
+}
880
+```
881
+
882
+You can also block instead of allowing operating systems, just prepend the blocked os with a '!':
883
+
884
+```json
885
+{
886
+ "os": ["!win32"]
887
+}
888
+```
889
+
890
+The host operating system is determined by `process.platform`
891
+
892
+It is allowed to both block and allow an item, although there isn't any good reason to do this.
893
+
894
+### cpu
895
+
896
+If your code only runs on certain cpu architectures, you can specify which ones.
897
+
898
+```json
899
+{
900
+ "cpu": ["x64", "ia32"]
901
+}
902
+```
903
+
904
+Like the `os` option, you can also block architectures:
905
+
906
+```json
907
+{
908
+ "cpu": ["!arm", "!mips"]
909
+}
910
+```
911
+
912
+The host architecture is determined by `process.arch`
913
+
914
+### libc
915
+
916
+If your code only runs or builds in certain versions of libc, you can specify which ones. This field only applies if `os` is `linux`.
917
+
918
+```json
919
+{
920
+ "os": "linux",
921
+ "libc": "glibc"
922
+}
923
+```
924
+
925
+### devEngines
926
+
927
+The `devEngines` field aids engineers working on a codebase to all be using the same tooling.
928
+
929
+You can specify a `devEngines` property in your `package.json` which will run before `install`, `ci`, and `run` commands.
930
+
931
+> Note: `engines` and `devEngines` differ in object shape. They also function very differently. `engines` is designed to alert the user when a dependency uses a differening npm or node version that the project it's being used in, whereas `devEngines` is used to alert people interacting with the source code of a project.
932
+
933
+The supported keys under the `devEngines` property are `cpu`, `os`, `libc`, `runtime`, and `packageManager`. Each property can be an object or an array of objects. Objects must contain `name`, and optionally can specify `version`, and `onFail`. `onFail` can be `warn`, `error`, or `ignore`, and if left undefined is of the same value as `error`. `npm` will assume that you're running with `node`. Here's an example of a project that will fail if the environment is not `node` and `npm`. If you set `runtime.name` or `packageManager.name` to any other string, it will fail within the npm CLI.
934
+
935
+```json
936
+{
937
+ "devEngines": {
938
+ "runtime": {
939
+ "name": "node",
940
+ "onFail": "error"
941
+ },
942
+ "packageManager": {
943
+ "name": "npm",
944
+ "onFail": "error"
945
+ }
946
+ }
947
+}
948
+```
949
+
950
+### private
951
+
952
+If you set `"private": true` in your package.json, then npm will refuse to publish it.
953
+
954
+This is a way to prevent accidental publication of private repositories. If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the `publishConfig` dictionary described below to override the `registry` config param at publish-time.
955
+
956
+### publishConfig
957
+
958
+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.
959
+
960
+See [`config`](/cli/v11/using-npm/config) to see the list of config options that can be overridden.
961
+
962
+### workspaces
963
+
964
+The optional `workspaces` field is an array of file patterns that describes locations within the local file system that the install client should look up to find each [workspace](/cli/v11/using-npm/workspaces) that needs to be symlinked to the top level `node_modules` folder.
965
+
966
+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.
967
+
968
+In the following example, all folders located inside the folder `./packages` will be treated as workspaces as long as they have valid `package.json` files inside them:
969
+
970
+```json
971
+{
972
+ "name": "workspace-example",
973
+ "workspaces": ["./packages/*"]
974
+}
975
+```
976
+
977
+See [`workspaces`](/cli/v11/using-npm/workspaces) for more examples.
978
+
979
+### DEFAULT VALUES
980
+
981
+npm will default some values based on package contents.
982
+
983
+- `"scripts": {"start": "node server.js"}`
984
+
985
+ If there is a `server.js` file in the root of your package, then npm will default the `start` command to `node server.js`.
986
+
987
+- `"scripts":{"install": "node-gyp rebuild"}`
988
+
989
+ If there is a `binding.gyp` file in the root of your package and you have not defined an `install` or `preinstall` script, npm will default the `install` command to compile using node-gyp.
990
+
991
+- `"contributors": [...]`
992
+
993
+ If there is an `AUTHORS` file in the root of your package, npm will treat each line as a `Name <email> (url)` format, where email and url are optional. Lines which start with a `#` or are blank, will be ignored.
994
+
995
+### SEE ALSO
996
+
997
+- [semver](https://github.com/npm/node-semver#versions)
998
+- [workspaces](/cli/v11/using-npm/workspaces)
999
+- [npm init](/cli/v11/commands/npm-init)
1000
+- [npm version](/cli/v11/commands/npm-version)
1001
+- [npm config](/cli/v11/commands/npm-config)
1002
+- [npm help](/cli/v11/commands/npm-help)
1003
+- [npm install](/cli/v11/commands/npm-install)
1004
+- [npm publish](/cli/v11/commands/npm-publish)
1005
+- [npm uninstall](/cli/v11/commands/npm-uninstall)
content/cli/v11/configuring-npm/package-lock-json.mdx
new
+161
@@ -0,0 +1,161 @@
1
+---
2
+title: package-lock.json
3
+section: 5
4
+description: A manifestation of the manifest
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/configuring-npm/package-lock-json.md
8
+redirect_from:
9
+ - /cli-documentation/configuring-npm/package-lock-json
10
+ - /cli-documentation/configuring-npm/package-lock.json
11
+ - /cli-documentation/files/package-lock-json
12
+ - /cli-documentation/files/package-lock.json
13
+ - /cli-documentation/v11/configuring-npm/package-lock-json
14
+ - /cli-documentation/v11/configuring-npm/package-lock.json
15
+ - /cli-documentation/v11/files/package-lock-json
16
+ - /cli-documentation/v11/files/package-lock.json
17
+ - /cli/configuring-npm/package-lock-json
18
+ - /cli/configuring-npm/package-lock.json
19
+ - /cli/files/package-lock-json
20
+ - /cli/files/package-lock.json
21
+ - /cli/v11/configuring-npm/package-lock.json
22
+ - /cli/v11/files/package-lock-json
23
+ - /cli/v11/files/package-lock.json
24
+ - /configuring-npm/package-lock-json
25
+ - /configuring-npm/package-lock.json
26
+ - /files/package-lock-json
27
+ - /files/package-lock.json
28
+---
29
+
30
+### Description
31
+
32
+`package-lock.json` is automatically generated for any operations where npm modifies either the `node_modules` tree, or `package.json`. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
33
+
34
+This file is intended to be committed into source repositories, and serves various purposes:
35
+
36
+- Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
37
+
38
+- Provide a facility for users to "time-travel" to previous states of `node_modules` without having to commit the directory itself.
39
+
40
+- Facilitate greater visibility of tree changes through readable source control diffs.
41
+
42
+- Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
43
+
44
+- As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read `package.json` files, and allowing for significant performance improvements.
45
+
46
+When `npm` creates or updates `package-lock.json`, it will infer line endings and indentation from `package.json` so that the formatting of both files matches.
47
+
48
+### `package-lock.json` vs `npm-shrinkwrap.json`
49
+
50
+Both of these files have the same format, and perform similar functions in the root of a project.
51
+
52
+The difference is that `package-lock.json` cannot be published, and it will be ignored if found in any place other than the root project.
53
+
54
+In contrast, [npm-shrinkwrap.json](/cli/v11/configuring-npm/npm-shrinkwrap-json) allows publication, and defines the dependency tree from the point encountered. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.
55
+
56
+If both `package-lock.json` and `npm-shrinkwrap.json` are present in the root of a project, `npm-shrinkwrap.json` will take precedence and `package-lock.json` will be ignored.
57
+
58
+### Hidden Lockfiles
59
+
60
+In order to avoid processing the `node_modules` folder repeatedly, npm as of v7 uses a "hidden" lockfile present in `node_modules/.package-lock.json`. This contains information about the tree, and is used in lieu of reading the entire `node_modules` hierarchy provided that the following conditions are met:
61
+
62
+- All package folders it references exist in the `node_modules` hierarchy.
63
+- No package folders exist in the `node_modules` hierarchy that are not listed in the lockfile.
64
+- The modified time of the file is at least as recent as all of the package folders it references.
65
+
66
+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.
67
+
68
+Note that it _is_ possible to manually change the _contents_ of a package in such a way that the modified time of the package folder is unaffected. For example, if you add a file to `node_modules/foo/lib/bar.js`, then the modified time on `node_modules/foo` will not reflect this change. If you are manually editing files in `node_modules`, it is generally best to delete the file at `node_modules/.package-lock.json`.
69
+
70
+As the hidden lockfile is ignored by older npm versions, it does not contain the backwards compatibility affordances present in "normal" lockfiles. That is, it is `lockfileVersion: 3`, rather than `lockfileVersion: 2`.
71
+
72
+### Handling Old Lockfiles
73
+
74
+When npm detects a lockfile from npm v6 or before during the package installation process, it is automatically updated to fetch missing information from either the `node_modules` tree or (in the case of empty `node_modules` trees or very old lockfile formats) the npm registry.
75
+
76
+### File Format
77
+
78
+#### `name`
79
+
80
+The name of the package this is a package-lock for. This will match what's in `package.json`.
81
+
82
+#### `version`
83
+
84
+The version of the package this is a package-lock for. This will match what's in `package.json`.
85
+
86
+#### `lockfileVersion`
87
+
88
+An integer version, starting at `1` with the version number of this document whose semantics were used when generating this `package-lock.json`.
89
+
90
+Note that the file format changed significantly in npm v7 to track information that would have otherwise required looking in `node_modules` or the npm registry. Lockfiles generated by npm v7 will contain `lockfileVersion: 2`.
91
+
92
+- No version provided: an "ancient" shrinkwrap file from a version of npm prior to npm v5.
93
+- `1`: The lockfile version used by npm v5 and v6.
94
+- `2`: The lockfile version used by npm v7 and v8. Backwards compatible to v1 lockfiles.
95
+- `3`: The lockfile version used by npm v9 and above. Backwards compatible to npm v7.
96
+
97
+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.
98
+
99
+#### `packages`
100
+
101
+This is an object that maps package locations to an object containing the information about that package.
102
+
103
+The root project is typically listed with a key of `""`, and all other packages are listed with their relative paths from the root project folder.
104
+
105
+Package descriptors have the following fields:
106
+
107
+- version: The version found in `package.json`
108
+
109
+- resolved: The place where the package was actually resolved from. In the case of packages fetched from the registry, this will be a url to a tarball. In the case of git dependencies, this will be the full git url with commit sha. In the case of link dependencies, this will be the location of the link target. `registry.npmjs.org` is a magic value meaning "the currently configured registry".
110
+
111
+- integrity: A `sha512` or `sha1` [Standard Subresource Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) string for the artifact that was unpacked in this location.
112
+
113
+- 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.
114
+
115
+- dev, optional, devOptional: If the package is strictly part of the `devDependencies` tree, then `dev` will be true. If it is strictly part of the `optionalDependencies` tree, then `optional` will be set. If it is both a `dev` dependency _and_ an `optional` dependency of a non-dev dependency, then `devOptional` will be set. (An `optional` dependency of a `dev` dependency will have both `dev` and `optional` set.)
116
+
117
+- inBundle: A flag to indicate that the package is a bundled dependency.
118
+
119
+- hasInstallScript: A flag to indicate that the package has a `preinstall`, `install`, or `postinstall` script.
120
+
121
+- hasShrinkwrap: A flag to indicate that the package has an `npm-shrinkwrap.json` file.
122
+
123
+- bin, license, engines, dependencies, optionalDependencies: fields from `package.json`
124
+
125
+#### dependencies
126
+
127
+Legacy data for supporting versions of npm that use `lockfileVersion: 1`. This is a mapping of package names to dependency objects. Because the object structure is strictly hierarchical, symbolic link dependencies are somewhat challenging to represent in some cases.
128
+
129
+npm v7 ignores this section entirely if a `packages` section is present, but does keep it up to date in order to support switching between npm v6 and npm v7.
130
+
131
+Dependency objects have the following fields:
132
+
133
+- version: a specifier that varies depending on the nature of the package, and is usable in fetching a new copy of it.
134
+
135
+ - bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.
136
+ - registry sources: This is a version number. (eg, `1.2.3`)
137
+ - git sources: This is a git specifier with resolved committish. (eg, `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`)
138
+ - http tarball sources: This is the URL of the tarball. (eg, `https://example.com/example-1.3.0.tgz`)
139
+ - local tarball sources: This is the file URL of the tarball. (eg `file:///opt/storage/example-1.3.0.tgz`)
140
+ - local link sources: This is the file URL of the link. (eg `file:libs/our-module`)
141
+
142
+- integrity: A `sha512` or `sha1` [Standard Subresource Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) string for the artifact that was unpacked in this location. For git dependencies, this is the commit sha.
143
+
144
+- resolved: For registry sources this is path of the tarball relative to the registry URL. If the tarball URL isn't on the same server as the registry URL then this is a complete URL. `registry.npmjs.org` is a magic value meaning "the currently configured registry".
145
+
146
+- 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.
147
+
148
+- 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.
149
+
150
+- 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.
151
+
152
+- requires: This is a mapping of module name to version. This is a list of everything this module requires, regardless of where it will be installed. The version should match via normal matching rules a dependency either in our `dependencies` or in a level higher than us.
153
+
154
+- dependencies: The dependencies of this dependency, exactly as at the top level.
155
+
156
+### See also
157
+
158
+- [npm shrinkwrap](/cli/v11/commands/npm-shrinkwrap)
159
+- [npm-shrinkwrap.json](/cli/v11/configuring-npm/npm-shrinkwrap-json)
160
+- [package.json](/cli/v11/configuring-npm/package-json)
161
+- [npm install](/cli/v11/commands/npm-install)
content/cli/v11/index.mdx
new
+17
@@ -0,0 +1,17 @@
1
+---
2
+title: npm CLI
3
+shortName: CLI
4
+github_repo: npm/cli
5
+github_branch: latest
6
+github_path: docs/lib/content/nav.yml
7
+redirect_from:
8
+ - /cli
9
+ - /cli-documentation
10
+ - /cli-documentation/index
11
+ - /cli-documentation/v11
12
+ - /cli-documentation/v11/index
13
+ - /cli/index
14
+ - /cli/v11/index
15
+---
16
+
17
+<Index depth="1" />
content/cli/v11/using-npm/changelog.mdx
new
+178
@@ -0,0 +1,178 @@
1
+---
2
+title: Changelog
3
+github_repo: npm/cli
4
+github_branch: latest
5
+github_path: CHANGELOG.md
6
+redirect_from:
7
+ - /cli-documentation/misc/changelog
8
+ - /cli-documentation/using-npm/changelog
9
+ - /cli-documentation/v11/misc/changelog
10
+ - /cli-documentation/v11/using-npm/changelog
11
+ - /cli/misc/changelog
12
+ - /cli/using-npm/changelog
13
+ - /cli/v11/misc/changelog
14
+ - /misc/changelog
15
+ - /using-npm/changelog
16
+---
17
+
18
+## [11.0.0](https://github.com/npm/cli/compare/v11.0.0-pre.1...v11.0.0) (2024-12-16)
19
+
20
+### Documentation
21
+
22
+- [`8a911da`](https://github.com/npm/cli/commit/8a911da452b9785bcd051778570beeb2d8b27421) [#7963](https://github.com/npm/cli/pull/7963) ls: removed design change pending section note (#7963) (@milaninfy)
23
+
24
+### Dependencies
25
+
26
+- [`5319e48`](https://github.com/npm/cli/commit/5319e48a5a91768dccdfe728392dc2040e7ce27e) [#7973](https://github.com/npm/cli/pull/7973) remove unnecessary sprintf-js files in node_modules (#7973)
27
+- [`d369c77`](https://github.com/npm/cli/commit/d369c7716d753580da708723a2a4f8b3be767cb1) [#7976](https://github.com/npm/cli/pull/7976) `socks-proxy-agent@8.0.5`
28
+- [`3b2951a`](https://github.com/npm/cli/commit/3b2951a3ba1521b9866d9b33960aa3307d4f31dd) [#7976](https://github.com/npm/cli/pull/7976) `https-proxy-agent@7.0.6`
29
+- [`a598b7b`](https://github.com/npm/cli/commit/a598b7bd3de2b02bd14a3fa2f49c14a5ca50a43e) [#7976](https://github.com/npm/cli/pull/7976) `agent-base@7.1.3`
30
+- [`52bcaf6`](https://github.com/npm/cli/commit/52bcaf6464f44b30137ee3d3fe79322c1b1646ef) [#7976](https://github.com/npm/cli/pull/7976) `debug@4.4.0`
31
+- [`aabf345`](https://github.com/npm/cli/commit/aabf345a524f8aba7e0f45c0d4b8c86d5160d0cc) [#7976](https://github.com/npm/cli/pull/7976) `p-map@7.0.3`
32
+- [`28e8761`](https://github.com/npm/cli/commit/28e876135411cd9a93dbdd74906869c54286d7bc) [#7976](https://github.com/npm/cli/pull/7976) `npm-package-arg@12.0.1`
33
+
34
+### Chores
35
+
36
+- [`ecd7190`](https://github.com/npm/cli/commit/ecd719026860d464557223b212acec4347477128) [#7976](https://github.com/npm/cli/pull/7976) dev dependency updates (@wraithgar)
37
+- [`a07f4e0`](https://github.com/npm/cli/commit/a07f4e0d921f640be6aa87736debd550ec478f89) [#7976](https://github.com/npm/cli/pull/7976) `@npmcli/template-oss@4.23.6` (@wraithgar)
38
+- [`687ab12`](https://github.com/npm/cli/commit/687ab12eb5ea0ee1017101f3a83d42fd76299627) [#7970](https://github.com/npm/cli/pull/7970) remove pre-release mode from npm 11 and workspaces (#7970) (@wraithgar)
39
+- [workspace](https://github.com/npm/cli/releases/tag/arborist-v9.0.0): `@npmcli/arborist@9.0.0`
40
+- [workspace](https://github.com/npm/cli/releases/tag/config-v10.0.0): `@npmcli/config@10.0.0`
41
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmaccess-v10.0.0): `libnpmaccess@10.0.0`
42
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmdiff-v8.0.0): `libnpmdiff@8.0.0`
43
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmexec-v10.0.0): `libnpmexec@10.0.0`
44
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmfund-v7.0.0): `libnpmfund@7.0.0`
45
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmorg-v8.0.0): `libnpmorg@8.0.0`
46
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmpack-v9.0.0): `libnpmpack@9.0.0`
47
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmpublish-v11.0.0): `libnpmpublish@11.0.0`
48
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmsearch-v9.0.0): `libnpmsearch@9.0.0`
49
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmteam-v8.0.0): `libnpmteam@8.0.0`
50
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmversion-v8.0.0): `libnpmversion@8.0.0`
51
+
52
+## [11.0.0-pre.1](https://github.com/npm/cli/compare/v11.0.0-pre.0...v11.0.0-pre.1) (2024-12-06)
53
+
54
+### ⚠️ BREAKING CHANGES
55
+
56
+- Upon publishing, in order to apply a default "latest" dist tag, the command now retrieves all prior versions of the package. It will require that the version you're trying to publish is above the latest semver version in the registry, not including pre-release tags.
57
+- `npm init` now has a `type` prompt, and sorts the entries the created packages differently
58
+- `bun.lockb` files are now included in the strict ignore list during packing
59
+
60
+### Features
61
+
62
+- [`f3ac7b7`](https://github.com/npm/cli/commit/f3ac7b7460e1d9e1f9d3d8056317e36bb9813d5d) [#7939](https://github.com/npm/cli/pull/7939) no implicit latest tag on publish when latest > version (#7939) (@reggi, @ljharb)
63
+
64
+### Bug Fixes
65
+
66
+- [`e362c6d`](https://github.com/npm/cli/commit/e362c6d3a6c8bc0221b8c8a6c3dd623da9e6ae04) [#7944](https://github.com/npm/cli/pull/7944) prefix: remove duplicate -g from usage output (#7944) (@wraithgar)
67
+
68
+### Documentation
69
+
70
+- [`2af31dd`](https://github.com/npm/cli/commit/2af31dd30f4c226f43ce7295cd0b5fbb3f3cb2a6) [#7947](https://github.com/npm/cli/pull/7947) change certfile to cafile (#7947) (@wraithgar)
71
+- [`1be8e95`](https://github.com/npm/cli/commit/1be8e9500826e7aef041976fd908658f473caf23) [#7945](https://github.com/npm/cli/pull/7945) update ignore rules (@wraithgar)
72
+
73
+### Dependencies
74
+
75
+- [`bc9b14d`](https://github.com/npm/cli/commit/bc9b14dc35378262c36ef5f59f96455b21a430cc) [#7955](https://github.com/npm/cli/pull/7955) `@npmcli/run-script@9.0.2`
76
+- [`fecfcf4`](https://github.com/npm/cli/commit/fecfcf4987e30cc5ed04b0b77ccc9eb30c2b5c8f) [#7955](https://github.com/npm/cli/pull/7955) `node-gyp@11.0.0`
77
+- [`8905037`](https://github.com/npm/cli/commit/890503767c733a1eacfdd562b01eb37ac253906c) [#7955](https://github.com/npm/cli/pull/7955) `p-map@7.0.2`
78
+- [`ac8eb39`](https://github.com/npm/cli/commit/ac8eb390b0e0a21346fcdc5476ee0b884278b3a9) [#7955](https://github.com/npm/cli/pull/7955) `diff@7.0.0`
79
+- [`c0bcc2a`](https://github.com/npm/cli/commit/c0bcc2a860fec5c86234dec44f5474364c25aefc) [#7955](https://github.com/npm/cli/pull/7955) `walk-up-path@4.0.0`
80
+- [`d463a6f`](https://github.com/npm/cli/commit/d463a6f071da79b7a2151eeeea8a6f6cceea182f) [#7955](https://github.com/npm/cli/pull/7955) `init-package-json@8.0.0`
81
+- [`b87ba24`](https://github.com/npm/cli/commit/b87ba2402ab86532d54b7b4e09b38582c0f11a5e) [#7945](https://github.com/npm/cli/pull/7945) `@npmcli/package-json@6.1.0`
82
+- [`4bf1901`](https://github.com/npm/cli/commit/4bf1901f6dc57748d851ebe82262e9bef85a4ba7) [#7945](https://github.com/npm/cli/pull/7945) `@npmcli/metavuln-calculator@9.0.0`
83
+- [`ca84b22`](https://github.com/npm/cli/commit/ca84b22a18806495c37ef6ee2aecd42a1c7bb7f6) [#7945](https://github.com/npm/cli/pull/7945) `pacote@21.0.0`
84
+- [`4906f3d`](https://github.com/npm/cli/commit/4906f3ddf05c97f6e9832617a22c7ae228b46985) [#7945](https://github.com/npm/cli/pull/7945) `npm-packlist@10.0.0`
85
+
86
+### Chores
87
+
88
+- [`cfdf214`](https://github.com/npm/cli/commit/cfdf2147b5bfd80c7478486d07cb085de6fb8c4c) [#7943](https://github.com/npm/cli/pull/7943) fork changelog (#7943) (@wraithgar)
89
+- [workspace](https://github.com/npm/cli/releases/tag/arborist-v9.0.0-pre.1): `@npmcli/arborist@9.0.0-pre.1`
90
+- [workspace](https://github.com/npm/cli/releases/tag/config-v10.0.0-pre.1): `@npmcli/config@10.0.0-pre.1`
91
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmdiff-v8.0.0-pre.1): `libnpmdiff@8.0.0-pre.1`
92
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmexec-v10.0.0-pre.1): `libnpmexec@10.0.0-pre.1`
93
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmfund-v7.0.0-pre.1): `libnpmfund@7.0.0-pre.1`
94
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmorg-v8.0.0-pre.1): `libnpmorg@8.0.0-pre.1`
95
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmpack-v9.0.0-pre.1): `libnpmpack@9.0.0-pre.1`
96
+
97
+## [11.0.0-pre.0](https://github.com/npm/cli/compare/v10.9.0...v11.0.0-pre.0) (2024-11-26)
98
+
99
+### ⚠️ BREAKING CHANGES
100
+
101
+- When publishing a package with a pre-release version, you must explicitly specify a tag.
102
+- `--ignore-scripts` now applies to all lifecycle scripts, include `prepare`
103
+- npm will no longer fall back to the old audit endpoint if the bulk advisory request fails.
104
+- npm will no longer switch to global mode if aliased to "npmg" or "npm-g" etc.
105
+- The `npm hook` command has been removed
106
+- Attestations made by this package will no longer validate in npm versions prior to 10.6.0
107
+- npm now supports node `^20.17.0 || >=22.9.0`
108
+- @npmcli/docs now supports node `^20.17.0 || >=22.9.0`
109
+
110
+### Features
111
+
112
+- [`6995303`](https://github.com/npm/cli/commit/6995303687ab59541b727bf611f73624d1829b6c) [#7850](https://github.com/npm/cli/pull/7850) adds `--ignore-scripts` flag to `pack` (@reggi)
113
+
114
+### Bug Fixes
115
+
116
+- [`16b7367`](https://github.com/npm/cli/commit/16b7367245a0ea7228a27a43555eefb3c6b16870) [#7910](https://github.com/npm/cli/pull/7910) publishing prerelease requires explicit tag (#7910) (@reggi)
117
+- [`e19bff0`](https://github.com/npm/cli/commit/e19bff0ece79b189497720f076c0b324cb641061) [#7901](https://github.com/npm/cli/pull/7901) perf: enable compile cache if present (#7901) (@H4ad)
118
+- [`080a0f2`](https://github.com/npm/cli/commit/080a0f2d3f09a81f0a5b2992431e0bc7feb8d701) [#7911](https://github.com/npm/cli/pull/7911) remove old audit fallback request (@wraithgar)
119
+- [`780afc5`](https://github.com/npm/cli/commit/780afc50e3a345feb1871a28e33fa48235bc3bd5) [#7855](https://github.com/npm/cli/pull/7855) pkg: display if any of multiple attributes exist (#7855) (@Sanderovich)
120
+- [`ecd2d23`](https://github.com/npm/cli/commit/ecd2d23d429b2fee833e534e679cce97e4190b1b) [#7842](https://github.com/npm/cli/pull/7842) don't go into global mode if aliased to npmg (#7842) (@wraithgar)
121
+- [`62c71e5`](https://github.com/npm/cli/commit/62c71e5128a01283f97bd62da30ddc673bddda0b) [#7835](https://github.com/npm/cli/pull/7835) removes `npm hook` command (@reggi)
122
+- [`7f541e8`](https://github.com/npm/cli/commit/7f541e82a0b2908cc0cfef9a36b714eeab40c029) [#7815](https://github.com/npm/cli/pull/7815) make pack and exec work with git hash refs (#7815) (@milaninfy)
123
+- [`3162620`](https://github.com/npm/cli/commit/316262004747e04dfdcf2628abbc45cd366c86b8) [#7831](https://github.com/npm/cli/pull/7831) sets node engine range to `^20.17.0 || >=22.9.0` (@reggi)
124
+- [`4c8ba0a`](https://github.com/npm/cli/commit/4c8ba0aa678b532146200e4cc082f151983b0d82) [#7831](https://github.com/npm/cli/pull/7831) for @npmcli/docs sets node engine range to `^20.17.0 || >=22.9.0` (@reggi)
125
+- [`70cd88d`](https://github.com/npm/cli/commit/70cd88d95aa06ac96154c14ee262076704af807f) [#7808](https://github.com/npm/cli/pull/7808) view: sort and truncate dist-tags (#7808) (@wraithgar)
126
+- [`534ad77`](https://github.com/npm/cli/commit/534ad7789e5c61f579f44d782bdd18ea3ff1ee20) [#7795](https://github.com/npm/cli/pull/7795) remove unused parameters catch statements (#7795) (@btea)
127
+
128
+### Documentation
129
+
130
+- [`feb54f7`](https://github.com/npm/cli/commit/feb54f7e9a39bd52519221bae4fafc8bc70f235e) [#7822](https://github.com/npm/cli/pull/7822) package.json: add libc field (#7822) (@wraithgar)
131
+
132
+### Dependencies
133
+
134
+- [`78293ad`](https://github.com/npm/cli/commit/78293ad9b58b30b373dd69d15ea4e5735e720f55) [#7937](https://github.com/npm/cli/pull/7937) `spdx-license-ids@3.0.20`
135
+- [`33cf580`](https://github.com/npm/cli/commit/33cf5801308b4b0b2a055e842a340135367f8a8d) [#7937](https://github.com/npm/cli/pull/7937) `promise-call-limit@3.0.2`
136
+- [`ef1c368`](https://github.com/npm/cli/commit/ef1c3687b35295993258127ad7a5b0fd323fba8b) [#7937](https://github.com/npm/cli/pull/7937) `package-json-from-dist@1.0.1`
137
+- [`92e6f07`](https://github.com/npm/cli/commit/92e6f076789b3bc39377308b84ee834b98855258) [#7937](https://github.com/npm/cli/pull/7937) `npm-registry-fetch@18.0.2`
138
+- [`e32284a`](https://github.com/npm/cli/commit/e32284a8ebb679e41a2e8f0c8c63cc704296810c) [#7937](https://github.com/npm/cli/pull/7937) `npm-install-checks@7.1.1`
139
+- [`5dffd11`](https://github.com/npm/cli/commit/5dffd112ba85864582b9af688ffc0b6d1a6a0166) [#7937](https://github.com/npm/cli/pull/7937) `negotiator@0.6.4`
140
+- [`69d9f01`](https://github.com/npm/cli/commit/69d9f01ab11cb79bede2bde00423b9511d048c56) [#7937](https://github.com/npm/cli/pull/7937) `make-fetch-happen@14.0.3`
141
+- [`884bbde`](https://github.com/npm/cli/commit/884bbde5a2865722fae0eb4de386f4d55ebdba93) [#7937](https://github.com/npm/cli/pull/7937) `hosted-git-info@8.0.2`
142
+- [`3c74ec0`](https://github.com/npm/cli/commit/3c74ec00e1244178226b88331f703aded3c9d1e2) [#7937](https://github.com/npm/cli/pull/7937) `debug@4.3.7`
143
+- [`f00359f`](https://github.com/npm/cli/commit/f00359f422d00ea6d209d624e2885e072b0a8f60) [#7937](https://github.com/npm/cli/pull/7937) `cross-spawn@7.0.6`
144
+- [`534bbe8`](https://github.com/npm/cli/commit/534bbe8482f04f65c96c34fdd8734be91b29b18a) [#7937](https://github.com/npm/cli/pull/7937) `ci-info@4.1.0`
145
+- [`8cbf1a7`](https://github.com/npm/cli/commit/8cbf1a75e12c586cdf77f03f7494ecb17b7030df) [#7937](https://github.com/npm/cli/pull/7937) `@npmcli/promise-spawn@8.0.2`
146
+- [`1bd39e7`](https://github.com/npm/cli/commit/1bd39e7f766373021cc137fecc3cc3076967b444) [#7937](https://github.com/npm/cli/pull/7937) `@npmcli/map-workspaces@4.0.2`
147
+- [`eb6498d`](https://github.com/npm/cli/commit/eb6498dc543fa117ba4d4bc87c7bc77423e2b72a) [#7937](https://github.com/npm/cli/pull/7937) `ansi-regex@6.1.0`
148
+- [`66fc8c9`](https://github.com/npm/cli/commit/66fc8c997a37b0e28d35cb537fc68f6ed5466a73) [#7850](https://github.com/npm/cli/pull/7850) `@npmcli/metavuln-calculator@8.0.1`
149
+- [`7dbef6f`](https://github.com/npm/cli/commit/7dbef6f3a3ead089b1b8b9fe6b2fa25e24309000) [#7850](https://github.com/npm/cli/pull/7850) `pacote@20.0.0`
150
+- [`75a3f12`](https://github.com/npm/cli/commit/75a3f1228865f426d8790be27f1258e501f2c450) [#7859](https://github.com/npm/cli/pull/7859) remove unused deps (#7859)
151
+- [`f36dc59`](https://github.com/npm/cli/commit/f36dc593ecbfe77439a1d0e31afb5a45de3b8d14) [#7833](https://github.com/npm/cli/pull/7833) `pacote@19.0.1`
152
+- [`7ee15bb`](https://github.com/npm/cli/commit/7ee15bbdc1da0ed85297f47952b66089f29ed3fd) [#7833](https://github.com/npm/cli/pull/7833) bump sigstore from 2.x to 3.0.0 (@bdehamer)
153
+
154
+### Chores
155
+
156
+- [`2d530a5`](https://github.com/npm/cli/commit/2d530a5db705e72569d4beec02d86a2939b212f3) [#7941](https://github.com/npm/cli/pull/7941) tests: account for when npm is a prerelease (#7941) (@wraithgar)
157
+- [`2c1b369`](https://github.com/npm/cli/commit/2c1b36951b1af9b798ece9392d778d4f9eff2268) [#7937](https://github.com/npm/cli/pull/7937) dev dependency updates (@wraithgar)
158
+- [`6edfe2f`](https://github.com/npm/cli/commit/6edfe2f3a45169b6d194ccd8d366bb8d0e09b4a5) [#7937](https://github.com/npm/cli/pull/7937) `@npmcli/template-oss@4.23.5` (@wraithgar)
159
+- [`475285b`](https://github.com/npm/cli/commit/475285b81e8db441ccadca1273b2bae9d83fc941) [#7920](https://github.com/npm/cli/pull/7920) clean up dependency graph repos (#7920) (@hashtagchris)
160
+- [`ec57f5f`](https://github.com/npm/cli/commit/ec57f5f0831e6e82b87b9ed9ebdfa9fc3d5ba1ee) [#7911](https://github.com/npm/cli/pull/7911) fix dependencies script for circular workspace deps (@wraithgar)
161
+- [`ccd8420`](https://github.com/npm/cli/commit/ccd84201e4e369992289842a5117cb3b531a7a36) [#7911](https://github.com/npm/cli/pull/7911) fix cli tests for audit fallback removal (@wraithgar)
162
+- [`720b4d8`](https://github.com/npm/cli/commit/720b4d807bd2e214a045a9ffa9c56435823a7a05) [#7833](https://github.com/npm/cli/pull/7833) bump @npmcli/arborist to 8.0.0 (@wraithgar)
163
+- [`286739c`](https://github.com/npm/cli/commit/286739c0224bad88c4a38927bafd61973f71098c) [#7824](https://github.com/npm/cli/pull/7824) add creation of a DEPENDENCIES.json file (#7824) (@reggi)
164
+- [`852dd8b`](https://github.com/npm/cli/commit/852dd8bdcb958439d343bcd9fb27fb4f07e95991) [#7831](https://github.com/npm/cli/pull/7831) sets npm 11 to prerelase (@reggi)
165
+- [`95d009e`](https://github.com/npm/cli/commit/95d009e606b187b9e148f4f1119b8a19e5beb7f0) [#7831](https://github.com/npm/cli/pull/7831) update engine `^20.17.0 || >=22.9.0` in actions (@reggi)
166
+- [`5a74478`](https://github.com/npm/cli/commit/5a744782af53d6655669e49d911468934ea5e027) [#7831](https://github.com/npm/cli/pull/7831) update engines `^20.17.0 || >=22.9.0` in package template (@reggi)
167
+- [workspace](https://github.com/npm/cli/releases/tag/arborist-v9.0.0-pre.0): `@npmcli/arborist@9.0.0-pre.0`
168
+- [workspace](https://github.com/npm/cli/releases/tag/config-v10.0.0-pre.0): `@npmcli/config@10.0.0-pre.0`
169
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmaccess-v10.0.0-pre.0): `libnpmaccess@10.0.0-pre.0`
170
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmdiff-v8.0.0-pre.0): `libnpmdiff@8.0.0-pre.0`
171
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmexec-v10.0.0-pre.0): `libnpmexec@10.0.0-pre.0`
172
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmfund-v7.0.0-pre.0): `libnpmfund@7.0.0-pre.0`
173
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmorg-v8.0.0-pre.0): `libnpmorg@8.0.0-pre.0`
174
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmpack-v9.0.0-pre.0): `libnpmpack@9.0.0-pre.0`
175
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmpublish-v11.0.0-pre.0): `libnpmpublish@11.0.0-pre.0`
176
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmsearch-v9.0.0-pre.0): `libnpmsearch@9.0.0-pre.0`
177
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmteam-v8.0.0-pre.0): `libnpmteam@8.0.0-pre.0`
178
+- [workspace](https://github.com/npm/cli/releases/tag/libnpmversion-v8.0.0-pre.0): `libnpmversion@8.0.0-pre.0`
content/cli/v11/using-npm/config.mdx
new
+1463
@@ -0,0 +1,1463 @@
1
+---
2
+title: config
3
+section: 7
4
+description: More than you probably want to know about npm configuration
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/config.md
8
+redirect_from:
9
+ - /cli-documentation/misc/config
10
+ - /cli-documentation/using-npm/config
11
+ - /cli-documentation/v11/misc/config
12
+ - /cli-documentation/v11/using-npm/config
13
+ - /cli/misc/config
14
+ - /cli/using-npm/config
15
+ - /cli/v11/misc/config
16
+ - /misc/config
17
+ - /using-npm/config
18
+---
19
+
20
+### Description
21
+
22
+This article details npm configuration in general. To learn about the `config` command, see [`npm config`](/cli/v11/commands/npm-config).
23
+
24
+npm gets its configuration values from the following sources, sorted by priority:
25
+
26
+#### Command Line Flags
27
+
28
+Putting `--foo bar` on the command line sets the `foo` configuration parameter to `"bar"`. A `--` argument tells the cli parser to stop reading flags. Using `--flag` without specifying any value will set the value to `true`.
29
+
30
+Example: `--flag1 --flag2` will set both configuration parameters to `true`, while `--flag1 --flag2 bar` will set `flag1` to `true`, and `flag2` to `bar`. Finally, `--flag1 --flag2 -- bar` will set both configuration parameters to `true`, and the `bar` is taken as a command argument.
31
+
32
+#### Environment Variables
33
+
34
+Any environment variables that start with `npm_config_` will be interpreted as a configuration parameter. For example, putting `npm_config_foo=bar` in your environment will set the `foo` configuration parameter to `bar`. Any environment configurations that are not given a value will be given the value of `true`. Config values are case-insensitive, so `NPM_CONFIG_FOO=bar` will work the same. However, please note that inside [`scripts`](/cli/v11/using-npm/scripts) npm will set its own environment variables and Node will prefer those lowercase versions over any uppercase ones that you might set. For details see [this issue](https://github.com/npm/npm/issues/14528).
35
+
36
+Notice that you need to use underscores instead of dashes, so `--allow-same-version` would become `npm_config_allow_same_version=true`.
37
+
38
+#### npmrc Files
39
+
40
+The four relevant files are:
41
+
42
+- per-project configuration file (`/path/to/my/project/.npmrc`)
43
+- per-user configuration file (defaults to `$HOME/.npmrc`; configurable via CLI option `--userconfig` or environment variable `$NPM_CONFIG_USERCONFIG`)
44
+- global configuration file (defaults to `$PREFIX/etc/npmrc`; configurable via CLI option `--globalconfig` or environment variable `$NPM_CONFIG_GLOBALCONFIG`)
45
+- npm's built-in configuration file (`/path/to/npm/npmrc`)
46
+
47
+See [npmrc](/cli/v11/configuring-npm/npmrc) for more details.
48
+
49
+#### Default Configs
50
+
51
+Run `npm config ls -l` to see a set of configuration parameters that are internal to npm, and are defaults if nothing else is specified.
52
+
53
+### Shorthands and Other CLI Niceties
54
+
55
+The following shorthands are parsed on the command-line:
56
+
57
+- `-a`: `--all`
58
+- `--enjoy-by`: `--before`
59
+- `-c`: `--call`
60
+- `--desc`: `--description`
61
+- `-f`: `--force`
62
+- `-g`: `--global`
63
+- `--iwr`: `--include-workspace-root`
64
+- `-L`: `--location`
65
+- `-d`: `--loglevel info`
66
+- `-s`: `--loglevel silent`
67
+- `--silent`: `--loglevel silent`
68
+- `--ddd`: `--loglevel silly`
69
+- `--dd`: `--loglevel verbose`
70
+- `--verbose`: `--loglevel verbose`
71
+- `-q`: `--loglevel warn`
72
+- `--quiet`: `--loglevel warn`
73
+- `-l`: `--long`
74
+- `-m`: `--message`
75
+- `--local`: `--no-global`
76
+- `-n`: `--no-yes`
77
+- `--no`: `--no-yes`
78
+- `-p`: `--parseable`
79
+- `--porcelain`: `--parseable`
80
+- `-C`: `--prefix`
81
+- `--readonly`: `--read-only`
82
+- `--reg`: `--registry`
83
+- `-S`: `--save`
84
+- `-B`: `--save-bundle`
85
+- `-D`: `--save-dev`
86
+- `-E`: `--save-exact`
87
+- `-O`: `--save-optional`
88
+- `-P`: `--save-prod`
89
+- `-?`: `--usage`
90
+- `-h`: `--usage`
91
+- `-H`: `--usage`
92
+- `--help`: `--usage`
93
+- `-v`: `--version`
94
+- `-w`: `--workspace`
95
+- `--ws`: `--workspaces`
96
+- `-y`: `--yes`
97
+
98
+If the specified configuration param resolves unambiguously to a known configuration parameter, then it is expanded to that configuration parameter. For example:
99
+
100
+```bash
101
+npm ls --par
102
+# same as:
103
+npm ls --parseable
104
+```
105
+
106
+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:
107
+
108
+```bash
109
+npm ls -gpld
110
+# same as:
111
+npm ls --global --parseable --long --loglevel info
112
+```
113
+
114
+### Config Settings
115
+
116
+#### `_auth`
117
+
118
+- Default: null
119
+- Type: null or String
120
+
121
+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"
122
+
123
+Warning: This should generally not be set via a command-line option. It is safer to use a registry-provided authentication bearer token stored in the ~/.npmrc file by running `npm login`.
124
+
125
+#### `access`
126
+
127
+- Default: 'public' for new packages, existing packages it will not change the current level
128
+- Type: null, "restricted", or "public"
129
+
130
+If you do not want your scoped package to be publicly viewable (and installable) set `--access=restricted`.
131
+
132
+Unscoped packages can not be set to `restricted`.
133
+
134
+Note: This defaults to not changing the current access level for existing packages. Specifying a value of `restricted` or `public` during publish will change the access for an existing package the same way that `npm access set status` would.
135
+
136
+#### `all`
137
+
138
+- Default: false
139
+- Type: Boolean
140
+
141
+When running `npm outdated` and `npm ls`, setting `--all` will show all outdated or installed packages, rather than only those directly depended upon by the current project.
142
+
143
+#### `allow-same-version`
144
+
145
+- Default: false
146
+- Type: Boolean
147
+
148
+Prevents throwing an error when `npm version` is used to set the new version to the same value as the current version.
149
+
150
+#### `audit`
151
+
152
+- Default: true
153
+- Type: Boolean
154
+
155
+When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for [`npm audit`](/cli/v11/commands/npm-audit) for details on what is submitted.
156
+
157
+#### `audit-level`
158
+
159
+- Default: null
160
+- Type: null, "info", "low", "moderate", "high", "critical", or "none"
161
+
162
+The minimum level of vulnerability for `npm audit` to exit with a non-zero exit code.
163
+
164
+#### `auth-type`
165
+
166
+- Default: "web"
167
+- Type: "legacy" or "web"
168
+
169
+What authentication strategy to use with `login`. Note that if an `otp` config is given, this value will always be set to `legacy`.
170
+
171
+#### `before`
172
+
173
+- Default: null
174
+- Type: null or Date
175
+
176
+If passed to `npm install`, will rebuild the npm tree such that only versions that were available **on or before** the `--before` time get installed. If there's no versions available for the current set of direct dependencies, the command will error.
177
+
178
+If the requested version is a `dist-tag` and the given tag does not pass the `--before` filter, the most recent version less than or equal to that tag will be used. For example, `foo@latest` might install `foo@1.2` even though `latest` is `2.0`.
179
+
180
+#### `bin-links`
181
+
182
+- Default: true
183
+- Type: Boolean
184
+
185
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
186
+
187
+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.
188
+
189
+#### `browser`
190
+
191
+- Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
192
+- Type: null, Boolean, or String
193
+
194
+The browser that is called by npm commands to open websites.
195
+
196
+Set to `false` to suppress browser behavior and instead print urls to terminal.
197
+
198
+Set to `true` to use default system URL opener.
199
+
200
+#### `ca`
201
+
202
+- Default: null
203
+- Type: null or String (can be set multiple times)
204
+
205
+The Certificate Authority signing certificate that is trusted for SSL connections to the registry. Values should be in PEM format (Windows calls it "Base-64 encoded X.509 (.CER)") with newlines replaced by the string "\n". For example:
206
+
207
+```ini
208
+ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
209
+```
210
+
211
+Set to `null` to only allow "known" registrars, or to a specific CA cert to trust only that specific signing authority.
212
+
213
+Multiple CAs can be trusted by specifying an array of certificates:
214
+
215
+```ini
216
+ca[]="..."
217
+ca[]="..."
218
+```
219
+
220
+See also the `strict-ssl` config.
221
+
222
+#### `cache`
223
+
224
+- Default: Windows: `%LocalAppData%\npm-cache`, Posix: `~/.npm`
225
+- Type: Path
226
+
227
+The location of npm's cache directory.
228
+
229
+#### `cafile`
230
+
231
+- Default: null
232
+- Type: Path
233
+
234
+A path to a file containing one or multiple Certificate Authority signing certificates. Similar to the `ca` setting, but allows for multiple CA's, as well as for the CA information to be stored in a file on disk.
235
+
236
+#### `call`
237
+
238
+- Default: ""
239
+- Type: String
240
+
241
+Optional companion option for `npm exec`, `npx` that allows for specifying a custom command to be run along with the installed packages.
242
+
243
+```bash
244
+npm exec --package yo --package generator-node --call "yo node"
245
+```
246
+
247
+#### `cidr`
248
+
249
+- Default: null
250
+- Type: null or String (can be set multiple times)
251
+
252
+This is a list of CIDR address to be used when configuring limited access tokens with the `npm token create` command.
253
+
254
+#### `color`
255
+
256
+- Default: true unless the NO_COLOR environ is set to something other than '0'
257
+- Type: "always" or Boolean
258
+
259
+If false, never shows colors. If `"always"` then always shows colors. If true, then only prints color codes for tty file descriptors.
260
+
261
+#### `commit-hooks`
262
+
263
+- Default: true
264
+- Type: Boolean
265
+
266
+Run git commit hooks when using the `npm version` command.
267
+
268
+#### `cpu`
269
+
270
+- Default: null
271
+- Type: null or String
272
+
273
+Override CPU architecture of native modules to install. Acceptable values are same as `cpu` field of package.json, which comes from `process.arch`.
274
+
275
+#### `depth`
276
+
277
+- Default: `Infinity` if `--all` is set, otherwise `1`
278
+- Type: null or Number
279
+
280
+The depth to go when recursing packages for `npm ls`.
281
+
282
+If not set, `npm ls` will show only the immediate dependencies of the root project. If `--all` is set, then npm will show all dependencies by default.
283
+
284
+#### `description`
285
+
286
+- Default: true
287
+- Type: Boolean
288
+
289
+Show the description in `npm search`
290
+
291
+#### `diff`
292
+
293
+- Default:
294
+- Type: String (can be set multiple times)
295
+
296
+Define arguments to compare in `npm diff`.
297
+
298
+#### `diff-dst-prefix`
299
+
300
+- Default: "b/"
301
+- Type: String
302
+
303
+Destination prefix to be used in `npm diff` output.
304
+
305
+#### `diff-ignore-all-space`
306
+
307
+- Default: false
308
+- Type: Boolean
309
+
310
+Ignore whitespace when comparing lines in `npm diff`.
311
+
312
+#### `diff-name-only`
313
+
314
+- Default: false
315
+- Type: Boolean
316
+
317
+Prints only filenames when using `npm diff`.
318
+
319
+#### `diff-no-prefix`
320
+
321
+- Default: false
322
+- Type: Boolean
323
+
324
+Do not show any source or destination prefix in `npm diff` output.
325
+
326
+Note: this causes `npm diff` to ignore the `--diff-src-prefix` and `--diff-dst-prefix` configs.
327
+
328
+#### `diff-src-prefix`
329
+
330
+- Default: "a/"
331
+- Type: String
332
+
333
+Source prefix to be used in `npm diff` output.
334
+
335
+#### `diff-text`
336
+
337
+- Default: false
338
+- Type: Boolean
339
+
340
+Treat all files as text in `npm diff`.
341
+
342
+#### `diff-unified`
343
+
344
+- Default: 3
345
+- Type: Number
346
+
347
+The number of lines of context to print in `npm diff`.
348
+
349
+#### `dry-run`
350
+
351
+- Default: false
352
+- Type: Boolean
353
+
354
+Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, `install`, `update`, `dedupe`, `uninstall`, as well as `pack` and `publish`.
355
+
356
+Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
357
+
358
+#### `editor`
359
+
360
+- Default: The EDITOR or VISUAL environment variables, or '%SYSTEMROOT%\notepad.exe' on Windows, or 'vi' on Unix systems
361
+- Type: String
362
+
363
+The command to run for `npm edit` and `npm config edit`.
364
+
365
+#### `engine-strict`
366
+
367
+- Default: false
368
+- Type: Boolean
369
+
370
+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.
371
+
372
+This can be overridden by setting the `--force` flag.
373
+
374
+#### `expect-result-count`
375
+
376
+- Default: null
377
+- Type: null or Number
378
+
379
+Tells to expect a specific number of results from the command.
380
+
381
+This config can not be used with: `expect-results`
382
+
383
+#### `expect-results`
384
+
385
+- Default: null
386
+- Type: null or Boolean
387
+
388
+Tells npm whether or not to expect results from the command. Can be either true (expect some results) or false (expect no results).
389
+
390
+This config can not be used with: `expect-result-count`
391
+
392
+#### `fetch-retries`
393
+
394
+- Default: 2
395
+- Type: Number
396
+
397
+The "retries" config for the `retry` module to use when fetching packages from the registry.
398
+
399
+npm will retry idempotent read requests to the registry in the case of network failures or 5xx HTTP errors.
400
+
401
+#### `fetch-retry-factor`
402
+
403
+- Default: 10
404
+- Type: Number
405
+
406
+The "factor" config for the `retry` module to use when fetching packages.
407
+
408
+#### `fetch-retry-maxtimeout`
409
+
410
+- Default: 60000 (1 minute)
411
+- Type: Number
412
+
413
+The "maxTimeout" config for the `retry` module to use when fetching packages.
414
+
415
+#### `fetch-retry-mintimeout`
416
+
417
+- Default: 10000 (10 seconds)
418
+- Type: Number
419
+
420
+The "minTimeout" config for the `retry` module to use when fetching packages.
421
+
422
+#### `fetch-timeout`
423
+
424
+- Default: 300000 (5 minutes)
425
+- Type: Number
426
+
427
+The maximum amount of time to wait for HTTP requests to complete.
428
+
429
+#### `force`
430
+
431
+- Default: false
432
+- Type: Boolean
433
+
434
+Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
435
+
436
+- Allow clobbering non-npm files in global installs.
437
+- Allow the `npm version` command to work on an unclean git repository.
438
+- Allow deleting the cache folder with `npm cache clean`.
439
+- Allow installing packages that have an `engines` declaration requiring a different version of npm.
440
+- Allow installing packages that have an `engines` declaration requiring a different version of `node`, even if `--engine-strict` is enabled.
441
+- Allow `npm audit fix` to install modules outside your stated dependency range (including SemVer-major changes).
442
+- Allow unpublishing all versions of a published package.
443
+- Allow conflicting peerDependencies to be installed in the root project.
444
+- Implicitly set `--yes` during `npm init`.
445
+- Allow clobbering existing values in `npm pkg`
446
+- Allow unpublishing of entire packages (not just a single version).
447
+
448
+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!
449
+
450
+#### `foreground-scripts`
451
+
452
+- Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
453
+- Type: Boolean
454
+
455
+Run all build scripts (ie, `preinstall`, `install`, and `postinstall`) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
456
+
457
+Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
458
+
459
+#### `format-package-lock`
460
+
461
+- Default: true
462
+- Type: Boolean
463
+
464
+Format `package-lock.json` or `npm-shrinkwrap.json` as a human readable file.
465
+
466
+#### `fund`
467
+
468
+- Default: true
469
+- Type: Boolean
470
+
471
+When "true" displays the message at the end of each `npm install` acknowledging the number of dependencies looking for funding. See [`npm fund`](/cli/v11/commands/npm-fund) for details.
472
+
473
+#### `git`
474
+
475
+- Default: "git"
476
+- Type: String
477
+
478
+The command to use for git commands. If git is installed on the computer, but is not in the `PATH`, then set this to the full path to the git binary.
479
+
480
+#### `git-tag-version`
481
+
482
+- Default: true
483
+- Type: Boolean
484
+
485
+Tag the commit when using the `npm version` command. Setting this to false results in no commit being made at all.
486
+
487
+#### `global`
488
+
489
+- Default: false
490
+- Type: Boolean
491
+
492
+Operates in "global" mode, so that packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
493
+
494
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
495
+- bin files are linked to `{prefix}/bin`
496
+- man pages are linked to `{prefix}/share/man`
497
+
498
+#### `globalconfig`
499
+
500
+- Default: The global --prefix setting plus 'etc/npmrc'. For example, '/usr/local/etc/npmrc'
501
+- Type: Path
502
+
503
+The config file to read for global config options.
504
+
505
+#### `heading`
506
+
507
+- Default: "npm"
508
+- Type: String
509
+
510
+The string that starts all the debugging log output.
511
+
512
+#### `https-proxy`
513
+
514
+- Default: null
515
+- Type: null or URL
516
+
517
+A proxy to use for outgoing https requests. If the `HTTPS_PROXY` or `https_proxy` or `HTTP_PROXY` or `http_proxy` environment variables are set, proxy settings will be honored by the underlying `make-fetch-happen` library.
518
+
519
+#### `if-present`
520
+
521
+- Default: false
522
+- Type: Boolean
523
+
524
+If true, npm will not exit with an error code when `run-script` is invoked for a script that isn't defined in the `scripts` section of `package.json`. This option can be used when it's desirable to optionally run a script when it's present and fail if the script fails. This is useful, for example, when running scripts that may only apply for some builds in an otherwise generic CI setup.
525
+
526
+This value is not exported to the environment for child processes.
527
+
528
+#### `ignore-scripts`
529
+
530
+- Default: false
531
+- Type: Boolean
532
+
533
+If true, npm does not run scripts specified in package.json files.
534
+
535
+Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
536
+
537
+#### `include`
538
+
539
+- Default:
540
+- Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
541
+
542
+Option that allows for defining which types of dependencies to install.
543
+
544
+This is the inverse of `--omit=<type>`.
545
+
546
+Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
547
+
548
+#### `include-staged`
549
+
550
+- Default: false
551
+- Type: Boolean
552
+
553
+Allow installing "staged" published packages, as defined by [npm RFC PR #92](https://github.com/npm/rfcs/pull/92).
554
+
555
+This is experimental, and not implemented by the npm public registry.
556
+
557
+#### `include-workspace-root`
558
+
559
+- Default: false
560
+- Type: Boolean
561
+
562
+Include the workspace root when workspaces are enabled for a command.
563
+
564
+When false, specifying individual workspaces via the `workspace` config, or all workspaces via the `workspaces` flag, will cause npm to operate only on the specified workspaces, and not on the root project.
565
+
566
+This value is not exported to the environment for child processes.
567
+
568
+#### `init-author-email`
569
+
570
+- Default: ""
571
+- Type: String
572
+
573
+The value `npm init` should use by default for the package author's email.
574
+
575
+#### `init-author-name`
576
+
577
+- Default: ""
578
+- Type: String
579
+
580
+The value `npm init` should use by default for the package author's name.
581
+
582
+#### `init-author-url`
583
+
584
+- Default: ""
585
+- Type: "" or URL
586
+
587
+The value `npm init` should use by default for the package author's homepage.
588
+
589
+#### `init-license`
590
+
591
+- Default: "ISC"
592
+- Type: String
593
+
594
+The value `npm init` should use by default for the package license.
595
+
596
+#### `init-module`
597
+
598
+- Default: "~/.npm-init.js"
599
+- Type: Path
600
+
601
+A module that will be loaded by the `npm init` command. See the documentation for the [init-package-json](https://github.com/npm/init-package-json) module for more information, or [npm init](/cli/v11/commands/npm-init).
602
+
603
+#### `init-version`
604
+
605
+- Default: "1.0.0"
606
+- Type: SemVer string
607
+
608
+The value that `npm init` should use by default for the package version number, if not already set in package.json.
609
+
610
+#### `install-links`
611
+
612
+- Default: false
613
+- Type: Boolean
614
+
615
+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.
616
+
617
+#### `install-strategy`
618
+
619
+- Default: "hoisted"
620
+- Type: "hoisted", "nested", "shallow", or "linked"
621
+
622
+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.
623
+
624
+#### `json`
625
+
626
+- Default: false
627
+- Type: Boolean
628
+
629
+Whether or not to output JSON data, rather than the normal output.
630
+
631
+- In `npm pkg set` it enables parsing set values with JSON.parse() before saving them to your `package.json`.
632
+
633
+Not supported by all npm commands.
634
+
635
+#### `legacy-peer-deps`
636
+
637
+- Default: false
638
+- Type: Boolean
639
+
640
+Causes npm to completely ignore `peerDependencies` when building a package tree, as in npm versions 3 through 6.
641
+
642
+If a package cannot be installed because of overly strict `peerDependencies` that collide, it provides a way to move forward resolving the situation.
643
+
644
+This differs from `--omit=peer`, in that `--omit=peer` will avoid unpacking `peerDependencies` on disk, but will still design a tree such that `peerDependencies` _could_ be unpacked in a correct place.
645
+
646
+Use of `legacy-peer-deps` is not recommended, as it will not enforce the `peerDependencies` contract that meta-dependencies may rely on.
647
+
648
+#### `libc`
649
+
650
+- Default: null
651
+- Type: null or String
652
+
653
+Override libc of native modules to install. Acceptable values are same as `libc` field of package.json
654
+
655
+#### `link`
656
+
657
+- Default: false
658
+- Type: Boolean
659
+
660
+Used with `npm ls`, limiting output to only those packages that are linked.
661
+
662
+#### `local-address`
663
+
664
+- Default: null
665
+- Type: IP Address
666
+
667
+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.
668
+
669
+#### `location`
670
+
671
+- Default: "user" unless `--global` is passed, which will also set this value to "global"
672
+- Type: "global", "user", or "project"
673
+
674
+When passed to `npm config` this refers to which config file to use.
675
+
676
+When set to "global" mode, packages are installed into the `prefix` folder instead of the current working directory. See [folders](/cli/v11/configuring-npm/folders) for more on the differences in behavior.
677
+
678
+- packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
679
+- bin files are linked to `{prefix}/bin`
680
+- man pages are linked to `{prefix}/share/man`
681
+
682
+#### `lockfile-version`
683
+
684
+- Default: Version 3 if no lockfile, auto-converting v1 lockfiles to v3, otherwise maintain current lockfile version.
685
+- Type: null, 1, 2, 3, "1", "2", or "3"
686
+
687
+Set the lockfile format version to be used in package-lock.json and npm-shrinkwrap-json files. Possible options are:
688
+
689
+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.
690
+
691
+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.
692
+
693
+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.
694
+
695
+#### `loglevel`
696
+
697
+- Default: "notice"
698
+- Type: "silent", "error", "warn", "notice", "http", "info", "verbose", or "silly"
699
+
700
+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.
701
+
702
+Any logs of a higher level than the setting are shown. The default is "notice".
703
+
704
+See also the `foreground-scripts` config.
705
+
706
+#### `logs-dir`
707
+
708
+- Default: A directory named `_logs` inside the cache
709
+- Type: null or Path
710
+
711
+The location of npm's log directory. See [`npm logging`](/cli/v11/using-npm/logging) for more information.
712
+
713
+#### `logs-max`
714
+
715
+- Default: 10
716
+- Type: Number
717
+
718
+The maximum number of log files to store.
719
+
720
+If set to 0, no log files will be written for the current run.
721
+
722
+#### `long`
723
+
724
+- Default: false
725
+- Type: Boolean
726
+
727
+Show extended information in `ls`, `search`, and `help-search`.
728
+
729
+#### `maxsockets`
730
+
731
+- Default: 15
732
+- Type: Number
733
+
734
+The maximum number of connections to use per origin (protocol/host/port combination).
735
+
736
+#### `message`
737
+
738
+- Default: "%s"
739
+- Type: String
740
+
741
+Commit message which is used by `npm version` when creating version commit.
742
+
743
+Any "%s" in the message will be replaced with the version number.
744
+
745
+#### `node-options`
746
+
747
+- Default: null
748
+- Type: null or String
749
+
750
+Options to pass through to Node.js via the `NODE_OPTIONS` environment variable. This does not impact how npm itself is executed but it does impact how lifecycle scripts are called.
751
+
752
+#### `noproxy`
753
+
754
+- Default: The value of the NO_PROXY environment variable
755
+- Type: String (can be set multiple times)
756
+
757
+Domain extensions that should bypass any proxies.
758
+
759
+Also accepts a comma-delimited string.
760
+
761
+#### `offline`
762
+
763
+- Default: false
764
+- Type: Boolean
765
+
766
+Force offline mode: no network requests will be done during install. To allow the CLI to fill in missing cache data, see `--prefer-offline`.
767
+
768
+#### `omit`
769
+
770
+- Default: 'dev' if the `NODE_ENV` environment variable is set to 'production', otherwise empty.
771
+- Type: "dev", "optional", or "peer" (can be set multiple times)
772
+
773
+Dependency types to omit from the installation tree on disk.
774
+
775
+Note that these dependencies _are_ still resolved and added to the `package-lock.json` or `npm-shrinkwrap.json` file. They are just not physically installed on disk.
776
+
777
+If a package type appears in both the `--include` and `--omit` lists, then it will be included.
778
+
779
+If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
780
+
781
+#### `omit-lockfile-registry-resolved`
782
+
783
+- Default: false
784
+- Type: Boolean
785
+
786
+This option causes npm to create lock files without a `resolved` key for registry dependencies. Subsequent installs will need to resolve tarball endpoints with the configured registry, likely resulting in a longer install time.
787
+
788
+#### `os`
789
+
790
+- Default: null
791
+- Type: null or String
792
+
793
+Override OS of native modules to install. Acceptable values are same as `os` field of package.json, which comes from `process.platform`.
794
+
795
+#### `otp`
796
+
797
+- Default: null
798
+- Type: null or String
799
+
800
+This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with `npm access`.
801
+
802
+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.
803
+
804
+#### `pack-destination`
805
+
806
+- Default: "."
807
+- Type: String
808
+
809
+Directory in which `npm pack` will save tarballs.
810
+
811
+#### `package`
812
+
813
+- Default:
814
+- Type: String (can be set multiple times)
815
+
816
+The package or packages to install for [`npm exec`](/cli/v11/commands/npm-exec)
817
+
818
+#### `package-lock`
819
+
820
+- Default: true
821
+- Type: Boolean
822
+
823
+If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
824
+
825
+#### `package-lock-only`
826
+
827
+- Default: false
828
+- Type: Boolean
829
+
830
+If set to true, the current operation will only use the `package-lock.json`, ignoring `node_modules`.
831
+
832
+For `update` this means only the `package-lock.json` will be updated, instead of checking `node_modules` and downloading dependencies.
833
+
834
+For `list` this means the output will be based on the tree described by the `package-lock.json`, rather than the contents of `node_modules`.
835
+
836
+#### `parseable`
837
+
838
+- Default: false
839
+- Type: Boolean
840
+
841
+Output parseable results from commands that write to standard output. For `npm search`, this will be tab-separated table format.
842
+
843
+#### `prefer-dedupe`
844
+
845
+- Default: false
846
+- Type: Boolean
847
+
848
+Prefer to deduplicate packages if possible, rather than choosing a newer version of a dependency.
849
+
850
+#### `prefer-offline`
851
+
852
+- Default: false
853
+- Type: Boolean
854
+
855
+If true, staleness checks for cached data will be bypassed, but missing data will be requested from the server. To force full offline mode, use `--offline`.
856
+
857
+#### `prefer-online`
858
+
859
+- Default: false
860
+- Type: Boolean
861
+
862
+If true, staleness checks for cached data will be forced, making the CLI look for updates immediately even for fresh package data.
863
+
864
+#### `prefix`
865
+
866
+- 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.
867
+- Type: Path
868
+
869
+The location to install global items. If set on the command line, then it forces non-global commands to run in the specified folder.
870
+
871
+#### `preid`
872
+
873
+- Default: ""
874
+- Type: String
875
+
876
+The "prerelease identifier" to use as a prefix for the "prerelease" part of a semver. Like the `rc` in `1.2.0-rc.8`.
877
+
878
+#### `progress`
879
+
880
+- Default: `true` unless running in a known CI system
881
+- Type: Boolean
882
+
883
+When set to `true`, npm will display a progress bar during time intensive operations, if `process.stderr` and `process.stdout` are a TTY.
884
+
885
+Set to `false` to suppress the progress bar.
886
+
887
+#### `provenance`
888
+
889
+- Default: false
890
+- Type: Boolean
891
+
892
+When publishing from a supported cloud CI/CD system, the package will be publicly linked to where it was built and published from.
893
+
894
+This config can not be used with: `provenance-file`
895
+
896
+#### `provenance-file`
897
+
898
+- Default: null
899
+- Type: Path
900
+
901
+When publishing, the provenance bundle at the given path will be used.
902
+
903
+This config can not be used with: `provenance`
904
+
905
+#### `proxy`
906
+
907
+- Default: null
908
+- Type: null, false, or URL
909
+
910
+A proxy to use for outgoing http requests. If the `HTTP_PROXY` or `http_proxy` environment variables are set, proxy settings will be honored by the underlying `request` library.
911
+
912
+#### `read-only`
913
+
914
+- Default: false
915
+- Type: Boolean
916
+
917
+This is used to mark a token as unable to publish when configuring limited access tokens with the `npm token create` command.
918
+
919
+#### `rebuild-bundle`
920
+
921
+- Default: true
922
+- Type: Boolean
923
+
924
+Rebuild bundled dependencies after installation.
925
+
926
+#### `registry`
927
+
928
+- Default: "https://registry.npmjs.org/"
929
+- Type: URL
930
+
931
+The base URL of the npm registry.
932
+
933
+#### `replace-registry-host`
934
+
935
+- Default: "npmjs"
936
+- Type: "npmjs", "never", "always", or String
937
+
938
+Defines behavior for replacing the registry host in a lockfile with the configured registry.
939
+
940
+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.
941
+
942
+You may also specify a bare hostname (e.g., "registry.npmjs.org").
943
+
944
+#### `save`
945
+
946
+- Default: `true` unless when using `npm update` where it defaults to `false`
947
+- Type: Boolean
948
+
949
+Save installed packages to a `package.json` file as dependencies.
950
+
951
+When used with the `npm rm` command, removes the dependency from `package.json`.
952
+
953
+Will also prevent writing to `package-lock.json` if set to `false`.
954
+
955
+#### `save-bundle`
956
+
957
+- Default: false
958
+- Type: Boolean
959
+
960
+If a package would be saved at install time by the use of `--save`, `--save-dev`, or `--save-optional`, then also put it in the `bundleDependencies` list.
961
+
962
+Ignored if `--save-peer` is set, since peerDependencies cannot be bundled.
963
+
964
+#### `save-dev`
965
+
966
+- Default: false
967
+- Type: Boolean
968
+
969
+Save installed packages to a package.json file as `devDependencies`.
970
+
971
+#### `save-exact`
972
+
973
+- Default: false
974
+- Type: Boolean
975
+
976
+Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
977
+
978
+#### `save-optional`
979
+
980
+- Default: false
981
+- Type: Boolean
982
+
983
+Save installed packages to a package.json file as `optionalDependencies`.
984
+
985
+#### `save-peer`
986
+
987
+- Default: false
988
+- Type: Boolean
989
+
990
+Save installed packages to a package.json file as `peerDependencies`
991
+
992
+#### `save-prefix`
993
+
994
+- Default: "^"
995
+- Type: String
996
+
997
+Configure how versions of packages installed to a package.json file via `--save` or `--save-dev` get prefixed.
998
+
999
+For example if a package has version `1.2.3`, by default its version is set to `^1.2.3` which allows minor upgrades for that package, but after `npm config set save-prefix='~'` it would be set to `~1.2.3` which only allows patch upgrades.
1000
+
1001
+#### `save-prod`
1002
+
1003
+- Default: false
1004
+- Type: Boolean
1005
+
1006
+Save installed packages into `dependencies` specifically. This is useful if a package already exists in `devDependencies` or `optionalDependencies`, but you want to move it to be a non-optional production dependency.
1007
+
1008
+This is the default behavior if `--save` is true, and neither `--save-dev` or `--save-optional` are true.
1009
+
1010
+#### `sbom-format`
1011
+
1012
+- Default: null
1013
+- Type: "cyclonedx" or "spdx"
1014
+
1015
+SBOM format to use when generating SBOMs.
1016
+
1017
+#### `sbom-type`
1018
+
1019
+- Default: "library"
1020
+- Type: "library", "application", or "framework"
1021
+
1022
+The type of package described by the generated SBOM. For SPDX, this is the value for the `primaryPackagePurpose` field. For CycloneDX, this is the value for the `type` field.
1023
+
1024
+#### `scope`
1025
+
1026
+- Default: the scope of the current project, if any, or ""
1027
+- Type: String
1028
+
1029
+Associate an operation with a scope for a scoped registry.
1030
+
1031
+Useful when logging in to or out of a private registry:
1032
+
1033
+```
1034
+# log in, linking the scope to the custom registry
1035
+npm login --scope=@mycorp --registry=https://registry.mycorp.com
1036
+
1037
+# log out, removing the link and the auth token
1038
+npm logout --scope=@mycorp
1039
+```
1040
+
1041
+This will cause `@mycorp` to be mapped to the registry for future installation of packages specified according to the pattern `@mycorp/package`.
1042
+
1043
+This will also cause `npm init` to create a scoped package.
1044
+
1045
+```
1046
+# accept all defaults, and create a package named "@foo/whatever",
1047
+# instead of just named "whatever"
1048
+npm init --scope=@foo --yes
1049
+```
1050
+
1051
+#### `script-shell`
1052
+
1053
+- Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
1054
+- Type: null or String
1055
+
1056
+The shell to use for scripts run with the `npm exec`, `npm run` and `npm init <package-spec>` commands.
1057
+
1058
+#### `searchexclude`
1059
+
1060
+- Default: ""
1061
+- Type: String
1062
+
1063
+Space-separated options that limit the results from search.
1064
+
1065
+#### `searchlimit`
1066
+
1067
+- Default: 20
1068
+- Type: Number
1069
+
1070
+Number of items to limit search results to. Will not apply at all to legacy searches.
1071
+
1072
+#### `searchopts`
1073
+
1074
+- Default: ""
1075
+- Type: String
1076
+
1077
+Space-separated options that are always passed to search.
1078
+
1079
+#### `searchstaleness`
1080
+
1081
+- Default: 900
1082
+- Type: Number
1083
+
1084
+The age of the cache, in seconds, before another registry request is made if using legacy search endpoint.
1085
+
1086
+#### `shell`
1087
+
1088
+- Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" on Windows
1089
+- Type: String
1090
+
1091
+The shell to run for the `npm explore` command.
1092
+
1093
+#### `sign-git-commit`
1094
+
1095
+- Default: false
1096
+- Type: Boolean
1097
+
1098
+If set to true, then the `npm version` command will commit the new package version using `-S` to add a signature.
1099
+
1100
+Note that git requires you to have set up GPG keys in your git configs for this to work properly.
1101
+
1102
+#### `sign-git-tag`
1103
+
1104
+- Default: false
1105
+- Type: Boolean
1106
+
1107
+If set to true, then the `npm version` command will tag the version using `-s` to add a signature.
1108
+
1109
+Note that git requires you to have set up GPG keys in your git configs for this to work properly.
1110
+
1111
+#### `strict-peer-deps`
1112
+
1113
+- Default: false
1114
+- Type: Boolean
1115
+
1116
+If set to `true`, and `--legacy-peer-deps` is not set, then _any_ conflicting `peerDependencies` will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
1117
+
1118
+By default, conflicting `peerDependencies` deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's `peerDependencies` object.
1119
+
1120
+When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If `--strict-peer-deps` is set, then this warning is treated as a failure.
1121
+
1122
+#### `strict-ssl`
1123
+
1124
+- Default: true
1125
+- Type: Boolean
1126
+
1127
+Whether or not to do SSL key validation when making requests to the registry via https.
1128
+
1129
+See also the `ca` config.
1130
+
1131
+#### `tag`
1132
+
1133
+- Default: "latest"
1134
+- Type: String
1135
+
1136
+If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag.
1137
+
1138
+It is the tag added to the package@version specified in the `npm dist-tag add` command, if no explicit tag is given.
1139
+
1140
+When used by the `npm diff` command, this is the tag used to fetch the tarball that will be compared with the local files by default.
1141
+
1142
+If used in the `npm publish` command, this is the tag that will be added to the package submitted to the registry.
1143
+
1144
+#### `tag-version-prefix`
1145
+
1146
+- Default: "v"
1147
+- Type: String
1148
+
1149
+If set, alters the prefix used when tagging a new version when performing a version increment using `npm version`. To remove the prefix altogether, set it to the empty string: `""`.
1150
+
1151
+Because other tools may rely on the convention that npm version tags look like `v1.0.0`, _only use this property if it is absolutely necessary_. In particular, use care when overriding this setting for public packages.
1152
+
1153
+#### `timing`
1154
+
1155
+- Default: false
1156
+- Type: Boolean
1157
+
1158
+If true, writes timing information to a process specific json file in the cache or `logs-dir`. The file name ends with `-timing.json`.
1159
+
1160
+You can quickly view it with this [json](https://npm.im/json) command line: `cat ~/.npm/_logs/*-timing.json | npm exec -- json -g`.
1161
+
1162
+Timing information will also be reported in the terminal. To suppress this while still writing the timing file, use `--silent`.
1163
+
1164
+#### `umask`
1165
+
1166
+- Default: 0
1167
+- Type: Octal numeric string in range 0000..0777 (0..511)
1168
+
1169
+The "umask" value to use when setting the file creation mode on files and folders.
1170
+
1171
+Folders and executables are given a mode which is `0o777` masked against this value. Other files are given a mode which is `0o666` masked against this value.
1172
+
1173
+Note that the underlying system will _also_ apply its own umask value to files and folders that are created, and npm does not circumvent this, but rather adds the `--umask` config to it.
1174
+
1175
+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.
1176
+
1177
+#### `unicode`
1178
+
1179
+- Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the `LC_ALL`, `LC_CTYPE`, or `LANG` environment variables.
1180
+- Type: Boolean
1181
+
1182
+When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
1183
+
1184
+#### `update-notifier`
1185
+
1186
+- Default: true
1187
+- Type: Boolean
1188
+
1189
+Set to false to suppress the update notification when using an older version of npm than the latest.
1190
+
1191
+#### `usage`
1192
+
1193
+- Default: false
1194
+- Type: Boolean
1195
+
1196
+Show short usage output about the command specified.
1197
+
1198
+#### `user-agent`
1199
+
1200
+- Default: "npm/\{npm-version\} node/\{node-version\} \{platform\} \{arch\} workspaces/\{workspaces\} \{ci\}"
1201
+- Type: String
1202
+
1203
+Sets the User-Agent request header. The following fields are replaced with their actual counterparts:
1204
+
1205
+- `{npm-version}` - The npm version in use
1206
+- `{node-version}` - The Node.js version in use
1207
+- `{platform}` - The value of `process.platform`
1208
+- `{arch}` - The value of `process.arch`
1209
+- `{workspaces}` - Set to `true` if the `workspaces` or `workspace` options are set.
1210
+- `{ci}` - The value of the `ci-name` config, if set, prefixed with `ci/`, or an empty string if `ci-name` is empty.
1211
+
1212
+#### `userconfig`
1213
+
1214
+- Default: "~/.npmrc"
1215
+- Type: Path
1216
+
1217
+The location of user-level configuration settings.
1218
+
1219
+This may be overridden by the `npm_config_userconfig` environment variable or the `--userconfig` command line option, but may _not_ be overridden by settings in the `globalconfig` file.
1220
+
1221
+#### `version`
1222
+
1223
+- Default: false
1224
+- Type: Boolean
1225
+
1226
+If true, output the npm version and exit successfully.
1227
+
1228
+Only relevant when specified explicitly on the command line.
1229
+
1230
+#### `versions`
1231
+
1232
+- Default: false
1233
+- Type: Boolean
1234
+
1235
+If true, output the npm version as well as node's `process.versions` map and the version in the current working directory's `package.json` file if one exists, and exit successfully.
1236
+
1237
+Only relevant when specified explicitly on the command line.
1238
+
1239
+#### `viewer`
1240
+
1241
+- Default: "man" on Posix, "browser" on Windows
1242
+- Type: String
1243
+
1244
+The program to use to view help content.
1245
+
1246
+Set to `"browser"` to view html help content in the default web browser.
1247
+
1248
+#### `which`
1249
+
1250
+- Default: null
1251
+- Type: null or Number
1252
+
1253
+If there are multiple funding sources, which 1-indexed source URL to open.
1254
+
1255
+#### `workspace`
1256
+
1257
+- Default:
1258
+- Type: String (can be set multiple times)
1259
+
1260
+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.
1261
+
1262
+Valid values for the `workspace` config are either:
1263
+
1264
+- Workspace names
1265
+- Path to a workspace directory
1266
+- Path to a parent workspace directory (will result in selecting all workspaces within that folder)
1267
+
1268
+When set for the `npm init` command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
1269
+
1270
+This value is not exported to the environment for child processes.
1271
+
1272
+#### `workspaces`
1273
+
1274
+- Default: null
1275
+- Type: null or Boolean
1276
+
1277
+Set to true to run the command in the context of **all** configured workspaces.
1278
+
1279
+Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
1280
+
1281
+- Commands that operate on the `node_modules` tree (install, update, etc.) will link workspaces into the `node_modules` folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, _unless_ one or more workspaces are specified in the `workspace` config.
1282
+
1283
+This value is not exported to the environment for child processes.
1284
+
1285
+#### `workspaces-update`
1286
+
1287
+- Default: true
1288
+- Type: Boolean
1289
+
1290
+If set to true, the npm cli will run an update after operations that may possibly change the workspaces installed to the `node_modules` folder.
1291
+
1292
+#### `yes`
1293
+
1294
+- Default: null
1295
+- Type: null or Boolean
1296
+
1297
+Automatically answer "yes" to any prompts that npm might print on the command line.
1298
+
1299
+#### `also`
1300
+
1301
+- Default: null
1302
+- Type: null, "dev", or "development"
1303
+- DEPRECATED: Please use --include=dev instead.
1304
+
1305
+When set to `dev` or `development`, this is an alias for `--include=dev`.
1306
+
1307
+#### `cache-max`
1308
+
1309
+- Default: Infinity
1310
+- Type: Number
1311
+- DEPRECATED: This option has been deprecated in favor of `--prefer-online`
1312
+
1313
+`--cache-max=0` is an alias for `--prefer-online`
1314
+
1315
+#### `cache-min`
1316
+
1317
+- Default: 0
1318
+- Type: Number
1319
+- DEPRECATED: This option has been deprecated in favor of `--prefer-offline`.
1320
+
1321
+`--cache-min=9999 (or bigger)` is an alias for `--prefer-offline`.
1322
+
1323
+#### `cert`
1324
+
1325
+- Default: null
1326
+- Type: null or String
1327
+- DEPRECATED: `key` and `cert` are no longer used for most registry operations. Use registry scoped `keyfile` and `cafile` instead. Example: //other-registry.tld/:keyfile=/path/to/key.pem //other-registry.tld/:cafile=/path/to/cert.crt
1328
+
1329
+A client certificate to pass when accessing the registry. Values should be in PEM format (Windows calls it "Base-64 encoded X.509 (.CER)") with newlines replaced by the string "\n". For example:
1330
+
1331
+```ini
1332
+cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
1333
+```
1334
+
1335
+It is _not_ the path to a certificate file, though you can set a registry-scoped "cafile" path like "//other-registry.tld/:cafile=/path/to/cert.pem".
1336
+
1337
+#### `dev`
1338
+
1339
+- Default: false
1340
+- Type: Boolean
1341
+- DEPRECATED: Please use --include=dev instead.
1342
+
1343
+Alias for `--include=dev`.
1344
+
1345
+#### `global-style`
1346
+
1347
+- Default: false
1348
+- Type: Boolean
1349
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
1350
+
1351
+Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
1352
+
1353
+#### `init.author.email`
1354
+
1355
+- Default: ""
1356
+- Type: String
1357
+- DEPRECATED: Use `--init-author-email` instead.
1358
+
1359
+Alias for `--init-author-email`
1360
+
1361
+#### `init.author.name`
1362
+
1363
+- Default: ""
1364
+- Type: String
1365
+- DEPRECATED: Use `--init-author-name` instead.
1366
+
1367
+Alias for `--init-author-name`
1368
+
1369
+#### `init.author.url`
1370
+
1371
+- Default: ""
1372
+- Type: "" or URL
1373
+- DEPRECATED: Use `--init-author-url` instead.
1374
+
1375
+Alias for `--init-author-url`
1376
+
1377
+#### `init.license`
1378
+
1379
+- Default: "ISC"
1380
+- Type: String
1381
+- DEPRECATED: Use `--init-license` instead.
1382
+
1383
+Alias for `--init-license`
1384
+
1385
+#### `init.module`
1386
+
1387
+- Default: "~/.npm-init.js"
1388
+- Type: Path
1389
+- DEPRECATED: Use `--init-module` instead.
1390
+
1391
+Alias for `--init-module`
1392
+
1393
+#### `init.version`
1394
+
1395
+- Default: "1.0.0"
1396
+- Type: SemVer string
1397
+- DEPRECATED: Use `--init-version` instead.
1398
+
1399
+Alias for `--init-version`
1400
+
1401
+#### `key`
1402
+
1403
+- Default: null
1404
+- Type: null or String
1405
+- DEPRECATED: `key` and `cert` are no longer used for most registry operations. Use registry scoped `keyfile` and `cafile` instead. Example: //other-registry.tld/:keyfile=/path/to/key.pem //other-registry.tld/:cafile=/path/to/cert.crt
1406
+
1407
+A client key to pass when accessing the registry. Values should be in PEM format with newlines replaced by the string "\n". For example:
1408
+
1409
+```ini
1410
+key="-----BEGIN PRIVATE KEY-----\nXXXX\nXXXX\n-----END PRIVATE KEY-----"
1411
+```
1412
+
1413
+It is _not_ the path to a key file, though you can set a registry-scoped "keyfile" path like "//other-registry.tld/:keyfile=/path/to/key.pem".
1414
+
1415
+#### `legacy-bundling`
1416
+
1417
+- Default: false
1418
+- Type: Boolean
1419
+- DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
1420
+
1421
+Instead of hoisting package installs in `node_modules`, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets `--install-strategy=nested`.
1422
+
1423
+#### `only`
1424
+
1425
+- Default: null
1426
+- Type: null, "prod", or "production"
1427
+- DEPRECATED: Use `--omit=dev` to omit dev dependencies from the install.
1428
+
1429
+When set to `prod` or `production`, this is an alias for `--omit=dev`.
1430
+
1431
+#### `optional`
1432
+
1433
+- Default: null
1434
+- Type: null or Boolean
1435
+- DEPRECATED: Use `--omit=optional` to exclude optional dependencies, or `--include=optional` to include them.
1436
+
1437
+Default value does install optional deps unless otherwise omitted.
1438
+
1439
+Alias for --include=optional or --omit=optional
1440
+
1441
+#### `production`
1442
+
1443
+- Default: null
1444
+- Type: null or Boolean
1445
+- DEPRECATED: Use `--omit=dev` instead.
1446
+
1447
+Alias for `--omit=dev`
1448
+
1449
+#### `shrinkwrap`
1450
+
1451
+- Default: true
1452
+- Type: Boolean
1453
+- DEPRECATED: Use the --package-lock setting instead.
1454
+
1455
+Alias for --package-lock
1456
+
1457
+### See also
1458
+
1459
+- [npm config](/cli/v11/commands/npm-config)
1460
+- [npmrc](/cli/v11/configuring-npm/npmrc)
1461
+- [npm scripts](/cli/v11/using-npm/scripts)
1462
+- [npm folders](/cli/v11/configuring-npm/folders)
1463
+- [npm](/cli/v11/commands/npm)
content/cli/v11/using-npm/dependency-selectors.mdx
new
+240
@@ -0,0 +1,240 @@
1
+---
2
+title: Dependency Selector Syntax & Querying
3
+section: 7
4
+description: Dependency Selector Syntax & Querying
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/dependency-selectors.md
8
+redirect_from:
9
+ - /cli-documentation/misc/dependency-selectors
10
+ - /cli-documentation/using-npm/dependency-selectors
11
+ - /cli-documentation/v11/misc/dependency-selectors
12
+ - /cli-documentation/v11/using-npm/dependency-selectors
13
+ - /cli/misc/dependency-selectors
14
+ - /cli/using-npm/dependency-selectors
15
+ - /cli/v11/misc/dependency-selectors
16
+ - /misc/dependency-selectors
17
+ - /using-npm/dependency-selectors
18
+---
19
+
20
+### Description
21
+
22
+The [`npm query`](/cli/v11/commands/npm-query) command exposes a new dependency selector syntax (informed by & respecting many aspects of the [CSS Selectors 4 Spec](https://dev.w3.org/csswg/selectors4/#relational)) which:
23
+
24
+- Standardizes the shape of, & querying of, dependency graphs with a robust object model, metadata & selector syntax
25
+- Leverages existing, known language syntax & operators from CSS to make disparate package information broadly accessible
26
+- Unlocks the ability to answer complex, multi-faceted questions about dependencies, their relationships & associative metadata
27
+- Consolidates redundant logic of similar query commands in `npm` (ex. `npm fund`, `npm ls`, `npm outdated`, `npm audit` ...)
28
+
29
+### Dependency Selector Syntax
30
+
31
+#### Overview:
32
+
33
+- there is no "type" or "tag" selectors (ex. `div, h1, a`) as a dependency/target is the only type of `Node` that can be queried
34
+- the term "dependencies" is in reference to any `Node` found in a `tree` returned by `Arborist`
35
+
36
+#### Combinators
37
+
38
+- `>` direct descendant/child
39
+- ` ` any descendant/child
40
+- `~` sibling
41
+
42
+#### Selectors
43
+
44
+- `*` universal selector
45
+- `#<name>` dependency selector (equivalent to `[name="..."]`)
46
+- `#<name>@<version>` (equivalent to `[name=<name>]:semver(<version>)`)
47
+- `,` selector list delimiter
48
+- `.` dependency type selector
49
+- `:` pseudo selector
50
+
51
+#### Dependency Type Selectors
52
+
53
+- `.prod` dependency found in the `dependencies` section of `package.json`, or is a child of said dependency
54
+- `.dev` dependency found in the `devDependencies` section of `package.json`, or is a child of said dependency
55
+- `.optional` dependency found in the `optionalDependencies` section of `package.json`, or has `"optional": true` set in its entry in the `peerDependenciesMeta` section of `package.json`, or a child of said dependency
56
+- `.peer` dependency found in the `peerDependencies` section of `package.json`
57
+- `.workspace` dependency found in the [`workspaces`](https://docs.npmjs.com/cli/v8/using-npm/workspaces) section of `package.json`
58
+- `.bundled` dependency found in the `bundleDependencies` section of `package.json`, or is a child of said dependency
59
+
60
+#### Pseudo Selectors
61
+
62
+- [`:not(<selector>)`](https://developer.mozilla.org/en-US/docs/Web/CSS/:not)
63
+- [`:has(<selector>)`](https://developer.mozilla.org/en-US/docs/Web/CSS/:has)
64
+- [`:is(<selector list>)`](https://developer.mozilla.org/en-US/docs/Web/CSS/:is)
65
+- [`:root`](https://developer.mozilla.org/en-US/docs/Web/CSS/:root) matches the root node/dependency
66
+- [`:scope`](https://developer.mozilla.org/en-US/docs/Web/CSS/:scope) matches node/dependency it was queried against
67
+- [`:empty`](https://developer.mozilla.org/en-US/docs/Web/CSS/:empty) when a dependency has no dependencies
68
+- [`:private`](https://docs.npmjs.com/cli/v8/configuring-npm/package-json#private) when a dependency is private
69
+- `:link` when a dependency is linked (for instance, workspaces or packages manually [`linked`](https://docs.npmjs.com/cli/v8/commands/npm-link)
70
+- `:deduped` when a dependency has been deduped (note that this does _not_ always mean the dependency has been hoisted to the root of node_modules)
71
+- `:overridden` when a dependency has been overridden
72
+- `:extraneous` when a dependency exists but is not defined as a dependency of any node
73
+- `:invalid` when a dependency version is out of its ancestors specified range
74
+- `:missing` when a dependency is not found on disk
75
+- `:semver(<spec>, [selector], [function])` match a valid [`node-semver`](https://github.com/npm/node-semver) version or range to a selector
76
+- `:path(<path>)` [glob](https://www.npmjs.com/package/glob) matching based on dependencies path relative to the project
77
+- `:type(<type>)` [based on currently recognized types](https://github.com/npm/npm-package-arg#result-object)
78
+- `:outdated(<type>)` when a dependency is outdated
79
+- `:vuln(<selector>)` when a dependency has a known vulnerability
80
+
81
+##### `:semver(<spec>, [selector], [function])`
82
+
83
+The `:semver()` pseudo selector allows comparing fields from each node's `package.json` using [semver](https://github.com/npm/node-semver#readme) methods. It accepts up to 3 parameters, all but the first of which are optional.
84
+
85
+- `spec` a semver version or range
86
+- `selector` an attribute selector for each node (default `[version]`)
87
+- `function` a semver method to apply, one of: `satisfies`, `intersects`, `subset`, `gt`, `gte`, `gtr`, `lt`, `lte`, `ltr`, `eq`, `neq` or the special function `infer` (default `infer`)
88
+
89
+When the special `infer` function is used the `spec` and the actual value from the node are compared. If both are versions, according to `semver.valid()`, `eq` is used. If both values are ranges, according to `!semver.valid()`, `intersects` is used. If the values are mixed types `satisfies` is used.
90
+
91
+Some examples:
92
+
93
+- `:semver(^1.0.0)` returns every node that has a `version` satisfied by the provided range `^1.0.0`
94
+- `:semver(16.0.0, :attr(engines, [node]))` returns every node which has an `engines.node` property satisfying the version `16.0.0`
95
+- `:semver(1.0.0, [version], lt)` every node with a `version` less than `1.0.0`
96
+
97
+##### `:outdated(<type>)`
98
+
99
+The `:outdated` pseudo selector retrieves data from the registry and returns information about which of your dependencies are outdated. The type parameter may be one of the following:
100
+
101
+- `any` (default) a version exists that is greater than the current one
102
+- `in-range` a version exists that is greater than the current one, and satisfies at least one if its parent's dependencies
103
+- `out-of-range` a version exists that is greater than the current one, does not satisfy at least one of its parent's dependencies
104
+- `major` a version exists that is a semver major greater than the current one
105
+- `minor` a version exists that is a semver minor greater than the current one
106
+- `patch` a version exists that is a semver patch greater than the current one
107
+
108
+In addition to the filtering performed by the pseudo selector, some extra data is added to the resulting objects. The following data can be found under the `queryContext` property of each node.
109
+
110
+- `versions` an array of every available version of the given node
111
+- `outdated.inRange` an array of objects, each with a `from` and `versions`, where `from` is the on-disk location of the node that depends on the current node and `versions` is an array of all available versions that satisfies that dependency. This is only populated if `:outdated(in-range)` is used.
112
+- `outdated.outOfRange` an array of objects, identical in shape to `inRange`, but where the `versions` array is every available version that does not satisfy the dependency. This is only populated if `:outdated(out-of-range)` is used.
113
+
114
+Some examples:
115
+
116
+- `:root > :outdated(major)` returns every direct dependency that has a new semver major release
117
+- `.prod:outdated(in-range)` returns production dependencies that have a new release that satisfies at least one of its parent's dependencies
118
+
119
+##### `:vuln`
120
+
121
+The `:vuln` pseudo selector retrieves data from the registry and returns information about which if your dependencies has a known vulnerability. Only dependencies whose current version matches a vulnerability will be returned. For example if you have `semver@7.6.0` in your tree, a vulnerability for `semver` which affects versions `<=6.3.1` will not match.
122
+
123
+You can also filter results by certain attributes in advisories. Currently that includes `severity` and `cwe`. Note that severity filtering is done per severity, it does not include severities "higher" or "lower" than the one specified.
124
+
125
+In addition to the filtering performed by the pseudo selector, info about each relevant advisory will be added to the `queryContext` attribute of each node under the `advisories` attribute.
126
+
127
+Some examples:
128
+
129
+- `:root > .prod:vuln` returns direct production dependencies with any known vulnerability
130
+- `:vuln([severity=high])` returns only dependencies with a vulnerability with a `high` severity.
131
+- `:vuln([severity=high],[severity=moderate])` returns only dependencies with a vulnerability with a `high` or `moderate` severity.
132
+- `:vuln([cwe=1333])` returns only dependencies with a vulnerability that includes CWE-1333 (ReDoS)
133
+
134
+#### [Attribute Selectors](https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors)
135
+
136
+The attribute selector evaluates the key/value pairs in `package.json` if they are `String`s.
137
+
138
+- `[]` attribute selector (ie. existence of attribute)
139
+- `[attribute=value]` attribute value is equivalent...
140
+- `[attribute~=value]` attribute value contains word...
141
+- `[attribute*=value]` attribute value contains string...
142
+- `[attribute|=value]` attribute value is equal to or starts with...
143
+- `[attribute^=value]` attribute value starts with...
144
+- `[attribute$=value]` attribute value ends with...
145
+
146
+#### `Array` & `Object` Attribute Selectors
147
+
148
+The generic `:attr()` pseudo selector standardizes a pattern which can be used for attribute selection of `Object`s, `Array`s or `Arrays` of `Object`s accessible via `Arborist`'s `Node.package` metadata. This allows for iterative attribute selection beyond top-level `String` evaluation. The last argument passed to `:attr()` must be an `attribute` selector or a nested `:attr()`. See examples below:
149
+
150
+#### `Objects`
151
+
152
+```css
153
+/* return dependencies that have a `scripts.test` containing `"tap"` */
154
+*: attr(scripts, [test~=tap]);
155
+```
156
+
157
+#### Nested `Objects`
158
+
159
+Nested objects are expressed as sequential arguments to `:attr()`.
160
+
161
+```css
162
+/* return dependencies that have a testling config for opera browsers */
163
+*: attr(testling, browsers, [~=opera]);
164
+```
165
+
166
+#### `Arrays`
167
+
168
+`Array`s specifically uses a special/reserved `.` character in place of a typical attribute name. `Arrays` also support exact `value` matching when a `String` is passed to the selector.
169
+
170
+##### Example of an `Array` Attribute Selection:
171
+
172
+```css
173
+/* removes the distinction between properties & arrays */
174
+/* ie. we'd have to check the property & iterate to match selection */
175
+*:attr([keywords^=react])
176
+*:attr(contributors, :attr([name~=Jordan]))
177
+```
178
+
179
+##### Example of an `Array` matching directly to a value:
180
+
181
+```css
182
+/* return dependencies that have the exact keyword "react" */
183
+/* this is equivalent to `*:keywords([value="react"])` */
184
+*: attr([keywords=react]);
185
+```
186
+
187
+##### Example of an `Array` of `Object`s:
188
+
189
+```css
190
+/* returns */
191
+*: attr(contributors, [email=ruyadorno @github.com]);
192
+```
193
+
194
+### Groups
195
+
196
+Dependency groups are defined by the package relationships to their ancestors (ie. the dependency types that are defined in `package.json`). This approach is user-centric as the ecosystem has been taught to think about dependencies in these groups first-and-foremost. Dependencies are allowed to be included in multiple groups (ex. a `prod` dependency may also be a `dev` dependency (in that it's also required by another `dev` dependency) & may also be `bundled` - a selector for that type of dependency would look like: `*.prod.dev.bundled`).
197
+
198
+- `.prod`
199
+- `.dev`
200
+- `.optional`
201
+- `.peer`
202
+- `.bundled`
203
+- `.workspace`
204
+
205
+Please note that currently `workspace` deps are always `prod` dependencies. Additionally the `.root` dependency is also considered a `prod` dependency.
206
+
207
+### Programmatic Usage
208
+
209
+- `Arborist`'s `Node` Class has a `.querySelectorAll()` method
210
+ - this method will return a filtered, flattened dependency Arborist `Node` list based on a valid query selector
211
+
212
+```js
213
+const Arborist = require("@npmcli/arborist");
214
+const arb = new Arborist({});
215
+```
216
+
217
+```js
218
+// root-level
219
+arb.loadActual().then(async (tree) => {
220
+ // query all production dependencies
221
+ const results = await tree.querySelectorAll(".prod");
222
+ console.log(results);
223
+});
224
+```
225
+
226
+```js
227
+// iterative
228
+arb.loadActual().then(async (tree) => {
229
+ // query for the deduped version of react
230
+ const results = await tree.querySelectorAll("#react:not(:deduped)");
231
+ // query the deduped react for git deps
232
+ const deps = await results[0].querySelectorAll(":type(git)");
233
+ console.log(deps);
234
+});
235
+```
236
+
237
+## See Also
238
+
239
+- [npm query](/cli/v11/commands/npm-query)
240
+- [@npmcli/arborist](https://npm.im/@npmcli/arborist)
content/cli/v11/using-npm/developers.mdx
new
+203
@@ -0,0 +1,203 @@
1
+---
2
+title: developers
3
+section: 7
4
+description: Developer Guide
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/developers.md
8
+redirect_from:
9
+ - /cli-documentation/misc/developers
10
+ - /cli-documentation/using-npm/developers
11
+ - /cli-documentation/v11/misc/developers
12
+ - /cli-documentation/v11/using-npm/developers
13
+ - /cli/misc/developers
14
+ - /cli/using-npm/developers
15
+ - /cli/v11/misc/developers
16
+ - /misc/developers
17
+ - /using-npm/developers
18
+---
19
+
20
+### Description
21
+
22
+So, you've decided to use npm to develop (and maybe publish/deploy) your project.
23
+
24
+Fantastic!
25
+
26
+There are a few things that you need to do above the simple steps that your users will do to install your program.
27
+
28
+### About These Documents
29
+
30
+These are man pages. If you install npm, you should be able to then do `man npm-thing` to get the documentation on a particular topic, or `npm help thing` to see the same information.
31
+
32
+### What is a Package
33
+
34
+A package is:
35
+
36
+- a) a folder containing a program described by a package.json file
37
+- b) a gzipped tarball containing (a)
38
+- c) a url that resolves to (b)
39
+- d) a `<name>@<version>` that is published on the registry with (c)
40
+- e) a `<name>@<tag>` that points to (d)
41
+- f) a `<name>` that has a "latest" tag satisfying (e)
42
+- g) a `git` url that, when cloned, results in (a).
43
+
44
+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).
45
+
46
+Git urls can be of the form:
47
+
48
+```bash
49
+git://github.com/user/project.git#commit-ish
50
+git+ssh://user@hostname:project.git#commit-ish
51
+git+http://user@hostname/project/blah.git#commit-ish
52
+git+https://user@hostname/project/blah.git#commit-ish
53
+```
54
+
55
+The `commit-ish` can be any tag, sha, or branch which can be supplied as an argument to `git checkout`. The default is whatever the repository uses as its default branch.
56
+
57
+### The package.json File
58
+
59
+You need to have a `package.json` file in the root of your project to do much of anything with npm. That is basically the whole interface.
60
+
61
+See [`package.json`](/cli/v11/configuring-npm/package-json) for details about what goes in that file. At the very least, you need:
62
+
63
+- 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.
64
+
65
+ It does not necessarily need to match your github repository name.
66
+
67
+ So, `node-foo` and `bar-js` are bad names. `foo` or `bar` are better.
68
+
69
+- version: A semver-compatible version.
70
+
71
+- 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.
72
+
73
+- author: Take some credit.
74
+
75
+- scripts: If you have a special compilation or installation script, then you should put it in the `scripts` object. You should definitely have at least a basic smoke-test command as the "scripts.test" field. See [scripts](/cli/v11/using-npm/scripts).
76
+
77
+- 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.
78
+
79
+- 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.
80
+
81
+You can use `npm init` in the root of your package in order to get you started with a pretty basic package.json file. See [`npm init`](/cli/v11/commands/npm-init) for more info.
82
+
83
+### Keeping files _out_ of your Package
84
+
85
+Use a `.npmignore` file to keep stuff out of your package. If there's no `.npmignore` file, but there _is_ a `.gitignore` file, then npm will ignore the stuff matched by the `.gitignore` file. If you _want_ to include something that is excluded by your `.gitignore` file, you can create an empty `.npmignore` file to override it. Like `git`, `npm` looks for `.npmignore` and `.gitignore` files in all subdirectories of your package, not only the root directory.
86
+
87
+`.npmignore` files follow the [same pattern rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring) as `.gitignore` files:
88
+
89
+- Blank lines or lines starting with `#` are ignored.
90
+- Standard glob patterns work.
91
+- You can end patterns with a forward slash `/` to specify a directory.
92
+- You can negate a pattern by starting it with an exclamation point `!`.
93
+
94
+By default, some paths and files are ignored, so there's no need to add them to `.npmignore` explicitly. Some examples are:
95
+
96
+- `.*.swp`
97
+- `._*`
98
+- `.DS_Store`
99
+- `.git`
100
+- `.gitignore`
101
+- `.hg`
102
+- `.npmignore`
103
+- `.npmrc`
104
+- `.lock-wscript`
105
+- `.svn`
106
+- `.wafpickle-*`
107
+- `config.gypi`
108
+- `CVS`
109
+- `npm-debug.log`
110
+
111
+Additionally, everything in `node_modules` is ignored, except for bundled dependencies. npm automatically handles this for you, so don't bother adding `node_modules` to `.npmignore`.
112
+
113
+The following paths and files are never ignored, so adding them to `.npmignore` is pointless:
114
+
115
+- `package.json`
116
+- `README` (and its variants)
117
+- `CHANGELOG` (and its variants)
118
+- `LICENSE` / `LICENCE`
119
+
120
+If, given the structure of your project, you find `.npmignore` to be a maintenance headache, you might instead try populating the `files` property of `package.json`, which is an array of file or directory names that should be included in your package. Sometimes manually picking which items to allow is easier to manage than building a block list.
121
+
122
+See [`package.json`](/cli/v11/configuring-npm/package-json) for more info on what can and can't be ignored.
123
+
124
+#### Testing whether your `.npmignore` or `files` config works
125
+
126
+If you want to double check that your package will include only the files you intend it to when published, you can run the `npm pack` command locally which will generate a tarball in the working directory, the same way it does for publishing.
127
+
128
+### Link Packages
129
+
130
+`npm link` is designed to install a development package and see the changes in real time without having to keep re-installing it. (You do need to either re-link or `npm rebuild -g` to update compiled packages, of course.)
131
+
132
+More info at [`npm link`](/cli/v11/commands/npm-link).
133
+
134
+### Before Publishing: Make Sure Your Package Installs and Works
135
+
136
+**This is important.**
137
+
138
+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.
139
+
140
+In the root of your package, do this:
141
+
142
+```bash
143
+npm install . -g
144
+```
145
+
146
+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:
147
+
148
+```bash
149
+npm link
150
+```
151
+
152
+Use `npm ls -g` to see if it's there.
153
+
154
+To test a local install, go into some other folder, and then do:
155
+
156
+```bash
157
+cd ../some-other-folder
158
+npm install ../my-package
159
+```
160
+
161
+to install it locally into the node_modules folder in that other place.
162
+
163
+Then go into the node-repl, and try using require("my-thing") to bring in your module's main module.
164
+
165
+### Create a User Account
166
+
167
+Create a user with the adduser command. It works like this:
168
+
169
+```bash
170
+npm adduser
171
+```
172
+
173
+and then follow the prompts.
174
+
175
+This is documented better in [npm adduser](/cli/v11/commands/npm-adduser).
176
+
177
+### Publish your Package
178
+
179
+This part's easy. In the root of your folder, do this:
180
+
181
+```bash
182
+npm publish
183
+```
184
+
185
+You can give publish a url to a tarball, or a filename of a tarball, or a path to a folder.
186
+
187
+Note that pretty much **everything in that folder will be exposed** by default. So, if you have secret stuff in there, use a `.npmignore` file to list out the globs to ignore, or publish from a fresh checkout.
188
+
189
+### Brag about it
190
+
191
+Send emails, write blogs, blab in IRC.
192
+
193
+Tell the world how easy it is to install your program!
194
+
195
+### See also
196
+
197
+- [npm](/cli/v11/commands/npm)
198
+- [npm init](/cli/v11/commands/npm-init)
199
+- [package.json](/cli/v11/configuring-npm/package-json)
200
+- [npm scripts](/cli/v11/using-npm/scripts)
201
+- [npm publish](/cli/v11/commands/npm-publish)
202
+- [npm adduser](/cli/v11/commands/npm-adduser)
203
+- [npm registry](/cli/v11/using-npm/registry)
content/cli/v11/using-npm/index.mdx
new
+29
@@ -0,0 +1,29 @@
1
+---
2
+title: Using npm
3
+shortName: Using
4
+github_repo: npm/cli
5
+github_branch: latest
6
+github_path: docs/lib/content/nav.yml
7
+redirect_from:
8
+ - /cli-documentation/misc
9
+ - /cli-documentation/misc/index
10
+ - /cli-documentation/using-npm
11
+ - /cli-documentation/using-npm/index
12
+ - /cli-documentation/v11/misc
13
+ - /cli-documentation/v11/misc/index
14
+ - /cli-documentation/v11/using-npm
15
+ - /cli-documentation/v11/using-npm/index
16
+ - /cli/misc
17
+ - /cli/misc/index
18
+ - /cli/using-npm
19
+ - /cli/using-npm/index
20
+ - /cli/v11/misc
21
+ - /cli/v11/misc/index
22
+ - /cli/v11/using-npm/index
23
+ - /misc
24
+ - /misc/index
25
+ - /using-npm
26
+ - /using-npm/index
27
+---
28
+
29
+<Index depth="1" />
content/cli/v11/using-npm/logging.mdx
new
+103
@@ -0,0 +1,103 @@
1
+---
2
+title: Logging
3
+section: 7
4
+description: Why, What & How We Log
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/logging.md
8
+redirect_from:
9
+ - /cli-documentation/misc/logging
10
+ - /cli-documentation/using-npm/logging
11
+ - /cli-documentation/v11/misc/logging
12
+ - /cli-documentation/v11/using-npm/logging
13
+ - /cli/misc/logging
14
+ - /cli/using-npm/logging
15
+ - /cli/v11/misc/logging
16
+ - /misc/logging
17
+ - /using-npm/logging
18
+---
19
+
20
+### Description
21
+
22
+The `npm` CLI has various mechanisms for showing different levels of information back to end-users for certain commands, configurations & environments.
23
+
24
+### Setting Log File Location
25
+
26
+All logs are written to a debug log, with the path to that file printed if the execution of a command fails.
27
+
28
+The default location of the logs directory is a directory named `_logs` inside the npm cache. This can be changed with the `logs-dir` config option.
29
+
30
+For example, if you wanted to write all your logs to the current working directory, you could run: `npm install --logs-dir=.`. This is especially helpful in debugging a specific `npm` issue as you can run a command multiple times with different config values and then diff all the log files.
31
+
32
+Log files will be removed from the `logs-dir` when the number of log files exceeds `logs-max`, with the oldest logs being deleted first.
33
+
34
+To turn off logs completely set `--logs-max=0`.
35
+
36
+### Setting Log Levels
37
+
38
+#### `loglevel`
39
+
40
+`loglevel` is a global argument/config that can be set to determine the type of information to be displayed.
41
+
42
+The default value of `loglevel` is `"notice"` but there are several levels/types of logs available, including:
43
+
44
+- `"silent"`
45
+- `"error"`
46
+- `"warn"`
47
+- `"notice"`
48
+- `"http"`
49
+- `"info"`
50
+- `"verbose"`
51
+- `"silly"`
52
+
53
+All logs pertaining to a level proceeding the current setting will be shown.
54
+
55
+##### Aliases
56
+
57
+The log levels listed above have various corresponding aliases, including:
58
+
59
+- `-d`: `--loglevel info`
60
+- `--dd`: `--loglevel verbose`
61
+- `--verbose`: `--loglevel verbose`
62
+- `--ddd`: `--loglevel silly`
63
+- `-q`: `--loglevel warn`
64
+- `--quiet`: `--loglevel warn`
65
+- `-s`: `--loglevel silent`
66
+- `--silent`: `--loglevel silent`
67
+
68
+#### `foreground-scripts`
69
+
70
+The `npm` CLI began hiding the output of lifecycle scripts for `npm install` as of `v7`. Notably, this means you will not see logs/output from packages that may be using "install scripts" to display information back to you or from your own project's scripts defined in `package.json`. If you'd like to change this behavior & log this output you can set `foreground-scripts` to `true`.
71
+
72
+### Timing Information
73
+
74
+The [`--timing` config](/cli/v11/using-npm/config#timing) can be set which does a few things:
75
+
76
+1. Always shows the full path to the debug log regardless of command exit status
77
+1. Write timing information to a process specific timing file in the cache or `logs-dir`
78
+1. Output timing information to the terminal
79
+
80
+This file contains a `timers` object where the keys are an identifier for the portion of the process being timed and the value is the number of milliseconds it took to complete.
81
+
82
+Sometimes it is helpful to get timing information without outputting anything to the terminal. For example, the performance might be affected by writing to the terminal. In this case you can use `--timing --silent` which will still write the timing file, but not output anything to the terminal while running.
83
+
84
+### Registry Response Headers
85
+
86
+#### `npm-notice`
87
+
88
+The `npm` CLI reads from & logs any `npm-notice` headers that are returned from the configured registry. This mechanism can be used by third-party registries to provide useful information when network-dependent requests occur.
89
+
90
+This header is not cached, and will not be logged if the request is served from the cache.
91
+
92
+### Logs and Sensitive Information
93
+
94
+The `npm` CLI makes a best effort to redact the following from terminal output and log files:
95
+
96
+- Passwords inside basic auth URLs
97
+- npm tokens
98
+
99
+However, this behavior should not be relied on to keep all possible sensitive information redacted. If you are concerned about secrets in your log file or terminal output, you can use `--loglevel=silent` and `--logs-max=0` to ensure no logs are written to your terminal or filesystem.
100
+
101
+### See also
102
+
103
+- [config](/cli/v11/using-npm/config)
content/cli/v11/using-npm/orgs.mdx
new
+107
@@ -0,0 +1,107 @@
1
+---
2
+title: orgs
3
+section: 7
4
+description: Working with Teams & Orgs
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/orgs.md
8
+redirect_from:
9
+ - /cli-documentation/misc/orgs
10
+ - /cli-documentation/using-npm/orgs
11
+ - /cli-documentation/v11/misc/orgs
12
+ - /cli-documentation/v11/using-npm/orgs
13
+ - /cli/misc/orgs
14
+ - /cli/using-npm/orgs
15
+ - /cli/v11/misc/orgs
16
+ - /misc/orgs
17
+ - /using-npm/orgs
18
+---
19
+
20
+### Description
21
+
22
+There are three levels of org users:
23
+
24
+1. Super admin, controls billing & adding people to the org.
25
+2. Team admin, manages team membership & package access.
26
+3. Developer, works on packages they are given access to.
27
+
28
+The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a `developers` team that all users are automatically added to.
29
+
30
+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.
31
+
32
+The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only.
33
+
34
+There are two main commands:
35
+
36
+1. `npm team` see [npm team](/cli/v11/commands/npm-team) for more details
37
+2. `npm access` see [npm access](/cli/v11/commands/npm-access) for more details
38
+
39
+### Team Admins create teams
40
+
41
+- Check who you’ve added to your org:
42
+
43
+```bash
44
+npm team ls <org>:developers
45
+```
46
+
47
+- Each org is automatically given a `developers` team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the `access` command.
48
+
49
+- Create a new team:
50
+
51
+```bash
52
+npm team create <org:team>
53
+```
54
+
55
+- Add members to that team:
56
+
57
+```bash
58
+npm team add <org:team> <user>
59
+```
60
+
61
+### Publish a package and adjust package access
62
+
63
+- In package directory, run
64
+
65
+```bash
66
+npm init --scope=<org>
67
+```
68
+
69
+to scope it for your org & publish as usual
70
+
71
+- Grant access:
72
+
73
+```bash
74
+npm access grant <read-only|read-write> <org:team> [<package>]
75
+```
76
+
77
+- Revoke access:
78
+
79
+```bash
80
+npm access revoke <org:team> [<package>]
81
+```
82
+
83
+### Monitor your package access
84
+
85
+- See what org packages a team member can access:
86
+
87
+```bash
88
+npm access ls-packages <org> <user>
89
+```
90
+
91
+- See packages available to a specific team:
92
+
93
+```bash
94
+npm access ls-packages <org:team>
95
+```
96
+
97
+- Check which teams are collaborating on a package:
98
+
99
+```bash
100
+npm access ls-collaborators <pkg>
101
+```
102
+
103
+### See also
104
+
105
+- [npm team](/cli/v11/commands/npm-team)
106
+- [npm access](/cli/v11/commands/npm-access)
107
+- [npm scope](/cli/v11/using-npm/scope)
content/cli/v11/using-npm/package-spec.mdx
new
+97
@@ -0,0 +1,97 @@
1
+---
2
+title: package-spec
3
+section: 7
4
+description: Package name specifier
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/package-spec.md
8
+redirect_from:
9
+ - /cli-documentation/misc/package-spec
10
+ - /cli-documentation/using-npm/package-spec
11
+ - /cli-documentation/v11/misc/package-spec
12
+ - /cli-documentation/v11/using-npm/package-spec
13
+ - /cli/misc/package-spec
14
+ - /cli/using-npm/package-spec
15
+ - /cli/v11/misc/package-spec
16
+ - /misc/package-spec
17
+ - /using-npm/package-spec
18
+---
19
+
20
+### Description
21
+
22
+Commands like `npm install` and the dependency sections in the `package.json` use a package name specifier. This can be many different things that all refer to a "package". Examples include a package name, git url, tarball, or local directory. These will generally be referred to as `<package-spec>` in the help output for the npm commands that use this package name specifier.
23
+
24
+### Package name
25
+
26
+- `[<@scope>/]<pkg>`
27
+- `[<@scope>/]<pkg>@<tag>`
28
+- `[<@scope>/]<pkg>@<version>`
29
+- `[<@scope>/]<pkg>@<version range>`
30
+
31
+Refers to a package by name, with or without a scope, and optionally tag, version, or version range. This is typically used in combination with the [registry](/cli/v11/using-npm/config#registry) config to refer to a package in a registry.
32
+
33
+Examples:
34
+
35
+- `npm`
36
+- `@npmcli/arborist`
37
+- `@npmcli/arborist@latest`
38
+- `npm@6.13.1`
39
+- `npm@^4.0.0`
40
+
41
+### Aliases
42
+
43
+- `<alias>@npm:<name>`
44
+
45
+Primarily used by commands like `npm install` and in the dependency sections in the `package.json`, this refers to a package by an alias. The `<alias>` is the name of the package as it is reified in the `node_modules` folder, and the `<name>` refers to a package name as found in the configured registry.
46
+
47
+See `Package name` above for more info on referring to a package by name, and [registry](/cli/v11/using-npm/config#registry) for configuring which registry is used when referring to a package by name.
48
+
49
+Examples:
50
+
51
+- `semver:@npm:@npmcli/semver-with-patch`
52
+- `semver:@npm:semver@7.2.2`
53
+- `semver:@npm:semver@legacy`
54
+
55
+### Folders
56
+
57
+- `<folder>`
58
+
59
+This refers to a package on the local filesystem. Specifically this is a folder with a `package.json` file in it. This _should_ always be prefixed with a `/` or `./` (or your OS equivalent) to reduce confusion. npm currently will parse a string with more than one `/` in it as a folder, but this is legacy behavior that may be removed in a future version.
60
+
61
+Examples:
62
+
63
+- `./my-package`
64
+- `/opt/npm/my-package`
65
+
66
+### Tarballs
67
+
68
+- `<tarball file>`
69
+- `<tarball url>`
70
+
71
+Examples:
72
+
73
+- `./my-package.tgz`
74
+- `https://registry.npmjs.org/semver/-/semver-1.0.0.tgz`
75
+
76
+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.
77
+
78
+### git urls
79
+
80
+- `<git:// url>`
81
+- `<github username>/<github project>`
82
+
83
+Refers to a package in a git repo. This can be a full git url, git shorthand, or a username/package on GitHub. You can specify a git tag, branch, or other git ref by appending `#ref`.
84
+
85
+Examples:
86
+
87
+- `https://github.com/npm/cli.git`
88
+- `git@github.com:npm/cli.git`
89
+- `git+ssh://git@github.com/npm/cli#v6.0.0`
90
+- `github:npm/cli#HEAD`
91
+- `npm/cli#c12ea07`
92
+
93
+### See also
94
+
95
+- [npm-package-arg](https://npm.im/npm-package-arg)
96
+- [scope](/cli/v11/using-npm/scope)
97
+- [config](/cli/v11/using-npm/config)
content/cli/v11/using-npm/registry.mdx
new
+62
@@ -0,0 +1,62 @@
1
+---
2
+title: registry
3
+section: 7
4
+description: The JavaScript Package Registry
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/registry.md
8
+redirect_from:
9
+ - /cli-documentation/misc/registry
10
+ - /cli-documentation/using-npm/registry
11
+ - /cli-documentation/v11/misc/registry
12
+ - /cli-documentation/v11/using-npm/registry
13
+ - /cli/misc/registry
14
+ - /cli/using-npm/registry
15
+ - /cli/v11/misc/registry
16
+ - /misc/registry
17
+ - /using-npm/registry
18
+---
19
+
20
+### Description
21
+
22
+To resolve packages by name and version, npm talks to a registry website that implements the CommonJS Package Registry specification for reading package info.
23
+
24
+npm is configured to use the **npm public registry** at [https://registry.npmjs.org](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](https://docs.npmjs.com/policies/terms).
25
+
26
+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.
27
+
28
+npm's package registry implementation supports several write APIs as well, to allow for publishing packages and managing user account information.
29
+
30
+The npm public registry is powered by a CouchDB database, of which there is a public mirror at [https://skimdb.npmjs.com/registry](https://skimdb.npmjs.com/registry).
31
+
32
+The registry URL used is determined by the scope of the package (see [`scope`](/cli/v11/using-npm/scope). If no scope is specified, the default registry is used, which is supplied by the [`registry` config](/cli/v11/using-npm/config#registry) parameter. See [`npm config`](/cli/v11/commands/npm-config), [`npmrc`](/cli/v11/configuring-npm/npmrc), and [`config`](/cli/v11/using-npm/config) for more on managing npm's configuration. Authentication configuration such as auth tokens and certificates are configured specifically scoped to an individual registry. See [Auth Related Configuration](/cli/v11/configuring-npm/npmrc#auth-related-configuration)
33
+
34
+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.
35
+
36
+### Does npm send any information about me back to the registry?
37
+
38
+Yes.
39
+
40
+When making requests of the registry npm adds two headers with information about your environment:
41
+
42
+- `Npm-Scope` – If your project is scoped, this header will contain its scope. In the future npm hopes to build registry features that use this information to allow you to customize your experience for your organization.
43
+- `Npm-In-CI` – Set to "true" if npm believes this install is running in a continuous integration environment, "false" otherwise. This is detected by looking for the following environment variables: `CI`, `TDDIUM`, `JENKINS_URL`, `bamboo.buildKey`. If you'd like to learn more you may find the [original PR](https://github.com/npm/npm-registry-client/pull/129) interesting. This is used to gather better metrics on how npm is used by humans, versus build farms.
44
+
45
+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.
46
+
47
+### How can I prevent my package from being published in the official registry?
48
+
49
+Set `"private": true` in your `package.json` to prevent it from being published at all, or `"publishConfig":{"registry":"http://my-internal-registry.local"}` to force it to be published only to your internal/private registry.
50
+
51
+See [`package.json`](/cli/v11/configuring-npm/package-json) for more info on what goes in the package.json file.
52
+
53
+### Where can I find my (and others') published packages?
54
+
55
+[https://www.npmjs.com/](https://www.npmjs.com/)
56
+
57
+### See also
58
+
59
+- [npm config](/cli/v11/commands/npm-config)
60
+- [config](/cli/v11/using-npm/config)
61
+- [npmrc](/cli/v11/configuring-npm/npmrc)
62
+- [npm developers](/cli/v11/using-npm/developers)
content/cli/v11/using-npm/removal.mdx
new
+71
@@ -0,0 +1,71 @@
1
+---
2
+title: removal
3
+section: 7
4
+description: Cleaning the Slate
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/removal.md
8
+redirect_from:
9
+ - /cli-documentation/misc/removal
10
+ - /cli-documentation/misc/removing-npm
11
+ - /cli-documentation/using-npm/removal
12
+ - /cli-documentation/using-npm/removing-npm
13
+ - /cli-documentation/v11/misc/removal
14
+ - /cli-documentation/v11/misc/removing-npm
15
+ - /cli-documentation/v11/using-npm/removal
16
+ - /cli-documentation/v11/using-npm/removing-npm
17
+ - /cli/misc/removal
18
+ - /cli/misc/removing-npm
19
+ - /cli/using-npm/removal
20
+ - /cli/using-npm/removing-npm
21
+ - /cli/v11/misc/removal
22
+ - /cli/v11/misc/removing-npm
23
+ - /cli/v11/using-npm/removing-npm
24
+ - /misc/removal
25
+ - /misc/removing-npm
26
+ - /using-npm/removal
27
+ - /using-npm/removing-npm
28
+---
29
+
30
+### Synopsis
31
+
32
+So sad to see you go.
33
+
34
+```bash
35
+sudo npm uninstall npm -g
36
+```
37
+
38
+Or, if that fails, please proceed to more severe uninstalling methods.
39
+
40
+### More Severe Uninstalling
41
+
42
+Usually, the above instructions are sufficient. That will remove npm, but leave behind anything you've installed.
43
+
44
+If that doesn't work, or if you require more drastic measures, continue reading.
45
+
46
+Note that this is only necessary for globally-installed packages. Local installs are completely contained within a project's `node_modules` folder. Delete that folder, and everything is gone unless a package's install script is particularly ill-behaved.
47
+
48
+This assumes that you installed node and npm in the default place. If you configured node with a different `--prefix`, or installed npm with a different prefix setting, then adjust the paths accordingly, replacing `/usr/local` with your install prefix.
49
+
50
+To remove everything npm-related manually:
51
+
52
+```bash
53
+rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
54
+```
55
+
56
+If you installed things _with_ npm, then your best bet is to uninstall them with npm first, and then install them again once you have a proper install. This can help find any symlinks that are lying around:
57
+
58
+```bash
59
+ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
60
+```
61
+
62
+Prior to version 0.3, npm used shim files for executables and node modules. To track those down, you can do the following:
63
+
64
+```bash
65
+find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;
66
+```
67
+
68
+### See also
69
+
70
+- [npm uninstall](/cli/v11/commands/npm-uninstall)
71
+- [npm prune](/cli/v11/commands/npm-prune)
content/cli/v11/using-npm/scope.mdx
new
+124
@@ -0,0 +1,124 @@
1
+---
2
+title: scope
3
+section: 7
4
+description: Scoped packages
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/scope.md
8
+redirect_from:
9
+ - /cli-documentation/misc/npm-scope
10
+ - /cli-documentation/misc/scope
11
+ - /cli-documentation/using-npm/npm-scope
12
+ - /cli-documentation/using-npm/scope
13
+ - /cli-documentation/v11/misc/npm-scope
14
+ - /cli-documentation/v11/misc/scope
15
+ - /cli-documentation/v11/using-npm/npm-scope
16
+ - /cli-documentation/v11/using-npm/scope
17
+ - /cli/misc/npm-scope
18
+ - /cli/misc/scope
19
+ - /cli/using-npm/npm-scope
20
+ - /cli/using-npm/scope
21
+ - /cli/v11/misc/npm-scope
22
+ - /cli/v11/misc/scope
23
+ - /cli/v11/using-npm/npm-scope
24
+ - /misc/npm-scope
25
+ - /misc/scope
26
+ - /using-npm/npm-scope
27
+ - /using-npm/scope
28
+---
29
+
30
+### Description
31
+
32
+All npm packages have a name. Some package names also have a scope. A scope follows the usual rules for package names (URL-safe characters, no leading dots or underscores). When used in package names, scopes are preceded by an `@` symbol and followed by a slash, e.g.
33
+
34
+```bash
35
+@somescope/somepackagename
36
+```
37
+
38
+Scopes are a way of grouping related packages together, and also affect a few things about the way npm treats the package.
39
+
40
+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.
41
+
42
+Scoped packages can be published and installed as of `npm@2` and are supported by the primary npm registry. Unscoped packages can depend on scoped packages and vice versa. The npm client is backwards-compatible with unscoped registries, so it can be used to work with scoped and unscoped registries at the same time.
43
+
44
+### Installing scoped packages
45
+
46
+Scoped packages are installed to a sub-folder of the regular installation folder, e.g. if your other packages are installed in `node_modules/packagename`, scoped modules will be installed in `node_modules/@myorg/packagename`. The scope folder (`@myorg`) is simply the name of the scope preceded by an `@` symbol, and can contain any number of scoped packages.
47
+
48
+A scoped package is installed by referencing it by name, preceded by an `@` symbol, in `npm install`:
49
+
50
+```bash
51
+npm install @myorg/mypackage
52
+```
53
+
54
+Or in `package.json`:
55
+
56
+```json
57
+"dependencies": {
58
+ "@myorg/mypackage": "^1.3.0"
59
+}
60
+```
61
+
62
+Note that if the `@` symbol is omitted, in either case, npm will instead attempt to install from GitHub; see [`npm install`](/cli/v11/commands/npm-install).
63
+
64
+### Requiring scoped packages
65
+
66
+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.
67
+
68
+```javascript
69
+require("@myorg/mypackage");
70
+```
71
+
72
+There is nothing special about the way Node treats scope folders. This simply requires the `mypackage` module in the folder named `@myorg`.
73
+
74
+### Publishing scoped packages
75
+
76
+Scoped packages can be published from the CLI as of `npm@2` and can be published to any registry that supports them, including the primary npm registry.
77
+
78
+(As of 2015-04-19, and with npm 2.0 or better, the primary npm registry **does** support scoped packages.)
79
+
80
+If you wish, you may associate a scope with a registry; see below.
81
+
82
+#### Publishing public scoped packages to the primary npm registry
83
+
84
+Publishing to a scope, you have two options:
85
+
86
+- Publishing to your user scope (example: `@username/module`)
87
+- Publishing to an organization scope (example: `@org/module`)
88
+
89
+If publishing a public module to an organization scope, you must first either create an organization with the name of the scope that you'd like to publish to or be added to an existing organization with the appropriate permissions. For example, if you'd like to publish to `@org`, you would need to create the `org` organization on npmjs.com prior to trying to publish.
90
+
91
+Scoped packages are not public by default. You will need to specify `--access public` with the initial `npm publish` command. This will publish the package and set access to `public` as if you had run `npm access public` after publishing. You do not need to do this when publishing new versions of an existing scoped package.
92
+
93
+#### Publishing private scoped packages to the npm registry
94
+
95
+To publish a private scoped package to the npm registry, you must have an [npm Private Modules](https://docs.npmjs.com/private-modules/intro) account.
96
+
97
+You can then publish the module with `npm publish` or `npm publish --access restricted`, and it will be present in the npm registry, with restricted access. You can then change the access permissions, if desired, with `npm access` or on the npmjs.com website.
98
+
99
+### Associating a scope with a registry
100
+
101
+Scopes can be associated with a separate registry. This allows you to seamlessly use a mix of packages from the primary npm registry and one or more private registries, such as [GitHub Packages](https://github.com/features/packages) or the open source [Verdaccio](https://verdaccio.org) project.
102
+
103
+You can associate a scope with a registry at login, e.g.
104
+
105
+```bash
106
+npm login --registry=http://reg.example.com --scope=@myco
107
+```
108
+
109
+Scopes have a many-to-one relationship with registries: one registry can host multiple scopes, but a scope only ever points to one registry.
110
+
111
+You can also associate a scope with a registry using `npm config`:
112
+
113
+```bash
114
+npm config set @myco:registry=http://reg.example.com
115
+```
116
+
117
+Once a scope is associated with a registry, any `npm install` for a package with that scope will request packages from that registry instead. Any `npm publish` for a package name that contains the scope will be published to that registry instead.
118
+
119
+### See also
120
+
121
+- [npm install](/cli/v11/commands/npm-install)
122
+- [npm publish](/cli/v11/commands/npm-publish)
123
+- [npm access](/cli/v11/commands/npm-access)
124
+- [npm registry](/cli/v11/using-npm/registry)
content/cli/v11/using-npm/scripts.mdx
new
+311
@@ -0,0 +1,311 @@
1
+---
2
+title: scripts
3
+section: 7
4
+description: How npm handles the "scripts" field
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/scripts.md
8
+redirect_from:
9
+ - /cli-documentation/misc/scripts
10
+ - /cli-documentation/using-npm/scripts
11
+ - /cli-documentation/v11/misc/scripts
12
+ - /cli-documentation/v11/using-npm/scripts
13
+ - /cli/misc/scripts
14
+ - /cli/using-npm/scripts
15
+ - /cli/v11/misc/scripts
16
+ - /misc/scripts
17
+ - /using-npm/scripts
18
+---
19
+
20
+### Description
21
+
22
+The `"scripts"` property of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. _Pre_ and _post_ commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.
23
+
24
+### Pre & Post Scripts
25
+
26
+To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script _with a matching name_ and add "pre" or "post" to the beginning of them.
27
+
28
+```json
29
+{
30
+ "scripts": {
31
+ "precompress": "{{ executes BEFORE the `compress` script }}",
32
+ "compress": "{{ run command to compress files }}",
33
+ "postcompress": "{{ executes AFTER `compress` script }}"
34
+ }
35
+}
36
+```
37
+
38
+In this example `npm run compress` would execute these scripts as described.
39
+
40
+### Life Cycle Scripts
41
+
42
+There are some special life cycle scripts that happen only in certain situations. These scripts happen in addition to the `pre<event>`, `post<event>`, and `<event>` scripts.
43
+
44
+- `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`, `dependencies`
45
+
46
+**prepare** (since `npm@4.0.0`)
47
+
48
+- Runs BEFORE the package is packed, i.e. during `npm publish` and `npm pack`
49
+- Runs on local `npm install` without any arguments
50
+- Runs AFTER `prepublish`, but BEFORE `prepublishOnly`
51
+
52
+- NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.
53
+
54
+- As of `npm@7` these scripts run in the background. To see the output, run with: `--foreground-scripts`.
55
+
56
+**prepublish** (DEPRECATED)
57
+
58
+- Does not run during `npm publish`, but does run during `npm ci` and `npm install`. See below for more info.
59
+
60
+**prepublishOnly**
61
+
62
+- Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.
63
+
64
+**prepack**
65
+
66
+- Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependency).
67
+- NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.
68
+
69
+**postpack**
70
+
71
+- 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)
72
+
73
+**dependencies**
74
+
75
+- Runs AFTER any operations that modify the `node_modules` directory IF changes occurred.
76
+- Does NOT run in global mode
77
+
78
+#### Prepare and Prepublish
79
+
80
+**Deprecation Note: prepublish**
81
+
82
+Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).
83
+
84
+See [https://github.com/npm/npm/issues/10074](https://github.com/npm/npm/issues/10074) for a much lengthier justification, with further reading, for this change.
85
+
86
+**Use Cases**
87
+
88
+If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a `prepublish` script. This includes tasks such as:
89
+
90
+- Compiling CoffeeScript source code into JavaScript.
91
+- Creating minified versions of JavaScript source code.
92
+- Fetching remote resources that your package will use.
93
+
94
+The advantage of doing these things at `prepublish` time is that they can be done once, in a single place, thus reducing complexity and variability. Additionally, this means that:
95
+
96
+- You can depend on `coffee-script` as a `devDependency`, and thus your users don't need to have it installed.
97
+- You don't need to include minifiers in your package, reducing the size for your users.
98
+- You don't need to rely on your users having `curl` or `wget` or other system tools on the target machines.
99
+
100
+#### Dependencies
101
+
102
+The `dependencies` script is run any time an `npm` command causes changes to the `node_modules` directory. It is run AFTER the changes have been applied and the `package.json` and `package-lock.json` files have been updated.
103
+
104
+### Life Cycle Operation Order
105
+
106
+#### [`npm cache add`](/cli/v11/commands/npm-cache)
107
+
108
+- `prepare`
109
+
110
+#### [`npm ci`](/cli/v11/commands/npm-ci)
111
+
112
+- `preinstall`
113
+- `install`
114
+- `postinstall`
115
+- `prepublish`
116
+- `preprepare`
117
+- `prepare`
118
+- `postprepare`
119
+
120
+These all run after the actual installation of modules into `node_modules`, in order, with no internal actions happening in between
121
+
122
+#### [`npm diff`](/cli/v11/commands/npm-diff)
123
+
124
+- `prepare`
125
+
126
+#### [`npm install`](/cli/v11/commands/npm-install)
127
+
128
+These also run when you run `npm install -g <pkg-name>`
129
+
130
+- `preinstall`
131
+- `install`
132
+- `postinstall`
133
+- `prepublish`
134
+- `preprepare`
135
+- `prepare`
136
+- `postprepare`
137
+
138
+If there is a `binding.gyp` file in the root of your package and you haven't defined your own `install` or `preinstall` scripts, npm will default the `install` command to compile using node-gyp via `node-gyp rebuild`
139
+
140
+These are run from the scripts of `<pkg-name>`
141
+
142
+#### [`npm pack`](/cli/v11/commands/npm-pack)
143
+
144
+- `prepack`
145
+- `prepare`
146
+- `postpack`
147
+
148
+#### [`npm publish`](/cli/v11/commands/npm-publish)
149
+
150
+- `prepublishOnly`
151
+- `prepack`
152
+- `prepare`
153
+- `postpack`
154
+- `publish`
155
+- `postpublish`
156
+
157
+#### [`npm rebuild`](/cli/v11/commands/npm-rebuild)
158
+
159
+- `preinstall`
160
+- `install`
161
+- `postinstall`
162
+- `prepare`
163
+
164
+`prepare` is only run if the current directory is a symlink (e.g. with linked packages)
165
+
166
+#### [`npm restart`](/cli/v11/commands/npm-restart)
167
+
168
+If there is a `restart` script defined, these events are run, otherwise `stop` and `start` are both run if present, including their `pre` and `post` iterations)
169
+
170
+- `prerestart`
171
+- `restart`
172
+- `postrestart`
173
+
174
+#### [`npm run <user defined>`](/cli/v11/commands/npm-run-script)
175
+
176
+- `pre<user-defined>`
177
+- `<user-defined>`
178
+- `post<user-defined>`
179
+
180
+#### [`npm start`](/cli/v11/commands/npm-start)
181
+
182
+- `prestart`
183
+- `start`
184
+- `poststart`
185
+
186
+If there is a `server.js` file in the root of your package, then npm will default the `start` command to `node server.js`. `prestart` and `poststart` will still run in this case.
187
+
188
+#### [`npm stop`](/cli/v11/commands/npm-stop)
189
+
190
+- `prestop`
191
+- `stop`
192
+- `poststop`
193
+
194
+#### [`npm test`](/cli/v11/commands/npm-test)
195
+
196
+- `pretest`
197
+- `test`
198
+- `posttest`
199
+
200
+#### [`npm version`](/cli/v11/commands/npm-version)
201
+
202
+- `preversion`
203
+- `version`
204
+- `postversion`
205
+
206
+#### A Note on a lack of [`npm uninstall`](/cli/v11/commands/npm-uninstall) scripts
207
+
208
+While npm v6 had `uninstall` lifecycle scripts, npm v7 does not. Removal of a package can happen for a wide variety of reasons, and there's no clear way to currently give the script enough context to be useful.
209
+
210
+Reasons for a package removal include:
211
+
212
+- a user directly uninstalled this package
213
+- a user uninstalled a dependant package and so this dependency is being uninstalled
214
+- a user uninstalled a dependant package but another package also depends on this version
215
+- this version has been merged as a duplicate with another version
216
+- etc.
217
+
218
+Due to the lack of necessary context, `uninstall` lifecycle scripts are not implemented and will not function.
219
+
220
+### User
221
+
222
+When npm is run as root, scripts are always run with the effective uid and gid of the working directory owner.
223
+
224
+### Environment
225
+
226
+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.
227
+
228
+#### path
229
+
230
+If you depend on modules that define executable scripts, like test suites, then those executables will be added to the `PATH` for executing the scripts. So, if your package.json has this:
231
+
232
+```json
233
+{
234
+ "name": "foo",
235
+ "dependencies": {
236
+ "bar": "0.1.x"
237
+ },
238
+ "scripts": {
239
+ "start": "bar ./test"
240
+ }
241
+}
242
+```
243
+
244
+then you could run `npm start` to execute the `bar` script, which is exported into the `node_modules/.bin` directory on `npm install`.
245
+
246
+#### package.json vars
247
+
248
+The package.json fields are tacked onto the `npm_package_` prefix. So, for instance, if you had `{"name":"foo", "version":"1.2.5"}` in your package.json file, then your package scripts would have the `npm_package_name` environment variable set to "foo", and the `npm_package_version` set to "1.2.5". You can access these variables in your code with `process.env.npm_package_name` and `process.env.npm_package_version`, and so on for other fields.
249
+
250
+See [`package.json`](/cli/v11/configuring-npm/package-json) for more on package configs.
251
+
252
+#### current lifecycle event
253
+
254
+Lastly, the `npm_lifecycle_event` environment variable is set to whichever stage of the cycle is being executed. So, you could have a single script used for different parts of the process which switches based on what's currently happening.
255
+
256
+Objects are flattened following this format, so if you had `{"scripts":{"install":"foo.js"}}` in your package.json, then you'd see this in the script:
257
+
258
+```bash
259
+process.env.npm_package_scripts_install === "foo.js"
260
+```
261
+
262
+### Examples
263
+
264
+For example, if your package.json contains this:
265
+
266
+```json
267
+{
268
+ "scripts": {
269
+ "install": "scripts/install.js",
270
+ "postinstall": "scripts/install.js"
271
+ }
272
+}
273
+```
274
+
275
+then `scripts/install.js` will be called for the install and post-install stages of the lifecycle. Since `scripts/install.js` is running for two different phases, it would be wise in this case to look at the `npm_lifecycle_event` environment variable.
276
+
277
+If you want to run a make command, you can do so. This works just fine:
278
+
279
+```json
280
+{
281
+ "scripts": {
282
+ "preinstall": "./configure",
283
+ "install": "make && make install",
284
+ "test": "make test"
285
+ }
286
+}
287
+```
288
+
289
+### Exiting
290
+
291
+Scripts are run by passing the line as a script argument to `sh`.
292
+
293
+If the script exits with a code other than 0, then this will abort the process.
294
+
295
+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.
296
+
297
+### Best Practices
298
+
299
+- Don't exit with a non-zero error code unless you _really_ mean it. If the failure is minor or only will prevent some optional features, then it's better to just print a warning and exit successfully.
300
+- Try not to use scripts to do what npm can do for you. Read through [`package.json`](/cli/v11/configuring-npm/package-json) to see all the things that you can specify and enable by simply describing your package appropriately. In general, this will lead to a more robust and consistent state.
301
+- Inspect the env to determine where to put things. For instance, if the `npm_config_binroot` environment variable is set to `/home/user/bin`, then don't try to install executables into `/usr/local/bin`. The user probably set it up that way for a reason.
302
+- 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.
303
+- Don't use `install`. Use a `.gyp` file for compilation, and `prepare` for anything else. You should almost never have to explicitly set a preinstall or install script. If you are doing this, please consider if there is another option. The only valid use of `install` or `preinstall` scripts is for compilation which must be done on the target architecture.
304
+- Scripts are run from the root of the package folder, regardless of what the current working directory is when `npm` is invoked. If you want your script to use different behavior based on what subdirectory you're in, you can use the `INIT_CWD` environment variable, which holds the full path you were in when you ran `npm run`.
305
+
306
+### See Also
307
+
308
+- [npm run-script](/cli/v11/commands/npm-run-script)
309
+- [package.json](/cli/v11/configuring-npm/package-json)
310
+- [npm developers](/cli/v11/using-npm/developers)
311
+- [npm install](/cli/v11/commands/npm-install)
content/cli/v11/using-npm/workspaces.mdx
new
+198
@@ -0,0 +1,198 @@
1
+---
2
+title: workspaces
3
+section: 7
4
+description: Working with workspaces
5
+github_repo: npm/cli
6
+github_branch: latest
7
+github_path: docs/lib/content/using-npm/workspaces.md
8
+redirect_from:
9
+ - /cli-documentation/misc/workspaces
10
+ - /cli-documentation/using-npm/workspaces
11
+ - /cli-documentation/v11/misc/workspaces
12
+ - /cli-documentation/v11/using-npm/workspaces
13
+ - /cli/misc/workspaces
14
+ - /cli/using-npm/workspaces
15
+ - /cli/v11/misc/workspaces
16
+ - /misc/workspaces
17
+ - /using-npm/workspaces
18
+---
19
+
20
+### Description
21
+
22
+**Workspaces** is a generic term that refers to the set of features in the npm cli that provides support for managing multiple packages from your local file system from within a singular top-level, root package.
23
+
24
+This set of features makes up for a much more streamlined workflow handling linked packages from the local file system. It automates the linking process as part of `npm install` and removes the need to manually use `npm link` in order to add references to packages that should be symlinked into the current `node_modules` folder.
25
+
26
+We also refer to these packages being auto-symlinked during `npm install` as a single **workspace**, meaning it's a nested package within the current local file system that is explicitly defined in the [`package.json`](/cli/v11/configuring-npm/package-json#workspaces) `workspaces` configuration.
27
+
28
+### Defining workspaces
29
+
30
+Workspaces are usually defined via the `workspaces` property of the [`package.json`](/cli/v11/configuring-npm/package-json#workspaces) file, e.g:
31
+
32
+```json
33
+{
34
+ "name": "my-workspaces-powered-project",
35
+ "workspaces": ["packages/a"]
36
+}
37
+```
38
+
39
+Given the above `package.json` example living at a current working directory `.` that contains a folder named `packages/a` that itself contains a `package.json` inside it, defining a Node.js package, e.g:
40
+
41
+```
42
+.
43
++-- package.json
44
+`-- packages
45
+ +-- a
46
+ | `-- package.json
47
+```
48
+
49
+The expected result once running `npm install` in this current working directory `.` is that the folder `packages/a` will get symlinked to the `node_modules` folder of the current working dir.
50
+
51
+Below is a post `npm install` example, given that same previous example structure of files and folders:
52
+
53
+```
54
+.
55
++-- node_modules
56
+| `-- a -> ../packages/a
57
++-- package-lock.json
58
++-- package.json
59
+`-- packages
60
+ +-- a
61
+ | `-- package.json
62
+```
63
+
64
+### Getting started with workspaces
65
+
66
+You may automate the required steps to define a new workspace using [npm init](/cli/v11/commands/npm-init). For example in a project that already has a `package.json` defined you can run:
67
+
68
+```
69
+npm init -w ./packages/a
70
+```
71
+
72
+This command will create the missing folders and a new `package.json` file (if needed) while also making sure to properly configure the `"workspaces"` property of your root project `package.json`.
73
+
74
+### Adding dependencies to a workspace
75
+
76
+It's possible to directly add/remove/update dependencies of your workspaces using the [`workspace` config](/cli/v11/using-npm/config#workspace).
77
+
78
+For example, assuming the following structure:
79
+
80
+```
81
+.
82
++-- package.json
83
+`-- packages
84
+ +-- a
85
+ | `-- package.json
86
+ `-- b
87
+ `-- package.json
88
+```
89
+
90
+If you want to add a dependency named `abbrev` from the registry as a dependency of your workspace **a**, you may use the workspace config to tell the npm installer that package should be added as a dependency of the provided workspace:
91
+
92
+```
93
+npm install abbrev -w a
94
+```
95
+
96
+Note: other installing commands such as `uninstall`, `ci`, etc will also respect the provided `workspace` configuration.
97
+
98
+### Using workspaces
99
+
100
+Given the [specifics of how Node.js handles module resolution](https://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together) it's possible to consume any defined workspace by its declared `package.json` `name`. Continuing from the example defined above, let's also create a Node.js script that will require the workspace `a` example module, e.g:
101
+
102
+```
103
+// ./packages/a/index.js
104
+module.exports = 'a'
105
+
106
+// ./lib/index.js
107
+const moduleA = require('a')
108
+console.log(moduleA) // -> a
109
+```
110
+
111
+When running it with:
112
+
113
+`node lib/index.js`
114
+
115
+This demonstrates how the nature of `node_modules` resolution allows for **workspaces** to enable a portable workflow for requiring each **workspace** in such a way that is also easy to [publish](/cli/v11/commands/npm-publish) these nested workspaces to be consumed elsewhere.
116
+
117
+### Running commands in the context of workspaces
118
+
119
+You can use the `workspace` configuration option to run commands in the context of a configured workspace. Additionally, if your current directory is in a workspace, the `workspace` configuration is implicitly set, and `prefix` is set to the root workspace.
120
+
121
+Following is a quick example on how to use the `npm run` command in the context of nested workspaces. For a project containing multiple workspaces, e.g:
122
+
123
+```
124
+.
125
++-- package.json
126
+`-- packages
127
+ +-- a
128
+ | `-- package.json
129
+ `-- b
130
+ `-- package.json
131
+```
132
+
133
+By running a command using the `workspace` option, it's possible to run the given command in the context of that specific workspace. e.g:
134
+
135
+```
136
+npm run test --workspace=a
137
+```
138
+
139
+You could also run the command within the workspace.
140
+
141
+```
142
+cd packages/a && npm run test
143
+```
144
+
145
+Either will run the `test` script defined within the `./packages/a/package.json` file.
146
+
147
+Please note that you can also specify this argument multiple times in the command-line in order to target multiple workspaces, e.g:
148
+
149
+```
150
+npm run test --workspace=a --workspace=b
151
+```
152
+
153
+Or run the command for each workspace within the 'packages' folder:
154
+
155
+```
156
+npm run test --workspace=packages
157
+```
158
+
159
+It's also possible to use the `workspaces` (plural) configuration option to enable the same behavior but running that command in the context of **all** configured workspaces. e.g:
160
+
161
+```
162
+npm run test --workspaces
163
+```
164
+
165
+Will run the `test` script in both `./packages/a` and `./packages/b`.
166
+
167
+Commands will be run in each workspace in the order they appear in your `package.json`
168
+
169
+```
170
+{
171
+ "workspaces": [ "packages/a", "packages/b" ]
172
+}
173
+```
174
+
175
+Order of run is different with:
176
+
177
+```
178
+{
179
+ "workspaces": [ "packages/b", "packages/a" ]
180
+}
181
+```
182
+
183
+### Ignoring missing scripts
184
+
185
+It is not required for all of the workspaces to implement scripts run with the `npm run` command.
186
+
187
+By running the command with the `--if-present` flag, npm will ignore workspaces missing target script.
188
+
189
+```
190
+npm run test --workspaces --if-present
191
+```
192
+
193
+### See also
194
+
195
+- [npm install](/cli/v11/commands/npm-install)
196
+- [npm publish](/cli/v11/commands/npm-publish)
197
+- [npm run-script](/cli/v11/commands/npm-run-script)
198
+- [config](/cli/v11/using-npm/config)
content/nav.yml
+267
@@ -1594,3 +1594,270 @@
1594
- title: Changelog
1595
url: /cli/v10/using-npm/changelog
1596
description: Changelog notes for each version
1597
+ - title: Version 11.0.0
1598
+ shortName: v11
1599
+ url: /cli/v11
1600
+ default: true
1601
+ type: latest
1602
+ children:
1603
+ - title: CLI Commands
1604
+ shortName: Commands
1605
+ url: /cli/v11/commands
1606
+ children:
1607
+ - title: npm
1608
+ url: /cli/v11/commands/npm
1609
+ description: JavaScript package manager
1610
+ - title: npm access
1611
+ url: /cli/v11/commands/npm-access
1612
+ description: Set access level on published packages
1613
+ - title: npm adduser
1614
+ url: /cli/v11/commands/npm-adduser
1615
+ description: Add a registry user account
1616
+ - title: npm audit
1617
+ url: /cli/v11/commands/npm-audit
1618
+ description: Run a security audit
1619
+ - title: npm bugs
1620
+ url: /cli/v11/commands/npm-bugs
1621
+ description: Bugs for a package in a web browser maybe
1622
+ - title: npm cache
1623
+ url: /cli/v11/commands/npm-cache
1624
+ description: Manipulates packages cache
1625
+ - title: npm ci
1626
+ url: /cli/v11/commands/npm-ci
1627
+ description: Install a project with a clean slate
1628
+ - title: npm completion
1629
+ url: /cli/v11/commands/npm-completion
1630
+ description: Tab completion for npm
1631
+ - title: npm config
1632
+ url: /cli/v11/commands/npm-config
1633
+ description: Manage the npm configuration files
1634
+ - title: npm dedupe
1635
+ url: /cli/v11/commands/npm-dedupe
1636
+ description: Reduce duplication
1637
+ - title: npm deprecate
1638
+ url: /cli/v11/commands/npm-deprecate
1639
+ description: Deprecate a version of a package
1640
+ - title: npm diff
1641
+ url: /cli/v11/commands/npm-diff
1642
+ description: The registry diff command
1643
+ - title: npm dist-tag
1644
+ url: /cli/v11/commands/npm-dist-tag
1645
+ description: Modify package distribution tags
1646
+ - title: npm docs
1647
+ url: /cli/v11/commands/npm-docs
1648
+ description: Docs for a package in a web browser maybe
1649
+ - title: npm doctor
1650
+ url: /cli/v11/commands/npm-doctor
1651
+ description: Check your environments
1652
+ - title: npm edit
1653
+ url: /cli/v11/commands/npm-edit
1654
+ description: Edit an installed package
1655
+ - title: npm exec
1656
+ url: /cli/v11/commands/npm-exec
1657
+ description: Run a command from an npm package
1658
+ - title: npm explain
1659
+ url: /cli/v11/commands/npm-explain
1660
+ description: Explain installed packages
1661
+ - title: npm explore
1662
+ url: /cli/v11/commands/npm-explore
1663
+ description: Browse an installed package
1664
+ - title: npm find-dupes
1665
+ url: /cli/v11/commands/npm-find-dupes
1666
+ description: Find duplication in the package tree
1667
+ - title: npm fund
1668
+ url: /cli/v11/commands/npm-fund
1669
+ description: Retrieve funding information
1670
+ - title: npm help
1671
+ url: /cli/v11/commands/npm-help
1672
+ description: Search npm help documentation
1673
+ - title: npm help-search
1674
+ url: /cli/v11/commands/npm-help-search
1675
+ description: Get help on npm
1676
+ - title: npm init
1677
+ url: /cli/v11/commands/npm-init
1678
+ description: Create a package.json file
1679
+ - title: npm install
1680
+ url: /cli/v11/commands/npm-install
1681
+ description: Install a package
1682
+ - title: npm install-ci-test
1683
+ url: /cli/v11/commands/npm-install-ci-test
1684
+ description: Install a project with a clean slate and run tests
1685
+ - title: npm install-test
1686
+ url: /cli/v11/commands/npm-install-test
1687
+ description: Install package(s) and run tests
1688
+ - title: npm link
1689
+ url: /cli/v11/commands/npm-link
1690
+ description: Symlink a package folder
1691
+ - title: npm login
1692
+ url: /cli/v11/commands/npm-login
1693
+ description: Login to a registry user account
1694
+ - title: npm logout
1695
+ url: /cli/v11/commands/npm-logout
1696
+ description: Log out of the registry
1697
+ - title: npm ls
1698
+ url: /cli/v11/commands/npm-ls
1699
+ description: List installed packages
1700
+ - title: npm org
1701
+ url: /cli/v11/commands/npm-org
1702
+ description: Manage orgs
1703
+ - title: npm outdated
1704
+ url: /cli/v11/commands/npm-outdated
1705
+ description: Check for outdated packages
1706
+ - title: npm owner
1707
+ url: /cli/v11/commands/npm-owner
1708
+ description: Manage package owners
1709
+ - title: npm pack
1710
+ url: /cli/v11/commands/npm-pack
1711
+ description: Create a tarball from a package
1712
+ - title: npm ping
1713
+ url: /cli/v11/commands/npm-ping
1714
+ description: Ping npm registry
1715
+ - title: npm pkg
1716
+ url: /cli/v11/commands/npm-pkg
1717
+ description: Manages your package.json
1718
+ - title: npm prefix
1719
+ url: /cli/v11/commands/npm-prefix
1720
+ description: Display prefix
1721
+ - title: npm profile
1722
+ url: /cli/v11/commands/npm-profile
1723
+ description: Change settings on your registry profile
1724
+ - title: npm prune
1725
+ url: /cli/v11/commands/npm-prune
1726
+ description: Remove extraneous packages
1727
+ - title: npm publish
1728
+ url: /cli/v11/commands/npm-publish
1729
+ description: Publish a package
1730
+ - title: npm query
1731
+ url: /cli/v11/commands/npm-query
1732
+ description: Retrieve a filtered list of packages
1733
+ - title: npm rebuild
1734
+ url: /cli/v11/commands/npm-rebuild
1735
+ description: Rebuild a package
1736
+ - title: npm repo
1737
+ url: /cli/v11/commands/npm-repo
1738
+ description: Open package repository page in the browser
1739
+ - title: npm restart
1740
+ url: /cli/v11/commands/npm-restart
1741
+ description: Restart a package
1742
+ - title: npm root
1743
+ url: /cli/v11/commands/npm-root
1744
+ description: Display npm root
1745
+ - title: npm run-script
1746
+ url: /cli/v11/commands/npm-run-script
1747
+ description: Run arbitrary package scripts
1748
+ - title: npm sbom
1749
+ url: /cli/v11/commands/npm-sbom
1750
+ description: Generate a Software Bill of Materials (SBOM)
1751
+ - title: npm search
1752
+ url: /cli/v11/commands/npm-search
1753
+ description: Search for packages
1754
+ - title: npm shrinkwrap
1755
+ url: /cli/v11/commands/npm-shrinkwrap
1756
+ description: Lock down dependency versions for publication
1757
+ - title: npm star
1758
+ url: /cli/v11/commands/npm-star
1759
+ description: Mark your favorite packages
1760
+ - title: npm stars
1761
+ url: /cli/v11/commands/npm-stars
1762
+ description: View packages marked as favorites
1763
+ - title: npm start
1764
+ url: /cli/v11/commands/npm-start
1765
+ description: Start a package
1766
+ - title: npm stop
1767
+ url: /cli/v11/commands/npm-stop
1768
+ description: Stop a package
1769
+ - title: npm team
1770
+ url: /cli/v11/commands/npm-team
1771
+ description: Manage organization teams and team memberships
1772
+ - title: npm test
1773
+ url: /cli/v11/commands/npm-test
1774
+ description: Test a package
1775
+ - title: npm token
1776
+ url: /cli/v11/commands/npm-token
1777
+ description: Manage your authentication tokens
1778
+ - title: npm uninstall
1779
+ url: /cli/v11/commands/npm-uninstall
1780
+ description: Remove a package
1781
+ - title: npm unpublish
1782
+ url: /cli/v11/commands/npm-unpublish
1783
+ description: Remove a package from the registry
1784
+ - title: npm unstar
1785
+ url: /cli/v11/commands/npm-unstar
1786
+ description: Remove an item from your favorite packages
1787
+ - title: npm update
1788
+ url: /cli/v11/commands/npm-update
1789
+ description: Update a package
1790
+ - title: npm version
1791
+ url: /cli/v11/commands/npm-version
1792
+ description: Bump a package version
1793
+ - title: npm view
1794
+ url: /cli/v11/commands/npm-view
1795
+ description: View registry info
1796
+ - title: npm whoami
1797
+ url: /cli/v11/commands/npm-whoami
1798
+ description: Display npm username
1799
+ - title: npx
1800
+ url: /cli/v11/commands/npx
1801
+ description: Run a command from an npm package
1802
+ - title: Configuring npm
1803
+ shortName: Configuring
1804
+ url: /cli/v11/configuring-npm
1805
+ children:
1806
+ - title: Install
1807
+ url: /cli/v11/configuring-npm/install
1808
+ description: Download and install node and npm
1809
+ - title: Folders
1810
+ url: /cli/v11/configuring-npm/folders
1811
+ description: Folder structures used by npm
1812
+ - title: .npmrc
1813
+ url: /cli/v11/configuring-npm/npmrc
1814
+ description: The npm config files
1815
+ - title: npm-shrinkwrap.json
1816
+ url: /cli/v11/configuring-npm/npm-shrinkwrap-json
1817
+ description: A publishable lockfile
1818
+ - title: package.json
1819
+ url: /cli/v11/configuring-npm/package-json
1820
+ description: Specifics of npm's package.json handling
1821
+ - title: package-lock.json
1822
+ url: /cli/v11/configuring-npm/package-lock-json
1823
+ description: A manifestation of the manifest
1824
+ - title: Using npm
1825
+ shortName: Using
1826
+ url: /cli/v11/using-npm
1827
+ children:
1828
+ - title: Registry
1829
+ url: /cli/v11/using-npm/registry
1830
+ description: The JavaScript Package Registry
1831
+ - title: Package spec
1832
+ url: /cli/v11/using-npm/package-spec
1833
+ description: Package name specifier
1834
+ - title: Config
1835
+ url: /cli/v11/using-npm/config
1836
+ description: About npm configuration
1837
+ - title: Logging
1838
+ url: /cli/v11/using-npm/logging
1839
+ description: Why, What & How we Log
1840
+ - title: Scope
1841
+ url: /cli/v11/using-npm/scope
1842
+ description: Scoped packages
1843
+ - title: Scripts
1844
+ url: /cli/v11/using-npm/scripts
1845
+ description: How npm handles the "scripts" field
1846
+ - title: Workspaces
1847
+ url: /cli/v11/using-npm/workspaces
1848
+ description: Working with workspaces
1849
+ - title: Organizations
1850
+ url: /cli/v11/using-npm/orgs
1851
+ description: Working with teams & organizations
1852
+ - title: Dependency Selectors
1853
+ url: /cli/v11/using-npm/dependency-selectors
1854
+ description: Dependency Selector Syntax & Querying
1855
+ - title: Developers
1856
+ url: /cli/v11/using-npm/developers
1857
+ description: Developer guide
1858
+ - title: Removal
1859
+ url: /cli/v11/using-npm/removal
1860
+ description: Cleaning the slate
1861
+ - title: Changelog
1862
+ url: /cli/v11/using-npm/changelog
1863
+ description: Changelog notes for each version
package.json
+1
-1
@@ -105,7 +105,7 @@
105
},
106
"templateOSS": {
107
"//@npmcli/template-oss": "This file is partially managed by @npmcli/template-oss. Edits may be overwritten.",
108
- "version": "4.23.5",
108
+ "version": "4.23.6",
109
"content": "./scripts/template-oss",
110
"allowPaths": [
111
"cli-cache.json"