pnpm install --frozen-lockfile fails with pnpm v9

[Jack-Works]

Verify latest release

• I verified that the issue exists in the latest pnpm release

pnpm version

9.0.0

Which area(s) of pnpm are affected? (leave empty if unsure)

Lockfile

Link to the code that reproduces this issue or a replay of the bug

https://github.com/DimensionDev/Maskbook/pull/11571/files

Reproduction steps

Clone the PR and try an upgrade

Describe the Bug

I upgraded pnpm from 8.7.6 to 9.0.0 and the lockfile is broken (as you can see in the link I mentioned).

One thing you can observe is that: peer dependencies to react are mostly resolved to 18.2.0, not 0.0.0-experimental-8039e6d0b-20231026 as I specified in package.json/pnpm/peerDependencyRules/allowedVersions.

I tried to remove the whole section of allowedVersions and reinstall, then add it back hope it can re-resolve dependencies, but that does not work.

Expected Behavior

Upgrade and keep my peer dependencies version correct

Which Node.js version are you using?

21

Which operating systems have you used?

• macOS
• Windows
• Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

No response

[rijx]

Can confirm and also looking to hear from the team if the lockfile not being backwards compatible was intended:

ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE  Cannot perform a frozen installation because the version of the lockfile is incompatible with this version of pnpm

[areriklq]

Can confirm and also looking to hear from the team if the lockfile not being backwards compatible was intended:

ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE  Cannot perform a frozen installation because the version of the lockfile is incompatible with this version of pnpm

I am seeing the exact same issue with pnpm v9 and a lock file with version 6. I thought only v5 was dropped?

[joan-gerard]

A temporary solution for me was to get my workflows to install a specific pnpm version rather than the latest version

[zkochan]

I can check.

But you should be able to run pnpm install locally to update the lockfile to the new format preserving versions. Although, I would recommend to remove the lockfile and node_modules to generate one from scratch as pnpm v9 has some fixes to resolution of peer dependencies.

[Mathias-S]

pnpm 9 seems to be incompatible with lockfile v6.0:

• Running pnpm install --frozen-lockfile on a v6 lockfile results in the error  ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE  Cannot perform a frozen installation because the version of the lockfile is incompatible with this version of pnpm
• Running pnpm install with no arguments updates the lockfile to v9, which is incompatible with pnpm 8

Is no lockfile version compatible with both pnpm 8 and 9?

The changelog seemed to suggest that Lockfile v6 is supported in pnpm 9, but I can't get it to work.

Edit: Readonly support for Lockfile v6 as introduced in pnpm 9.0.1 is a good compromise

[zkochan]

