“This is the 11th day of my participation in the Gwen Challenge in November. See details: The Last Gwen Challenge in 2021”

At first glance, NPM CI, CI, well, that’s a good name for continuous integration. In fact, it is faster, more rigorous, and better suited to CI. Why this is said will be explained separately below.

NPM CI is based on a separate installation dependency called libcipm, which has an API compatible with NPM Install. When it installs dependencies, the default is cache first, and it takes full advantage of the cache to speed up package loading.

See the differences between NPM CI and NPM I directly from the official documentation

In short, 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.

I will make appropriate extensions based on the official documentation

Package-lock. json must exist

Package-lock. json must be present at NPM CI, otherwise an error will be reported and further execution of CI pipeline will be blocked.

Package-lock. json is used to lock the version number of the package to avoid build errors or runtime errors caused by the version in the production environment, which is also useful for front-end engineering. Package-lock. json must exist when NPM CI and avoids this problem, which improves the security of the project.

Package. json does not match package-lock.json

You might wonder why they don’t match. This is certainly not the case under normal circumstances.

  1. Manual changes package.jsonThe version number of a package in
  2. There is noOnce again,npm install
  3. git pushTriggered the CI

In my work experience, I have encountered an incident where the version number in package.json was manually overwritten but not synchronized to package-lock.json.

Using NPM CI will guarantee its security, but if the two do not match, an exception will be thrown. There are two lessons here

  1. Do not manually override the version number
  2. Used in CInpm ciEnsure safety

Automatically deletes node_modules

When NPM CI, if node_modules exists, it is automatically removed to ensure a clean node_modules environment and avoid the side effects of legacy libraries.

But because CI tends to be stateless: when a build is triggered, the code is pulled in a temporary directory, and node_modules won’t exist.

Cannot be packed separately

This one is easy to explain because it is suitable for continuous integration environments and cannot be packaged separately, such as loDash.