Closed DanielRuf closed 5 years ago
Thank you very much for the PR!
I do believe, though, that using npm ci
is actually correct behavior, according to NPM documentation:
This command is similar to npm-install, except it’s meant to be used in automated environments such as test platforms, continuous integration, and deployment...
It depends. It does not reflect the behavior of the users / consumers and the deptree is different as lockfiles are not used on this level.
Ok, thanks for elaborating. I do personally see that using npm ci
does have some tangible benefits!
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.
According to the docs, using the CI command does prevent incorrect dependencies from being installed and also will error when the lockfile doesn't line up with dependencies specified in package.json
.
Sure but ci
is never used in production (users). It's mainly for apps like lockfiles are for apps, not libraries ;-)
By default Travis CI used
npm ci
if it finds a lockfile starting with newer Node.js versions. But this does not reflect what is happening on the consumer side (npmjs and npm / yarn users) as the lockfiles are not used there and have no effect.