Why would you patch a security vuln in a later version? Should be patched in all versions.. that's what semver is for.

Ah yes the incredibly common practice of... checks notes backporting security packages in node packages.

Semver doesn't help if you just declare all older versions EOL.

What you're looking for are Debian stable packages. :p

Who is 'you' here? All of the npm package maintainers?

Yes, if they all just backport security patches we'll be fine. No, people are not going to just.

A patch updates is a newer version, and they are just as likely to be compromised by supply chain attacks as minor or major updates.

Not exactly.

Security patches aren't like bugs or features where you can just roll a new version. Often patches need to be backported to older versions allowing software and libraries to be "upgraded" in place with no other change introduced.

Say you had software that controlled the careful mix of chemicals introduced into a municipal water supply. You just don't move from version 1.4 to 3.2, you fix 1.4 in place.

No, you create version 1.4.19, which fixes a bug in 1.4.18.

At this point, the risk of a compromised package outweighs the risk of an upstream vuln that actually matters. Npm audit is full of junk like client side redos vulns, you could probably ignore 90%+ of the reports and still be secure against the majority of of-concern attack classes.

Even with ^ you won't get an updated version until somebody runs an install and updates the lockfile.

We have things like dependebot for this.

https://docs.github.com/en/code-security/tutorials/secure-yo...