undefined | Better HN

0 pointsarp2421y ago0 comments

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.

0 comments

3np1y ago

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

arp242OP1y ago

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".

3np1y ago

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.

1 more reply

tyingq1y ago

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.

arp242OP1y ago

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?

tyingq1y ago

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.

dartos1y ago

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

3np1y ago

> 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...

j / k navigate · click thread line to collapse

0 pointsarp2421y ago0 comments

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()

0 comments

3np1y ago

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

arp242OP1y ago

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".

3np1y ago

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!

1 more reply

tyingq1y ago

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.

arp242OP1y ago

tyingq1y ago

dartos1y ago

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

3np1y ago

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...

j / k navigate · click thread line to collapse