> Why bother with semantic versioning if everybody is expected to manually
> check and pin their dependencies anyway?
I think this is the disconnect here: the lockfile does protect me from updates, but ranges are still useful: they allow a tool to help me upgrade my dependencies. With the lockfile-based approach, you usually _don't_ pin to specific versions: with Cargo, we even defaulted to the ^ operator, so 'foo = "1.2.3"' is the same as 'foo = "^1.2.3"'. So this is what happens:
1. foo v1.2.3 comes out and I put that in my Cargo.toml.
2. foo v1.3.0 comes out. My build doesn't change.
3. I decide "hey, there's some new versions of my dependencies, let's upgrade."
4. I type "cargo update". Now, my lockfile is updated to have 1.3.0 instead.
That is, ranges allow you to use semver as a tool. The big issue here is transitive dependencies; yes, for my own deps, I could have specified an exact version and done it every time. But what about the dependencies of my dependencies? Or the dependencies of the dependencies of my dependencies?
I totally understand your concerns about cargo-culting tooling, and that Facebook-sized organizations have different needs than non-Facebook sized ones. But repeatable builds are a big deal, and managing dependency ranges so you can still use semver while getting repeatable builds is a big deal. Even for smaller organizations.
(And that's beyond the speed and security aspects of yarn.)
> That is, ranges allow you to use semver as a tool.
I understand that, but you're looking at it from a technical perspective, while it's partially a psychological issue - namely, the question of how you drive certain desirable behaviour.
When you make upgrades explicit, rather than automatically installing newer versions, you reduce the deployment of (security) bugfixes, because many people simply will not run `upgrade`.
The reason is that you've created an expectation of manually checking versions before updating them - after all, why would it be a manual action otherwise? - and people do not want to commit to doing that. That is why this will harm the ecosystem - it undermines the mutual trust that a maintainer will be using semver, and that you can rely on it to automatically get updates.
The solution is simple: make lockfiles opt-in. That doesn't mean that you can't aggressively require a developer to lock their versions once they have opted in - it just shouldn't be a feature that is enabled by default.
> But repeatable builds are a big deal, and managing dependency ranges so you can still use semver while getting repeatable builds is a big deal. Even for smaller organizations.
For many people, it really isn't. Comparing the tradeoffs of manual upgrade management vs. the chance of occasional breakage due to non-determinism, many people will pick the latter.
And I'm not just talking about "organizations" here either - there's plenty of development going on outside of any organization, on personal projects, and that is precisely the kind of development you'd want to encourage.
I totally understand your concerns about cargo-culting tooling, and that Facebook-sized organizations have different needs than non-Facebook sized ones. But repeatable builds are a big deal, and managing dependency ranges so you can still use semver while getting repeatable builds is a big deal. Even for smaller organizations.
(And that's beyond the speed and security aspects of yarn.)