Deprecate Yarn v1

[MikeMcC399]

Refs: #2264

Description

Deprecation information for (un)bundling of Yarn v1 Classic is added to the README.

Users with legacy needs are also advised that Yarn v1 can be installed with the following commands, according to Yarn installation instructions:

npm install --global yarn

This is possible, since Node.js bundles the npm package manager and so provides the prerequisites to use npm to install Yarn v1.

Motivation and Context

• Node.js Docker images bundle the Yarn v1 Classic package manager into each published image. This has been the case since Feb 2017
• Yarn v1 Classic package manager has been frozen since the release of Yarn 2 in January 2020 and is unsupported since then.
• https://yarnpkg.com/latest-version has remained at release yarn@1.22.22 since March 2024 in line with the frozen and unsupported status of this version
• Removal of Yarn v1 from Node.js Docker images has been proposed again and again over the years
• Yarn is not included in the Node.js distribution itself and so it is an exceptional addition into the Docker images

Assumption

According to the discussion in #2264 it's assumed here that Node.js Docker images will stop bundling Yarn v1 for Node.js release lines 26 and above, starting with the release of Node.js 26.0.0 (planned for 2026-04-22).

It's also assumed that Yarn v1 will continue to be bundled with currently supported Node.js release lines for legacy reasons. The end of availability of Docker images with Yarn v1 would then be when Node.js 24.x transitions into end-of-life planned for 2028-04-30.

Testing Details

N/A

Types of changes

• Documentation
• Version change (Update, remove or add more Node.js versions)
• Variant change (Update, remove or add more variants, or versions of variants)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (none of the above)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• All new and existing tests passed.

[MikeMcC399]

Preview

https://github.com/MikeMcC399/docker-node/blob/yarn-v1-deprecation/README.md#yarn-v1-classic-bundling

[sxa]

Suggest re-running that markdown check if possible - the "dead link" it was complaining about seems ok to me right now.

[MikeMcC399]

I'm requesting tsc-agenda on this PR (from associated issue #2264)

[sxa]

I'm requesting tsc-agenda on this PR (from associated issue #2264)

Noting an earlier comment stating that the TSC has never taken a position on this although as the WG is being fully de-chartered that may change ;-)

[MikeMcC399]

@sxa

I'm requesting tsc-agenda on this PR (from associated issue #2264)

Noting an earlier comment stating that the TSC has never taken a position on this although as the WG is being fully de-chartered that may change ;-)

The background for asking for the tsc-agenda is the proposal:

If a final decision cannot be made using Consensus Seeking, the issue should be
escalated to the Node.js TSC (for example by requesting tsc-agenda).

In that case, the Node.js TSC is the final arbiter, consistent with the
TSC Charter.

and the fact that the Docker Working Group has yet to be convened in its proposed new form (the old form is no longer active).

[sxa]

I can stick the agenda label on it and while I do do now have the authority to "just merge" this PR in the absence of any notable disagreement I'd rather not until the charter changes were in place therefore it would be preferable to have TSC confirmation that no-one there has any fundamental objections to making this change so I can add the tag as much for awareness than anything else. At the time of writing no-one other then me has given an approval on this PR.

If the TSC (or of course any of the earlier docker-node team) are happy with me going ahead and merging before the charter change goes through then they can let me know via this issue :-)

Also noting that I've raised an issue on the nodejs/snap repository about making the same change there. I think that's about the only other place that we have this concern. I'll also note that it would potentially be useful for us to have a team of people who can look at consistency across the different ways that we distribute node (Noting that we have the distros and delivery-channels teams - linked in the snap issue) but I don't think this sort of thing is necessarily within their remit. If the TSC thinks otherwise let me know.

[MikeMcC399]

@sxa

I think any decision should have wide consensus, so I wouldn't want to push you to decide on your own. The deadline would be the release date of Node.js 26.0.0 on 2026-04-22, however the sooner that there is a clear decision, the better it would be for everyone's preparation.

It's good that you thought about nodejs/snap for consistency. I've also reminded them to update their default version to Node.js 24 whilst I took a look in that repo once again!

[mcollina]

lgtm

[sxa]

TSC discussion from this week in case anyone's interested: https://www.youtube.com/live/9s-luy_kEuI?si=ep940kzPcbRWPXwe&t=669