deps: add Yarn 1.22.5 by arcanis · Pull Request #37277 · nodejs/node

4 min read Original article ↗

This isn't about Yarn 1 either - you neither use it, nor recommend it.

I use it often. My employer also uses it often, and I have worked with the people in those teams often. I've also helped advise on how we can better support it to make a seamless experience for Yarn users in multiple products for customers who do use Yarn.

This isn't about bugs - you'd otherwise be at arms about some other things we won't list here.

I have cited a concern around bugs#37277 (comment), which you dismissed by saying "Yarn 1, as it is, is fine. It has its flaws, and some people would like more features, but, and that's critical, its value comes from its stability." As an SME, I trust and believe your input, but you seem to invalidate that as if it never happened.

This isn't about community - you certainly didn't talk to Yarn's users, nor even cared about their opinion.

Throughout this I've been pinging friends, colleagues, and peers from across the ecosystem who are experienced Yarn users with my feedback before posting it.

This isn't about Node - it should be fairly obvious that shipping a project owned by a for-profit as part of a free software is a major red flag and liability.

If this is your concern, why didn't you bring it up earlier? Further, why are you solving this problem by adding more things rather than proposing that the alleged red flag and liability be removed? How does shipping Yarn meaningfully address this concern?

This isn't about package management ecosystem - otherwise you'd listen to those actually writing those package managers (you may have missed it, but I'm not even the only one - another ghost is lurking this thread as well).

A former maintainer of npm and a former maintainer of Yarn have commented -1 against this PR. Why are you ignoring their input?

What this is is that you believe that modern npm is as good as Yarn, and you don't see how this proposal would do you any good. To you, Yarn should die a fiery death to give back npm all its glory, and you have many amazing ideas to make that happen. It's fine, we all have opinions. I'm more an Emacs user myself, but whatever. The problem is that this, quite literally, isn't the discussion at hand. Right here, right now, we're talking about the existing state of the ecosystem.

This is an entirely unproductive comment that assumes bad faith on the part of those who've made objections to a proposal.

For the better or worse, whether you like it or not, Yarn is used. That's it. It's really not up to you (or me) to decide whether its users are right or wrong.

Nobody disagrees with this. Every single person I know, from Node.js TSC members to package maintainers to end-users to engineering managers, are happy that Yarn is used and that there is more than one option. This is also unrelated to Node.js and this PR. Nobody thinks others are "wrong" for their package manager choice, and it's frankly weird that that is being asserted here.

(not only would Node tolerate a for-profit project, it would actively fight for it; do you still want to laugh at Deno?)

This is a weird remark. Several Node.js TSC members actively engage with Deno and there's a lot of hope that - like yarn did with npm - Deno can help move the ecosystem forward as a whole, no matter which platform end-users choose. Also, Deno is now a for-profit company using the open core model, in case you missed the news. In that news, they actively attacked how Node.js operates as an open governance project, despite our project leadership's eagerness to work with them. Perhaps not the best example.

Frankly, the question really isn't "should Node add Yarn" - it's rather "can Node prone inclusivity by persisting in providing a subpar developer experience to a specific set of people, depending on the tool they use?".

I don't understand what you're saying here?

As a side note, out of the 1000 most depended packages on the npm registry, 216 definitely use Yarn, and 291 use npm (the rest being undeterminable).

Your point here is that a majority of projects in the top 1000 most depended packages in the npm registry are undeterminable?