Add corepack (instead of yarn)

[SpecLad]

Tool name

corepack

Tool license

MIT

Add or update?

• Add
• Update

Desired version

latest

Approximate size

1 MB (however, it's smaller than yarn, so this will actually decrease the image size)

Brief description of tool

Corepack provides shims for the Yarn and pnpm package managers that automatically download and run the version of the manager defined in package.json. Adding Corepack to the base image will let projects using pnpm and Yarn 2+ run these tools without an extra install step.

Currently, the runner images include Yarn 1.x. This should be deleted, as it will conflict with Corepack's yarn shim. The shim also uses Yarn 1.x by default in most cases, so most workflows should be unaffected by this change. The only observable incompatibility I could find is that yarn init will use Yarn 4.x if ran outside a project directory; however, since this command creates a new project, I would not expect to see it in a CI workflow.

URL for tool's homepage

https://github.com/nodejs/corepack

Provide a basic test case to validate the tool's functionality.

yarn --version
pnpm --version

Platforms where you need the tool

• Azure DevOps
• GitHub Actions

Runner images where you need the tool

• Ubuntu 22.04
• Ubuntu 24.04
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Can this tool be installed during the build?

npm install -g corepack

# Note that currently Node.js bundles a version of corepack where the shims are disabled by default.
# This version is slated to be removed in Node 25, so I think it's best to ignore it,
# and just install the latest from NPM.

Tool installation time in runtime

Negligible

Are you willing to submit a PR?

Probably not

[SpecLad]

FYI, I didn't tick any of the runner image checkboxes, since it seems to me that the best time to implement this will be when adding the next generation of operating systems. But I won't mind if this is implemented in existing images as well.

[kishorekumar-anchala]

Hi @SpecLad ,

Thank you for bringing this issue to our attention. We will look into this issue and will update you after investigating.


[MikeMcC399]

Please don't remove Yarn Classic! This would be a breaking change!

• Yarn Classic is still is widespread use, despite its maintenance mode status (see also Lifecycle planning / end-of-life? yarnpkg/yarn#9062)

corepack is not a drop-in substitute for Yarn Classic

Currently corepack is already part of all base images, since it is still bundled with Node.js. This is planned to change however - see Node.js 24 documentation corepack

[MikeMcC399]

Before deciding to add a separately installed version of corepack to GitHub runner images, I suggest that a review of corepack open issues should be done.

The latest release is currently corepack@0.33.0.

Corepack releases 0.y.z follow Semantic Versioning Specification for initial development and by this definition should not be considered stable. Corepack released through Node.js additionally carries the label Experimental - see Node.js documentation corepack and therefore not suitable for production usage.

[SpecLad]

Please don't remove Yarn Classic! This would be a breaking change!

Could you clarify how breaking it would be? As I've mentioned in my initial post, the only incompatibility I could find was with yarn init, which is not something I'd expect to see in a CI pipeline.

[MikeMcC399]

@SpecLad

Please don't remove Yarn Classic! This would be a breaking change!

Could you clarify how breaking it would be?

I don't think I'm able to say what it might break as that would mean that I knew about all GitHub workflows using Yarn Classic. It seems like a very courageous act to remove Yarn Classic and then rely on corepack.

As I've mentioned in my initial post, the only incompatibility I could find was with yarn init, which is not something I'd expect to see in a CI pipeline.

https://github.com/eslint/css/blob/main/.github/workflows/ci-build-all-pm.yml is an example of a workflow using yarn init (albeit with Yarn Modern, not Yarn Classic), however it does show that the assumption that yarn init is never used in any workflow is not correct.

[SpecLad]

I don't think I'm able to say what it might break as that would mean that I knew about all GitHub workflows using Yarn Classic.

I mean... you're the one saying that this would be a breaking change. How can you claim this if you don't know what would break?

[MikeMcC399]

@SpecLad

I don't think I'm able to say what it might break as that would mean that I knew about all GitHub workflows using Yarn Classic.

I mean... you're the one saying that this would be a breaking change. How can you claim this if you don't know what would break?

You're right. I've claimed it's a breaking change without providing any concrete example of a workflow where it would break. I will see if I can find any.