-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deps: add Yarn 1.22.5 #37277
deps: add Yarn 1.22.5 #37277
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally don't think this should land without TSC agreement. @nodejs/tsc. Each dependency we include means more work for the project, more security releases etc. I also don't know where you draw the line, do we include 2 package mangers, 3, 10?
This has been discussed in other threads, but it seems there was a recent suggestion to PR this in even though those conversations did not conclude one way or the other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. I'd much rather see npm improved than have to maintain another package manager in the source tree.
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:
|
@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. |
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. |
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.
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:
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.
Is Corepack still progressing? If so, why are we considering this PR since Corepack would theoretically replace it?
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
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.
|
Are you 100% certain, without question, that nobody is relying on the global yarn to be a specific version rather than using
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.
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:
I fail to see how this PR is not entirely antithetical to the goal of including Corepack and does not "clutter the Node distribution" |
No 2.x stable release was ever made on the npm registry. The last one which was, 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. |
// * node -e 'require("v8-compile-cache")' | ||
// * node -r 'v8-compile-cache' | ||
// * Or, requiring from the REPL. | ||
const parentName = module.parent && typeof module.parent.filename === 'string' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if this code ends up being executed, but it would emit a pending deprecation warning (https://nodejs.org/dist/latest-v15.x/docs/api/deprecations.html#DEP0144)
I opened a PR to fix it but got no answer: zertosh/v8-compile-cache#34
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR was merged and published.
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. |
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. |
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.
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 Best wishes, ✌️ |
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:
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? |
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. |
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.
|
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:
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 |
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" |
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.
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.
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.
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?
A former maintainer of npm and a former maintainer of Yarn have commented -1 against this PR. Why are you ignoring their input?
This is an entirely unproductive comment that assumes bad faith on the part of those who've made objections to a proposal.
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.
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.
I don't understand what you're saying here?
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 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 |
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. |
This comment has been minimized.
This comment has been minimized.
Opened #38471 for this comment by Michael
|
Ref #37193 (and #37193 (comment) in particular, cc @jasnell @mcollina)
This commit adds Yarn to the Node release tarballs and installers. I tested:
.\vcbuild.bat msi
and ran the resulting exe)make pkg
and ran the resulting pkg).tar.gz
file)In all cases, running
yarn --version
yielded the correct Yarn version (1.22.5 for infra reasons, which is for all purposes identical to 1.22.10 minus a postinstall script which has no impact whatsoever in this situation).npm
from the Node.js project, and you can still install Yarn separately from Node.js), it's meant to improve the experience of new users.