Repository navigation
Release corepack@1.0.0 #687
Description
Activity
I'd suggest to disable auto-pinning before tagging 1.0 stable.
Reacted by Mike McCready, Steven, Jordan Harband, zanminkian, 朝倉水希, Clément Grégoire, Nathan Bierema, Jeff Marks, Brian Buchalter, Mark Florian and 1 more#202 should also be fixed.
Without a fix, stored package manager versions are used, based on whatever version was current at the time of a Corepack release, instead of using the version from
lastKnownGood.jsonthat can be set explicitly bycorepack install -g.This means, for instance, that commands which might be expected to be identical are run with differing versions of Yarn.
Based on
corepack@0.32.0andyarn@4.9.1on Ubuntu22.04.2LTSrm -rf ~/.cache/node/corepack npm install corepack@latest -g corepack install yarn@stable -g cd $(mktemp -d)
Command Version yarn dlx create-viteyarn@4.6.0yarn create viteyarn@4.9.1I'd suggest to disable auto-pinning before tagging 1.0 stable.
Thanks for disabling this in corepack@0.33.0!
One less blocker for a production-ready release!
Could the maintainers please respond about their plans for this repo?
It seems that there is now very little activity. PR #647 is stalled and there are several new issues that are getting no response.
Is there any likelihood that Corepack will ever achieve a
1.0.0release status?Should users expect that there will be improvements to Corepack, or is it now effectively frozen, apart from necessary fixes to keep it aligned with shipping Corepack bundled with Node.js
20.x,22.xand24.xuntil these reach their respective end-of-life milestones?Is there any likelihood that Corepack will ever achieve a
1.0.0release status?I don't personnally see a benefit to bringing it to 1.0, and I don't see it as frozen either. I just don't have bandwidth to spend on tasks that don't directly matter to Yarn.
Reacted by Mike McCreadyThanks for explaining your bandwidth constraints! That does however seem to leave a gap unless there are going to be other active maintainers looking after the interests of npm and pnpm users.
I've been reading up on corepack GitHub issues for a while now, since Node.js decided to drop it in v25+ in March 2025.
@MikeMcC399 already has contributions on the project and has been active responding on the issues. I think they should be made a co-maintainer. They weren't interested when I'd proposed it in April 2025 in #681 (comment).
Nothing has changed since my previous #681 (comment). My bandwidth is also taken up with other repos that I maintain, and since one of those repos depends on Corepack this explains my continued interested in Corepack. This however shouldn't be interpreted to mean that I want to become a maintainer here and I cannot fulfil your wish for you to see me in this role. Hopefully there will be others with time and skills to fit the need.
Corepack seems to be in an odd position because the world has changed since it was first introduced:
- yarn can set the project's version https://yarnpkg.com/cli/set/version
- pnpm can set the project's version https://pnpm.io/settings#managepackagemanagerversions
- npm can kind of set the project's version (but not auto update) https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines
So it seems like npm would benefit most from corepack but it also seems like the package manager least willing to cooperate with corepack.
If that's the case, should we wait and/or follow-up for yarn classic to add version manager option in yarnpkg/berry#6443, and work towards deprecation announcement of corepack?
Releasing 1.0.0 might be a hint to corepack users that it's going to be supported long term.
The npm trends data shows corepack is hovering around 2M downloads a week though.Being a long-term corepack user, I'll be sad to move away from corepack.
But if I do need to move away, I'll look at what it helped achieve, i.e. creation of Package Metadata Interoperability Collab Space and pushed for standardizing devEngines field.work towards deprecation announcement of corepack?
No, since it's not deprecated. People will have to install it manually from npm for the time being, and it's possible that in the future better alternatives will become available and build up on the standard Corepack provides, but it's not the case right now and until then Corepack should remain in its current state: experimental, not yet a final product, but not something end of life.
and pushed for standardizing devEngines field.
I have no interest supporting this field in Yarn or any Yarn-derived tool right now.
Reacted by Trivikram KamatShould we provide a summary and close this issue as corepack is not going to reach 1.0.0 in short-term?
A new issue can be created in future, when (and if) required.Should we provide a summary
I'm not sure how you would summarize the status better than the response in #687 (comment)
The status doesn't seems to fit well into any of the standard Node.js Stability index categories, although officially Corepack is still declared as Experimental on https://nodejs.org/docs/latest/api/corepack.html :
Status Applicability Stability: 0 - Deprecated There has been no deprecation announcement, only a decision not to distribute Corepack in Node.js 25 and above Stability: 1 - Experimental This is the current formal category for Corepack according to https://nodejs.org/docs/latest/api/corepack.html Stability: 1.0 - Early development Corepack has already passed this stage Stability: 1.1 - Active development Corepack has already reached minimum viability, however maintainer feedback indicates that development is no longer active Stability: 1.2 - Release candidate There is no indication of a goal for Corepack to become stable (subject of this issue) Stability: 2 - Stable The Node.js TSC declined to give Corepack a Stable status in their vote on Mar 19, 2025 Stability: 3 - Legacy This is a possible status only if Corepack passes through a Stable status ... and close this issue as corepack is not going to reach 1.0.0 in short-term? A new issue can be created in future, when (and if) required.
The issue should only be closed if there is a decision that Corepack will never attempt to achieve Stable status. If this is the case then a re-categorization as Deprecated could be appropriate, however that decision should not be taken lightly.
IMO corepack has lost relevance to both Yarn and pnpm. At this point it causes more problems for us than it solves. Feel free to remove pnpm support from corepack.
Reacted by Steven and Ruy AdornoReacted by Aviv Keller, Leonardo Rocha, Matt Mower and Md Asadujjaman BappiDocumentation change for pnpm noted:
pnpm installation 11.x & pnpm installation 12.x no longer recommend Corepack.
pnpm installation 10.x is the last version to mention Corepack. pnpm 10.x is no longer actively maintained.
Is your request related to a problem? Please describe.
On 2025-03-19, the Node.js TSC voted to stop distributing corepack in Node.js v25+
Corepack will continue to be available on npm, but users have to globally install it using
npm install -g corepack. If users install it from npm, they don't have to runcorepack enablelike they have to when using the version distributed through npm.However, there are users who like corepack to manage their package manager versions and would like to continue globally installing it. There are many sources for this.
Many folks in the software industry associate v1.0.0 as stability. There are some who consider everything with 0.x as unstable irrespective of the popularity or usage. As corepack is not going to be distributed though Node.js, the users have to globally install it with
npm install -g corepack. Although it doesn't show version, there are some users who might check the latest version on npm and may not install it if it's still 0.xAt the time of comment, the latest version of corepack is v0.32.0. There are enough data points provided above that v1.0.0 can be published. The release of corepack@v1.0.0 will not affect it's experimental status in Node.js core while it's distributed in <=v24.
Describe the solution you'd like
If maintainers think it's ready, please release corepack@v1.0.0 so that the users who associate 0.x with instability will no longer hesitate to install corepack.
If maintainer thinks it's not ready, please use this issue or create a new issue/milestone/label for tracking the v1.0.0 release.
Describe alternatives you've considered
I personally don't have any issue with using corepack while it's 0.x
For folks who do, we can create documentation similar to what other popular tools who're on 0.x have done, like esbuild or ReactNative.
Additional context
This was suggested in #104 (comment)