pnpm: Breaking changes with v8.6: Installing with older versions (e.g. 8.5.1) does no longer work

pnpm version: 8.6.1

Code to reproduce the issue:

  • Install pnpm 8.6.1
  • pnpm install vite
  • Uninstall pnpm and install version 8.5.1
  • pnpm install

Expected behavior:

packages are getting installed, lockfile version is maybe being downgrade

Actual behavior:

Following error message:

 WARN  Your pnpm-lock.yaml was generated by a newer version of pnpm. It is a compatible version but it might get downgraded to version 6.0
 ERROR  /@esbuild/android-arm64@0.17.19 is an invalid relative dependency path

pnpm: /@esbuild/android-arm64@0.17.19 is an invalid relative dependency path
    at Object.parse2 [as parse] (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:114178:15)
    at nameVerFromPkgSnapshot (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:114287:28)
    at addPreferredVersionsFromLockfile (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:196837:89)
    at getPreferredVersionsFromLockfileAndManifests (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:196831:7)
    at _installInContext (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:197757:142)
    at async installInContext (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:198099:16)
    at async _install (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:197622:25)
    at async mutateModules (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:197344:23)
    at async mutateModulesInSingleProject (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:197291:23)
    at async installDeps (/home/pawelka/.npm-global/lib/node_modules/pnpm/dist/pnpm.cjs:199330:33)

Running pnpm install --prefer-offline --frozen-lockfile yields the following error

 WARN  Your pnpm-lock.yaml was generated by a newer version of pnpm. It is a compatible version but it might get downgraded to version 6.0
node_modules/.pnpm                       |  WARN  Your pnpm-lock.yaml was generated by a newer version of pnpm. It is a compatible version but it might get downgraded to version 6.0
Lockfile is up to date, resolution step is skipped
 ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY  Broken lockfile: no entry for '/vite/4.3.9' in pnpm-lock.yaml

This issue is probably caused by a badly resolved merge conflict.
To fix the lockfile, run 'pnpm install --no-frozen-lockfile'.

Additional information:

  • node -v prints: v19.3.0
  • Windows, macOS, or Linux?: Linux

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 19 (13 by maintainers)

Commits related to this issue

Most upvoted comments

You may want to consider deprecating v8.6.1.

I’d like this approach. Maybe mark some vulnerabilities in this release.

make a clear public apology and tell people how to fix the issue that you’ve caused

This is an OPEN-SOURCE aka FREE-OF-CHARGE program. Some of you guys acting as if you’re one of the biggest sponsors of this project. You can’t just ignore the release notes and blame the author after upgrading recklessly.

I can only put one line of Chinese saying here: 要饭的还嫌饭馊。That is, a person as a beggar who still complains about the food given to him is dirty.

appreciate the feature (attempt) BTW.

the changes to the lockfile were not reverted. There is a new field in the lockfile called “settings”. It works with older versions of pnpm. Only the bump to the lockfile version was reverted.

You should really consider raising some money and hiring more full time staff. I think it’s unfortunate how this falls on the shoulder of someone who maintains it ‘in their spare time’. It’s a wonderful project, and I hope you consider it.

You may want to consider deprecating v8.6.1.

See https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions#deprecating-a-single-version-of-a-package

PS Unpublish is not recommended since v8.6.1 was published on June 5, 2023, which is more than 72 hours ago. (See https://docs.npmjs.com/unpublishing-packages-from-the-registry).

I’m sorry, but this is bad and should not have happened. Imho this is a breaking change and should have been released as version 9.

We have a lot of workspaces and pipelines. Some with pinned pnpm versions. Now a developer using 8.6 changes the lock file without realizing it is breaking and boom, all pipelines are broken.

Example: lockfile is 6.1 created by pnpm 8.6.1 rinning pnpm i with 8.5.1:

❯ pnpm i
 WARN  Your pnpm-lock.yaml was generated by a newer version of pnpm. It is a compatible version but it might get downgraded to version 6.0
 ERROR  /@ampproject/remapping@2.2.1 is an invalid relative dependency path

pnpm: /@ampproject/remapping@2.2.1 is an invalid relative dependency path
    at Object.parse2 [as parse] (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:114178:15)
    at nameVerFromPkgSnapshot (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:114287:28)
    at addPreferredVersionsFromLockfile (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:196837:89)
    at getPreferredVersionsFromLockfileAndManifests (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:196831:7)
    at _installInContext (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:197757:142)
    at async installInContext (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:198099:16)
    at async _install (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:197622:25)
    at async mutateModules (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:197344:23)
    at async install (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:197270:45)
    at async installDeps (/home/mriehema/.local/share/pnpm/global/5/.pnpm/pnpm@8.5.1/node_modules/pnpm/dist/pnpm.cjs:199336:31)

And the only solution is to get all pipelines and developers to the same version either >=8.6 or <=8.5? And we need to release all our packages with the new lockfile or we need to disallow the usage of 8.6? Do you understand how much effort this needs to achieve?

The only solution might be to revert the lockfile format version, which I am considering. But it should be done in a way that will not affect users who have already upgraded.

@zkochan I’ve upgraded but as it was spotted early enough, no big deal and really appreciate the feature (attempt) BTW.

Release notes are helpful and I tend to refer to it often. Might be nice to have some kind of links to “errors” a bit like what’s done in nextjs: ‘Lockfile 6.1 was deprecated, see how to solve https://pnpm.io/errors/pnpm-lockfile-6.1-deprecated’… Just an idea.

Don’t you read the release notes before upgrading the version of pnpm? I pin my version of pnpm via volta’s or asdfto ensure everyone is using the same versionpnpm` for a project

Update pnpm to v8.6. That is the only solution. Unfortunately there is a bug in pnpm v8.5, it thinks the lockfile v6.1 format is v5. I only noticed it after bumping the lockfile format to v6.1