Using "npm ci" instead of "npm install" for deterministic project setup

3.8k views Asked by At

Given a project where the package-lock.json is managed in source control with the goal that all developers on the team get exactly the same dependencies.

From the documentation of npm I think developers should use npm ci to set up their development environment and probably also later when dependencies are updated.

However the instructions I see in typical npm projects is still to use npm install.

Is there a reason developers should use npm install instead of npm ci? Does npm ci have disadvantages in this scenario?

I understand that npm ci does delete the whole node_modules and therefore potentially re-download some dependencies that were already present.

But with npm install I had regularly the case that an npm install is actually changing the package-lock.json (see links below), which is definitely not what is expected in a traditional project setup, where the main goal is that all developers get the same environment.
Therefore I would like to recommend to use npm ci.

Examples of "unexpected" behavior of npm install:

2

There are 2 answers

0
Ictus On

You should use npm ci (clean install) whenever you want a reproducible environment. You are right: the dev team should use it most of the time.

Use npm install only when they modify the packages or are ready to upgrade dependencies (one of them does it and fixes conflicts; after the commit of package.json AND package-lock.json, the others keep doing npm ci).

Please, see my answer explaining the uses of each tool.

1
Andrew On

There isn't a reason to use npm ci instead of npm i when building a repo locally or updating dependencies (because it uses the npm cache, it's roughly the same speed as npm i), but there are the following situations where npm i might be preferred:

  1. You actually want to receive minor/patch updates of your direct dependencies automatically;
  2. if you've made manual changes to versions in package.json and want them to trump the versions in package-lock.json.