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

Macariel · 2023-06-06T07:20:38Z

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

The text was updated successfully, but these errors were encountered:

ghostdevv · 2023-06-08T13:03:06Z

Noticing this too unfortunately

zkochan · 2023-06-09T01:21:22Z

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

pitgrap · 2023-06-09T08:39:55Z

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?

lietu · 2023-06-11T13:13:31Z

"... closed this as not planned", so what you're saying is that you're aware of a breaking change, and are refusing to even consider fixing it?

The correct solution would be something like

pull the broken version causing a breaking change within 8.x
make sure the lockfile version is not marked as a minor change if it's a breaking change, so not 6.1 but 7.0
release that as pnpm 9.x
make a clear public apology and tell people how to fix the issue that you've caused

not

tell people who happen to find some closed issue that they can only fix it by requiring everyone in the team, every CI machine, etc. to upgrade to 8.6
do nothing else

zkochan · 2023-06-11T13:30:26Z

pull the broken version causing a breaking change within 8.x

That is not an easy task. It will cause problems for people who have already updated. What will happen then? Their lockfile will be downgraded to the previous version, and they will need to update the CI and inform everyone on the team?

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.

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

Do you think I am happy with this situation? Please refrain from attacking a person who maintains an open source project in their free time.

weyert · 2023-06-11T14:21:02Z

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

zkochan · 2023-06-11T14:22:56Z

Let's not blame the users. I do acknowledge that this is an issue. I will change the lockfile version field to 6.0. It should fix the issue.

weyert · 2023-06-11T14:26:51Z

Okay, I will see if I need to make changes to my pnpm lock file parser to accommodate for that change.

zkochan · 2023-06-11T14:28:19Z

It will still have this new field:

pnpm/pnpm-lock.yaml

Lines 3 to 5 in 955d073

    
           settings: 
        
             autoInstallPeers: true 
        
             excludeLinksFromLockfile: false

just the lockfileVersion field will be changed back to 6.0

It will work with older versions of pnpm, which just ignore the new field.

weyert · 2023-06-11T14:30:10Z

Yeah, I meant third party tools that depend on it, e.g. Turborepo or vulnerability scanners etc

close #6648

MikeMcC399 · 2023-06-11T20:45:16Z

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).

RoyRao2333 · 2023-06-12T10:17:55Z

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.

zkochan · 2023-06-12T13:53:46Z

Maybe mark some vulnerabilities in this release.

This wasn't a security vulnerability.

belgattitude · 2023-06-12T14:17:05Z

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.

zkochan · 2023-06-12T14:18:55Z

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.

mikhael28 · 2023-06-12T16:05:42Z

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.

* Related issue: pnpm/pnpm#6648

ekwoka · 2023-06-13T06:06:21Z

Why don't people just keep their stuff up to date?

pitgrap · 2023-06-13T08:55:51Z

Why don't people just keep their stuff up to date?

Why don't people just keep silent, if they don't contribute anything useful?

Thank you @zkochan, for the fast and simple fix.

zkochan · 2023-06-13T09:03:31Z

I agree that it was the right choice to revert the version number bump. I will lock the issue now.

v8.6.0, v8.6.1, v7.33.0 had the new lockfile version. If you created a lockfile with these versions and need to use the lockfile with older pnpm versions, you may manually edit the lockfileVersion field in pnpm-lock.yaml to 6.0. From v8.6.2 and at least untill v9, pnpm will keep the lockfileVersion field set to 6.0 for compatibility with all pnpm v8 versions.

Macariel added the type: bug label Jun 6, 2023

Macariel changed the title ~~Lockfile generated with 8.6.1 does not work with 8.5.1~~ Breaking changes with v8.6.1: Installing with older versions (e.g. 8.5.1) does no longer work Jun 6, 2023

Macariel changed the title ~~Breaking changes with v8.6.1: Installing with older versions (e.g. 8.5.1) does no longer work~~ Breaking changes with v8.6: Installing with older versions (e.g. 8.5.1) does no longer work Jun 6, 2023

zkochan closed this as not planned Won't fix, can't repro, duplicate, stale Jun 9, 2023

