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

[ADTC]

For awareness, you technically don't need to install globally. You can simply update to latest version in in the current project (which also does the install):

corepack use pnpm@latest
# Installing [email protected] in the project...

corepack use -h
Define the package manager to use for the current project

━━━ Usage ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

$ corepack use <pattern>

━━━ Details ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

When run, this command will retrieve the latest release matching the provided 
descriptor, assign it to the project's package.json file, and automatically 
perform an install.

This updates packageManager field in the package.json file.

Warning

I highly recommend to NOT do corepack use pnpm as it appears to install an unreleased beta version [email protected] for some dumb reason. I had to use corepack use pnpm@latest to revert to latest release, which also had to wipe and re-create the node_modules folder.

---

It seems you can also quickly update to latest minor version by the shortcut command up (also without doing any global installs):

corepack up
# Installing [email protected] in the project...

corepack up -h
Update the package manager used in the current project

━━━ Usage ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

$ corepack up

━━━ Details ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Retrieve the latest available version for the current major release line of the 
package manager used in the local project, and update the project to use it.

Unlike `corepack use` this command doesn't take a package manager name nor a 
version range, as it will always select the latest available version from the 
same major line. Should you need to upgrade to a new major, use an explicit 
`corepack use '{name}@*'` call.

[ADTC]

This should be corepack use pnpm@${opts.latestVersion} when inside a project with a package.json that has packageManager field set to pnpm.

pnpm/cli/default-reporter/src/reporterForClient/reportUpdateCheck.ts

Lines 51 to 54 in 0bc7a3f

	function renderUpdateCommand (opts: UpdateMessageOptions): string {
	if (isExecutedByCorepack(opts.env)) {
	return `corepack install -g pnpm@${opts.latestVersion}`
	}

Tip

The use command will also do the install, so doing an install -g prior to use is not necessary.

See also: #6325 (comment)