[arp242]

Hugely surprising that package.json and package-lock.json don't have to match. The way I would expect it to work is something like:

  for d in dependencies_from_package_json()
    get_package(d)
    if hash_package(d) != package_lock_hash(d)
      error()
    end
  end

And not:

  use_package_lock_and_ignore_package_json_lol_fuck_you_haha_kthxbye()

I also discovered that npm doesn't actually verify what's in node_modules when using "npm install". I found this out a few ago after I had some corrupted files due to a flake internet connection. Hugely confusing. Also doesn't seem to be a straightforward way to check this (as near I could find in a few minutes).

But luckily "npm audit" will warn us about 30 "high severity" ReDos "high impact" "vulnerabilities" that can never realistically be triggered and are not really a "vulnerability" in the first place, let alone a "high impact" one.

[3np]

For situations when you care, go for `npm ci` instead of `npm install`. It will ensure lockfile consistency.

https://docs.npmjs.com/cli/v9/commands/npm-ci

[arp242]

That's just "rm -r node_modules && npm install".

Aside from needlessly taking a long time, it also means we're back to "if something goes wrong we're left with an inconsistent node_modules".

[3np]

No, it's more than that. Did you read the documentation page linked in the comment you replied to?

> But what about after the command has run?

If you munge around in node_modules after a successful `npm ci`, that's on you. If you run scripts that do, that's on you. If you depend on packages that run such scripts, that's on you.

> What, you mean I'm supposed to audit my dependencies myself? That's too much work!

Yes, as part of code review we expect our devs to manually inspect every change in the lockfile for anything that matters or might start to, which includes most things. No, you can't outsource that task to an AI, regardless of how well-performing it appears.

[arp242]

It says exactly that: "If a node_modules is already present, it will be automatically removed before npm ci begins its install".

I didn't "munge around" in node_modules; I said "if something goes wrong". Like I said in my previous comment: "I found this out a few ago after I had some corrupted files due to a flaky internet connection". That's not munging around, that's computers being computers. Network errors happen. Disk errors happen. Memory errors happen. Things like that. I've also had an install ISO corrupted at some point. I always check the sums since, just in case because there was a lot of confusion involved before I found out the ISO was just downloaded wrong for some reason. Stuff doesn't often get randomly corrupted, but it does happen, and with 2GB ISO files (or 2GB node_modules) the chances do grow.

On Go I can do "go mod verify". I think yarn has "yarn check" for this (but didn't verify). I don't know about other package managers off-hand, but if they don't have something for it, they should. You need to be able to verify the content on disk is identical to what's expected.

I never mentioned anything about auditing dependencies or AI.

Your entire post is a masterclass in arguing against things that were never claimed and forceful injection of your own bugbears. I just want to check if node_modules is identical to what's expected, just in case, because computers kind of suck and are unreliable.

[3np]

Well, you did say (emphasis mine):

> That's just "rm -r node_modules && npm install".

And there is more to it, very much relevant to your original complaint, which is not applicable to it.

> I didn't "munge around" in node_modules; I said "if something goes wrong". Like I said in my previous comment: "I found this out a few ago after I had some corrupted files due to a flaky internet connection".

I do believe that if you had run `npm ci` instead of `npm install`, that would have resulted in an error and an empty node_modules instead of inconsistency.

> Disk errors happen. Memory errors happen. Things like that.

Those are at lower layers than the package manager. I think it's unreasonable to expect the package manager to check for inconsistencies induced by hardware errors. You have file-system level solutions (zfs,btrfs) and things like ECC for that. Nothing is a silver bullet.

> I've also had an install ISO corrupted at some point. I always check the sums since, just in case because there was a lot of confusion involved before I found out the ISO was just downloaded wrong for some reason

Good! It happens. Keep doing it. There's a reason integrity verification is a step in every Linux distro installation guide.

> Your entire post is a masterclass in arguing against things that were never claimed and forceful injection of your own bugbears.

Fair! Though I do want to call out your "Who is carefully auditing if the repo URL in the lockfile is actually the correct one?" in a sibling comment - apparently the inferred bugbear wasn't all off-base :p

> I just want to check if node_modules is identical to what's expected, just in case, because computers kind of suck and are unreliable.

I think we can agree on that npm is not sufficient tooling for this. My response is additional tooling. I guess you want a more feature-complete package manager. Wish I had one to recommend. npm is severely neglected after the MS acquisition; yarn maintainers are completely misguided on a couple of fundamentals; every time I get around to take another look at pnpm either I run into a bug or catch a recent enough breakage-outside-of-semver that I decide they're not ready yet...

[tyingq]

I think that's true for most package managers. That if there's a lock file, there's typically a default command to use it for installs and ignore the main config file.

[arp242]

Yeah maybe, I don't really know off-hand and I'd have to check. I know it's not possible in Go but not sure about anything else. I'd consider it hugely surprising for other packagers where that's possible too. Who is carefully auditing if the repo URL in the lockfile is actually the correct one?

[tyingq]

Poetry for sure acts this way. Some checks on things like "poetry.lock is older than pyproject.toml", but no real checks unless you specifically ask for them. Not saying it's good, of course. Just that it's typical.

[dartos]

FWIW l, I believe “npm ci” is the install command which strictly respects the lock file

[3np]

> But luckily "npm audit" will warn us about 30 "high severity" ReDos "high impact" "vulnerabilities" that can never realistically be triggered and are not really a "vulnerability" in the first place, let alone a "high impact" one.

Yeah, you want to be using a tool that lets you ignore/acknowledge specific entries.

`npm audit` is not an end-all-be-all.

Like and subscribe[0]: https://github.com/npm/rfcs/pull/18

https://www.npmjs.com/package/npm-audit-resolver

[0]: The bottom comment from Jan sums up what happens when Microsoft steps up...