Bot user for nodejs/corepack

[arcanis]

I'd like to automate Corepack so that it'd automatically be updated with new package manager information, and republished. The setup I have in mind:

• Every day, a workflow checks what are the latest npm/pnpm/Yarn releases, updates the config file, and opens a PR
• On each commit, check if the package.json version is on the npm registry; if it isn't, publish it

This would require the following:

• Adding a npm publish token into the Corepack repository
• (optional) Transfering the corepack package to ~nodejs-foundation
• (optional) Adding a GH bot user token into the Corepack repository, for the workflow to open PRs

Ref nodejs/corepack#90

[aduh95]

/cc @nodejs/tsc

[mcollina]

I do not think this is a great idea.
One of the main reason we adopted corepack was to avoid work in nodejs/node to support multiple package managers. There is a measurable amount of traffic on our H1 due to vulnerabilities in the npm dependencies, and my goal is to not increase it.

I propose that the config file include only the major version of each package manager. This will ensure that for a specific version of Node.js there won't be any breaking change.
(I consider the drop of a Node.js version a breaking change).
Then we will update the major version of each package manager whenever we ship a new major release of Node.js.

[arcanis]

Limiting updates to major is a good idea, but it's tangential to having an automation - we'll still want to bump the minor / patch releases from the same major.

I propose that the config file include only the major version of each package manager. This will ensure that for a specific version of Node.js there won't be any breaking change.

The config file contains exact versions so as one Corepack / Node version always provides the exact same default pnpm / Yarn versions, mirroring the way you currently distribute npm.

[mcollina]

Limiting updates to major is a good idea, but it's tangential to having an automation - we'll still want to bump the minor / patch releases from the same major.

No. I'm proposing to avoid the problem altogether and just specify the major version.

The config file contains exact versions so as one Corepack / Node version always provides the exact same default pnpm / Yarn versions, mirroring the way you currently distribute npm.

I would note that having a config file with the exact versions defeats one of the purposes of corepack.

I'm proposing a change so we can actually avoid the problem completely. Given corepack download the package managers dynamically, we should not have users install versions with known vulnerabilities or even bugs if a fix is available.

I do not think corepack should mirror what Node does with npm because we ship npm in source tree. This is a source of frequent reported vulnerabilities for Node.js (false positeves, usually RedDoS).

[arcanis]

I'm proposing a change so we can actually avoid the problem completely. Given corepack download the package managers dynamically, we should not have users install versions with known vulnerabilities or even bugs if a fix is available.

Dynamic installs are a large topic, with some people seing them as a pro in terms of security (always up-to-date) while others see it as a con (faker.js situation). The current design avoids this problem by ensuring that the default versions are static (even if the binaries are lazy loaded), which matches the existing status quo.

In my opinion, changing to dynamic versioning is a separate topic that's worthy to be debated on its own (and if everyone agrees to the change then so be it, I personally don't have strong feelings either way), but that shouldn't block improvements on the current design in the meantime.

[aduh95]

I'm +1 changing the default of Corepack to always be the most up-to-date semver-minor/semver-patch of all supported package managers. IMHO being up-to-date is much preferable than keeping an insecure version forever.

I'm +1 having a bot that opens a PR to nodejs/corepack every time a new major version of npm or pnpm is released, and that opens a PR to nodejs/node every time a new version of Corepack is released.

[BethGriggs]

+1 to @mcollina's suggestion.

I completely missed the fact that Corepack maintains a config file with specific versions in the original discussion. Even with automation to create the PRs to update Corepack, that means Corepack puts extra burden on the project to ship new releases any time one of the three package managers upgrade their defaults in the Corepack config.

To add, I struggled to find the config file in Node.js core as it's packed 14000 lines into corepack.js (thanks for the pointer to that, @richardlau).

[mhdawson]

I agree with the sentiments in the last few comments. From my perspective the only reason some of us were willing to pull in corepack is because it avoided pulling the package managers into Node.js itself. If it's effectively the same thing and forces Node.js to do security updates when an update is needed in one of the package managers we just don't have the bandwidth to support that that (we already struggle with the CVEs etc. that we have to handle from including npm).

[aduh95]

On the TSC meeting it was decided to go on with adding an automation that opens a PR to nodejs/node every time a new version of Corepack is released. We have already a workflow in the core repo to update dependencies: https://github.com/nodejs/node/blob/HEAD/.github/workflows/tools.yml.
@arcanis would you like to open a PR to add a step on this workflow that checks for Corepack updates?

[arcanis]

Sure, will do 👍

[arcanis]

Opened nodejs/node#42090 to auto-update Corepack in Node. However my initial points were also to allow automated releases in the Corepack repository; is it possible?

Even if Corepack switches to dynamic versions, I'd still prefer to have some repository workflow for Corepack releases, and avoid having to release it by running commands from my own laptop.