package.json keeps my pnpm version artificially old

[hyperknot]

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: it keeps annoying me with the "Please update pnpm with corepack" notice AND 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?

[zkochan]

We do not add the packageManager field when it isn't present. corepack adds it. If you want to disable this behaviour of corepack, you may set the COREPACK_ENABLE_AUTO_PIN environment variable to 0.

[hyperknot]

I'd understand this, if there were multiple pnpm installations like /Users/user/.nvm/versions/node/v20.17.0/bin/[email protected]/pnpm or similar. But there is one single file, which is reporting different versions based on where it's called from.

[zkochan]

I don't know how it operates in your setup but it works by the spec. Maybe /Users/user/.nvm/versions/node/v20.17.0/bin/[email protected]/pnpm is in your PATH, that is why it runs first, then it reads the field in package.json and switches to the right version, which is not in the PATH.

[hyperknot]

I don't have those files, I just wrote a fictional path names, like how it's done with every other tool.

But with corepack, it seems to create "phantom" versions of pnpm, so that

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

is reporting multiple versions. It's not acting like a proper binary file.

BTW, the bug is totally in corepack, it's not upgrading the packageManager field.
nodejs/corepack#587

BTW, I think it's a terrible design choice on corepack side, I don't know a single situation in any other programming language where they'd want to keep an old version of a packaging manager.

And it's not just weird, it's actually buggy. I guess you'll be recommending many pnpm users to disable COREPACK_ENABLE_AUTO_PIN in the future.

[zkochan]

I’m not sure what you mean by “buggy”. It works as designed. The purpose of pinning the version isn’t to use an old version but to ensure consistency across all environments. You definitely should update the package manager version periodically.

[hyperknot]

1. First, the command being shown does not update anything, so it keeps being displayed once per day.
2. The package manager is pinned to an old version.

BTW, the default choice you are making is breaking so many workflows, the #1 Google result is nodejs/corepack#485 with 29 upvotes!

I believe there should be a single version of a package manager in each node environment, everything else is just asking for trouble.

[hyperknot]

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