zkochan reopened this Jun 11, 2023

weyert mentioned this issue Jun 11, 2023

[Turborepo] Add supporting to pnpm-lock.yaml v.6.1 vercel/turbo#5117

Closed

zkochan mentioned this issue Jun 11, 2023

Cannot update pnpm after downgrade #6660

Closed

zkochan added a commit that referenced this issue Jun 11, 2023

fix: downgrade lockfile version to 6.0

8f5d67a

close #6648

zkochan mentioned this issue Jun 11, 2023

fix: downgrade lockfile version to 6.0 #6664

Merged

zkochan closed this as completed in #6664 Jun 11, 2023

zkochan added a commit that referenced this issue Jun 11, 2023

fix: downgrade lockfile version to 6.0 (#6664)

302ebff

close #6648

zkochan added a commit that referenced this issue Jun 11, 2023

fix: downgrade lockfile version to 6.0 (#6664)

dcedc35

close #6648

rollingmoai mentioned this issue Jun 13, 2023

Feature request: support the pnpm package manager dependabot/dependabot-core#1736

Closed

wxx9248 added a commit to wxx9248/matrix.wxx9248.top that referenced this issue Jun 13, 2023

Fix lockfile version

72b46d8

* Related issue: pnpm/pnpm#6648

wxx9248 mentioned this issue Jun 13, 2023

Fix lockfile version wxx9248/matrix.wxx9248.top#8

Merged

wxx9248 pushed a commit to wxx9248/matrix.wxx9248.top that referenced this issue Jun 13, 2023

Fix lockfile version (#8)

6893a63

* Related issue: pnpm/pnpm#6648

preschian mentioned this issue Jun 13, 2023

🔧 ExploreGrid NeoField mb-0 kodadot/nft-gallery#6180

Merged

2 tasks

pnpm locked as resolved and limited conversation to collaborators Jun 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

Macariel commented Jun 6, 2023 •

edited

ghostdevv commented Jun 8, 2023

zkochan commented Jun 9, 2023

pitgrap commented Jun 9, 2023 •

edited

lietu commented Jun 11, 2023

zkochan commented Jun 11, 2023

weyert commented Jun 11, 2023

zkochan commented Jun 11, 2023

weyert commented Jun 11, 2023

zkochan commented Jun 11, 2023

weyert commented Jun 11, 2023

MikeMcC399 commented Jun 11, 2023 •

edited

RoyRao2333 commented Jun 12, 2023 •

edited

zkochan commented Jun 12, 2023

belgattitude commented Jun 12, 2023

zkochan commented Jun 12, 2023

mikhael28 commented Jun 12, 2023

ekwoka commented Jun 13, 2023

pitgrap commented Jun 13, 2023 •

edited

zkochan commented Jun 13, 2023

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

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

Comments

Macariel commented Jun 6, 2023 • edited

pnpm version: 8.6.1

Code to reproduce the issue:

Expected behavior:

Actual behavior:

Additional information:

ghostdevv commented Jun 8, 2023

zkochan commented Jun 9, 2023

pitgrap commented Jun 9, 2023 • edited

lietu commented Jun 11, 2023

zkochan commented Jun 11, 2023

weyert commented Jun 11, 2023

zkochan commented Jun 11, 2023

weyert commented Jun 11, 2023

zkochan commented Jun 11, 2023

weyert commented Jun 11, 2023

MikeMcC399 commented Jun 11, 2023 • edited

RoyRao2333 commented Jun 12, 2023 • edited

zkochan commented Jun 12, 2023

belgattitude commented Jun 12, 2023

zkochan commented Jun 12, 2023

mikhael28 commented Jun 12, 2023

ekwoka commented Jun 13, 2023

pitgrap commented Jun 13, 2023 • edited

zkochan commented Jun 13, 2023

Macariel commented Jun 6, 2023 •

edited

pitgrap commented Jun 9, 2023 •

edited

MikeMcC399 commented Jun 11, 2023 •

edited

RoyRao2333 commented Jun 12, 2023 •

edited

pitgrap commented Jun 13, 2023 •

edited