upvote

points

by rvz14 hours ago |
comments
upvoteby AgentME14 hours ago|
next
[-]
Npm's package-lock.json already handles pinning everything to exact versions, including subdependencies. Pinning exact versions in package.json doesn't affect your subdependencies.
reply
upvoteby beart10 hours ago|
parent|
[-]
You aren't wrong. However, this article does offer some additional advice on this matter, and some potential reasons why it might still be desirable to pin your deps in package.json.

https://docs.renovatebot.com/dependency-pinning/#pinning-dep...

Some exerts:

> If a lock file gets out of sync with its package.json, it can no longer be guaranteed to lock anything, and the package.json will be the source of truth for installs.

> provides much less visibility than package.json, because it's not designed to be human readable and is quite dense.

> If the package.json has a range, and a new in-range version is released that would break the build, then essentially your package.json is in a state of "broken", even if the lock file is still holding things together.

reply
upvoteby eqvinox13 hours ago|
prev|
next
[-]
Or help distributions do the manual process of packaging - which involves at least rudimentary security checks - so they can ship newer versions faster.

And then use distro packages.

(I'm not accepting distro fragmentation as counterargument. With containerization the distro is something you can choose. Choose one, help there, and use it everywhere.)

reply
upvoteby losvedir13 hours ago|
prev|
next
[-]
Are you talking about in package.json? What's your threat model? That's what the lock file is for, which also pins transitive dependencies, which is just as crucial. Now what's actually insecure is if you don't commit the lockfile. and if you don't do `npm ci`.

I think `npx` might pull down new versions, too? I wish npm worked more like Elixir where updating the lock file was an explicit command, and everything else used the lock file directly.

reply
upvoteby jonchurch_14 hours ago|
prev|
next
[-]
its so wild to have seen this advice reverse course over the past year.

it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.

different times, different threat model I suppose

reply
upvoteby n_e13 hours ago|
parent|
[-]
> it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.

This is still the right advice for libraries. For security it doesn’t matter a whole lot anymore as package managers can force the transitive dependencies version, but it allows for much better transitive dependency de duplication.

For non-libraries it doesn’t matter as the exact versions get pinned in the package-lock.

reply
upvoteby captn3m014 hours ago|
prev|
[-]
I've been collecting things you can't pin:

- Python inline dependencies in PEP-0723, which you can pin with a==1.0, but can't be hash-pinned afaik.

- The bin package manager lets you pin binaries, but they aren't hash-pinned either.

- The pants build tool suggests vendoring a get-pants.sh script[0] but it downloads the latest. Even if you pass it a version, it doesn't do any checks on the version number and just installs it to ~/.local/bin

[0]: https://github.com/pantsbuild/setup/blob/gh-pages/get-pants....

reply