Lockfile v6 will work with pnpm v9 but only as readonly (after this fix: #7935). v9 will not make updates in the previous format.

As I said before. This is a breaking change for a reason. We had to change the lockfile format in order to fix some issues with peer dependencies. The fix was too big to port it to v8.

[jh-sh]

While I can also confirm incompatibility of lock-file versions between 8.15.5 & 9.0.0, there's the other thing related to corepack and 9.0.0.

If no packageManager field is provided in your package.json, running

corepack enable
corepack prepare pnpm@8.15.5 --activate

gives you 9.0.0.

with the notorious:

Scope: all 32 workspace projects
 ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE  Cannot perform a frozen installation because the version of the lockfile is incompatible with this version of pnpm

Try either:
1. Aligning the version of pnpm that generated the lockfile with the version that installs from it, or
2. Migrating the lockfile so that it is compatible with the newer version of pnpm, or
3. Using "pnpm install --no-frozen-lockfile".
Note that in CI environments, this setting is enabled by default.

That doesn't happen locally, but for some reason happens on a CI.

The solution is to check in the package.json after going with latest section of Using Corepack section.

@zkochan , isn't it a bit strange that any tag on corepack started pointing to 9.0.x?

EDIT: any tag -> any 8.15.x tag. I tried 1 to 5, and got 9.0.0 each time on CI

[zkochan]

By default pnpm install fails in CI if it detects that updates should be made to the lockfile. That will be fixed in 9.0.1.

Not sure what the issue with corepack is

[jh-sh]

@zkochan My guess would be that it's some issue with some part of node's ecosystem.
this installation of 9.0.0 against the requested 8.15.x stated happening right after the release ~3 hr ago.

[zkochan]

I tested it in a node.js docker container (docker run --rm -it node sh). All seems to work correctly. Maybe you have a packageManager field in your package.json, try to use:

corepack use pnpm@8.15.5

Which should update the field in package.json.

[zkochan]

One thing you can observe is that: peer dependencies to react are mostly resolved to 18.2.0, not 0.0.0-experimental-8039e6d0b-20231026 as I specified in package.json/pnpm/peerDependencyRules/allowedVersions.

I tried to remove the whole section of allowedVersions and reinstall, then add it back hope it can re-resolve dependencies, but that does not work.

The allowedVersions field only affects warnings printed to the console. If you need to override a peer dependency version just install the dependency that you want (as a direct dependency).

[jh-sh]

I tested it in a node.js docker container (docker run --rm -it node sh). All seems to work correctly. Maybe you have a packageManager field in your package.json, try to use:

corepack use pnpm@8.15.5

Which should update the field in package.json.

Yep, I also mentioned that section of pnpm docks with packageManager field in package.json, bc it solved the issue for us.

Nevertheless, I beg my pardon. Doublechecked the pipe logs. The below is not enough:

corepack enable
corepack prepare pnpm@8.15.5 --activate

It proceeds with enabling "pnpm@latest" instead of "pnpm@8.15.5" that's is expected according to a node v.18 docs.

It's solely corepack documentation issue, and has nothing to do with pnpm.

[zkochan]

🚢 9.0.1

[MrOxMasTer]

What is this? I can't build a container. 9.0.1

[zkochan]

Doesn't seem related to this issue.

Which version of electron is it?

[MrOxMasTer]

Doesn't seem related to this issue.

Which version of electron is it?

I don't understand what electron we're talking about if I don't have it in my dependencies and it's not an electron.js application

[Jack-Works]

One thing you can observe is that: peer dependencies to react are mostly resolved to 18.2.0, not 0.0.0-experimental-8039e6d0b-20231026 as I specified in package.json/pnpm/peerDependencyRules/allowedVersions.
I tried to remove the whole section of allowedVersions and reinstall, then add it back hope it can re-resolve dependencies, but that does not work.

The allowedVersions field only affects warnings printed to the console. If you need to override a peer dependency version just install the dependency that you want (as a direct dependency).

This surprised me. I thought this is an override of the incompatible peer versions

I read the doc again. Thank you for pointing me out!

[Jack-Works]

Hi @zkochan It's still not working.

In DimensionDev/Maskbook@4f5f116 (#11571) (Good state), if you search "react@18.2.0" you'll find nothing, but if you change package.json to "packageManager": "pnpm@9.0.1", and run pnpm install, now the lockfile contains "react@18.2.0" and the app is broken.

In the lockfile I can see my override is acknowledged: react: 0.0.0-experimental-8039e6d0b-20231026 but it does not work.

[pawelblaszczyk5]

Also if anyone stumble here in the same case as me - it seems like turborepo pruning fails with the new lockfile format and causes the same error as described here. I've opened issue on their side - vercel/turbo#7993

[lorypelli]

A question: why is lockfile version 9.0 and not 7.0?

[dwiyatci]

A question: why is lockfile version 9.0 and not 7.0?

Could it be that they wanted to make it more streamlined with the pnpm version itself? 😄

[zkochan]

A question: why is lockfile version 9.0 and not 7.0?

The lockfile version will be the same as the pnpm version where it was introduced.

[zkochan]

In DimensionDev/Maskbook@4f5f116 (#11571) (Good state), if you search "react@18.2.0" you'll find nothing, but if you change package.json to "packageManager": "pnpm@9.0.1", and run pnpm install, now the lockfile contains "react@18.2.0" and the app is broken.

I you want to override the version of react, use an override

[Jack-Works]

In DimensionDev/Maskbook@4f5f116 (#11571) (Good state), if you search "react@18.2.0" you'll find nothing, but if you change package.json to "packageManager": "pnpm@9.0.1", and run pnpm install, now the lockfile contains "react@18.2.0" and the app is broken.

I you want to override the version of react, use an override

Yes! I'm using it but still have the problem. Just tried again with 9.0.2

[milanpajovic]

packageManager

Hey

How did you solve this?
This is my build command:
corepack enable && corepack prepare pnpm@8.3.1 --activate && pnpm install --frozen-lockfile && npm install --global lerna && cd ./packages/database && npx prisma generate && cd ../.. && pnpm lerna run build

Ans still I am getting the following error:
 ERR_PNPM_BAD_PM_VERSION  This project is configured to use v8.10.4 of pnpm. Your current pnpm is v9.0.2

[jh-sh]

@milanpajovic , you have to add packageManager to your package.json and check it in.
to do so, you'll have to run corepack use pnpm@x.y.z with the version you need to stick to before going with pnpm i

[jh-sh]

@milanpajovic
I assume, it would be:

corepack enable
corepack prepare pnpm@8.10.4 --activate
corepack use pnpm@8.10.4
# ... rest commands

that works for us in node 18 LTS

PS: in my case, I ran that locally, pushed changed package.json to the repo. for CI just

corepack enable
corepack prepare pnpm@x.y.z --activate

was enough.

[jh-sh]

@milanpajovic, btw, according to the node 20.x docs you might not even need to run prepare

[milanpajovic]

corepack use pnpm@8.10.4

Thank you.
I am using monorepo using lerna

this is how package.json looks like

"engines": {
"node": ">= 18.14.0",
"npm": "please-use-pnpm"
},
"packageManager": "pnpm@8.3.1"
}
I moved all of them to pnpm@8.3.1
We are on node 18
But it seems that pipeline is still getting the newest version of pnpm

[cbin]

I have the same problem:
└─# pnpm -v 9.0.4
`
─# pnpm run dev
 ERR_PNPM_BAD_PM_VERSION  This project is configured to use v8.15.4 of pnpm. Your current pnpm is v9.0.4

If you want to bypass this version check, you can set the "package-manager-strict" configuration to "false" or set the "COREPACK_ENABLE_STRICT" environment variable to "0"

`

[raydot]

Having the same problem. corepack use pnpm@8.15.5 runs and returns no errors but then the next pnpm command returns Expected version: 8 Got: 9.0.6". packageManager in package.json is pointing to pnpm@8.15 and engines contains "pnpm": "8"

[dlarr]

Having same issue : local pnpm version is 9.1.0 and CI version is 8.14.1

I am interested in backward compatibility

Say local pnpm install is made with 8.14.1

Will pnpm 9+ succeed with pnpm install --frozen-lockfile on the CI ?

[exiguus]

Having the same issue in CI with Vercel. Vercel provide ATM pnpm@9.0.4. But we use 9.1.1.
As a work around we use corepack to update the "packageManager" field in package.json before we run pnpm i:

corepack use pnpm@`pnpm -v`

This will write whatever current installed version is on your system to the package.json file. No ERR_PNPM_BAD_PM_VERSION error anymore.

[froko]

@exiguus Can you give me a hint how to do this? Is this something like a pre-build hook that I can set up on Vercel side?

[pawelblaszczyk5]

You can enable core pack at Vercel by using environment variable - https://vercel.com/changelog/corepack-experimental-is-now-available

[exiguus]

@exiguus Can you give me a hint how to do this? Is this something like a pre-build hook that I can set up on Vercel side?

Sure, i described the solution more in detail in this comment: #8087 (comment)

Basically you have to add your own install command in Vercel and run

corepack use pnpm@`pnpm -v` && pnpm i