Skip to content

Corepack Support #531

Open
@RichiCoder1

Description

@RichiCoder1

Description:
Support using https://github.com/nodejs/corepack to manage non-NPM package managers.

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.

Related: #530 #182

Are you willing to submit a PR?
Yes

Activity

dmitry-shibanov

dmitry-shibanov commented on Jun 28, 2022

@dmitry-shibanov
Contributor

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

RichiCoder1 commented on Jun 28, 2022

@RichiCoder1
Author

@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!

self-assigned this
on Aug 15, 2022
tisonkun

tisonkun commented on Aug 16, 2022

@tisonkun

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

brcrista

brcrista commented on Aug 16, 2022

@brcrista
Contributor

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?

tisonkun

tisonkun commented on Aug 16, 2022

@tisonkun

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

brcrista

brcrista commented on Aug 16, 2022

@brcrista
Contributor

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

RichiCoder1

RichiCoder1 commented on Aug 16, 2022

@RichiCoder1
Author

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.

RichiCoder1

RichiCoder1 commented on Aug 16, 2022

@RichiCoder1
Author

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

dsame

dsame commented on Aug 17, 2022

@dsame
Contributor

@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.

73 remaining items

rt-joe

rt-joe commented on Oct 9, 2024

@rt-joe

the current issue is trying to introduce a feature that is about to be removed, which is unreasonable.

Even if it were removed today, node v20 is supported until April 2026 and soon to be LTS v22 into 2027/2028 (idk exact date) and they both include corepack. There's been arguments for/against corepack for a long while, many of which were already mentioned in this issue. We've already wasted 2+ years (since at least this issue was opened, although corepack has been around much longer) without proper support despite the high popularity of this "experimental" feature. We can still get 2-3 more years of usage and easily remove it if/when it is finally decided to put corepack to rest which I'm guessing would be v24 at the earliest.

That being said, I agree with what @karfau said as well.

karfau

karfau commented on Oct 9, 2024

@karfau

Has anybody attempted to create a PR for this?

Yes: #901

I think it should be fine to use the PR as is or with an "experimental feature" / "only works with node versions x-?" in the readme, and deal with the topic of extending the support in a different way, when the related node version is released.

trivikr

trivikr commented on Mar 20, 2025

@trivikr
Contributor

The Node.js team has decided to stop distributing corepack from v25+ onwards in TSC vote nodejs/TSC#1697 (comment)

However, recent updates indicate that the developers will continue to use corepack, but install it from npm instead.
I've summarized some updates in nodejs/corepack#681 (comment)

It would be awesome if setup-node action accepts a configuration, say corepack: true suggested in PR #901, which installs the latest version of corepack from npm and enables it.

benquarmby

benquarmby commented on Mar 21, 2025

@benquarmby

...which installs the latest version of corepack from npm

Wholeheartedly agree with that plan, with one small tweak.

For those concerned with stability / security, there needs to be a way to pin to a specific corepack version rather than use @latest. This mirrors how Node.js distributes corepack today; one specific version per release. Teams can use tools like renovate or dependabot to prompt for stable upgrades with a visible code change. That would reduce the vector for supply-chain attacks and avoid dealing with day-zero bugs. Even for those who don't care about the risks of @latest, there needs to be an escape hatch in case the bleeding edge is broken.

Edit: This is now implemented in #901, thank you @jrparish

SpecLad

SpecLad commented on Jun 4, 2025

@SpecLad

I submitted an alternative proposal, which is to add Corepack to the base runner images: actions/runner-images#12310. If that's implemented, then no changes to the action will be required.

fulldecent

fulldecent commented on Jun 10, 2025

@fulldecent
Contributor

Here is the workaround GitHub Actions workflow I use to workaround how setup-node does not handle corepack.

https://github.com/fulldecent/github-pages-template/blob/e000f740424695642b479074872fc32835aa6be2/.github/workflows/code-lint.yml#L19-L26

This does NOT support caching.

Would love to see others' live workflows that are working around the issue.

benquarmby

benquarmby commented on Jun 10, 2025

@benquarmby

I submitted an alternative proposal, which is to add Corepack to the base runner images...

Here is the workaround GitHub Actions workflow I use...

Thanks for the contributions. However, neither of these address the chicken / egg problem for self-hosted runners where we can't assume an existing Node installation. We're starting from a clean slate as explained here: #182 (comment)

In the mean time, I've just gotten used to doing this for every single workflow. It's not great, but it works:

steps:
  - name: Install Node.js
    uses: actions/setup-node@v4
    with:
      node-version-file: .nvmrc
  - name: Enable Corepack
    run: corepack enable
  - name: Configure Dependency Cache
    uses: actions/setup-node@v4
    with:
      cache: pnpm
rt-joe

rt-joe commented on Jun 11, 2025

@rt-joe

I use the same double setup-node as @benquarmby. Also previously stated in this thread over 2 YEARS ago 😒

The amount of times I've had to put that into a workflow w/ a comment about why it's duplicated with a link to this issue... 🙄

vishnup-ditto

vishnup-ditto commented on Jun 12, 2025

@vishnup-ditto

I submitted an alternative proposal, which is to add Corepack to the base runner images...

Here is the workaround GitHub Actions workflow I use...

Thanks for the contributions. However, neither of these address the chicken / egg problem for self-hosted runners where we can't assume an existing Node installation. We're starting from a clean slate as explained here: #182 (comment)

In the mean time, I've just gotten used to doing this for every single workflow. It's not great, but it works:

steps:

  • name: Install Node.js
    uses: actions/setup-node@v4
    with:
    node-version-file: .nvmrc
  • name: Enable Corepack
    run: corepack enable
  • name: Configure Dependency Cache
    uses: actions/setup-node@v4
    with:
    cache: pnpm

Hi @benquarmby , have you every tried this with yarn as the package manager. I assume the caching mechanism should work but wanted to check

benquarmby

benquarmby commented on Jun 12, 2025

@benquarmby

...have you every tried this with yarn as the package manager?

With yarn 1.x, yes. This was working just fine before switching to pnpm. Never tried with yarn berry.

Note that the action is smart enough to only perform the caching steps on the second run. It doesn't try to install Node again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestNew feature or request to improve the current logicneeds eyes

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Participants

      @wmertens@ildella@nikolaik@karfau@koistya

      Issue actions

        Corepack Support · Issue #531 · actions/setup-node