[alessioalex]

Shouldn’t you use fixed versions and use something like ‘npm ci’ to install the exact dependency tree?

Feels more like an oversight from the developers rather than a JavaScript problem.

When you want to upgrade, only then do you run all regression tests and do so.

[zaSmilingIdiot]

I agree with this. But dont just use `npm ci`on prod builds since that would typically include all the dev dependencies as well in your production builds, which is not usually desirable. It might be possible to add the `--only=production` flag to npm ci? But otherwise, as pointed out, pinned versions are needed for all dependencies.

[rezonant]

"npm ci" omits dev dependencies by default.

However, "npm install" also adheres to your package-lock.json, and does not update things on you.

npm ci is just npm install with a few tweaks that make it better to use for CI and builds, see here: https://docs.npmjs.com/cli/v8/commands/npm-ci

[fendy3002]

Last time I know during node 16, npm install updates your package-lock.json, but for patch version number (unsure about minor version) only and if the package.json is using relative version number. Definitely use npm ci or yarn if you want to adhere to lock files.

[rezonant]

> if the package.json is using relative version number

What do you mean by this? You can specify dependency versions using "^" which means "I accept new minor and patch versions" or "~" which says "I accept new patch versions", or a bare version to say I want an exact version; but none of those have anything to do with a bare "npm install" command. They are relevant when you install a new package, with "npm install <package>". That is a totally different operation, and it absolutely can update versions when needed.

However, when you just do "npm install" it does not update your package-lock.json to the latest version that matches your semver requirements in package.json. That will only happen if you install a new package that needs it or you use `npm update` or some other command.

This is easy to test but it's also intuitively correct- you don't expect to run `npm install` and have an uncommitted change to `package-lock.json` appear, and that does not happen in normal usage.

It is kind of unfortunate that "npm install" and "npm install <package>" use the same verb of "install" for two different things- other package managers don't make this mistake and it avoids the sort of misconception we're running into here.

[fendy3002]

Exactly what I said, I have experience with ~ but not with ^ and have never used it. Let's say that you have a package version ~1.2.11 and have 1.2.11 as installed version in package lock. Then if let's say 1.2.13 is out there, npm install will update package lock to that one. npm ci won't change that. package.json file will kept unchanged though.

[rezonant]

No, "npm install" doesn't actually do that. In the situation you are talking about, "npm install" and "npm ci" behave the same.

It makes sense that they behave the same here right? What is the point of a package lock if just installing packages on a new copy of a codebase updates the dependencies?

Package locks aren't just about deploying: As a developer, I need to be assured that the code I'm running is the same as my coworker.

[MrJohz]

That flag exists (or an equivalent, I forget what the exact syntax is).