Wishlist on managing package manager versions in a Node.js application

[trivikr]

Is your feature request related to a problem? Please describe.

There are several discussions about managing package manager version in the past.

At the time of writing, i.e. 2024-07-30, Node.js ships experimental 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 https://github.com/nodejs/corepack/issues/104 The PR to enable yarn/pnpm corepack binaries by default in https://github.com/nodejs/node/pull/51886, has moved from most approvals to most declines. There's an open PR to remove corepack too at https://github.com/nodejs/node/pull/51981

The tweets about corepack often go viral, like ones by Matt https://twitter.com/search?q=from%3Amattpocockuk%20corepack&src=typed_query, and then some discussions happen Twitter threads which aren't documented.

Here is some wishlist I would like to share:

• As a Node.js user, I want an built-in way to manage my package manager version, like corepack.
• As a corepack user, I don't want my application which specified packageManager field to break.
• As a Node.js user, I'm open to experiment with alternatives, like devEngines.

Describe the solution you'd like

Based on requirements, and consensus in devEngines proposal as of July 2024, here is what a good solution may look like:

• Do not break applications which use packageManager field.
• Implement devEngines specification, and provide an easy built-in way for users to use it. This can be corepack or something else. It doesn't matter as long as it ships with Node.js and is easy to use.

Over time, if there's data that one specification is better than other, then add doc/runtime deprecations and provide a migration path to the preferred one.

Describe alternatives you've considered

• Switch to installing corepack from npm.
• Switch to a different runtime, like Deno/Bun.

Additional context

Originally posted as a tweet in https://twitter.com/trivikram/status/1818303053902307479. A GitHub issue was created as per response from @wesleytodd

[trivikr]

I'm not too happy with the existing title Wishlist on managing package manager versions in a Node.js application, as it's too generic. Do suggest a better one in the comments, if you come across one.

[alexaka1]

Describe alternatives you've considered

• Switch to installing corepack from npm.

I think this outcome is the one that should be avoided. Why? Bad defaults.
I spend way too much time finding people npm i yarn at work and online, and then I always have to spend 30 minutes explaining to them what yarn is in 2024, what corepack is and why This is the way.
People don't know what corepack is, because it's not enabled by default.
The breaking changes of Yarn 2 have left behind a generation's worth of outdated new code, just because the proper way of installing Yarn 2+ is not via NPM, so people have no idea that a yarn newer than 1.x even exists, or how to install is, because the NPM package makes no mention of it (afaik). Upon RTFM-ing the docs, they are asked to run some command, and some mentions of the binary maybe not even being available on your Node install. This is just mental overhead, and a bad default.

Most people statistically never switch away from defaults, and arguing or urging people to do so causes frustration and a bad experience. Bad defaults cause all sorts of problems, from security, privacy, financial, and so on. So the onus is on Node to provide a good experience. And imo Corepack is a good experience. I have not heard of devEngines until now, it looks alright. I really like the shim approach of corepack, but to each their own. My only concern is, that node version managers are a solved problem. Nvm, fnm are the two recommended by Node, in fact fnm specifically solves this problem by exposing a setting to the user, to always enable corepack on new Node installs, or the very aggressive --use-on-cd flag to switch node versions. However, that is yet another setting and software that devs need to 1) know about, 2) remember to turn on/use, because it is not the default. I believe this is a worthy enough breaking change, to not worry about old Node version. I.e. from Node XX you have to specify what NPM version you need, you cannot run npm commands in your project unless you have someProperty set in your package.json. I think worrying about seamless upgrades from Node 0.4 to Node 24 is futile. Microsoft is known for going all in on backwards compatibility and has famously bad defaults, that are vulnerable to all kinds of attacks, in both Entra ID and Windows. Speaking of...

This whole npm i corepack or nver install workflow is very Edge-like. On a fresh Windows you open Edge just to download Chrome and then never use Edge again. While Edge is fighting tooth and nail to stop you from doing this. It gives a bad vibe for NPM to act this way, plus just more churn for developers to dislike the newer (and inarguably better) solutions to NPM.

(sorry for the long rant)