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 [email protected] and [email protected]), 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 [email protected] and [email protected], it would install [email protected] and [email protected]).

[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.

[nickserv]

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 [email protected] 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.

[nickserv]

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.

[nickserv]

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.

I'm trying this and it's not working. As soon as Yarn is upgraded globally with corepack install --global or corepack prepare --active, its version will be used as soon as I run yarn in a local project without packageManager.

It seems if I don't want to upgrade legacy Yarn projects while using corepack, I have to either only update Yarn locally or explicitly set packageManager to yarn@1… (which may not be an option for older open source projects, and is also easy to forget if you do it in the wrong order).

For now I'm avoiding upgrading package managers globally with corepack to improve compatibility. For security purposes, I'll still update my global npm and local Yarn/pnpm versions.

[tukusejssirs]

I am not sure how this should work, however, in my case, [email protected] does not upgrade PNPM to its latest version using corepack install -g pnpm@latest.

While the log says Installing [email protected]..., a subsequent run of pnpm -v returns 8.15.3.

Is there an additional command I need to run so that PNPM get upgraded to its latest version and made the default version to be used in all new shells/terminals?

Moreover, even corepack prepare pnpm@latest --activate (outputting only Preparing pnpm@latest for immediate activation...) does not activate the latest version, but PNPM stays on 8.15.3.

The only thing that actually works is pnpm -g i pnpm@latest, however, it does not seem right if I installed PNPM using corepack in the first place.

Thanks! 🙏

[Tobbe]

@tukusejssirs What's your environment? I've seen this behavior in Github Codespaces. Is that where you're trying to do this?

[tukusejssirs]

@Tobbe, I use Linux (specifically Fedora with SwayWM). And I don’t use GitHub much (apart from contributions), as I prefer GitLab. So, this happens on my local machine.

[Tobbe]

@tukusejssirs What does corepack pnpm -v return for you? If that gives you the expected version (9.5.0) then corepack doesn't have the permissions it needs to properly set everything up on your machine

Also: What's your node version? The issue actually seems to be fixed for Github Codespaces, and I noticed that when I last tried they were on Node 20.14.0, now they're on 20.15.1. Someone else also reported a similar issue on Node 20.11.0. So maybe try upgrading Node if you aren't already on the latest version

[tukusejssirs]

What does corepack pnpm -v return for you?

@Tobbe, it returns 8.15.3.

Note that I have installed Node.js and NPM via nvm which installs Node/NPM into my home folder (under ~/.nvm).

What's your node version?

I use lts/iron which nvm resolved to [email protected] and [email protected].

---

After looking more into which Node version is used using nvm ls, I had it set to stable (specifically v21.6.2) as the default Node version in NVM. After changing it to lts/* (or lts/iron) using nvm alias default 'lts/*', all seems to work correctly.

As my installed stable Node version was not the latest, I have upgraded it to v22.5.0 and when I used that version, PNPM version was already v9.5.0.

In the end, the only Node version which does not work as expected, is v21.6.2 with [email protected] and [email protected]. After uninstalling and reinstalling [email protected] (nvm uninstall 21.6.2 && nvm i 21.6.2), [email protected] was already installed.

Sorry for the noise. 😉 And thank you for helping me out! 🙏

PS—While my specific problem is solved, there still might be some issue somewhere between Corepack and NVM (I am not sure at which end). I presume I’ll have the same issue when I try to upgrade PNPM next time. 🤔

[Tobbe]

Yeah, switching around between different node version using nvm I noticed similar behavior (Github Codespaces are also using nvm).

So there's definitely some weirdness going on between nvm and corepack