corepack icon indicating copy to clipboard operation
corepack copied to clipboard

Release [email protected]

Open trivikr opened this issue 8 months ago • 5 comments

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 run corepack enable like 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.

  • For explicit request, check https://github.com/nodejs/corepack/issues/681
  • Comments and reactions to requesting removing experimental status for corepack from Node.js in https://github.com/nodejs/corepack/issues/104 and https://github.com/nodejs/node/issues/50963, while it was open to discussion.
  • Increase in npm download counts by 10X to 2M+ per week in early Feb 2025, when there was an issue with npm rotating the keys which affected pnpm installations from corepack.
  • The documentation in yarn and pnpm already recommend installing corepack globally from npm.

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

At 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 [email protected] 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 [email protected] 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 https://github.com/nodejs/corepack/issues/104#issuecomment-2746172451

trivikr avatar Mar 23 '25 17:03 trivikr

I'd suggest to disable auto-pinning before tagging 1.0 stable.

arcanis avatar Mar 23 '25 19:03 arcanis

Open issues should be reviewed to determine if any are blockers to declaring Corepack "production-ready" ~~@arcanis already suggested #485~~ Edit: resolved

MikeMcC399 avatar Apr 08 '25 08:04 MikeMcC399

https://github.com/nodejs/corepack/issues/616 also seems like it ought to be defined as a blocker. The related PR https://github.com/nodejs/corepack/pull/647 looks like it has stalled waiting for maintainer feedback.

MikeMcC399 avatar Apr 22 '25 13:04 MikeMcC399

#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.json that can be set explicitly by corepack install -g.

This means, for instance, that commands which might be expected to be identical are run with differing versions of Yarn.

Based on [email protected] and [email protected] on Ubuntu 22.04.2 LTS

rm -rf ~/.cache/node/corepack
npm install corepack@latest -g
corepack install yarn@stable -g
cd $(mktemp -d)
Command Version
yarn dlx create-vite [email protected]
yarn create vite [email protected]

MikeMcC399 avatar May 09 '25 05:05 MikeMcC399

@arcanis

I'd suggest to disable auto-pinning before tagging 1.0 stable.

Thanks for disabling this in [email protected]!

One less blocker for a production-ready release!

MikeMcC399 avatar Jun 04 '25 10:06 MikeMcC399

Could the maintainers please respond about their plans for this repo?

It seems that there is now very little activity. PR https://github.com/nodejs/corepack/pull/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.0 release 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.x and 24.x until these reach their respective end-of-life milestones?

MikeMcC399 avatar Jun 24 '25 07:06 MikeMcC399

Is there any likelihood that Corepack will ever achieve a 1.0.0 release 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.

arcanis avatar Jun 24 '25 07:06 arcanis

@arcanis

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

MikeMcC399 avatar Jul 01 '25 15:07 MikeMcC399

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 https://github.com/nodejs/corepack/issues/681#issuecomment-2829546843.

trivikr avatar Jul 01 '25 17:07 trivikr

@trivikr

Nothing has changed since my previous https://github.com/nodejs/corepack/issues/681#issuecomment-2829546843. 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.

MikeMcC399 avatar Jul 01 '25 17:07 MikeMcC399

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.

styfle avatar Jul 01 '25 19:07 styfle

If that's the case, should we wait and/or follow-up for yarn classic to add version manager option in https://github.com/yarnpkg/berry/issues/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.

trivikr avatar Jul 01 '25 20:07 trivikr

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.

arcanis avatar Jul 01 '25 21:07 arcanis

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

trivikr avatar Jul 01 '25 21:07 trivikr

@trivikr

Should we provide a summary

I'm not sure how you would summarize the status better than the response in https://github.com/nodejs/corepack/issues/687#issuecomment-3025544220

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 is no longer actively maintained

... 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 Legacy could be appropriate, however that decision should not be taken lightly.

MikeMcC399 avatar Jul 04 '25 11:07 MikeMcC399