Hello @RichiCoder1. Thank you for your feature request. Actually we had similar proposal to enable corepack by default. I think we should reinvestigate adding corepack support. We'll ping you about its results.

@dmitry-shibanov apologies for not seeing that closed ticket! I very much hope ya'll do. While technically experimental, it's being officially recommended and there's no (current) way to use both this action and corepack without some awkward contortions. Looking forward to the outcome!

I use corepack locally and hope we can integrate it with GitHub Actions :)

If I'm understanding correctly, right now you can run setup-node, set up Corepack, and then run the standalone cache action. So is the benefit of this just to be able to do it all inside the setup-node action?

Thank @brcrista ! Could you share a minimal config to achieve this? I may not understand how to set up corepack manually here.

I don't know either, I was just summarizing my understanding from the issue description.

The semi-simple way w/ caching and something like pnpm would be:

- run: corepack enable
- uses: actions/setup-node@v3
  with:
    node-version: 16
    cache: pnpm
- run: pnpm i

I think that may be faintly fragile as corepack enable operates on the built in node and not the potentially installed one. It does however fix an issue where setup-node will look for a pnpm exe/cache that doesn't exist yet when setting up cache I think.

@brcrista and your understanding is correct. Ideally with some extra smarts enabled by knowing exactly which packageManager is in use.

@RichiCoder1 thanks for you notification, it was a good point to review, but we should not go ahead of nodejs team and turn on corepack by default while it is not default for the nodejs itself.
The consequences of having corepack enabled are risky for some builds and adding new input is not necessary complication of the action and its documentation.
In the current state of the corepack to have an explicit simple step enabling the feature seems to be optimal solution.

I have to reject the feature request and close the issue, but please feel free to reopen it or create new one in case you still have some problems.

That's unfortunate; I avoid using the cache feature of the action because I'm nervous of mixing different major npm versions' caches. Having a corepack opt-in would compose well there, but I guess I'll just keep using the 4 steps (!) of setup-node, enable corepack, get cache location, cache, or keep mixing the npm version into the cache key.

@dsame perhaps you can close this issue as not planned instead of completed?

We can leave this open to see if it continues to attract attention. We're not going to do anything about it right now for the reasons that @dsame shared. When Node makes Corepack the default, we can revisit it.

There is the perfectly fine alternative for now to just have corepack be opt in. Lets people use it without conflicting with the action, and makes flipping the switch later easy.

Edit: I missed this statement:

adding new input is not necessary complication of the action and its documentation.
In the current state of the corepack to have an explicit simple step enabling the feature seems to be optimal solution

I strongly disagree. As noted above, this doesn't account for this action installing an alternative Node (and possibly breaking the enablement) and it doesn't solve caching whatsoever.

I strongly agree with @RichiCoder1 and would even go for a fork of setup-node with corepack support to achieve this goal.

For yarn and pnpm users there seem to be no reliable workflow to use setup-node with proper caching at the moment.

Please also keep in mind, that for GitHub Enterprise users there is in most cases neither node preinstalled on runners nor are they able to customize their runners because they are managed by company IT.

I just made a PR to fix the tests for the PR of BeeeQueue.

This would add optional corepack support by simply setting corepack: true in the action inputs.

The PR adds 3 little lines of code to the main.ts of setup-node and one new input which is easy to understand and should not overcomplicate things. The documentation and action manifest update is done and the new code is also covered in tests.

And as a bonus - as corepack is completely optional - this feature is not a breaking change and could be published right away as a minor version update for v3.

In regards to attention on this topic:

• there are currently 2 open PRs who are trying to bring corepack support to setup-node.
• there are 3 open issues regarding corepack support (Corepack Support #531, feature request: cache: 'auto' #306, Yarn is not installed #182) where 2 of them have ongoing and recent activity.
• and you can be sure there are a lot of yarn and pnpm users out there as well as users of self-hosted runners with GitHub Enterprise who would be very thankful if this feature would be added.

That would be great to have it as an input
"corepack: true"
As each of my actions have to do "corepack enable"

Ok, bare with me everyone, I have been dealing with this for some time now I an just getting back to my device. I might need assistance

I notice that I can achieve this mechanism simply with:

      - name: Enable Corepack
        run: corepack enable

Thus, I'm OK with current status and don't find this issue a blocker to me :)

See this workflow as an example.

