You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ideally in between installing node and bootstrapping the package manager cache, this action:
enables corepack (could be a no-op depending on the node version)
caches/restores the corepack root
runs corepack prepare --active
(after some research, that last one may not necessary but instead makes an implicit step explicit)
This behavior could either be trigged by the presence of the packageManager field in the root package.json (might be suprising), cache: 'auto' as possibly envisioned in #306, or corepack: true
Justification:
Both pnpm and yarn support corepack, and yarn recommendeds corepack for package manager versioning. Currently using corepack with this action will break when using the cache key as this action assumes the appropriate version manager has already been installed. However, you don't necessarily want to bootstrap with corepack until the appropriate node version has been installed and configured.
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!
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?
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.
Reacted by Wout Mertens, Emilio Martinez, Marius Butuc, Fernando Pasik and helle253
@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.
Reacted by Jarrod Davis, Tetsuro Higuchi, Steven, Daniel Bayley, Ranieri Althoff, Konstantin Tarkus, Chris Weed, Mark H, Andrey (Andrii) Los, Grigory and 16 more
Reacted by Hugo Alliaume, Jackson Blankenship, Simon Lepel, yarinsa, Josh Wooding, Wout Mertens, Nwel, Tetsuro Higuchi, Steven, Mark H and 5 more
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.
However, what would be the recommended approach for supporting Node 25 in the future?
It won't supply the corepack anymore. So should I explicitly add the npm i -g corepack before the corepack enable npm?
I would say that even after all these years, I still oppose adding configuration support for corepack to actions/setup-node. Corepack is not actively maintained and is no longer built into NodeJS.
Reacted by Martin Adámek, Daniil Suvorov, Yaroslav Admin, Oleksandr Danylchenko, Joe, Filip Malinowski, Sʜɪᴍᴜʀᴀ Yū, Eduardo Sanchez, Mikey O'Toole, Nelson Martell and 3 more
Reacted by Filip Malinowski, Sʜɪᴍᴜʀᴀ Yū, Eli, Brian Kidd, Eduardo Sanchez, Chris Nielsen, Simon Rolland and Noah Sherwin
Reacted by Nikolai Røed Kristiansen, Christian Bewernitz, Daniil Suvorov, Oleksandr Danylchenko, Yaroslav Admin, Joe, Filip Malinowski, Steven, Eli, Brian Kidd and 2 more
According to the decision made in pnpm/pnpm#11732 (comment) , the pnpm community has essentially removed pnpm's support for corepack. I don't see any point in pretending that corepack is still compatible with third-party package managers within its git repository.
@oleksandr-danylchenko even though Node.js soon (i.e. next LTS) drops support and pnpm/Yarn deprecate corepack, there is no plan for GitHub runners to drop corepack. It would be responsible if they support corepack at least until actions/setup-node supports all the next generation solutions from these respective package managers.
Activity
dmitry-shibanov commentedon Jun 28, 2022
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.
RichiCoder1 commentedon Jun 28, 2022
@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!
tisonkun commentedon Aug 16, 2022
I use corepack locally and hope we can integrate it with GitHub Actions :)
brcrista commentedon Aug 16, 2022
If I'm understanding correctly, right now you can run
setup-node, set up Corepack, and then run the standalonecacheaction. So is the benefit of this just to be able to do it all inside thesetup-nodeaction?tisonkun commentedon Aug 16, 2022
Thank @brcrista ! Could you share a minimal config to achieve this? I may not understand how to set up corepack manually here.
brcrista commentedon Aug 16, 2022
I don't know either, I was just summarizing my understanding from the issue description.
RichiCoder1 commentedon Aug 16, 2022
The semi-simple way w/ caching and something like pnpm would be:
I think that may be faintly fragile as
corepack enableoperates on the built in node and not the potentially installed one. It does however fix an issue wheresetup-nodewill look for apnpmexe/cache that doesn't exist yet when setting up cache I think.RichiCoder1 commentedon Aug 16, 2022
@brcrista and your understanding is correct. Ideally with some extra smarts enabled by knowing exactly which packageManager is in use.
dsame commentedon Aug 17, 2022
@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.
jakebailey commentedon Aug 17, 2022
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.
65 remaining items
rt-joe commentedon Dec 2, 2025
The downvotes aren't because of the provided solution's ineffectiveness (it works) but because of setup-node inability to properly address it.
oleksandr-danylchenko commentedon Dec 10, 2025
Thanks, @fulldecent. The following solution worked for my
npmsetup:However, what would be the recommended approach for supporting Node 25 in the future?
It won't supply the
corepackanymore. So should I explicitly add thenpm i -g corepackbefore thecorepack enable npm?ci(github): Stop installing PNPM manually but leave it to Corepack
ci(github): Stop installing PNPM manually but leave it to Corepack
ci(github): Stop installing PNPM manually but leave it to Corepack
fix(ci): implement proper Yarn 4 caching with actions/cache@v5
linghengqian commentedon May 24, 2026
I would say that even after all these years, I still oppose adding configuration support for corepack to
actions/setup-node. Corepack is not actively maintained and is no longer built into NodeJS.trivikr commentedon May 24, 2026
This statement is incorrect.
linghengqian commentedon Aug 13, 2026
According to the decision made in pnpm/pnpm#11732 (comment) , the pnpm community has essentially removed pnpm's support for corepack. I don't see any point in pretending that corepack is still compatible with third-party package managers within its git repository.
zkochan commentedon Aug 13, 2026
Not only the pnpm community. Yarn as well, they have their new official version switcher: https://v6.yarnpkg.com/concepts/switch
Please, do not use corepack to install pnpm.
fulldecent commentedon Aug 24, 2026
Now that actions/setup-node@v7 is released, Yarn works for me (including cache) with @ildella's approach:
This should solve @xenoterracide's issue above, and @cowwoc's double setup-node workaround, which was previously best practice.
I now maintain a repo just for integration testing how Yarn installs on GitHub Actions.
@oleksandr-danylchenko even though Node.js soon (i.e. next LTS) drops support and pnpm/Yarn deprecate corepack, there is no plan for GitHub runners to drop corepack. It would be responsible if they support corepack at least until actions/setup-node supports all the next generation solutions from these respective package managers.
chore: move the actions and the toolchain off their first-commit pins
fix: keep .nvmrc readable on Windows and run CI on the Node it installs
chore: Node 24 LTS 승격 + 런타임·패키지매니저 버전 단일 출처화 (#14)
chore(ci): enable corepack before setup-node and drop the double setu…