I am -1 based on the fact that Yarn v1 (a.k.a. anything other than Berry) is frozen. That does not sound like a dependency that we should be taking on imo.

From yarnpkg/yarn:

The 1.x line is frozen - features and bugfixes now happen on https://github.com/yarnpkg/berry

@bnb This point is discussed (and answered) there. As the maintainer of both release lines I don't mind discussing it further, but I think this linked thread would be a better opportunity to discuss these topics than an implementation PR - both for ergonomic reasons and because it's already been answered.

Just to be clear, I don't mind waiting for a TSC evaluation. I've only contributed to Node a couple times, and processes / ownerships are still a bit fuzzy to me. I'm happy to wait for the decision of whoever group is in charge of this kind of work. At least the implementation exists and provides a concrete picture of what the outcome would be.

@arcanis I appreciate the content there but it does not address my concern. The fact that Yarn v1 is frozen is a massive red flag to me as a 'new' dependency. IMO that context deserves to be held in the PR to add a dependency if it is a concern.

You assert that you expect people to stop using Yarn in favor of Berry, and have data to back that up. Further, you assert that the only changes you're planning on making are security changes - this is relatively well demonstrated by the backlog of PRs that are submitted solving issues that users are having but aren't being merged or addressed, including tiny ones like fixing broken links.

From the perspective of looking at Node.js over the next few years - rather than the short-term benefit of such a change - I frankly cannot see a reason why the Node.js project would take something on that's actively and intentionally being migrated off of as a result of the maintainers' choice in direction for it and isn't addressing problems end-users are facing outside of security issues.

I frankly cannot see a reason why the Node.js project would take something on that's actively and intentionally being migrated off of as a result of the maintainers' choice in direction for it and isn't addressing problems end-users are facing outside of security issues.

That's because you're deriving an incorrect premise, which is that Yarn 1 doesn't address problems end-users are facing. To reiterate:

Yarn 1 isn't legacy

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. People using Yarn 1.x right now have a project that already works. They may hit edge cases every once in a while, but the whole reason they use it is that they mostly figured out that the tradeoff was still value-positive for their current project. Being frozen is a feature, it's a gift that we are giving. It means that existing users won't get accidental regressions or bugs. Yarn is about stability, and putting our users in control. You shouldn't need to upgrade just because we release something new.

Yarn 2 is technologically better in many aspects. It would be easier for us to simply say that it should be the global binary at all time and that's it - similar to how npm is distributed. But different projects value different things, and in our case we care a lot about giving each user exactly the version they expect - whether it's Yarn 1, 2, 3, or 42. We care about it so much that we introduced a builtin feature for that three years ago, that we made it the default a year ago, and that we started the discussions around Corepack three months ago.

Of course it means that not all users are necessarily on the latest release. That's fine! Because they already have a tool that solves their needs right now, and because we'll never break semantics by redefining existing fields or ranges - as that would negatively affect past users by forcing them to upgrade. Now, perhaps later their use case will evolve, they'll need better perfs, or to solve a particular bug, or to implement something on their own, and they'll upgrade to the latest release, which will keep receiving regular bugfixes and new features. But perhaps not, and that's fine, because they will still follow an explicitly supported use case.

That's because you're deriving an incorrect premise, which is that Yarn 1 doesn't address problems end-users are facing.

At no point am I basing my assertion in that on the premise that Yarn 1 doesn't address problems end-users are facing. Bower is a good tool that solve(d/s) problems that end-users were facing. There are absolutely still people using it in production, and it still "works" as far as I'm aware.

That's not justification for being bundled in Node.js, imo.

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. People using Yarn 1.x right now have a project that already works. They may hit edge cases every once in a while, but the whole reason they use it is that they mostly figured out that the tradeoff was still value-positive for their current project. Being frozen is a feature, it's a gift that we are giving. It means that existing users won't get accidental regressions or bugs. Yarn is about stability, and putting our users in control. You shouldn't need to upgrade just because we release something new.

I can understand where you're coming from here, but this sounds like a pitch to me. It feels like justification of decisions without crediting the potential trade-offs or drawbacks of those decisions.

