Skip to content
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

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

Open
2 tasks
trivikr opened this issue Aug 7, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@trivikr
Copy link
Contributor

trivikr commented Aug 7, 2024

  • 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.
  • Configuration: Requiring developers to install specific yarn version which manages itself.

Describe alternatives you've considered

@trivikr trivikr added the enhancement New feature or request label Aug 7, 2024
@arcanis
Copy link
Member

arcanis commented Aug 7, 2024

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
Copy link
Contributor Author

trivikr commented Aug 7, 2024

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
Copy link
Contributor Author

trivikr commented Aug 8, 2024

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
Copy link

zoontek commented Aug 19, 2024

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
Copy link

Julusian commented Sep 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants