[Feature] Alternative to Node.js experimental corepack to manage package manager version

[trivikr]

• I'd be willing to implement this feature (contributing guide)
• This feature is important to have in this repository; a contrib plugin wouldn't do

Describe the user story

Yarn recommends using experimental corepack to manage yarn versions https://yarnpkg.com/getting-started/install

At the time of writing, Node.js ships corepack which allows pinning the packageManager field in package.json. It's being used in at least tens of thousands of applications searchable in public code.

There has been asks to make corepack stable since May 2022 nodejs/corepack#104
The PR to enable yarn/pnpm corepack binaries by default in nodejs/node#51886, has moved from most approvals to most declines. There's an open PR to remove corepack too at nodejs/node#51981

I'm a very happy corepack+yarn user. I use it all the yarn modern projects I'm primary author of, like https://github.com/aws/aws-sdk-js-codemod, and have got consensus to use corepack in open source packages I maintain with other folks, like https://github.com/facebook/jscodeshift. I also closely monitor/participate in requests to enable corepack in other projects, like GitHub action to setup node in actions/setup-node#531

I'll very be sad when (and if) Node.js removes corepack in future, and have provided a wishlist to package-maintenance team to reduce the impact on ecosystem in nodejs/package-maintenance#609. If corepack can handle package-maintenance team specification, currently called devEngines, and if that helps to get it stable in Node.js core, that would be awesome.

Describe the solution you'd like

Provide some alternative to Node.js experimental corepack to manage yarn versions.

It can be as simple as recommending yarn users to install corepack from npm instead of using the Node.js provided one. This is feasible if corepack maintainers, many of whom help maintain yarn too, plan to continue developing it in case it's removed from Node.js core.

Or it can be like pnpm https://github.com/pnpm/pnpm/releases/tag/v9.7.0, which released a configuration manage-package-manager-versions to manage it's own versions instead of depending on corepack. It may be nice to have similar configuration for yarn users instead of depending on corepack.

Describe the drawbacks of your solution

• Install corepack from npm: Dependency on npm to install corepack.
  • The Node.js core decided in March'24 that removing npm is a non-goal with 17 approvals doc: state that removing npm is a non-goal nodejs/node#51951, so this wouldn't a problem.
• Configuration: Requiring developers to install specific yarn version which manages itself.

Describe alternatives you've considered

• Following up on https://github.com/nodejs/corepack repo on what the maintainers plan to do there.
• Following up on devEngines specification in feat: add proposal for binary management nodejs/package-maintenance#594, and who plans to implement it.
• Switching to a different package manager, like pnpm v9.7.0, which manages it's own version by referring packageManager field introduced by corepack in existing applications.

[arcanis]

The current alternative is to use yarnPath, but we're discussing adding packageManager support to the yarn npm package, so that users can either use npm install -g corepack or npm install -g yarn and have things work.

Of course the friction is still significantly higher than not having to do any of those two actions, and I hope the Node.js leadership will recognize in time its internal brigading issues on all subjects even tangentially related to Npm Inc.

[trivikr]

The current alternative is to use yarnPath

This usually requires yarn binary to be present in the repository, and many people didn't like the idea of adding a binary to their repository as explained in Yarn 4.0 blog post https://yarnpkg.com/blog/release/4.0#installing-yarn

we're discussing adding packageManager support to the yarn npm package

This would be a great solution, if implemented.
Yarn users don't need to have modern versions of yarn to manage yarn versions.

use npm install -g corepack

Although this is the easiest option for everyone looking at the current friction, it may not be worth developing corepack further. Especially if alternative package managers, like https://github.com/pnpm/pnpm/releases/tag/v9.7.0, are deciding to manage their own versions and npm wants to remove itself from corepack in nodejs/corepack#418.

[trivikr]

Socket Security wrote a blog post summarizing decision from Node.js PMWG (Package Maintenance Working Group)

https://socket.dev/blog/node-js-takes-steps-towards-removing-corepack

[zoontek]

This usually requires yarn binary to be present in the repository, and many people didn't like the idea of adding a binary to their repository as explained in Yarn 4.0 blog post https://yarnpkg.com/blog/release/4.0#installing-yarn

I would like to add my grain of salt here.

A lot of users never migrated to Yarn v2, as the changes were just too big (PnP by default, corepack, not installed globally anymore) and some people just waited for alternatives to emerge (pnpm).

I think this will be perceived as a regression for a lot of users, but:

• Migrate away from corepack
• Make node_modules the default linker (PnP will still be available - just not the default)
• Remove the need to commit yarn into your repo
• Make it manage its own version, using packageManager

Could be a great move to (finally) get rid of yarn legacy (v1)

[Julusian]

One concern I have with the suggestion to install corepack from npm is that in some cases users will then also have to manage the corepack version too.
Not only making sure to update corepack at times, but sometimes pinning the version being installed in their ci scripts, because there are times when it is necessary to use an end of life nodejs version that the latest corepack has dropped support for.
Maybe this is an unavoidable problem, as whatever provides those shims will need this unless it is capable of self-updating. But it worked so nicely with corepack shipped by node, as you knew you would have a compatible version, andt that it would get updated.

A bunch of my libraries are still using 14 in ci simply because there isn't a compelling reason to do a major version bump every year to drop support for the newly end of life release, and doing so is unnecessary friction for users.