3 ms·

> But NPM has gotten much better (it uses lock files by default now for example) Last time I checked, "npm install" will still overwrite your lock file, you ha

> But NPM has gotten much better (it uses lock files by default now for example) Last time I checked, "npm install" will still overwrite your lock file, you have to explicitly use "npm ci" for that not to happen. Or maybe that changed recently?

nicoburns 4y ago
Looks like that's still the case. It does still use lockfiles, it just updates them by default. There is also as you mention a built-in command that does the right thing.
- Tainnor 4y ago
  Right, it's just one of these things that inexperienced people (or people coming from other languages) would get wrong, so no idea why they have this behaviour.
MrJohz 4y ago
It depends on the context. * If the package.json file can be satisfied by the lock file (i.e. if the two files match) then the lock file will be used unchanged, even if there are newer versions available. This is (mostly) identical to the `npm ci` command. * If the package.json requires more recent versions of a particular package than are available in the lock file then this package will be updated (but other packages will remain the same) and a new lock file will be written. This happens if, for example, the package.json file has been changed by hand, and so the lock file is no longer in date. In contrast, the `npm ci` command exits and fails to install the dependencies. * Similarly, if the package.json file has new dependencies that aren't in the lock file, it if dependencies exist in the lock file that are no longer present in package.json, then these packages will be installed or deleted and the lock file updated. Theoretically, only the relevant dependency and its dependencies will be affected, but because if the deduping algorithm, NPM may make other changes if it thinks it can simplify the dependency tree. Again, in this situation, `npm ci` will just fail. There is one other minor exception. The `npm ci` command will never make any changes to the lock file, but `npm install` may still choose to update the lock file with additional metadata (for example if the lock file was created with an older version of npm). This will never change the versions, but it may look a bit messy in the commit history, particularly if different people on a team are using different versions of npm. As a result, I tend to use npm ci as my default anyway. However, as a role of thumb, if `npm ci` is able to successfully install dependencies, then running `npm install` will always install the same dependencies. The only difference is when the package.json file disagrees with the lock file, in which case `npm install` will probably do what you want, unless you want some very specific results in which case you still have the npm ci command available. (This has been true since at least npm v5, although I think there were some bugs in the initial implementation.)
ss108 4y ago
Why wouldn't one wish to update the lock file by default?
- Tainnor 4y ago
  Because you want reproducible builds. Updating dependencies should be an explicit operation, distinct from installing from a known state.

nicoburns 4y ago

Looks like that's still the case. It does still use lockfiles, it just updates them by default. There is also as you mention a built-in command that does the right thing.

Tainnor 4y ago
Right, it's just one of these things that inexperienced people (or people coming from other languages) would get wrong, so no idea why they have this behaviour.

MrJohz 4y ago

It depends on the context. * If the package.json file can be satisfied by the lock file (i.e. if the two files match) then the lock file will be used unchanged, even if there are newer versions available. This is (mostly) identical to the `npm ci` command. * If the package.json requires more recent versions of a particular package than are available in the lock file then this package will be updated (but other packages will remain the same) and a new lock file will be written. This happens if, for example, the package.json file has been changed by hand, and so the lock file is no longer in date. In contrast, the `npm ci` command exits and fails to install the dependencies. * Similarly, if the package.json file has new dependencies that aren't in the lock file, it if dependencies exist in the lock file that are no longer present in package.json, then these packages will be installed or deleted and the lock file updated. Theoretically, only the relevant dependency and its dependencies will be affected, but because if the deduping algorithm, NPM may make other changes if it thinks it can simplify the dependency tree. Again, in this situation, `npm ci` will just fail. There is one other minor exception. The `npm ci` command will never make any changes to the lock file, but `npm install` may still choose to update the lock file with additional metadata (for example if the lock file was created with an older version of npm). This will never change the versions, but it may look a bit messy in the commit history, particularly if different people on a team are using different versions of npm. As a result, I tend to use npm ci as my default anyway. However, as a role of thumb, if `npm ci` is able to successfully install dependencies, then running `npm install` will always install the same dependencies. The only difference is when the package.json file disagrees with the lock file, in which case `npm install` will probably do what you want, unless you want some very specific results in which case you still have the npm ci command available. (This has been true since at least npm v5, although I think there were some bugs in the initial implementation.)

ss108 4y ago

Why wouldn't one wish to update the lock file by default?

Tainnor 4y ago
Because you want reproducible builds. Updating dependencies should be an explicit operation, distinct from installing from a known state.