Repository navigation
How do we run upgrade global package managers #395
Description
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?
Activity
styfle commentedon Feb 22, 2024
What's the difference from
corepack install -g yarn@latest pnpm@latest?aduh95 commentedon Feb 22, 2024
corepack install -g yarn@latest pnpm@latestwould install whatever version has the latest tag on their relative registry (at the time of writingyarn@4.1.0andpnpm@8.15.3), which is rarely what you want (at least, it's certainly not what you want foryarn, the global version should always be Yarn 1.x).corepack up -g yarn pnpmon the other hand would bump to the latest version on whatever major is already globally installed. (e.g. if the global versions areyarn@1.19.0andpnpm@7.15.3, it would installyarn@1.22.21andpnpm@7.33.7).arcanis commentedon Feb 22, 2024
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 commandaduh95 commentedon Feb 22, 2024
Why do we have a
corepack upcommand if this is not a behavior we want?arcanis commentedon Feb 22, 2024
corepack upis meant to update the version of thepackageManagerfield. In a sense it's similar to what would beinstallwithout the-gflag, but without needing the package name to be specified (since we already know it from thepackageManagerfield).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
packageManagerimo.nickserv commentedon Feb 22, 2024
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 commentedon Feb 22, 2024
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.0isn't what's installed bynpm install -g yarnis that it'd break older projects who happen to runnpm install -g yarnin 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 commentedon Feb 22, 2024
If I install Yarn modern globally, will Yarn classic still be used if I don't have
packageManagerin a localpackage.json? I'm fine with global usage, I just don't want this breaking Yarn classic projects.aduh95 commentedon Feb 22, 2024
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.
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 commentedon Jun 25, 2024
I'm trying this and it's not working. As soon as Yarn is upgraded globally with
corepack install --globalorcorepack prepare --active, its version will be used as soon as I runyarnin a local project withoutpackageManager.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
packageManagertoyarn@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 commentedon Jul 18, 2024
I am not sure how this should work, however, in my case,
corepack@0.28.1does not upgrade PNPM to its latest version usingcorepack install -g pnpm@latest.While the log says
Installing pnpm@9.5.0..., a subsequent run ofpnpm -vreturns8.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 onlyPreparing pnpm@latest for immediate activation...) does not activate the latest version, but PNPM stays on8.15.3.The only thing that actually works is
pnpm -g i pnpm@latest, however, it does not seem right if I installed PNPM usingcorepackin the first place.Thanks! 🙏
Tobbe commentedon Jul 18, 2024
@tukusejssirs What's your environment? I've seen this behavior in Github Codespaces. Is that where you're trying to do this?
tukusejssirs commentedon Jul 18, 2024
@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 commentedon Jul 18, 2024
@tukusejssirs What does
corepack pnpm -vreturn 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 machineAlso: 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 commentedon Jul 18, 2024
@Tobbe, it returns
8.15.3.Note that I have installed Node.js and NPM via
nvmwhich installs Node/NPM into my home folder (under~/.nvm).I use
lts/ironwhichnvmresolved tonode@20.15.1andnpm@10.7.0.After looking more into which Node version is used using
nvm ls, I had it set tostable(specificallyv21.6.2) as the default Node version in NVM. After changing it tolts/*(orlts/iron) usingnvm alias default 'lts/*', all seems to work correctly.As my installed
stableNode version was not the latest, I have upgraded it tov22.5.0and when I used that version, PNPM version was alreadyv9.5.0.In the end, the only Node version which does not work as expected, is
v21.6.2withnpm@10.2.4andcorepack@0.24.0. After uninstalling and reinstallingnode@21.6.2(nvm uninstall 21.6.2 && nvm i 21.6.2),pnpm@9.5.0was 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 commentedon Jul 18, 2024
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