3 ms·

As I understand it, it automatically locks in the (exact) version of everything you install, rather than having this as a separate, optional feature (like shrin

As I understand it, it automatically locks in the (exact) version of everything you install, rather than having this as a separate, optional feature (like shrinkwrap does, despite it not working well - but that's an implementation problem). The big deal about semver and how it's implemented in NPM is that there is a choice of how to deal with it - either you automatically allow compatible updates and risk an occasional maintainer fuckup, or you explicitly pin everything and take on the burden of constantly updating your versions manually and tracking security releases. The latter might work for Facebook and other large organizations, but for many smaller developers, the consequences of an accidental break are much, much less serious than those of constantly having to keep pinned dependencies up to date. End result: people don't bother at all, and insecure versions never get upgraded for the majority of the userbase. This, in turn, removes the incentive for package authors to do anything with semver at all, once Yarn's approach becomes commonplace. Why bother with semantic versioning if everybody is expected to manually check and pin their dependencies anyway? Facebook also needs to take into account their influence over the ecosystem. The reality is that whatever project Facebook puts out is immediately seen as gospel and "naturally, a well-engineered thing and a good choice to use!" - this is literally a daily argument in #Node.js when somebody is trying to argue why a poorly-fitting tool is somehow appropriate for their usecase. "Well, Facebook uses it!" In reality, the Yarn workflow is designed to work for Facebook and organizations of similar size, and in all likelihood it will break down in other situations. People will not realize this until they've already bought into it, and by then it's too late.

steveklabnik 10y ago
> 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.)
- joepie91_ 10y ago
  > 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.
  - steveklabnik 10y ago
    Thanks for elaborating. I think we fundamentally disagree, but I understand your perspective a lot better now.
nmblackburn 10y ago
"Facebook also needs to take into account their influence over the ecosystem. The reality is that whatever project Facebook puts out is immediately seen as gospel and "naturally, a well-engineered thing and a good choice to use!" - this is literally a daily argument in #Node.js when somebody is trying to argue why a poorly-fitting tool is somehow appropriate for their usecase. "Well, Facebook uses it!"" Absolutely agree with this statement, it drives me insane listening to the hype before anyone has really even had chance to form an opinion on it.

steveklabnik 10y ago

> 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.)

joepie91_ 10y ago
> 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.
- steveklabnik 10y ago
  Thanks for elaborating. I think we fundamentally disagree, but I understand your perspective a lot better now.

nmblackburn 10y ago

"Facebook also needs to take into account their influence over the ecosystem. The reality is that whatever project Facebook puts out is immediately seen as gospel and "naturally, a well-engineered thing and a good choice to use!" - this is literally a daily argument in #Node.js when somebody is trying to argue why a poorly-fitting tool is somehow appropriate for their usecase. "Well, Facebook uses it!"" Absolutely agree with this statement, it drives me insane listening to the hype before anyone has really even had chance to form an opinion on it.