search

nodejs / corepack

Zero-runtime-dependency package acting as bridge between Node projects and their package managers
MIT License
2.36k stars 150 forks source link

How do we run upgrade global package managers #395

Open aduh95 opened 5 months ago

aduh95 commented 5 months ago

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

Originally posted by @nickmccurdy in https://github.com/nodejs/corepack/issues/351#issuecomment-1958930467

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

styfle commented 5 months ago

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

aduh95 commented 5 months ago

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 commented 5 months ago

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:

aduh95 commented 5 months ago

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

arcanis commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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.

nickmccurdy commented 4 weeks ago

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 commented 5 days ago

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

While the log says Installing pnpm@9.5.0..., 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! :pray:

Tobbe commented 5 days ago

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

tukusejssirs commented 5 days ago

@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 commented 5 days ago

@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 commented 5 days ago

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 node@20.15.1 and npm@10.7.0.

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 npm@10.2.4 and corepack@0.24.0. After uninstalling and reinstalling node@21.6.2 (nvm uninstall 21.6.2 && nvm i 21.6.2), pnpm@9.5.0 was already installed.

Sorry for the noise. :wink: And thank you for helping me out! :pray:

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. :thinking:

Tobbe commented 5 days ago

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