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 #### How `npm install` uses `package-lock.json`
57
58 When you run `npm install` without arguments, npm compares `package.json` and `package-lock.json`:
59
60 - **If the lockfile's resolved versions satisfy the `package.json` ranges:** npm uses the exact versions from `package-lock.json` to ensure reproducible builds across environments.
61
62 - **If the ranges don't match:** npm resolves new versions that satisfy the `package.json` ranges and updates `package-lock.json` accordingly. This happens when you modify version ranges in `package.json` (e.g., changing `^7.0.0` to `^8.0.0`). Note that changing a range within the same major version (e.g., `^7.0.0` to `^7.1.0`) will only update the metadata in the lockfile if the currently installed version still satisfies the new range.
63
64 In essence, `package-lock.json` locks your dependencies to specific versions, but `package.json` is the source of truth for acceptable version ranges. When the lockfile's versions satisfy the `package.json` ranges, the lockfile wins. When they conflict, `package.json` wins and the lockfile is updated.
65
66 If you want to install packages while ensuring that `package.json` is not modified and that both files are strictly in sync, use [`npm ci`](/cli/v11/commands/npm-ci) instead.
67
68 A `package` is:
69
70 - a) a folder containing a program described by a [`package.json`](/cli/v11/configuring-npm/package-json) file
71 - b) a gzipped tarball containing (a)
72 - c) a url that resolves to (b)
73 - d) a `<name>@<version>` that is published on the registry (see [`registry`](/cli/v11/using-npm/registry)) with (c)
74 - e) a `<name>@<tag>` (see [`npm dist-tag`](/cli/v11/commands/npm-dist-tag)) that points to (d)
75 - f) a `<name>` that has a "latest" tag satisfying (e)
76 - g) a `<git remote url>` that resolves to (a)
77
78 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).
79
80 - `npm install` (in a package directory, no arguments):
81
82 Install the dependencies to the local `node_modules` folder.
83
84 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.
85
86 By default, `npm install` will install all modules listed as dependencies in [`package.json`](/cli/v11/configuring-npm/package-json).
87
88 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`.
89
90 > NOTE: The `--production` flag has no particular meaning when adding a dependency to a project.
91
92 - `npm install <folder>`:
93
94 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>`.
95
96 > 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.
97
98 Example:
99
100 ```bash
101 npm install ../../other-package --install-links
102 npm install ./sub-package
103 ```
104
105 - `npm install <tarball file>`:
106
107 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).
108
109 Tarball requirements:
110 - The filename _must_ use `.tar`, `.tar.gz`, or `.tgz` as the extension.
111 - 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).
112 - The package must contain a `package.json` file with `name` and `version` properties.
113
114 Example:
115
116 ```bash
117 npm install ./package.tgz
118 ```
119
120 - `npm install <tarball url>`:
121
122 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://"
123
124 Example:
125
126 ```bash
127 npm install https://github.com/indexzero/forever/tarball/v0.5.6
128 ```
129
130 - `npm install [<@scope>/]<name>`:
131
132 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`.)
133
134 In most cases, this will install the version of the modules tagged as `latest` on the npm registry.
135
136 **Note:** When installing by name without specifying a version or tag, npm prioritizes versions that match the current Node.js version based on the package's `engines` field. If the `latest` tag points to a version incompatible with your current Node.js version, npm will install the newest compatible version instead. To install a specific version regardless of `engines` compatibility, explicitly specify the version or tag: `npm install <name>@latest`.
137
138 Example:
139
140 ```bash
141 npm install sax
142 ```
143
144 `npm install` saves any specified packages into `dependencies` by default. Additionally, you can control where and how they get saved with some additional flags:
145 - `-P, --save-prod`: Package will appear in your `dependencies`. This is the default unless `-D` or `-O` are present.
146
147 - `-D, --save-dev`: Package will appear in your `devDependencies`.
148
149 - `--save-peer`: Package will appear in your `peerDependencies`.
150
151 - `-O, --save-optional`: Package will appear in your `optionalDependencies`.
152
153 - `--no-save`: Prevents saving to `dependencies`.
154
155 When using any of the above options to save dependencies to your package.json, there are two additional, optional flags:
156 - `-E, --save-exact`: Saved dependencies will be configured with an exact version rather than using npm's default semver range operator.
157
158 - `-B, --save-bundle`: Saved dependencies will also be added to your `bundleDependencies` list.
159
160 Further, if you have an `npm-shrinkwrap.json` or `package-lock.json` then it will be updated as well.
161
162 `<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).
163
164 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.
165
166 Examples:
167
168 ```bash
169 npm install sax
170 npm install githubname/reponame
171 npm install @myorg/privatepackage
172 npm install node-tap --save-dev
173 npm install dtrace-provider --save-optional
174 npm install readable-stream --save-exact
175 npm install ansi-regex --save-bundle
176 ```
177
178 - `npm install <alias>@npm:<name>`:
179
180 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).
181
182 Examples:
183
184 ```bash
185 npm install my-react@npm:react
186 npm install jquery2@npm:jquery@2
187 npm install jquery3@npm:jquery@3
188 npm install npa@npm:npm-package-arg
189 ```
190
191 - `npm install [<@scope>/]<name>@<tag>`:
192
193 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.
194
195 Example:
196
197 ```bash
198 npm install sax@latest
199 npm install @myorg/mypackage@latest
200 ```
201
202 - `npm install [<@scope>/]<name>@<version>`:
203
204 Install the specified version of the package. This will fail if the version has not been published to the registry.
205
206 Example:
207
208 ```bash
209 npm install sax@0.1.1
210 npm install @myorg/privatepackage@1.5.0
211 ```
212
213 - `npm install [<@scope>/]<name>@<version range>`:
214
215 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).
216
217 Note that most version ranges must be put in quotes so that your shell will treat it as a single argument.
218
219 Example:
220
221 ```bash
222 npm install sax@">=0.1.0 <0.2.0"
223 npm install @myorg/privatepackage@"16 - 17"
224 ```
225
226 **Prerelease versions:** By default, version ranges only match stable versions. To include prerelease versions, they must be explicitly specified in the range. Prerelease versions are tied to a specific version triple (major.minor.patch). For example, `^1.2.3-beta.1` will only match prereleases for `1.2.x`, not `1.3.x`. To match all prereleases for a major version, use a range like `^1.0.0-0`, which will include all `1.x.x` prereleases.
227
228 Example:
229
230 ```bash
231 npm install package@^1.2.3-beta.1 # Matches 1.2.3-beta.1, 1.2.3-beta.2, 1.2.4-beta.1, etc.
232 npm install package@^1.0.0-0 # Matches all 1.x.x prereleases and stable versions
233 ```
234
235 - `npm install <git remote url>`:
236
237 Installs the package from the hosted git provider, cloning it with `git`. For a full git remote url, only that URL will be attempted.
238
239 ```bash
240 <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
241 ```
242
243 `<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or `git+file`.
244
245 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.
246
247 If the repository makes use of submodules, those submodules will be cloned as well.
248
249 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.
250
251 The following git environment variables are recognized by npm and will be added to the environment when running git:
252 - `GIT_ASKPASS`
253 - `GIT_EXEC_PATH`
254 - `GIT_PROXY_COMMAND`
255 - `GIT_SSH`
256 - `GIT_SSH_COMMAND`
257 - `GIT_SSL_CAINFO`
258 - `GIT_SSL_NO_VERIFY`
259
260 See the git man page for details.
261
262 Examples:
263
264 ```bash
265 npm install git+ssh://git@github.com:npm/cli.git#v1.0.27
266 npm install git+ssh://git@github.com:npm/cli#pull/273
267 npm install git+ssh://git@github.com:npm/cli#semver:^5.0
268 npm install git+https://isaacs@github.com/npm/cli.git
269 npm install git://github.com/npm/cli.git#v1.0.27
270 GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://git@github.com:npm/cli.git
271 ```
272
273 - `npm install <githubname>/<githubrepo>[#<commit-ish>]`:
274 - `npm install github:<githubname>/<githubrepo>[#<commit-ish>]`:
275
276 Install the package at `https://github.com/githubname/githubrepo` by attempting to clone it using `git`.
277
278 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.
279
280 As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing.
281
282 Examples:
283
284 ```bash
285 npm install mygithubuser/myproject
286 npm install github:mygithubuser/myproject
287 ```
288
289 - `npm install gist:[<githubname>/]<gistID>[#<commit-ish>|#semver:<semver>]`:
290
291 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`.
292
293 As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing.
294
295 Example:
296
297 ```bash
298 npm install gist:101a11beef
299 ```
300
301 - `npm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit-ish>]`:
302
303 Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo` by attempting to clone it using `git`.
304
305 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.
306
307 As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing.
308
309 Example:
310
311 ```bash
312 npm install bitbucket:mybitbucketuser/myproject
313 ```
314
315 - `npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]`:
316
317 Install the package at `https://gitlab.com/gitlabname/gitlabrepo` by attempting to clone it using `git`.
318
319 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.
320
321 As with regular git dependencies, `dependencies` and `devDependencies` will be installed if the package has a `prepare` script before the package is done installing.
322
323 Example:
324
325 ```bash
326 npm install gitlab:mygitlabuser/myproject
327 npm install gitlab:myusr/myproj#semver:^5.0
328 ```
329
330 You may combine multiple arguments and even multiple types of arguments. For example:
331
332 ```bash
333 npm install sax@">=0.1.0 <0.2.0" bench supervisor
334 ```
335
336 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.
337
338 **Note:** The `--tag` option only affects packages specified on the command line. It does not override version ranges specified in `package.json`. For example, if `package.json` specifies `"foo": "^1.0.0"` and you run `npm install --tag beta`, npm will still install a version matching `^1.0.0` even if the `beta` tag points to a different version. To install a tagged version, specify the package explicitly: `npm install foo@beta`.
339
340 The `--dry-run` argument will report in the usual way what the install would have done without actually installing anything.
341
342 The `--package-lock-only` argument will only update the `package-lock.json`, instead of checking `node_modules` and downloading dependencies.
343
344 The `-f` or `--force` argument will force npm to fetch remote resources even if a local copy exists on disk.
345
346 ```bash
347 npm install sax --force
348 ```
349
350 ### Configuration
351
352 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.
353
354 These are some of the most common options related to installation.
355
356 #### `save`
357
358 - Default: `true` unless when using `npm update` where it defaults to `false`
359 - Type: Boolean
360
361 Save installed packages to a `package.json` file as dependencies.
362
363 When used with the `npm rm` command, removes the dependency from `package.json`.
364
365 Will also prevent writing to `package-lock.json` if set to `false`.
366
367 #### `save-exact`
368
369 - Default: false
370 - Type: Boolean
371
372 Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
373
374 #### `global`
375
376 - Default: false
377 - Type: Boolean
378
379 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.
380
381 - packages are installed into the `{prefix}/lib/node_modules` folder, instead of the current working directory.
382 - bin files are linked to `{prefix}/bin`
383 - man pages are linked to `{prefix}/share/man`
384
385 #### `install-strategy`
386
387 - Default: "hoisted"
388 - Type: "hoisted", "nested", "shallow", or "linked"
389
390 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.
391
392 #### `legacy-bundling`
393
394 - Default: false
395 - Type: Boolean
396 - DEPRECATED: This option has been deprecated in favor of `--install-strategy=nested`
397
398 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`.
399
400 #### `global-style`
401
402 - Default: false
403 - Type: Boolean
404 - DEPRECATED: This option has been deprecated in favor of `--install-strategy=shallow`
405
406 Only install direct dependencies in the top level `node_modules`, but hoist on deeper dependencies. Sets `--install-strategy=shallow`.
407
408 #### `omit`
409
410 - Default: 'dev' if the `NODE_ENV` environment variable is set to 'production'; otherwise, empty.
411 - Type: "dev", "optional", or "peer" (can be set multiple times)
412
413 Dependency types to omit from the installation tree on disk.
414
415 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.
416
417 If a package type appears in both the `--include` and `--omit` lists, then it will be included.
418
419 If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment variable will be set to `'production'` for all lifecycle scripts.
420
421 #### `include`
422
423 - Default:
424 - Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
425
426 Option that allows for defining which types of dependencies to install.
427
428 This is the inverse of `--omit=<type>`.
429
430 Dependency types specified in `--include` will not be omitted, regardless of the order in which omit/include are specified on the command-line.
431
432 #### `strict-peer-deps`
433
434 - Default: false
435 - Type: Boolean
436
437 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.
438
439 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.
440
441 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.
442
443 #### `prefer-dedupe`
444
445 - Default: false
446 - Type: Boolean
447
448 Prefer to deduplicate packages if possible, rather than choosing a newer version of a dependency.
449
450 #### `package-lock`
451
452 - Default: true
453 - Type: Boolean
454
455 If set to false, then ignore `package-lock.json` files when installing. This will also prevent _writing_ `package-lock.json` if `save` is true.
456
457 #### `package-lock-only`
458
459 - Default: false
460 - Type: Boolean
461
462 If set to true, the current operation will only use the `package-lock.json`, ignoring `node_modules`.
463
464 For `update` this means only the `package-lock.json` will be updated, instead of checking `node_modules` and downloading dependencies.
465
466 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`.
467
468 #### `foreground-scripts`
469
470 - Default: `false` unless when using `npm pack` or `npm publish` where it defaults to `true`
471 - Type: Boolean
472
473 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.
474
475 Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
476
477 #### `ignore-scripts`
478
479 - Default: false
480 - Type: Boolean
481
482 If true, npm does not run scripts specified in package.json files.
483
484 Note that commands explicitly intended to run a particular script, such as `npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run` will still run their intended script if `ignore-scripts` is set, but they will _not_ run any pre- or post-scripts.
485
486 #### `allow-directory`
487
488 - Default: "all"
489 - Type: "all", "none", or "root"
490
491 Limits the ability for npm to install dependencies from directories. That is, dependencies that point to a directory instead of a version or semver range. Please note that this could leave your tree incomplete and some packages may not function as intended or designed. Changing this setting will not remove dependencies that are already installed.
492
493 `all` allows any directories to be installed. `none` prevents any directories from being installed. `root` only allows directories defined in your project's package.json to be installed. Also allows directory dependencies to be used for other commands like `npm view`
494
495 #### `allow-file`
496
497 - Default: "all"
498 - Type: "all", "none", or "root"
499
500 Limits the ability for npm to install dependencies from tarball files. That is, dependencies that point to a local tarball file instead of a version or semver range. Please note that this could leave your tree incomplete and some packages may not function as intended or designed. Changing this setting will not remove dependencies that are already installed.
501
502 `all` allows any tarball file to be installed. `none` prevents any tarball file from being installed. `root` only allows tarball files defined in your project's package.json to be installed. Also allows tarball file dependencies to be used for other commands like `npm view`
503
504 #### `allow-git`
505
506 - Default: "all"
507 - Type: "all", "none", or "root"
508
509 Limits the ability for npm to fetch dependencies from git references. That is, dependencies that point to a git repo instead of a version or semver range. Please note that this could leave your tree incomplete and some packages may not function as intended or designed. Changing this setting will not remove dependencies that are already installed.
510
511 `all` allows any git dependencies to be fetched and installed. `none` prevents any git dependencies from being fetched and installed. `root` only allows git dependencies defined in your project's package.json to be fetched and installed. Also allows git dependencies to be fetched for other commands like `npm view`
512
513 #### `allow-remote`
514
515 - Default: "all"
516 - Type: "all", "none", or "root"
517
518 Limits the ability for npm to fetch dependencies from urls. That is, dependencies that point to a tarball url instead of a version or semver range. Please note that this could leave your tree incomplete and some packages may not function as intended or designed. Changing this setting will not remove dependencies that are already installed.
519
520 `all` allows any url to be installed. `none` prevents any url from being installed. `root` only allows urls defined in your project's package.json to be installed. Also allows url dependencies to be used for other commands like `npm view`
521
522 #### `audit`
523
524 - Default: true
525 - Type: Boolean
526
527 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.
528
529 #### `before`
530
531 - Default: null
532 - Type: null or Date
533
534 If passed to `npm install`, will rebuild the npm tree such that only versions that were available **on or before** the given date are installed. If there are no versions available for the current set of dependencies, the command will error.
535
536 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`.
537
538 If `before` and `min-release-age` are both set in the same source, `before` wins (an explicit absolute date overrides a relative window). Across sources, the standard precedence applies (cli > env > project > user > global), so a higher-priority source can always relax or override a lower-priority one.
539
540 #### `min-release-age`
541
542 - Default: null
543 - Type: null or Number
544
545 If set, npm will build the npm tree such that only versions that were available more than the given number of days ago will be installed. If there are no versions available for the current set of dependencies, the command will error.
546
547 This flag is a complement to `before`, which accepts an exact date instead of a relative number of days. The two may coexist (e.g. `min-release-age` in your `.npmrc` is preserved when npm internally spawns a sub-process with `--before` while preparing a `git:` or `github:` dependency); when both apply, `before` wins within a single source and across sources the standard precedence rules apply.
548
549 This value is not exported to the environment for child processes.
550
551 #### `bin-links`
552
553 - Default: true
554 - Type: Boolean
555
556 Tells npm to create symlinks (or `.cmd` shims on Windows) for package executables.
557
558 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.
559
560 #### `fund`
561
562 - Default: true
563 - Type: Boolean
564
565 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.
566
567 #### `dry-run`
568
569 - Default: false
570 - Type: Boolean
571
572 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`.
573
574 Note: This is NOT honored by other network related commands, eg `dist-tags`, `owner`, etc.
575
576 #### `cpu`
577
578 - Default: null
579 - Type: null or String
580
581 Override CPU architecture of native modules to install. Acceptable values are same as `cpu` field of package.json, which comes from `process.arch`.
582
583 #### `os`
584
585 - Default: null
586 - Type: null or String
587
588 Override OS of native modules to install. Acceptable values are same as `os` field of package.json, which comes from `process.platform`.
589
590 #### `libc`
591
592 - Default: null
593 - Type: null or String
594
595 Override libc of native modules to install. Acceptable values are same as `libc` field of package.json
596
597 #### `workspace`
598
599 - Default:
600 - Type: String (can be set multiple times)
601
602 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.
603
604 Valid values for the `workspace` config are either:
605
606 - Workspace names
607 - Path to a workspace directory
608 - Path to a parent workspace directory (will result in selecting all workspaces within that folder)
609
610 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.
611
612 This value is not exported to the environment for child processes.
613
614 #### `workspaces`
615
616 - Default: null
617 - Type: null or Boolean
618
619 Set to true to run the command in the context of **all** configured workspaces.
620
621 Explicitly setting this to false will cause commands like `install` to ignore workspaces altogether. When not set explicitly:
622
623 - 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.
624
625 This value is not exported to the environment for child processes.
626
627 #### `include-workspace-root`
628
629 - Default: false
630 - Type: Boolean
631
632 Include the workspace root when workspaces are enabled for a command.
633
634 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.
635
636 This value is not exported to the environment for child processes.
637
638 #### `install-links`
639
640 - Default: false
641 - Type: Boolean
642
643 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.
644
645 ### Algorithm
646
647 Given a `package{dep}` structure: `A{B,C}, B{C}, C{D}`, the npm install algorithm produces:
648
649 ```bash
650 A
651 +-- B
652 +-- C
653 +-- D
654 ```
655
656 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.
657
658 For `A{B,C}, B{C,D@1}, C{D@2}`, this algorithm produces:
659
660 ```bash
661 A
662 +-- B
663 +-- C
664 `-- D@2
665 +-- D@1
666 ```
667
668 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.
669
670 See [folders](/cli/v11/configuring-npm/folders) for a more detailed description of the specific folder structures that npm creates.
671
672 ### See Also
673
674 - [npm folders](/cli/v11/configuring-npm/folders)
675 - [npm update](/cli/v11/commands/npm-update)
676 - [npm audit](/cli/v11/commands/npm-audit)
677 - [npm fund](/cli/v11/commands/npm-fund)
678 - [npm link](/cli/v11/commands/npm-link)
679 - [npm rebuild](/cli/v11/commands/npm-rebuild)
680 - [npm scripts](/cli/v11/using-npm/scripts)
681 - [npm config](/cli/v11/commands/npm-config)
682 - [npmrc](/cli/v11/configuring-npm/npmrc)
683 - [npm registry](/cli/v11/using-npm/registry)
684 - [npm dist-tag](/cli/v11/commands/npm-dist-tag)
685 - [npm uninstall](/cli/v11/commands/npm-uninstall)
686 - [npm shrinkwrap](/cli/v11/commands/npm-shrinkwrap)
687 - [package.json](/cli/v11/configuring-npm/package-json)
688 - [workspaces](/cli/v11/using-npm/workspaces)