-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added option to enable corepack #901
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Steven <steven@ceriously.com> Co-authored-by: Sayak Mukhopadhyay <mukhopadhyaysayak@gmail.com> Co-authored-by: Jacob Parish <jacob.parish.1@gmail.com>
This works great for my use case. Looking over the code quickly, it also looks like this shouldn't introduce any breaking changes. Hoping this can get merged! |
Is there any point in making it optional? One can just ignore corepack if they don't want to use it. Everything else will still work as always. |
The biggest imo is it's still marked experimental. It is opt-in and should remain explicitly opt-in until it's part of stable node installation.
It will "transparently install [the package manager] if needed, and finally run it without requiring explicit user interactions" which can lead to unintended change in behavior compared to if it were not enabled. Also "Running npm install -g yarn doesn't work" which I assume is a fairly common command for those that don't have/want the pre-installed yarn that comes with github hosted runners (for example #182). Source: https://nodejs.org/docs/latest-v20.x/api/corepack.html Also just generally safer to be opt-in to have stronger guarantee that it doesn't break existing functionality and workflows. |
@rt-joe makes perfect sense. In this case, keeping it behind an input boolean should be enough |
Merging this would nicely simplify a few of my workflows quite a bit! Thanks @JP250552 |
const corepackArgs = ['enable']; | ||
if (input.length > 0 && input !== 'false') { | ||
if (input !== 'true') { | ||
const packageManagers = input.split(' '); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe also trim the input and split by \s+
to avoid issues due to leading, trailing and double-spacing, and also supporting multiline
Anything I can help out on to get this merged in? |
We are just waiting for reviews. @dsame Would you be able to take a look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the input corepack
is used here and there. But is it listed in /action.yml
?
PS: yes it is - #901 (comment)
- uses: actions/setup-node@v4 | ||
with: | ||
node-version: '18.x' | ||
corepack: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the input corepack
is not listed in /action.yml
did you forget to add it there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @JP250552! it looks like we got a couple more reviews and approvals that were needed. Is there anything I could potentially help out with here? Happy to get some of my team's resources on things if there is anything to help out with getting this in and included in an upcoming release. Thank you for all of your effort maintaining this community Action! |
@brianespinosa know anyone with repo write access that can review (and approve) this? |
Note that Corepack may stop working with future versions of Node.js if this PR gets merged: And we might not need to change gh actions if this other PR gets merged:
Feel free to add 👍 or 👎 to the linked PRs above. |
@styfle thanks for pointing those out, it's definitely worth noting. 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. |
Even if it ends up excluded, it should be a very small change to install corepack from npm instead of running |
We use Yarn heavily for our projects and I think it would be useful to have this option. I also don't see Corepack being removed at any point, but if we are concerned about that, perhaps it's worth highlighting the experimental nature of Corepack in the README? I can post a suggestion if that makes sense. |
const packageManagers = input.split(' '); | ||
corepackArgs.push(...packageManagers); | ||
} | ||
await getCommandOutput(`corepack ${corepackArgs.join(' ')}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking back at previous PRs, it was suggested that if Yarn ends up being enabled, any existing Yarn installation (which is evidently present on GitHub runners) should be uninstalled first: #482 (review). Is this is a concern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought corepack would interop with existing yarn installations (could be wrong)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the existing Yarn installation can be left as is and it won't cause conflict with the installed Yarn from Corepack.
@@ -59,6 +63,9 @@ export async function run() { | |||
auth.configAuthentication(registryUrl, alwaysAuth); | |||
} | |||
|
|||
const corepack = core.getInput('corepack') || 'false'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given that the yaml is structured and supports array, why not specifying the corepack
input in an array format?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For simplicity, i would prefer to keep it using a string as the input. But probably we can also make it support array, however currently there's no built-in function to do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be fine to use the PR as is or with an "experimental feature" / "only works with node versions ..." in the readme.
@@ -418,3 +418,30 @@ Please refer to the [Ensuring workflow access to your package - Configuring a pa | |||
|
|||
### always-auth input | |||
The always-auth input sets `always-auth=true` in .npmrc file. With this option set [npm](https://docs.npmjs.com/cli/v6/using-npm/config#always-auth)/yarn sends the authentication credentials when making a request to the registries. | |||
|
|||
## Enabling Corepack |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Enabling Corepack | |
## corepack input | |
**Experimental: This feature is marked as experimental in Node versions >=16.9 <=22. It will only ever be supported for node versions that support it.** |
is there any update on this? it would be awesome if this could get merged soon-ish. as many others, i am in the process of updating to yarn v4. this PR would simplify it greatly. we all know that corepack will stay for a few more years until it might get removed in a future LTS version and, looking at the history of this PR (and related issue), this action is not compatible with it since over a year. |
Okay so the way I see it, we are waiting on the issues linked here: #901 (comment) And until they're solved and a clear path is chosen, which might as well take even longer than Yarn classic will survive, we do absolutely NOTHING. |
Description:
Updated version of corepack support due to the original author not having time to refactor the original PR
Adds
corepack
option in which workflows can specifytrue
or a list of package managers to enable corepack accordingly.Related issue:
Check list: