Frozen lockfile error despite up to date lockfile

[Gregoor]

pnpm version: 8.0.0 (though 7.30 seems also affected)

Running pnpm install --frozen-lockfile yields:

Lockfile is up to date, resolution step is skipped
 ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json

Now when I run pnpm install, there are no lockfile changes.

Interestingly enough this also happens:

❯ pnpm cache
 ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL  Command failed with ENOENT: cache
spawn cache ENOENT

I don't have a repro, because I'm somewhat sure that this is my system being bonked, but I also could not find any guides for doing a clean uninstall (I tried store pruning, resetted all the configs etc)

Additional information:

• node -v prints: v18.13.0
• Windows, macOS, or Linux?: macOS Ventura 13.0

[iamchathu]

Try downgrading PNPM to v7 or upgrade the lockfile to v8

[Gregoor]

I tried both, to no avail.

[tjx666]

Same here:

[zkochan]

I don't know currently why this is happening but I will add more details to the error message: #6536

[tjx666]

My problem is not why lock file is not latest. My problem is why pnpm output:

Lockfile is up to date, resolution step is skipped

@zkochan

[zkochan]

I understand what is your problem but I can't fix it if I can't reproduce it. You should provide steps to reproduce. If not, with more info in the error message maybe we'll be able to figure out the issue.

[zkochan]

Update to v8.5.1 and post the new error message. The new details should printed at the bottom with default color (not red).

[tjx666]

@zkochan I create a new issue with reproduce #6544

[zkochan]

@Gregoor are the new details helping to localize the issue? Could you create a reproduction repo for this issue?

I'm somewhat sure that this is my system being bonked

There is a related issue that claims that this only happens on Linux but works on macOS.

[zkochan]

I think I know why this is happening. Probably the lockfile was generated with pnpm v7 (which has auto-install-peers=false by default), then pnpm i --frozen-lockfile was executed with pnpm v8 (which has auto-install-peers=true by default). The lockfile differs when auto-install-peers has a different value.

This may also be reproduce on the same pnpm v8 version just by changing the value of the auto-install-peers setting.

We should probably add a new field to the lockfile: autoInstallPeers. We should match to the current setting and print a more meaningful error message.

EDIT:

excludeLinksFromLockfile should also be added as it also changes how we check if the lockfile is up-to-date: https://github.com/pnpm/pnpm/blob/ea28b6f6c787595f81061a1df37b743b86d33e4f/lockfile/lockfile-utils/src/satisfiesPackageManifest.ts#LL35C3-L35C3

[i-bajrai]

can confirm upgrading to 8 on a mac causes this issue when it is run in linux

pnpm config set auto-install-peers false used this command on the mac to fix the issue

[Gregoor]

@Gregoor are the new details helping to localize the issue? Could you create a reproduction repo for this issue?

I'm somewhat sure that this is my system being bonked

There is a related issue that claims that this only happens on Linux but works on macOS.

Thanks for looking into it. I actually lost track on which project it happened, sorry. But I can say that it is not an issue for me anymore.

I think it might have been related to a global config which was setting (or unsetting) auto-install-peers, which I wasn't aware of.

It might be useful to know when a project-local setting is overriden because of some system thing, e.g. a warning when running pnpm install. Just an idea.

[justintemps]

Updating to pnpm@8.5.1 and re-installing deps resolved this for me.

[roch-numbered]

Hey @zkochan, about those 2 explanations:

Probably the lockfile was generated with pnpm v7 (which has auto-install-peers=false by default), then pnpm i --frozen-lockfile was executed with pnpm v8 (which has auto-install-peers=true by default). The lockfile differs when auto-install-peers has a different value.

This may also be reproduce on the same pnpm v8 version just by changing the value of the auto-install-peers setting.

We should probably add a new field to the lockfile: autoInstallPeers. We should match to the current setting and print a more meaningful error message.

Some settings influence the structure of the lockfile, so we cannot reuse the lockfile if those settings change. As a result, we need to store such settings in the lockfile. This way we will know with which settings the lockfile has been created.

A new field will now be present in the lockfile: settings. It will store the values of two settings: autoInstallPeers and excludeLinksFromLockfile. If someone tries to perform a frozen-lockfile installation and their active settings don't match the ones in the lockfile, then an error message will be thrown.

To understand things correctly, it means that the auto-install-peers setting needs to be saved in the .npmrc of the project to be sure to prevent errors for every members and the CI.

How I understand it right now is this way.

1. settings.autoInstallPeers: true + user with global setting auto-install-peers=true = pass ✅
2. settings.autoInstallPeers: true + user with global setting auto-install-peers=false = error ❌
3. settings.autoInstallPeers: true + CI with global setting default to the PNPM version = unknown ❓

Then if a .npmrc with auto-install-peers=true is added to the project, it ensures pnpm install to always work.

If this description is correct, then it means that it creates duplication of settings, inconsistency and possible confusion. Because of that, I'm not sure to fully understand this new lockfile option.

Let me know what do you think and what's the purpose behind this update.

---

EDIT: When I'm referring to CI, I'm talking about Vercel where you can't specify PNPM version. Otherwise, I think that the version is settable and the problem might not happen on CI.

[Wamy-Dev]

I had this problem in a CI env, and my solution was simply cloning the repo on a local machine and running pnpm install once again, and that cleared things up for me. It seemed like the problem was with quotation marks

The previous had "xxxxxxx" and the re-ran lock file had 'xxxxxxxx'. I don't know why it would be different. Something to consider is that the first time I ran pnpm install when I first deployed was on an Ubuntu machine, and when I ran it the second time, after the CI problem, it was done on a Windows machine. Maybe that has something to do with it? Nothing actually changed in the lock file, except for those quotation marks which is strange why it would matter.

[MehdiRazaNaqvi]

Just upgraded lockfileVersion in pnpm.lock.yaml from 6.0 to 8.5.1 and boom, deployed successfully

[atadeuccislideworks]

Just upgraded lockfileVersion in pnpm.lock.yaml from 6.0 to 8.5.1 and boom, deployed successfully

You manually updated the version?

[emnesty]

Just upgraded lockfileVersion in pnpm.lock.yaml from 6.0 to 8.5.1 and boom, deployed successfully

How?

[chandramuralis]

Just upgraded lockfileVersion in pnpm.lock.yaml from 6.0 to 8.5.1 and boom, deployed successfully

This worked for me too.

[heath-freenome]

How did y'all upgrade the lockfile version? I'm running 8.15.2 and it is still generates a lockfile version 6. We are using pnpm on the latest MacOS

[chandramuralis]

How did y'all upgrade the lockfile version? I'm running 8.15.2 and it is still generates a lockfile version 6. We are using pnpm on the latest MacOS

Just manually change the version number