[hobofan]

- URL-based dependencies also have some additional security issues in the most common usage scenarios (see my recent flagged post: https://news.ycombinator.com/item?id=34937327).

- You also lose all ecosystem upgradability, as everyone is using pinned versions instead of SemVer ranges

[tracker1]

How many things have been broken by doing that in practice though?

I mean seriously... in node/npm, I've seen way too many times where a minor version broke things in practice... so we go to patch level by default, usually safer... In the end, we still wind up needing tools, like with github to alert to issues that require larger bumps.. Oh, your application hasn't been updated in a year, and you now have two major versions of LibraryX to run through... Next thing you know, you've spent literally three weeks to update your node/npm/react project... and even then, some packages were too painful to update, so you just deal with the warnings anyway.

And, now you've concentrated targets to the latest minor/patch versions in packages... where if everyone is pinned, the targets are mostly unknowned from outside without deeper inspection.

Just saying, I'm not sure auto semver with lockfiles is really a win over just locking to begin with.

[hobofan]

> Just saying, I'm not sure auto semver with lockfiles is really a win over just locking to begin with.

It's still a win even if you consider only patch version updates. Without that, for a CVE in a dependency, every dependent package will have to update, and will first have to wait for the lower level to update and publish a new version. So for a dependency ~4 layers deep, with coordination and publishing lag in between, this can quickly take more than a week (and this is assuming responsive maintainers).

[tracker1]

A lot of time that happens anyway... at least with npm... there are a lot of times you see warnings, that you cannot resolve because of a nested dependency that is more than a point release off.