package.json keeps my pnpm version artificially old

[hyperknot]

I opened this issue in pnpm but it seems it's more related to corepack.

https://github.com/orgs/pnpm/discussions/8911#discussioncomment-11674247

Copying it here:

---

1. I go to any repo, with package.json
2. I run pnpm i
3. It adds this "packageManager": "[email protected]+sha512...." line
4. From now on: 1. it keeps annoying me with the "Please update pnpm with corepack" notice AND 2. it doesn't get updated.

By "doesn't get updated" I mean that even though I've updated my pnpm to the latest version, when I go inside that directory, it reports it as 9.10, not as 9.15.

Even though I'm running on the very same binary file!

Outside the project repo:

/Users/user/.nvm/versions/node/v20.17.0/bin/pnpm --version
9.15.1

Inside the project repo:

/Users/user/.nvm/versions/node/v20.17.0/bin/pnpm --version
9.10.0

This is extremely buggy / confusing like this. How can the same binary file have multiple versions?

[arcanis]

This is extremely buggy / confusing like this. How can the same binary file have multiple versions?

That's literally the point of Corepack. It uses the version configured for a given project, not whatever random version happens to be globally installed. The binary you see is not the final one. The final ones are in ~/.cache/node/corepack/pnpm, and which one is used depends on the packageManager field.

So if you want to upgrade pnpm, just do what pnpm says; it'll upgrade the packageManager field.

[hyperknot]

corepack install -g [email protected] does not upgrade my packageManager field. This is the core of the bug.

What's really strange / related is that this is not acting like a proper binary file, somehow this file:

/Users/user/.nvm/versions/node/v20.17.0/bin/pnpm --version

has multiple versions. But maybe it's per design. The core issue is the upgrade command not upgrading the package.json field.

[aduh95]

-g stands for --global, meaning you are asking Corepack to act on the "global scope", i.e. not on the project on the cwd. It's not a bug it's a feature.

Corepack will by default use the version defined on the package.json's packageManager field, and the global version is only used if no project config can be found. If you set DEBUG=corepack in your env, it might help you understand how Corepack chooses which version it loads.

[hyperknot]

I'm running the command I'm being told to run:

[zkochan]

So corepack install -g [email protected] doesn't update the version of pnpm in package.json? Do we recommend the wrong command in the update notice?

[hyperknot]

Here is a DEBUG run

DEBUG=corepack corepack install -g [email protected]
Installing [email protected]...
  corepack Reusing [email protected] found in /Users/user/.cache/node/corepack/v1/pnpm/9.15.2 +0ms
  corepack LastKnownGood file would be located at /Users/user/.cache/node/corepack/lastKnownGood.json +0ms
  corepack [email protected] is already Last Known Good version +1ms

[zkochan]

ok, if I understand correctly, we should show a different message when there's a packageManager field in the package.json. The same command without the -g flag. This should be fixed in pnpm.

[hyperknot]

That also doesn't work:

corepack install [email protected]
Unknown Syntax Error: Command not found; did you mean:

$ corepack install <-g,--global> [--cache-only] ...
While running install [email protected]

[arcanis]

I think it's supposed to be either corepack use [email protected] or just corepack up.