Don't run `npm install` on your build machine. Use `npm ci` instead.

@iKameo `npm install` will update your `package-lock.json` making the package-lock.json borderline useless. `npm ci` will never ever modify the `package-lock.json`. It will deem it frozen. It will even require its existence!

When running on a CI I always want a very specific known-to-work state so that my build is not broken by a random dependency update.

I also want errors when my `package.json` and `package-lock.json` are out of sync.

Bonus: It's faster than `npm install`.

@k0pernikus could you enlighten us mortals of why they've created the package-lock.json? It just seemed to be useless until now that you explained npm ci. Basically it ensures the deps versions are the same across environments, but isn't that the purpose of package.json?

@lucaspar in the package.json you can say for example any version compatible with version x.y.z, or any minor version of version x.y.

That way you also get patches without changing code.

@Codex404 @lucaspar It's worse than that. Even if you require a dependency at a min version level, e.g fnord@2.3.1 in the package.json, npm install will resolve its dependencies differently on different runs when those are updated.

A lock file also freezes your dependency's dependencies and ensures it will always be the same.

I want reliable repeatable builds and don't want sub-dependency to break my build.

A lock file is a concept that's been supported by a lot of package manager tools (composer, pip, etc) and npm was rather late to the party, only having the half-baked shrinkwrap feature, and only with npm@5 they default to package-lock.json.

That package-lock.json should be part of your VCS ensuring you'll get what you expect.

Yarn had a