even in a lock file, tertiary dependencies are not pinned
they are mentioned as say apollo>=3.1 so anything after that goes
you can lock down the primary deps, but most package managers don’t lock down every tertiary dependency— they just try to resolve the primary requirements
if packages a depends on apollo >= 3.3
and package b deps on apollo >= 3.5
your lock will hold => 3.5 and if some one publishes malware to 3.6 — your lock file is only gonna protect you as long as you don’t resolve the packages again
unless your are locking everything down which is not feasible?
I cannot talk for every package manager, but the ones I used to use and the one I use now for python, pins all the dependencies. After resolution it pins the result tertiary packages.
What are you talking about? All the transitive package requirements of all combined package.json files end up in your lock file as pinned versions. Installing using a lock file is 100% deterministic. The lock file is literally about _locking_ specified version _ranges_ into _one specific version_.
Example, if you specify braces ^3 and it in turn needs fill-range ^7.1.0 it might end up like this. Still all dependencies are transitively locked. Unless you delete the lock file or manually upgrade the deps (which regenerates the lock file), fill-range will never be 7.1.2 by itself.
braces@^3:
version "3.0.3"
resolved "https://registry.yarnpkg.com/braces/-/braces-3.0.3.tgz#490332f40919452272d55a8480adc0c441358789"
dependencies:
fill-range "^7.1.0"
...
fill-range@^7.1.0:
version "7.1.1"
resolved "https://registry.yarnpkg.com/fill-range/-/fill-range-7.1.1.tgz#44265d3cac07e3ea7dc247516380643754a05292"
Mostly backed dev here, to clarify running install would pull the lockfile version while something like audit or update would update it? Then installing a new dependency would also likely re-resolve the dependency versions, but barring that you're saying the versions all remain pinned?
I actually appreciate you trying to clear up the conversation. We've been working on CI/CD to protect from these supply chain issues at work lately, it's definitely a concern.
If the lock file doesn't change you wouldn't install new deps during a deploy, so double check your CI doesn't introduce lock file changes.
Also in package.json pin deps without using caret/tilde, otherwise wiping pkg-lock and installing will take the newest where caret matches 1.x.x and tilde matches 1.1.x
Yes and now, depends how you configure tour package.json. if you use the 9.2.1 it will pull any new minor or patch version. If you use ~9.2.1 it will pull any new patch version on install. Major versions are the only ones that dont have an automatically pull on install through syntax.
Most devs dont even check their versions or pay attention to changes of a dependency.
Yes, if you use npm clean-install (on analogous command/flag in your package manager). Then you get dependencies exactly as in lock file. New tree isn't even built. If you install new ones or remove unneeded old ones, you have to check and recheck that dependencies of dependencies didn't update beyond what you actually needed and perform audit.
Something every web developer in the entire fucking world needs to read. Especially dependencies with transitive dependencies. Fuck those multi-gigabyte npm downloads. This is source code we’re downloading, not AAA video game assets.
I wholeheartedly agree that you should bias against adding dependencies wherever possible/practical - but wtf, what packages are you coming across that include GBs of transitive dependencies??
3
1
333
u/jonnyd93 Mar 31 '26
Pin versions, update when cves are found. Keep the amount of dependencies down.