• I am surprised that this is actually an issue, corepack is still in the experimental stage and of course needs to be manually enabled. I myself have been using corepack enable && corepack prepare pnpm@7.11.0 --activate.

• This issue should actually be closed and wait for nodejs to enable corepack by default.

@tisonkun you're not even using setup-node...

Ideally, setup-node optionally supports corepack, since Node optionally supports it. For example:

- uses: actions/setup-node@v4
  with:
    node-version: 16
    corepack: true
    cache: true
    install: true

This would install Node 16, run corepack enable, read the packageManager field, set up the cache for that, and then call the package manager in the correct way for CI (npm ci, pnpm i etc).

Yarn's documentation shows corepack enable as the only way to install Yarn other than from git source (yarn set version from sources). Seems like this basically is required for Yarn, despite it being experimental. 🐔🥚

This is even more important now that Yarn no longer sets yarnPath by default in Yarn 4. When yarnPath is set it "just works" since the Yarn Classic binary that comes pre-installed on the GitHub runner images consults the yarnPath setting.

Curtis,

Hello yes this is tech support how can we help you?

Regards
Tech Support

actions/setup-node@v3 stopped working today, throwing the following error:

Error: This project's package.json defines "packageManager": "yarn@4.0.2".
       However the current global version of Yarn is 1.22.21.

actions/setup-node@v3 stopped working today, throwing the following error:

Error: This project's package.json defines "packageManager": "yarn@4.0.2".
       However the current global version of Yarn is 1.22.21.

Started seeing the same error today with cache: yarn too

actions/setup-node@v3 stopped working today, throwing the following error:

Error: This project's package.json defines "packageManager": "yarn@4.0.2".
       However the current global version of Yarn is 1.22.21.

Same with cache: yarn

actions/setup-node@v3 stopped working today, throwing the following error...

@koistya: Please raise a separate GitHub issue for that error. It is not the same as the important feature request which is the subject of this issue. Please do not overload this discussion any more other than to post a link to that separate error report.

actions/setup-node@v3 stopped working today, throwing the following error:

Error: This project's package.json defines "packageManager": "yarn@4.0.2".
       However the current global version of Yarn is 1.22.21.

Started seeing the same error today with cache: yarn too

You should be able to fix this by adding the following env to your workflow SKIP_YARN_COREPACK_CHECK: true. But it's more of a workaround since having corepack in setup-node would be preferable.

@janpe so what's the correct and direct fix?

@janpe so what's the correct and direct fix?

I don't really have anything to add to my previous comment, but I'll repeat if I was unclear earlier.

So currently you have to add the following to fix your failing workflow

env:
  SKIP_YARN_COREPACK_CHECK: true

But hopefully in the future we'll see an option like proposed here added to setup-node: #480 (comment)

I make it work with actions v4 and yarn 4.x.
The trick should be to run corepack enable before everything else.

    steps:
    - uses: actions/checkout@v4
    - run: corepack enable
    - uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'yarn'
    - run: yarn install --immutable

The only issue I have is the cache is never found. This is my log

actions/setup-node@v4

node: v20.10.0
npm: 10.2.3
yarn: 4.0.2

/usr/local/bin/yarn --version
4.0.2
/usr/local/bin/yarn config get cacheFolder
/home/runner/.yarn/berry/cache
/usr/local/bin/yarn config get enableGlobalCache
true
yarn cache is not found

We might not need to change @actions/setup-node if this other PR gets merged:

• enable corepack by default nodejs/node#50963
• build: enable yarn and pnpm Corepack binaries by default nodejs/node#51886

But there is also a scenario where Corepack may stop working with future versions of Node.js if this PR gets merged:

• deps: remove corepack nodejs/node#51981

Feel free to add 👍 or 👎 to the linked PRs.

Regarding the comment made above by @styfle with the PRs listed about node enabling corepack by default or removing corepack from node, I'm copy and pasting my reply from PR #901 that is complete and ready for review:

My 2 cents: those do seem far away from reaching social consensus (there's still ongoing debate as of hours ago), let alone from being integrated into node. With the latest active LTS (v20) having maintenance until April 2026 (and v22 active LTS just around the corner), I think corepack with node will be here to stay for a while.

I don't know if your comment was to imply that this PR should be held off on being merged, but if so, I think it solves a popular usecase for many users that won't go away anytime soon and can be properly addressed if/when the decision to include/exclude corepack in node is finalized.