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
- fix: downgrade lockfile version to 6.0 close #6648 — committed to pnpm/pnpm by zkochan a year ago
- fix: downgrade lockfile version to 6.0 (#6664) close #6648 — committed to pnpm/pnpm by zkochan a year ago
- fix: downgrade lockfile version to 6.0 (#6664) close #6648 — committed to pnpm/pnpm by zkochan a year ago
- Fix lockfile version * Related issue: https://github.com/pnpm/pnpm/issues/6648 — committed to wxx9248/matrix.wxx9248.top by wxx9248 a year ago
- Fix lockfile version (#8) * Related issue: https://github.com/pnpm/pnpm/issues/6648 — committed to wxx9248/matrix.wxx9248.top by deleted user a year ago
I’d like this approach. Maybe mark some vulnerabilities in this release.
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.
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:
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?
@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 ofpnpm
viavolta’s or
asdfto ensure everyone is using the same version
pnpm` for a projectUpdate 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