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": "pnpm@9.10.0+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 pnpm@9.15.2 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 pnpm@9.15.2 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 pnpm@9.15.2
Installing pnpm@9.15.2...
  corepack Reusing pnpm@9.15.2 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 pnpm@9.15.2 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 pnpm@9.15.2
Unknown Syntax Error: Command not found; did you mean:

$ corepack install <-g,--global> [--cache-only] ...
While running install pnpm@9.15.2

[arcanis]

I think it's supposed to be either corepack use pnpm@X.Y.Z or just corepack up.

[hyperknot]

I've wrote about my case here, maybe someone also runs into this:
https://blog.hyperknot.com/p/corepacks-packagemanager-field