There's so much to deconstruct in this bit so rather than doing it in paragraphs, I'm going to try to summarize in bullets:

• "It has its flaws" there are bug reports and PRs to patch them that are going unmerged. This is a very... simple and kind way to frame this.
• "People using Yarn 1.x right now have a project that already works." People using pnpm, bower, or jspm also have projects that work. If they're already using it and have a workflow that works for them, why do we need to include Yarn in Node.js? Why is yarn different from those other package managers?
• "They may hit edge cases every once in a while, but the whole reason they use it is that they mostly figured out that the tradeoff was still value-positive for their current project." Same point as above. If they're already using it and have a workflow around that, what is the reason to add it to Node.js?
• "Being frozen is a feature, it's a gift that we are giving." Framing a decision you've made as a "gift" implies that the recipient should be grateful. If they're not, that sets them up to be the villain. Frankly, I don't really think this framing has a space in this PR nor, honestly, to our users.
• "It means that existing users won't get accidental regressions or bugs. Yarn is about stability, and putting our users in control." How is this different than permanently pinning to a package manager version across a company? I can use the first-ever published version of Yarn and expect the same, just like I can for npm, pnpm, Bower, or jspm.
• "You shouldn't need to upgrade just because we release something new." Wasn't your previous assertion that you're only going to be doing security releases from now on?

I am entirely familiar with the arguments around projects being "done" and feature complete. I think that those reasons are entirely fine within userland. Where I think we need to be more critical of that is when we're committing it into Node.js in a way that is effectively irrevocable.

that we started the discussions around Corepack three months ago.

Is Corepack still progressing? If so, why are we considering this PR since Corepack would theoretically replace it?

Of course it means that not all users are necessarily on the latest release. That's fine! Because they already have a tool that solves their needs right now

Again, if they already have the tool why are we putting it in Node.js core? Doing so would force them to change their existing workflows - including involuntarily upgrading users who are on an older version - which seems to be antithetical to the stated goals of Yarn.

Again, if they already have the tool why are we putting it in Node.js core? Doing so would force them to change their existing workflows - including involuntarily upgrading users who are on an older version - which seems to be antithetical to the stated goals of Yarn.

I don't think you understand this diff, or how Yarn is distributed. All versions of Yarn act both as a package manager and a jumper (similar, if you will, to gulp-cli). If it finds a yarnPath entry in .yarnrc.yml, it will use it instead of the global one. In other words, older projects will use Yarn 1 (because that's the global version used as fallback when nothing is found), or the checked-in package manager if it finds the right configuration to do so. Put simply, everyone gets what they ask for. There is no "involuntarily upgrading users who are on an older version". On the other hand, it does require a Yarn to be globally available.

I can understand where you're coming from here, but this sounds like a pitch to me. It feels like justification of decisions without crediting the potential trade-offs or drawbacks of those decisions.

Let's be clear - you're telling me that I don't credit trade-offs or drawbacks, on a project I maintain, for a protocol that was designed a year ago, and for which noone has reported any automated breakage of any system, while still being able to migrate at the time of their choice. At this point I don't know what to tell you.

Is Corepack still progressing? If so, why are we considering this PR since Corepack would theoretically replace it?

That's answered.

Put simply, everyone gets what they ask for.

Are you 100% certain, without question, that nobody is relying on the global yarn to be a specific version rather than using yarnPath? If there is anyone who is and they upgrade, it'll very quickly become our problem.

you're telling me that I don't credit trade-offs or drawbacks, on a project I maintain

