Repository navigation
Remove unsupported Yarn v1.22 from docker-node base images #2264
Description
Activity
Yarn Classic v1 is a bit of an anomaly! As you say, it's unsupported, however it has not been declared end-of-life and download numbers are still increasing.
seems unlikely to be used widely
The supposition that Yarn is not widely used is not supported by current statistics, which show download figures for the yarn package of around 6 million per week.
I assume that the complexity of migrating from Yarn Classic v1 to Yarn Modern with pnp and Corepack technologies have been a barrier.
Edit:
At this time probably continuing "as-is" is the right decision.I have changed my mind about this, considering the state of Yarn v1 ClassicPLEASE add at least an argument for the YARN version. I'm right now copying the whole base Dockerfile into my repo to evade the absolute nightmare of not being able to override the "global package manager definition". Corepack is absolutely no help here at all as it always defaults to the preinstalled yarn1.22.22.
Which version of Yarn do you want to use and which Docker Node.js version are you using? I would expect the version of Yarn Modern to be in the
package.jsonfile in thepackageManagerfield, for example:"packageManager": "yarn@4.9.2+sha512.1fc009bc09d13cfd0e19efa44cbfc2b9cf6ca61482725eb35bbc5e257e093ebf4130db6dfe15d604ff4b79efd8e1e8e99b25fa7d0a6197c9f9826358d4d65c3c"
That would get picked up if you have the following in your Dockerfile:
RUN corepack enable yarnEdit: It also sounds like your problem is not with Yarn v1 Classic, which is now topic of this renamed issue, so it should probably be looked at in a different issue.
With CVE-2025-8262 and CVE-2025-9308 impacting 1.22.22 of yarn in alpine builds, will this be prioritized?
- changed the title
[-]Migrate to modern Yarn 4.x or remove[/-][+]Remove unsupported Yarn v1.22 from docker-node base images[/+]on Sep 5, 2025 Based on the separate high download numbers of the npm package yarn (current version
1.22.22, released Mar 3, 2024) of 6 million per week, I imagine that there could still be significant usage of Yarn v1 Classic through Node.js Docker images. Removing Yarn v1 Classic from these Docker images is therefore also likely to have a significant impact for users.
Yarn v1 Installation states:
In practice, there is no longer any maintainer response to issues raised in the repo https://github.com/yarnpkg/yarn/issues list. The failing nightly CircleCI pipeline has been abandoned and a request to fix (or disable the pipeline) was also not actioned. The pipeline runs on end-of-life versions of Node.js 4-13 and Node.js 12-16.
Whether or not to continue to bundle Yarn v1 Classic in Node.js Docker images may need to be a strategy topic for the Docker Working Group given the potential impact. If it's decided to remove Yarn v1 Classic then there may need to be an announcement ahead of time with a suitable transition period where its use in Node.js Docker images is deprecated before it is finally removed.
Please flag this with the WG-agenda label so the decision can be made.
Regarding the download numbers for Yarn v1, are we able to correct for the circular-reasoning factor, in which base images and other artifacts continue to install Yarn v1 due to these numbers, which ensures the numbers stay high?
Wondering if there's a better proxy for usage, or if the node-docker community has mechanism for announcing intent to deprecate and remove and solicit concerns?
Regarding the download numbers for Yarn v1, are we able to correct for the circular-reasoning factor, in which base images and other artifacts continue to install Yarn v1 due to these numbers, which ensures the numbers stay high?
Wondering if there's a better proxy for usage, or if the node-docker community has mechanism for announcing intent to deprecate and remove and solicit concerns?
I would expect that the download numbers for Yarn v1 Classic shown in the npm registry stats caused by including it in Docker node images would be restricted to each time a Docker image is built through this repo, not when it is used. If Yarn is included in the Docker image then it doesn't get downloaded from the npm registry every time.
It's not the first time that the continued inclusion of Yarn v1 Classic has been discussed here.
- Suggestion for dropping Yarn from Node 14 release #1238
- Decision about
yarnin images for next semver-major of Node.js #1979 - feat: enable Corepack (pnpm support, unbundle yarn) #1768
At one point there was an initiative to enable Corepack by default to support Yarn Modern, and support unbundling of Yarn v1 Classic.
And then there was the Node.js Technical Steering Committee vote on Mar 19, 2025 which resulted in the strategy decision:
Phase out later: stop distributing Corepack (i.e. the distribution will no longer contain a corepack executable) on future (i.e. 25+) release lines of Node.js – existing release lines as well as the very next (i.e. 24.x) will keep it as experimental.
Edit: Changed the text below, since Node.js
25.0.0has now been released:When Node.js
25.0.0released on Oct 15, 2025, there is no bundled Corepack included with Node.js>=25. Also in practice, since the announcement of the TSC vote outcome, no further significant development of Corepack is taking place in the Corepack repo.Possibly the Node.js 25 release milestone (Oct 15, 2025) would be the right trigger to discuss once again about what to do with Yarn v1 Classic?Too late, as this milestone is now in the past.Since yarn is installed via curl, using the recommended way to install corepack manually obviously doesn't work:
$ npm uninstall -g yarn pnpm up to date in 3s $ npm install -g corepack npm error code EEXIST npm error path /usr/local/bin/yarn npm error EEXIST: file already exists npm error File exists: /usr/local/bin/yarn npm error Remove the existing file and try again, or run npm npm error with --force to overwrite files recklessly. npm error A complete log of this run can be found in: /root/.npm/_logs/2025-10-19T09_03_30_940Z-debug-0.logI'm now using
npm install -g --force corepackReacted by GreyXorYou've raised a separate issue that occurs starting with Node.js 25 Docker images. These images have no Corepack pre-installed since Corepack is no longer bundled with Node.js starting with Node.js
25.0.0.To allow Corepack to install without error in containers based on Node.js
>=25Docker images, you would need to remove the Yarn v1 Classic symbolic links.To demonstrate:
docker run -it --rm --entrypoint bash node:25
rm /usr/local/bin/yarn* # remove Yarn v1 symlinks npm install -g corepack@latest # install Corepack
Using the Docker image
node:24, it is not necessary to remove the Yarn v1 symlinks before updating Corepack to the latest version.Reacted by peterhirn, Alex and David JeftsHi folks, it's interesting watching the discussion on this ticket. I understand the concern that removing Yarn v1 classic may break some users who depend on existing image.
I'm a bit skeptical that there are many users of the latest Node versions -- that is, users who are updating Node versions frequently -- who are still using Yarn v1 classic. But we must acknowledge that they may exist.
Q: Should we consider creating a named image variant which stops installing Yarn?
- Announce and publicize it (e.g. JS weekly news etc)
- Announce a date at top of README file by which the
no-yarnvariant will become the norm, and the installation of yarn will entirely cease - Observe the portion of pulls that move to new variants over time
My intent is to explore paths to de-couple the two concerns of (a) avoiding breaking existing users, and (b) beginning to publish an official no-yarn version for all the reasons mentioned in this thread and related issues.
Thoughts?
I took a quick look at the potential size savings by removing Yarn v1 Classic:
Image uncompressed uncompressed no Yarn savings MB savings % node:22.21-alpine3.22 161.97MB 156.6MB 5MB 3% node:22.21-trixie-slim 230.65MB 223.41MB 7MB 3% node:22.21-trixie 1.22GB 1.21GB 0.01GB 1% This probably isn't significant enough to motivate a change in itself.
The remaining argument is that Yarn v1 Classic is frozen, unsupported and unmaintained, although the source repo https://github.com/yarnpkg/yarn hasn't been archived. The npm package yarn (last published as
1.22.22in March 2024) hasn't been deprecated either and there has been no end-of-life declared on it.12 remaining items
I suggest to remove Yarn v1 Classic bundling from future Node.js 26.x Docker image releases and leave it in the existing currently supported release lines Node.js 20.x, 22.x, 24.x & 25.x of the Docker images.
Node.js generally follows the strategy of not removing support for associated dependencies or bundles during the lifetime of each release line.
My understanding is that it would not be aligned to the general strategy to remove Yarn v1 from currently supported release lines. It would need to remain in. That understanding would need to be confirmed by the Docker Working Group / Node.js TSC.
Conversely, and with the same assumption, if Yarn v1 is allowed to be distributed with Node.js 26.x Docker images, that would imply continuing the bundling until the end-of-life of Node.js 26.x, projected to be 2029-04-30. That would be 5 years after the release of yarn@1.22.22 and 9 years after the announcement of freeze of Yarn v1 with the release of Yarn 2. That is an exposure to an unsupported component that should be avoided.
Suggested strategy
Node.js Release line End-of-life Yarn v1 bundled 20.x 2026-04-30 YES 22.x 2027-04-30 YES 24.x 2028-04-30 YES 25.x 2026-06-01 YES 26.x 2029-04-30 NO >26.x various NO Reacted by Beth Griggs, Karl Horky, peterhirn, yosifkit and Stewart X AddisonThe new signing key for Yarn v1 (see #2364) expires on 2030-01-27 and the Yarn team have expressed their hope that users will have migrated away from Yarn v1 by then. The implication also is that they may not renew the key after that date, and it should be considered as a planning end-of-life date for Yarn v1, even if it hasn't been explicitly expressed as such.
# pub ed25519 2026-01-28 [SC] 4EF8 150F 4F2D 7DE4 4F1D FF0B B428 79CC 6B38 E118 uid [ unknown] Yarn Packaging (2026) <yarn@dan.cx> sub ed25519 2026-01-28 [S] [expires: 2030-01-27]This should definitely happen; node doesn't ship with yarn and so the docker image never should have done so in the first place.
Reacted by Eric MORAND and Sebastian Beltran@ljharb absolutely. I would add that node.js is an ECMAScript runtime. It is used to execute some ECMAScript code and there is no need for any package manager to execute such code. When we deploy a Node.js container in our infrastructure, it is to execute ECMAScript code, not for anything else, and those package managers are never used. Actually, we have to remove them from the images before we build the containers because they are not compliant with our production servers rules - which legitimately must not contain any package manager or anything that is not required to execute the embedded application.
I'm still not sure why it was included to begin with. A person that would need a yarn image would just use a yarn image. This images needs to inherits from a Node.js image since yarn depends on Node.js. Not the other way around.
Reacted by peterhirn and Jordan HarbandLGTM. We might want to put something out on the socials saying that we're going to make this change, but doing it in the new version sounds reasonable to me and we can see if we get any pushback.
Reacted by Mike McCready, Michael Kesper and Jordan HarbandI've had another read through all of these comments (and the ones in the earlier issues) and I'm not seeing any strong objections to making this change from v26. Once the governance change has gone through I would propose that we get this merged. Worst case we can revert it if there are compelling reasons that subsequently show up. We can also reach out to the social teams to publicise this ahead of time. I will also note that one of the comments when this was discussed for Node 14 nearly 6 years ago was that yarn was the 24th most downloaded package in homebrew. It's now 338.
While we have mentioned the possibility of having duplicate images with/without yarn I think the overhead is best avoided and that having a clean break with v26 is the approach we should take here.
Reacted by Mike McCready, yosifkit and Marc SiegelThe status now is that Yarn v1 Classic has been designated for discontinuation in future releases, starting with the upcoming Node.js 26 release.
README > Yarn v1 Classic bundling documents this.
To avoid disruption to existing usage, it is not planned for removal from existing supported release lines (currently 20, 22, 24 & 25) and it would continue to be bundled in any new builds until each of these release lines reaches their own end-of-life milestone.
This still needs a technical implementation so that bundling is dependent on the version of Node.js.
Possibly this issue should be closed now, and a new one opened to track the implementation?
Reacted by peterhirn, Jordan Harband and Marc SiegelReacted by Eric MORAND, Jordan Harband and Karl HorkyI suggest to now close this issue, and track further progress through issue #2407
Reacted by Marc SiegelThank you @MikeMcC399. Closing now as the path forward has been decided. Agree to track progress towards Yarn v1 removal in Node 26 in #2407.
Really appreciate the way open source collab played out here, it’s a great thing to be able to file a ticket and see a community collaboratively find a sensible path forward like this.
Reacted by Mike McCready and Jordan Harband- added a commit that references this issue
on Jun 3, 2026
UPDATE: IN PROGRESS
Please follow progress in #2407
Problem
Yarn v1 is included in the
docker-nodeimages, however it is receiving only limited security updates and the guidance has been to migrate to modern Yarn since 2020.Especially for smaller images like Alpine, this dependency contributes to the size of the base, but seems unlikely to be used widely.
Solution
Remove the installation of Yarn v1 from the
docker-nodebase images. Document best ways to then add Yarn v1 if needed.Alternatives to Consider
ARGto the base image which chooses a Yarn version to isntallno-yarnwhich does not contain yarn, but continue to install on other variants