Repository navigation
Suggestion for dropping Yarn from Node 14 release #1238
Description
Splitting off this discussion from #777 since there is around 3 weeks till Node 14 is supposed to be released. This represents a good time to remove the support from the image for v14 without requiring a breaking change later.
Why?
- Issues like Please update yarn to at least 1.22.0 (CVE-2020-8131) #1237 get raised for CVEs for Yarn, that we wouldn't patch like issues shipped with the bundled version of NPM in Node yargs-parser could be tricked into adding or modifying properties of Object.prototype using a "__proto__" payload. #1235
- Yarn 2 Yarn 2 support #1180 changed there deployment method to vendor in the binary into repos, so newer repos using Yarn shouldn't need the same global install
How?
- Update move the Yarn templating to update.sh and only append it when Node < 14
This would still keep Yarn in the <14 images till v12 hits EOL in April 2022, and follows a similar approach as the "OnBuild" deprecation by not adding it to newer versions after 8.
This wouldn't preclude a separate image with Yarn being taken back up by the Yarn project as they did in the past, giving them more control over tagging of their version releases.
Activity
[-]Suggestion for drop Yarn from Node 14 release[/-][+]Suggestion for dropping Yarn from Node 14 release[/+]PeterDaveHello commentedon Apr 8, 2020
I'm good with it. Let's cc other team members @nodejs/docker
SimenB commentedon Apr 8, 2020
I'm still hugely 👎 on removing yarn. AFAIK nothing has changed since the last time we discussed this. 30+% (as far as we know) use yarn, and we should keep supporting it unless TSC says no. This is the same argument that has been stated across multiple issues by multiple people.
I don't see how this counts "against" yarn. We cannot patch issues with npm either, we say "wait for next node release".
You still need a global
yarnbinary to launch the install, so it's still very much useful for us to keep shipping it.pesho commentedon Apr 10, 2020
Echoing what @SimenB said.
25 remaining items
arcanis commentedon Apr 21, 2020
I've found this type of arguments a bit lopsided in the past:
They often originate from people who don't often use alternate package managers as part of their workflows. There's nothing wrong with that by itself, but I feel like extra care should then be put into understanding the impact for people that do use them, which I don't find here.
As an example, the original post doesn't mention at all Yarn's usage rate - and thus which portion of the ecosystem will become second-class citizen. It's not easy to find it, but I feel like it's a critical part of the context that shouldn't have been omitted (polls show it a consistent ~30%-40%).
Second they typically address the problem in very focused ways, ignoring other options. @nschonni If the problem is that Yarn isn't acknowledged by Node, why do you jump to the conclusion that its support should be removed? Why not instead suggest to properly support it at the foundation level? Which is exactly what we're doing at https://github.com/nodejs/node/issues/15244.
In its current state, I personally don't find the orginal proposal very appealing:
And of course it would let the Yarn team know once again that we're second-class citizen, pushed back behind the glorious npm. Which is frankly tiring, not that anyone cares.
That would be reasonable, although I think it depends on the outcome of https://github.com/nodejs/node/issues/15244. If a jumper system is agreed upon, there will be no need for different images.
Generally, what I'm worried about is to change the usage instructions ("don't use node, use node-yarn") to change them back a release later ("don't use node-yarn, use node"). Because then, why not just directly go to the second step?
mcollina commentedon Apr 21, 2020
Given that v14 is going to be releases today and there is no agreement on this issue, I would recommend yarn1 to be included in the v14 image and wait for the decision of https://github.com/nodejs/node/issues/15244.
MylesBorins commentedon Apr 21, 2020
I would like to second what @mcollina has brought up. Do we have a timeline on the release of docker images for 14?
PeterDaveHello commentedon Apr 21, 2020
As it's still under discussion and unlikely to remove yarn@1, I'll still do the same thing on v14 release here.
SimenB commentedon Apr 21, 2020
I've opened up a v14 PR now, keeping the status quo (i.e. yarn@1 is still included). Would love to investigate the "no package manager" thing regardless of nodejs/node#15244 since I think it makes sense no matter if we keep yarn around or not, especially with multi-stage builds.
nschonni commentedon Apr 21, 2020
@SimenB and @Starefossen have landed the v14 PR already, so there is no point of further discussion here since the window for making this change has been closed
ljharb commentedon Apr 23, 2020
@nschonni there's still a point, because it can still be made for v15 - and it should be discussed now, not in a year when the window is tight.
nschonni commentedon Apr 24, 2020
@ljharb this one could be re-opened, but there are already existing discussion around splitting out Yarn in issues like #777. I opened this one to get a targeted decision for v14 which didn't work out.
ljharb commentedon Apr 24, 2020
Can we get a targeted decision for v15, far in advance of its release?
Trott commentedon Apr 26, 2020
@ljharb If that's desirable, then perhaps the thing to do is open a new issue proposing it. The problem with getting a decision this far out is that (a) there doesn't really seem to be consensus around whether or not this should be done and (b) six months out is a long time and a lot can change. If there's anything evolving in the yarn project in particular, it could affect (b) potentially.
However, if a discussion happens, and an impasse is arrived at, then the conversation can be escalated to the TSC again, and this time maybe a deadline for a decision can be more carefully observed by those of us on the TSC.
That said, I do suspect that the TSC will be very reluctant to overrule the opinions of the people actually doing the releases. (At least, that is my personal position as a TSC member. The case for doing so would have to be overwhelmingly compelling. Not impossible, but the bar is very high.) So gauging chances of success ahead of time could involve figuring out who is actually doing the work to create these releases, and then seeing where they personally stand on the matter.
Trott commentedon Apr 26, 2020
Big oops on my part! The TSC can offer its opinion, but the Docker Working Group is officially chartered and the TSC cannot overrule it on the areas of its chartered responsibility which include "Decide and implement image improvements and/or fixes.", which I would interpret to include "to include yarn or not to include yarn" decisions. Docker Working Group would have to escalate to TSC themselves or something. The only way the TSC can stop a decision it doesn't like is to de-charter the Working Group entirely, which I think we are exceedingly unlikely to do over an issue like this.
Trott commentedon Apr 26, 2020
By the way, if the working group isn't really active anymore and it's now just a GitHub team that does the releases but doesn't have any formal governance process that it actually follows or anything like that, de-chartering might make sense. So if that's the case, that might be the first step.