Initial Functional Structure Scaffold
This commit is contained in:
318
NodeJS/node_modules/npm/docs/content/commands/npm-ci.md
generated
vendored
Normal file
318
NodeJS/node_modules/npm/docs/content/commands/npm-ci.md
generated
vendored
Normal file
@ -0,0 +1,318 @@
|
||||
---
|
||||
title: npm-ci
|
||||
section: 1
|
||||
description: Clean install a project
|
||||
---
|
||||
|
||||
### Synopsis
|
||||
|
||||
```bash
|
||||
npm ci
|
||||
|
||||
aliases: clean-install, ic, install-clean, isntall-clean
|
||||
```
|
||||
|
||||
### Description
|
||||
|
||||
This command is similar to [`npm install`](/commands/npm-install), except
|
||||
it's meant to be used in automated environments such as test platforms,
|
||||
continuous integration, and deployment -- or any situation where you want
|
||||
to make sure you're doing a clean install of your dependencies.
|
||||
|
||||
The main differences between using `npm install` and `npm ci` are:
|
||||
|
||||
* The project **must** have an existing `package-lock.json` or
|
||||
`npm-shrinkwrap.json`.
|
||||
* If dependencies in the package lock do not match those in `package.json`,
|
||||
`npm ci` will exit with an error, instead of updating the package lock.
|
||||
* `npm ci` can only install entire projects at a time: individual
|
||||
dependencies cannot be added with this command.
|
||||
* If a `node_modules` is already present, it will be automatically removed
|
||||
before `npm ci` begins its install.
|
||||
* It will never write to `package.json` or any of the package-locks:
|
||||
installs are essentially frozen.
|
||||
|
||||
NOTE: If you create your `package-lock.json` file by running `npm install`
|
||||
with flags that can affect the shape of your dependency tree, such as
|
||||
`--legacy-peer-deps` or `--install-links`, you _must_ provide the same
|
||||
flags to `npm ci` or you are likely to encounter errors. An easy way to do
|
||||
this is to run, for example,
|
||||
`npm config set legacy-peer-deps=true --location=project` and commit the
|
||||
`.npmrc` file to your repo.
|
||||
|
||||
### Example
|
||||
|
||||
Make sure you have a package-lock and an up-to-date install:
|
||||
|
||||
```bash
|
||||
$ cd ./my/npm/project
|
||||
$ npm install
|
||||
added 154 packages in 10s
|
||||
$ ls | grep package-lock
|
||||
```
|
||||
|
||||
Run `npm ci` in that project
|
||||
|
||||
```bash
|
||||
$ npm ci
|
||||
added 154 packages in 5s
|
||||
```
|
||||
|
||||
Configure Travis CI to build using `npm ci` instead of `npm install`:
|
||||
|
||||
```bash
|
||||
# .travis.yml
|
||||
install:
|
||||
- npm ci
|
||||
# keep the npm cache around to speed up installs
|
||||
cache:
|
||||
directories:
|
||||
- "$HOME/.npm"
|
||||
```
|
||||
|
||||
### Configuration
|
||||
|
||||
#### `install-strategy`
|
||||
|
||||
* Default: "hoisted"
|
||||
* Type: "hoisted", "nested", "shallow", or "linked"
|
||||
|
||||
Sets the strategy for installing packages in node_modules. hoisted
|
||||
(default): Install non-duplicated in top-level, and duplicated as necessary
|
||||
within directory structure. nested: (formerly --legacy-bundling) install in
|
||||
place, no hoisting. shallow (formerly --global-style) only install direct
|
||||
deps at top-level. linked: (experimental) install in node_modules/.store,
|
||||
link in place, unhoisted.
|
||||
|
||||
|
||||
|
||||
#### `legacy-bundling`
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
* DEPRECATED: This option has been deprecated in favor of
|
||||
`--install-strategy=nested`
|
||||
|
||||
Instead of hoisting package installs in `node_modules`, install packages in
|
||||
the same manner that they are depended on. This may cause very deep
|
||||
directory structures and duplicate package installs as there is no
|
||||
de-duplicating. Sets `--install-strategy=nested`.
|
||||
|
||||
|
||||
|
||||
#### `global-style`
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
* DEPRECATED: This option has been deprecated in favor of
|
||||
`--install-strategy=shallow`
|
||||
|
||||
Only install direct dependencies in the top level `node_modules`, but hoist
|
||||
on deeper dependencies. Sets `--install-strategy=shallow`.
|
||||
|
||||
|
||||
|
||||
#### `omit`
|
||||
|
||||
* Default: 'dev' if the `NODE_ENV` environment variable is set to
|
||||
'production', otherwise empty.
|
||||
* Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
|
||||
Note that these dependencies _are_ still resolved and added to the
|
||||
`package-lock.json` or `npm-shrinkwrap.json` file. They are just not
|
||||
physically installed on disk.
|
||||
|
||||
If a package type appears in both the `--include` and `--omit` lists, then
|
||||
it will be included.
|
||||
|
||||
If the resulting omit list includes `'dev'`, then the `NODE_ENV` environment
|
||||
variable will be set to `'production'` for all lifecycle scripts.
|
||||
|
||||
|
||||
|
||||
#### `include`
|
||||
|
||||
* Default:
|
||||
* Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
|
||||
This is the inverse of `--omit=<type>`.
|
||||
|
||||
Dependency types specified in `--include` will not be omitted, regardless of
|
||||
the order in which omit/include are specified on the command-line.
|
||||
|
||||
|
||||
|
||||
#### `strict-peer-deps`
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
If set to `true`, and `--legacy-peer-deps` is not set, then _any_
|
||||
conflicting `peerDependencies` will be treated as an install failure, even
|
||||
if npm could reasonably guess the appropriate resolution based on non-peer
|
||||
dependency relationships.
|
||||
|
||||
By default, conflicting `peerDependencies` deep in the dependency graph will
|
||||
be resolved using the nearest non-peer dependency specification, even if
|
||||
doing so will result in some packages receiving a peer dependency outside
|
||||
the range set in their package's `peerDependencies` object.
|
||||
|
||||
When such an override is performed, a warning is printed, explaining the
|
||||
conflict and the packages involved. If `--strict-peer-deps` is set, then
|
||||
this warning is treated as a failure.
|
||||
|
||||
|
||||
|
||||
#### `foreground-scripts`
|
||||
|
||||
* Default: `false` unless when using `npm pack` or `npm publish` where it
|
||||
defaults to `true`
|
||||
* Type: Boolean
|
||||
|
||||
Run all build scripts (ie, `preinstall`, `install`, and `postinstall`)
|
||||
scripts for installed packages in the foreground process, sharing standard
|
||||
input, output, and error with the main npm process.
|
||||
|
||||
Note that this will generally make installs run slower, and be much noisier,
|
||||
but can be useful for debugging.
|
||||
|
||||
|
||||
|
||||
#### `ignore-scripts`
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
|
||||
Note that commands explicitly intended to run a particular script, such as
|
||||
`npm start`, `npm stop`, `npm restart`, `npm test`, and `npm run-script`
|
||||
will still run their intended script if `ignore-scripts` is set, but they
|
||||
will *not* run any pre- or post-scripts.
|
||||
|
||||
|
||||
|
||||
#### `audit`
|
||||
|
||||
* Default: true
|
||||
* Type: Boolean
|
||||
|
||||
When "true" submit audit reports alongside the current npm command to the
|
||||
default registry and all registries configured for scopes. See the
|
||||
documentation for [`npm audit`](/commands/npm-audit) for details on what is
|
||||
submitted.
|
||||
|
||||
|
||||
|
||||
#### `bin-links`
|
||||
|
||||
* Default: true
|
||||
* Type: Boolean
|
||||
|
||||
Tells npm to create symlinks (or `.cmd` shims on Windows) for package
|
||||
executables.
|
||||
|
||||
Set to false to have it not do this. This can be used to work around the
|
||||
fact that some file systems don't support symlinks, even on ostensibly Unix
|
||||
systems.
|
||||
|
||||
|
||||
|
||||
#### `fund`
|
||||
|
||||
* Default: true
|
||||
* Type: Boolean
|
||||
|
||||
When "true" displays the message at the end of each `npm install`
|
||||
acknowledging the number of dependencies looking for funding. See [`npm
|
||||
fund`](/commands/npm-fund) for details.
|
||||
|
||||
|
||||
|
||||
#### `dry-run`
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Indicates that you don't want npm to make any changes and that it should
|
||||
only report what it would have done. This can be passed into any of the
|
||||
commands that modify your local installation, eg, `install`, `update`,
|
||||
`dedupe`, `uninstall`, as well as `pack` and `publish`.
|
||||
|
||||
Note: This is NOT honored by other network related commands, eg `dist-tags`,
|
||||
`owner`, etc.
|
||||
|
||||
|
||||
|
||||
#### `workspace`
|
||||
|
||||
* Default:
|
||||
* Type: String (can be set multiple times)
|
||||
|
||||
Enable running a command in the context of the configured workspaces of the
|
||||
current project while filtering by running only the workspaces defined by
|
||||
this configuration option.
|
||||
|
||||
Valid values for the `workspace` config are either:
|
||||
|
||||
* Workspace names
|
||||
* Path to a workspace directory
|
||||
* Path to a parent workspace directory (will result in selecting all
|
||||
workspaces within that folder)
|
||||
|
||||
When set for the `npm init` command, this may be set to the folder of a
|
||||
workspace which does not yet exist, to create the folder and set it up as a
|
||||
brand new workspace within the project.
|
||||
|
||||
This value is not exported to the environment for child processes.
|
||||
|
||||
#### `workspaces`
|
||||
|
||||
* Default: null
|
||||
* Type: null or Boolean
|
||||
|
||||
Set to true to run the command in the context of **all** configured
|
||||
workspaces.
|
||||
|
||||
Explicitly setting this to false will cause commands like `install` to
|
||||
ignore workspaces altogether. When not set explicitly:
|
||||
|
||||
- Commands that operate on the `node_modules` tree (install, update, etc.)
|
||||
will link workspaces into the `node_modules` folder. - Commands that do
|
||||
other things (test, exec, publish, etc.) will operate on the root project,
|
||||
_unless_ one or more workspaces are specified in the `workspace` config.
|
||||
|
||||
This value is not exported to the environment for child processes.
|
||||
|
||||
#### `include-workspace-root`
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
|
||||
When false, specifying individual workspaces via the `workspace` config, or
|
||||
all workspaces via the `workspaces` flag, will cause npm to operate only on
|
||||
the specified workspaces, and not on the root project.
|
||||
|
||||
This value is not exported to the environment for child processes.
|
||||
|
||||
#### `install-links`
|
||||
|
||||
* Default: false
|
||||
* Type: Boolean
|
||||
|
||||
When set file: protocol dependencies will be packed and installed as regular
|
||||
dependencies instead of creating a symlink. This option has no effect on
|
||||
workspaces.
|
||||
|
||||
|
||||
|
||||
### See Also
|
||||
|
||||
* [npm install](/commands/npm-install)
|
||||
* [package-lock.json](/configuring-npm/package-lock-json)
|
||||
Reference in New Issue
Block a user