4 ms·

I'm a little confused on one of the excerpts from your article. > Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest

I'm a little confused on one of the excerpts from your article. > Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3 As far as I've always understood, the lockfile always specifies one single, locked version for each dependency, and even provides the URL to the tarball of that version. You can define "x version or newer" in the package.json file, but if it updates to a new patch version it's updating the lockfile with it. The npm docs suggest this is the case as well: https://arc.net/l/quote/cdigautx https://arc.net/l/quote/cdigautx And with that, packages usually shouldn't be getting updated in your CI pipeline. Am I mistaken on how npm(/yarn/pnpm) lockfiles work?

sigotirandolas 1y ago
Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`. In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.
- DDerTyp 1y ago
  TIL: I need to fix my CI pipeline. Gonna create a jira ticket I guess… Thank you!
  - josefbud 1y ago
    Sorry, I had assumed this was what you were doing when I wrote my question but I should have specified. And sorry for now making your npm install step twice as long! ;)
    - rimunroe 1y ago
      npm ci should be much faster in CI as it can install the exact dependency versions directly from the lockfile rather than having to go through the whole dependency resolution algorithm. In CI environments you don't have to wait to delete a potentially large pre-existing node_modules directory since you should be starting fresh each time anyway.
      - josefbud 1y ago
        I've seen pipelines that cache node modules between runs to save time, but yeah if they're not doing that then you're totally right.
        thunderfork 1y ago
        [dead]
- 0cf8612b2e1e 1y ago
  Not a web guy, but that seems a bonkers default. I would have naively assumed a lockfile would be used unless explicitly ignored.
  - metafunctor 1y ago
    Welcome to the web side. Everything’s bonkers. Hard-earned software engineering truths get tossed out, because hey, wtf, I’ll just do some stuff and yippee. Feels like everyone’s stuck at year three of software engineering, and every three years the people get swapped out.
    - jiggawatts 1y ago
      > every three years the people get swapped out That's because they are being "replaced", in a sense! When an industry doubles every 5 years like web dev was for a long time, that by the mathematical definition means that the average developer has 5 years or less experience. Sure, the old guard eventually get to 10 or 15 years of experience, but they're simply outnumbered by an exponentially growing influx of total neophytes. Hence the childish attitude and behaviour with everything to do with JavaScript.
      - metafunctor 1y ago
        Good point! The web is going through its own endless September. And so, it seems, is everything else. Perhaps, this commentary adds no value — just old man yells at cloud stuff.
    - anonymars 1y ago
      The web saw "worse is better" and said "hold my beer"
  - Already__Taken 1y ago
    We didn't get locking until npm v5 (some memory and googling, could be wrong.) And it took a long time to do everything you'd think you want. Changing the main command `npm install` after 7 years isn't really "stable". Anyway didn't this replace versions, so locking won't have helped either?
- josefbud 1y ago
  Yeah, I think I had made the assumption that they were using `npm ci` / `yarn install --frozen-lockfile` / `pnpm install --frozen-lockfile` in CI because that's technically what you're always supposed to do in CI, but I shouldn't have made that assumption.
DDerTyp 1y ago
You’re right and the excerpt you quoted was poorly worded and confusing. A lockfile is designed to do exactly what you said. The package.json locked the file to ^1.3.2. If a newer version exists online that still satisfies the range in package.json (like 1.3.3 for ^1.3.2), npm install will often fetch that newer version and update your package-lock.json file automatically. That’s how I understand it / that’s my current knowledge. Maybe there is someone here who can confirm/deny that. That would be great!
- typpilol 1y ago
  You're correct
Mattwmaster58 1y ago
As others have noted, npm install can/will change your lockfile as it installs, and one caveat for the clean-install command they provide is that it is SLOW, since it deletes the entire node_modules directory. Lots of people have complained but they have done nothing: https://github.com/npm/cli/issues/564 https://github.com/npm/cli/issues/564 The npm team eventually seemed to settle on requiring someone to bring an RFC for this improvment, and the RFC someone did create I think has sat neglected in a corner ever since.
- saghm 1y ago
  Is there no flag to opt out of this behavior? For Rust, Cargo commands will also do this by default, but they also have `--offline` for not checking online for new versions, `--locked` to require sticking with the exact version of the lockfile even when allowing downloading dependencies online (e.g. if you're building on a machine that's never downloaded dependencies before, so they aren't cached locally, but you still don't want to allow implicit updates), and `--frozen` (which is a shorthand for both `--locked` and `--offline`). I'm honestly on the fence about whether this is even sufficient, since I've worked at multiple places where the CI didn't actually run with `--locked` because whoever configured it didn't realize, and at least once a surprise update to the lockfile in CI ended up causing an issue that took a bit of time to debug before someone realized what was going on.

sigotirandolas 1y ago

Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`. In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.