Yes. In the paragraph you wrote - which is clearly what I was replying to - you only focus on the aspirational positives of Yarn v1 being frozen (outside of security updates, which you'd mentioned in a previous comment) without addressing potential trade-offs or drawbacks in a neutral way. I'm not sure how that's seemingly absurd or controversial to you.

That's answered.

You point to the Binary Management Discussion, which is somewhat about Corepack but ended up being more about version management. The PR you opened, says this:

In short, the intent is to provide standard shims that allow users to run Yarn and pnpm commands without having to explicitly install them first, and without cluttering the Node distribution.

I fail to see how this PR is not entirely antithetical to the goal of including Corepack and does not "clutter the Node distribution"

Are you 100% certain, without question, that nobody is relying on the global yarn to be a specific version rather than using yarnPath? If there is anyone who is and they upgrade, it'll very quickly become our problem.

No 2.x stable release was ever made on the npm registry. The last one which was, 2.0.0-rc.27 (out of 36), was only assigned to a berry tag. I'm positive no Yarn 2 user relies on a specific global version.

As for Yarn 1 users, past releases were semver-compliant, so 1.22.5 (the latest one) can installs the whole 1.x line. I would also point out that this wouldn't be any different from how npm releases work: you recently upgraded npm from 6 to 7, which is far riskier than Yarn 1.20 to 1.22 - at least semver-wise.

Discussed in the meeting today:

Consensus seems to be to try to do survey to get more information to help TSC members understand the need before calling a vote. Next step is to find volunteer to drive survey as we had no volunteers in the meeting. More details in: https://github.com/nodejs/TSC/pull/973/files and you can also watch the recording https://youtu.be/7WJ1p-W56nY at around 10:00 minutes in.

@mhdawson it was also suggested that we invite @arcanis to a meeting to make a case in favor of this PR before we move to a vote.

Sounds good 👍

Only remark I have: as we probably all know, which package managers people use tend to be a quite polarizing topic, where both communities can sometimes display a certain lack of empathy. Years ago it was Emacs v Vim, then Tabs v Space, and nowadays Yarn v npm. I feel the need to mention this, because studies have shown that those who oppose tend to be more vocal than those who support, especially when the opposition is the status quo.

Given that the primary goal (at least for me) is to help current users, not necessarily acquire new ones, I'd be wary of the survey wording. Specifically, I'd be cautious about not making it look like a "two parties" question. In my opinion, the survey would benefit by proving not only that a segment of the Node community would be positively impacted by this change, but also that even those who wouldn't directly benefit from it wouldn't be negatively impacted either.

For instance, rather than "would you like it? Y/N/neutral", which could incite non-Yarn users to answer N rather than neutral, perhaps a more suitable question would be "would it benefit your workflows? Y/N; would it impede your workflows? Y/N" (perhaps with a "Why?" box on each, to get testimonies on both sides). Basically focusing on the effects rather than the feelings. My 2 cents.

(One last note in the meantime, @jasnell made an informal Twitter poll pretty much about this about a year ago; while the results are incomplete with only 378 answers, it can help set expectations and perhaps give ideas about wording: #15244 (comment))

I can understand people having that misconception, yes, which is why it's been reiterated multiple times that yarn2 is quite explicitly not on the table. Sure, that could change at some indeterminate time in the future at which time we can discuss the pros and cons and make a decision, but that's a purely hypothetical argument right now.

It's not a misconception, it's how almost all software projects treat their dependencies. You will absolutely get issues filed to upgrade Yarn from users who will just assume that it's part of the plan.

Yarn 2 not being on the table today is not enough, it has to be explicitly off the table in the future. The harm to the ecosystem (and Node itself) is to great to invite in Yarn 1 as a trojan horse without such a commitment.

The harm to the ecosystem (and Node itself) is to great to invite in Yarn 1 as a trojan horse without such a commitment.

That's what I previously meant by this trust thing. Not only is your comment extremely insulting to the work my team is doing, you keep going and rambling "we caAaAn't truUust theEem theEey're the deviIil in disguiIise". I find this behavior ridiculous, entitled, and generally not up to the standard our community should strive for.

Again, we opened this PR because we saw a way to improve Node by this partnership, and we went with it. We certainly don't have anything tangible to gain from it, except an increased maintenance load. If the response is for a set of people to feel justified in harassing a project, let me say I'm disappointed.

@matthewp .... As has been stated repeatedly in this thread and throughout the entire conversation, yarn2 is simply, explicitly, intentionally not on the table and literally no one has even remotely suggested that it should or would ever be. If someone opens an issue or PR to add it later, we'll deal with that if it happens. But it is safe to say that right now there's an absolute and obvious consensus that it wouldn't land. Assuming something is "part of the plan" when literally everyone is repeatedly telling you that it is not is not productive and just wastes everyone's time and I'd ask you to please just stop.

@arcanis I think you're misinterpreting my comments in this thread. This is not Yarn's repo. I am not dismissing your work or the value of your project in the use cases you are aiming for. I am against Yarn 2 becoming a a built in feature of Node because of (1) poor performance and (2) incompatibility with the ecosystem, something that would be harmful for Node to endorse. As Yarn operates as an independent project I have no view on it, positively or negatively. I follow you on Twitter and think you're an insightful person. I never said there is an issue of trust of you or your team. I don't trust attitudes of all people whether in this thread or not not to change once a dependency is merged into core.

@jasnell I think it's perfectly valid to say that merging a dependency does increase the likelihood of a major version being introduced at a later time. I am not trolling by bringing up this concern. I presume that dependency updates are not all treating as one-off decisions in Node. You do not approach a V8 version update as an isolated decision "should we upgrade this time everyone or just stick to the current version", do you? I would presume that you approach it with the assumption that you will upgrade, unless there are reasons to not do so.

Merging Yarn 1 increases the likelihood of Yarn 2 being merged at a later date. And for that reason, Yarn 1 should not be merged into core.

@matthewp That's just not how the Node.js project works, all updates, as any change, need to go through a code review process. In the case of npm for example, we usually defer to members of npm who are also Node.js collaborators to review a PR updating the npm version bundled with Node.js. If this PR lands, I would expect that we would follow the same process: deferring reviews of PRs updating the bundled yarn version to members of the Yarn project who are also Node.js collaborators. So it is in fact a trust system between Yarn and Node.js.

Merging Yarn 1 increases the likelihood of Yarn 2 being merged at a later date. And for that reason, Yarn 1 should not be merged into core.

Thank you for expressing your concern, I think you made your point, please stop bringing it up so we can keep the discussion in this thread productive.

@aduh95 I will happily stop. Thank you for acknowledging what my point really is. It was frustrating to see my point be misinterpreted as something else.

It's also been frustrating to be treated as a troll when I was called entitled but responded with a compliment. Only I have been asked to stop, because apparently the decision on this issue has already been made and further input is unwanted.

I'll end by saying that making future decisions based on trust is a mistake. The current maintainers of Yarn might not be the future maintainers of Yarn. Like all projects, maintainers come and go. Future maintainers might have different opinions. Node should make a decision today on what it values and I would hope that ecosystem compatibility, compatibility with the node cli, and performance of node cli are high on that list. Deferring to future maintainers of other projects won't end well.

Best wishes, ✌️

I'll end by saying that making future decisions based on trust is a mistake. The current maintainers of Yarn might not be the future maintainers of Yarn. Like all projects, maintainers come and go. Future maintainers might have different opinions. Node should make a decision today on what it values and I would hope that ecosystem compatibility, compatibility with the node cli, and performance of node cli are high on that list. Deferring to future maintainers of other projects won't end well.

Node.js collaborators also come and go, it wouldn't be fair for us current collaborators to make a decision for future collaborators. Also, future collaborators will have more information (hopefully) than we have today, I trust them to make the correct call when the time comes. By a lot of regards, Node.js as it is today is based on trust; I agree that doesn't always work, but as it's written in capital letters in our license file: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND.

because apparently the decision on this issue has already been made and further input is unwanted.

FWIW decision hasn't been made yet, it has been discussed in TSC meetings and TSC members will vote to decide what is the status of Yarn in Node.js. I'm sorry if you felt your concern wasn't taken into consideration, I think it's simply because you believe, as you said, "making future decisions based on trust is a mistake", while other people may not (I don't).

I don’t think this achieves the goal of improving the experience for beginners, it just makes it confusing (“why are there two package managers that are compatible with one another?”)

It also makes node.js look confused: why should a distribution ship with two COMPETING package managers?

@jasnell

I would expect Node.js to hold Yarn accountable to that promise that the issues would be addressed, and if it turns out the issues are not addressed and major bugs persist, then we would always have the option of removing yarn from the distribution.

I can't imagine you reasonably expect us to be able to remove Yarn at some point in the future if it's merged into core? We've seen this time and again - once something gets into core, it's effectively impossible to remove without breaking a massive amount of the ecosystem. I'm curious how this example - especially with the scale of its impact - would be any different?

This is the root of the reason I think it make zero sense for Yarn v1 to go into Node.js core. Whether it's in a year when we decide for some reason that Yarn v1 isn't a match, or if it's in 7 years when it's gotten zero updates and is one of the Regrets from a current TSC member because we're permanently checking in technical debt, there's no chance we're ever able to remove this without causing massive ecosystem pain.

If Yarn v1 were being actively developed and improved, I think this PR would make sense. Thinking about our future selves and our users future selves, I can't find any avenue to understand how one could come to the conclusion that checking in "frozen" (I still take issue with the phrasing of this - it's effectively EOL, outside of a commitment by current maintainers to provide security fixes indefinitely) code is a good choice if enhancing the experience of our users is the only motivation, especially given that - at least to me - there's zero chance of ever reversing the decision.

I can't imagine you reasonably expect us to be able to remove Yarn at some point in the future if it's merged into core?

Yes, I do, if that's the expectation going in and we message it responsibly.

As someone that has been using Node.js heavily for years, I think adding Yarn 1 to Node.js would be a huge mistake.

• Modern npm is as good as Yarn 1.
• Yarn 1 has a lot of critical bugs that will never get fixed.
• It would better to focus on npm which is actively maintained. (Promising to fix critical security bugs does not mean Yarn 1 is actively mainained)
• It will hinder package management evolution, as Yarn 1 will lag behind and block package maintainer from using new features since many users are on Yarn 1. (If it's not in core, package maintainers can use that as an argument, but if it's in core ("blessed"), users will demand support)
• It will confuse beginners why there are multiple package managers.
• It will add more maintenance work for Node.js core team without any clear benefit. It's easy enough to install Yarn for the ones that want it.

Yes, I do, if that's the expectation going in and we message it responsibly.

I feel like we've learned in the past that people don't listen to what we tell them. This has also been a... consistent experience throughout the ecosystem, whether it be at the language level, the platform level, or the tooling level. I'm surprised that there's an assertion that we should decide rely on that now.

Without actually weighing in yes/no, I wanted to add some (IMO very important) background info to the conversation that I don't think has been clearly stated anywhere in this thread so far:

Yarn v1 is both a runtime and install-time dependency of Yarn v2. Edit: slightly more accurate: Yarn v2 installs are meant to be managed by Yarn v1. (In more details: Yarn v2 is meant to be installed via Yarn v1. Yarn v2 is meant to be installed locally on a per-project basis -- Yarn v2 is not designed to be installable globally. The binary you hit first when running a yarn command is the Yarn v1 binary. Yarn v1 redirects to run Yarn v2 if the project has set up Yarn v2 locally.)

So, the notion of including "Yarn v2 instead of Yarn v1" isn't technically doable with the current design of Yarn v1/v2.

I think that's also a big part of the background info needed to explain why including Yarn v1 with Node would make any sense, and why not including Yarn v2 with Node would make any sense.

From the perspective of a potential Yarn v2 user, and given the current designs of Yarn v1 & v2, this proposal is as close as it gets to "including Yarn v2 with Node". (And if I understand correctly, this proposal would seamlessly provide the closest thing to "including Yarn v3 with Node" as soon as/if/when that Yarn release exists.)

EDIT/correction?: Placing the Yarn v2 binary (having downloaded it with Yarn v1) at my usual global package install location as yarn does seem to yield a usable package manager. It's not the way the Yarn v2 docs instruct users to do things, though. So to be strictly accurate, Yarn v2 appears to be usable without Yarn v1. There's no apparent technical barrier stopping this workflow. But it's not supported by Yarn maintainers, I suppose. It appears to be a minified/bundled file, though. So not the usual global package install. The missing piece of the "user story" here is there's no easy way to update "globally installed Yarn v2" because Yarn v2 isn't officially meant to be globally installed, and it's not on the registries as a unified package, that I know of.

Modern npm is as good as Yarn 1.

And this, folks, is the real reason why the same group of vocals in this issue (not everyone, mostly those who take care to upvote each other) is against this proposal.

Let's be honest - this isn't about maintenance. None of you even assessed the maintenance cost, or made proposals to decrease it. This isn't about Yarn 1 either - you neither use it, nor recommend it. This isn't about bugs - you'd otherwise be at arms about some other things we won't list here. This isn't about community - you certainly didn't talk to Yarn's users, nor even cared about their opinion. 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. 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). This isn't whatever reason you want to make people believe it is, folks.

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.

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. The very fact that they use it means it matters. To block this proposal because, to you, "npm is as good" would be at best egoistical, at worst worrying meddling (not only would Node tolerate a for-profit project, it would actively fight for it; do you still want to laugh at Deno?). 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?".

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

"Everyone who disagrees with me doesn't know what they are talking about"

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?

The conversation here (on all sides) is devolving into less-than-productive discourse. The question is up for consideration and vote by the TSC, and "adding Yarn1" is not the only option. There are other choices on the table being discussed (such as the corepack option).

The feedback already discussed here has just established that there is not a clear consensus. (Yes, there are a good number of folks who have disagreed with the idea of adding yarn1 to the distribution but there are a enough who have spoken up in favor that we cannot ignore them)... therefore the question is going to the TSC to resolve.

Further back-and-forth around this is not going to serve the project or community well, so at this point, let's allow the TSC time to weigh the choices.

For those who are not aware, the alternative corepack option is to ship a utility that installs "jumpers" to the actual binaries. That is, it would install a yarn command-line that would on-demand download and install the yarn binary only if invoked and the user explicitly opts-in. It would also have the ability to install pnpm as well -- but the actual distributions of those package managers would not be included. I (and I believe @arcanis if he'll allow me to speak for him here) definitely prefer the corepack approach as opposed to bundling yarn1 directly. The vote that the TSC will be considering will also cover a decision on corepack.

The whole "should we add yarn or not" argument is kind of missing the forest for the trees.

It would be really nice to see node move towards not being so heavily dependent on needing any package manager, not adding more of them. And then the inevitable "enterprise" package manager manager meta stuff that will creep in with it.

The proposed yarn addition are not the sources but a result after it was 'built'. In other words, the javascript here is not the preferred method of editing but just distribution.. This would make it difficult or impossible to patch with upstream cherry-picks.

Please do not add yarn to node. Please consider removing npm from node.

When you install node on FreeBSD (using pkg), it installs ... node. If you want npm or yarn, no problem, that is just another simple install.

But new users will fail if npm isn't installed automatically! Well, if they can't follow a simple recipe and also install npm or yarn, they aren't going to get very far with async/await.

But lots of developers prefer yarn! Well, lots of developers prefer Express, or Fastify, or Hapi, but node does not bundle any of those either.

Node has succeeded in large part because of its modularity and composability. Please don't turn it into a monolith now by prescribing additional must-have packages from on high.

Please prefer minimal node. Do that one thing, and do it well.

https://en.wikipedia.org/wiki/Unix_philosophy#Doug_McIlroy_on_Unix_programming

@jfathman only rational reply in this godforsaken discussion thread. npm is an optional dependency on various linux distros such as Arch, I think it's better idea to push for yarn to be a optional dependency on distro packages rather than core nodejs.

While the decision is up for consideration by the TSC, I'm going to go ahead and lock the conversation here to just collaborators. While discussion on a topic is always a good thing, there's really not much more to be said here that's going to add to the discussion. Please allow the TSC time to review and decide what action will be taken, if any.

A reminder for the TSC folks that consulting our Technical values and priorities may be helpful in informing your vote on this issue.

TSC vote concluded that we would not include yarn directly and agreed on moving towards Corepack as the way forward instead. See nodejs/TSC#1012 (comment) for results of the vote.

Closing this as we will not land the PR. Please let us know if you think that was not the right thing to do.

Opened #38471 for this comment by Michael

Closing this as we will not land the PR. Please let us know if you think that was not the right thing to do.