How do we run upgrade global package managers

[aduh95]

How do we run upgrade package managers like we could before this change?

Originally posted by @nickmccurdy in #351 (comment)

Anybody have thoughts on adding something like corepack up -g yarn pnpm?

[styfle]

What's the difference from corepack install -g yarn@latest pnpm@latest?

[aduh95]

What's the difference from corepack install -g yarn@latest pnpm@latest?

corepack install -g yarn@latest pnpm@latest would install whatever version has the latest tag on their relative registry (at the time of writing yarn@4.1.0 and pnpm@8.15.3), which is rarely what you want (at least, it's certainly not what you want for yarn, the global version should always be Yarn 1.x).
corepack up -g yarn pnpm on the other hand would bump to the latest version on whatever major is already globally installed. (e.g. if the global versions are yarn@1.19.0 and pnpm@7.15.3, it would install yarn@1.22.21 and pnpm@7.33.7).

[arcanis]

I disagree this is a behavior we want to have. Package managers don't have this concept of "upgrade but stay on the same major", and I don't think we should add a whole new command just for that.

Some alternatives:

• Document that users must make explicit the version range if they really want that (ie corepack install -g yarn@^1)

• Add support for a version-less range (ie corepack install -g yarn@^), but not a whole separate command

[aduh95]

Why do we have a corepack up command if this is not a behavior we want?

[arcanis]

corepack up is meant to update the version of the packageManager field. In a sense it's similar to what would be install without the -g flag, but without needing the package name to be specified (since we already know it from the packageManager field).

I think I implemented the "same major restriction" there because someone else requested it and semantically it made some sense to be conservative for a project with a checked-in version. I don't think it makes that much sense for the global version - if someone wants to use a specific version somewhere, they should lock it with packageManager imo.

[nickmccurdy]

I just want to have one command that upgrades Yarn to the latest 1 and everything else to the latest major. It was removed in #351 with no documentation.

[arcanis]

Corepack is still experimental, so a regression in that way isn't necessarily to be fixed. Especially the part about "Yarn to the latest 1 and everything else to the latest major" is worth a debate. The one and only reason yarn@4.1.0 isn't what's installed by npm install -g yarn is that it'd break older projects who happen to run npm install -g yarn in their Dockerfile.

Since Corepack isn't used by those older projects, it doesn't have the same concerns, so it's worth really considering whether it makes sense to keep yarn@1 the default global there.

[nickmccurdy]

If I install Yarn modern globally, will Yarn classic still be used if I don't have packageManager in a local package.json? I'm fine with global usage, I just don't want this breaking Yarn classic projects.

[aduh95]

In my experience, most folks want to be up-to-date, but would prefer staying away from breaking changes, so I really think it makes sense to have.

it's worth really considering whether it makes sense to keep yarn@1 the default global there.

I agree it's debatable, but having this feature doesn't force anyone to use it – same way the fact that Corepack supports the "packageManager" field, it doesn't force anyone to use it.