DDerTyp 1y ago
TIL: I need to fix my CI pipeline. Gonna create a jira ticket I guess… Thank you!
- josefbud 1y ago
  Sorry, I had assumed this was what you were doing when I wrote my question but I should have specified. And sorry for now making your npm install step twice as long! ;)
  - rimunroe 1y ago
    npm ci should be much faster in CI as it can install the exact dependency versions directly from the lockfile rather than having to go through the whole dependency resolution algorithm. In CI environments you don't have to wait to delete a potentially large pre-existing node_modules directory since you should be starting fresh each time anyway.
    - josefbud 1y ago
      I've seen pipelines that cache node modules between runs to save time, but yeah if they're not doing that then you're totally right.
      - thunderfork 1y ago
        [dead]
0cf8612b2e1e 1y ago
Not a web guy, but that seems a bonkers default. I would have naively assumed a lockfile would be used unless explicitly ignored.
- metafunctor 1y ago
  Welcome to the web side. Everything’s bonkers. Hard-earned software engineering truths get tossed out, because hey, wtf, I’ll just do some stuff and yippee. Feels like everyone’s stuck at year three of software engineering, and every three years the people get swapped out.
  - jiggawatts 1y ago
    > every three years the people get swapped out That's because they are being "replaced", in a sense! When an industry doubles every 5 years like web dev was for a long time, that by the mathematical definition means that the average developer has 5 years or less experience. Sure, the old guard eventually get to 10 or 15 years of experience, but they're simply outnumbered by an exponentially growing influx of total neophytes. Hence the childish attitude and behaviour with everything to do with JavaScript.
    - metafunctor 1y ago
      Good point! The web is going through its own endless September. And so, it seems, is everything else. Perhaps, this commentary adds no value — just old man yells at cloud stuff.
  - anonymars 1y ago
    The web saw "worse is better" and said "hold my beer"
- Already__Taken 1y ago
  We didn't get locking until npm v5 (some memory and googling, could be wrong.) And it took a long time to do everything you'd think you want. Changing the main command `npm install` after 7 years isn't really "stable". Anyway didn't this replace versions, so locking won't have helped either?
josefbud 1y ago
Yeah, I think I had made the assumption that they were using `npm ci` / `yarn install --frozen-lockfile` / `pnpm install --frozen-lockfile` in CI because that's technically what you're always supposed to do in CI, but I shouldn't have made that assumption.

DDerTyp 1y ago

You’re right and the excerpt you quoted was poorly worded and confusing. A lockfile is designed to do exactly what you said. The package.json locked the file to ^1.3.2. If a newer version exists online that still satisfies the range in package.json (like 1.3.3 for ^1.3.2), npm install will often fetch that newer version and update your package-lock.json file automatically. That’s how I understand it / that’s my current knowledge. Maybe there is someone here who can confirm/deny that. That would be great!

typpilol 1y ago
You're correct

Mattwmaster58 1y ago

As others have noted, npm install can/will change your lockfile as it installs, and one caveat for the clean-install command they provide is that it is SLOW, since it deletes the entire node_modules directory. Lots of people have complained but they have done nothing: https://github.com/npm/cli/issues/564 https://github.com/npm/cli/issues/564 The npm team eventually seemed to settle on requiring someone to bring an RFC for this improvment, and the RFC someone did create I think has sat neglected in a corner ever since.

saghm 1y ago
Is there no flag to opt out of this behavior? For Rust, Cargo commands will also do this by default, but they also have `--offline` for not checking online for new versions, `--locked` to require sticking with the exact version of the lockfile even when allowing downloading dependencies online (e.g. if you're building on a machine that's never downloaded dependencies before, so they aren't cached locally, but you still don't want to allow implicit updates), and `--frozen` (which is a shorthand for both `--locked` and `--offline`). I'm honestly on the fence about whether this is even sufficient, since I've worked at multiple places where the CI didn't actually run with `--locked` because whoever configured it didn't realize, and at least once a surprise update to the lockfile in CI ended up causing an issue that took a bit of time to debug before someone realized what was going on.