4 ms·

This is not my experience with how most people specify their dependencies (and the tools use by default) If you have `^1.0.0` in package.json, the version mark

This is not my experience with how most people specify their dependencies (and the tools use by default) If you have `^1.0.0` in package.json, the version mark is `^1.0.11` in the lock file, which means that a random `npm i` or `yarn install` will install `^1.0.12` in your lock file. I more or less said this yesterday[1], but the behaviour of `yarn install --frozen-lockfile` and `npm ci` should be the _default_ behaviour. The current behaviour is demonstrably dangerous. A lockfile should remain locked without explicit action by developers. [1]: https://news.ycombinator.com/item?id=29869859 https://news.ycombinator.com/item?id=29869859

danenania 5y ago
"If you have `^1.0.0` in package.json, the version mark is `^1.0.11` in the lock file, which means that a random `npm i` or `yarn install` will install `^1.0.12` in your lock file." That's not true. package-lock.json file dependencies are specified as exact versions, not ranges. If you have 1.0.11 in your lock file, npm install will always install 1.0.11 unless it no longer satisfies the version in package.json.
- oauea 5y ago
  You're mixing up npm ci and npm install. npm install will update your lockfile. See the docs: https://docs.npmjs.com/cli/v6/configuring-npm/package-locks https://docs.npmjs.com/cli/v6/configuring-npm/package-locks
  - danenania 5y ago
    Where are you seeing that? From your link: “The presence of a package lock changes the installation behavior such that: The module tree described by the package lock is reproduced. This means reproducing the structure described in the file, using the specific files referenced in "resolved" if available, falling back to normal package resolution using "version" if one isn't. The tree is walked and any missing dependencies are installed in the usual fashion.”
- halostatue 5y ago
  The scenario is a _little_ more complicated than I laid out, but I have seen this in practice. I _believe_ that it will happen when you have two copies of a repo and one of the copies does not have one of the dependencies. If user A (repo copy 1) adds a package with `^1.0.0` but the lockfile indicates `^1.0.11`, then user B (repo copy 2) will get `^1.0.12`. The _only_ correct behaviour for a lockfile is `=1.0.11` (I think that npm calls that `1.0.11`, but NPM’s semver specification is unnecessarily complex compared to Elixir or Ruby) unless there is an explicit update. Otherwise, you will _not_ get the same version installed for all developers.
  - danenania 5y ago
    "If user A (repo copy 1) adds a package with `^1.0.0` but the lockfile indicates `^1.0.11`" NPM lockfiles can't indicate `^1.0.11` so I believe this is where you're mistaken. They point to a specific version (`=1.0.11`) just like you're saying they should.

danenania 5y ago

"If you have `^1.0.0` in package.json, the version mark is `^1.0.11` in the lock file, which means that a random `npm i` or `yarn install` will install `^1.0.12` in your lock file." That's not true. package-lock.json file dependencies are specified as exact versions, not ranges. If you have 1.0.11 in your lock file, npm install will always install 1.0.11 unless it no longer satisfies the version in package.json.

oauea 5y ago
You're mixing up npm ci and npm install. npm install will update your lockfile. See the docs: https://docs.npmjs.com/cli/v6/configuring-npm/package-locks https://docs.npmjs.com/cli/v6/configuring-npm/package-locks
- danenania 5y ago
  Where are you seeing that? From your link: “The presence of a package lock changes the installation behavior such that: The module tree described by the package lock is reproduced. This means reproducing the structure described in the file, using the specific files referenced in "resolved" if available, falling back to normal package resolution using "version" if one isn't. The tree is walked and any missing dependencies are installed in the usual fashion.”
halostatue 5y ago
The scenario is a _little_ more complicated than I laid out, but I have seen this in practice. I _believe_ that it will happen when you have two copies of a repo and one of the copies does not have one of the dependencies. If user A (repo copy 1) adds a package with `^1.0.0` but the lockfile indicates `^1.0.11`, then user B (repo copy 2) will get `^1.0.12`. The _only_ correct behaviour for a lockfile is `=1.0.11` (I think that npm calls that `1.0.11`, but NPM’s semver specification is unnecessarily complex compared to Elixir or Ruby) unless there is an explicit update. Otherwise, you will _not_ get the same version installed for all developers.
- danenania 5y ago
  "If user A (repo copy 1) adds a package with `^1.0.0` but the lockfile indicates `^1.0.11`" NPM lockfiles can't indicate `^1.0.11` so I believe this is where you're mistaken. They point to a specific version (`=1.0.11`) just like you're saying they should.