Verify latest release
pnpm version
11.1.1
Which area(s) of pnpm are affected? (leave empty if unsure)
CLI, lockfile, patching
Link to the code that reproduces this issue or a replay of the bug
https://github.com/Stanzilla/pnpm-optimistic-patch-lockfile-repro
Reproduction steps
This looks related to #10393, but this reproduces the lockfile-conflict case on the latest release.
git clone https://github.com/Stanzilla/pnpm-optimistic-patch-lockfile-repro.git
cd pnpm-optimistic-patch-lockfile-repro
pnpm install
git merge origin/update-patch
pnpm install
grep -n '<<<<<<<' pnpm-lock.yaml
Observed output from the final pnpm install:
Already up to date
Done in 177ms using pnpm v11.1.1
The final grep still finds conflict markers in pnpm-lock.yaml.
Control case:
rm -rf node_modules
pnpm install
grep -n '<<<<<<<' pnpm-lock.yaml || echo 'conflict resolved'
With node_modules removed, pnpm prints Merge conflict detected in pnpm-lock.yaml and successfully merged and resolves the lockfile.
Describe the Bug
When optimistic-repeat-install=true and node_modules is already up to date for the current branch, pnpm install can short-circuit before resolving a conflicted pnpm-lock.yaml.
The repro has two branches:
main: adds is-odd, so node_modules and pnpm-lock.yaml are up to date after the first install.
update-patch: only changes patches/is-number@7.0.0.patch and the lockfile entries generated from that patch hash.
After merging update-patch into main, pnpm-lock.yaml has conflicts. Running pnpm install exits successfully with Already up to date and leaves those conflict markers in place.
Expected Behavior
pnpm install should not use the optimistic repeat-install fast path when pnpm-lock.yaml contains conflict markers. It should resolve/recalculate the lockfile, including the updated patch hash, or fail instead of exiting successfully while the lockfile remains conflicted.
Which Node.js version are you using?
v24.14.1
Which operating systems have you used?
If your OS is a Linux based, which one it is? (Include the version if relevant)
No response
Verify latest release
pnpm version
11.1.1
Which area(s) of pnpm are affected? (leave empty if unsure)
CLI, lockfile, patching
Link to the code that reproduces this issue or a replay of the bug
https://github.com/Stanzilla/pnpm-optimistic-patch-lockfile-repro
Reproduction steps
This looks related to #10393, but this reproduces the lockfile-conflict case on the latest release.
Observed output from the final
pnpm install:The final
grepstill finds conflict markers inpnpm-lock.yaml.Control case:
With
node_modulesremoved, pnpm printsMerge conflict detected in pnpm-lock.yaml and successfully mergedand resolves the lockfile.Describe the Bug
When
optimistic-repeat-install=trueandnode_modulesis already up to date for the current branch,pnpm installcan short-circuit before resolving a conflictedpnpm-lock.yaml.The repro has two branches:
main: addsis-odd, sonode_modulesandpnpm-lock.yamlare up to date after the first install.update-patch: only changespatches/is-number@7.0.0.patchand the lockfile entries generated from that patch hash.After merging
update-patchintomain,pnpm-lock.yamlhas conflicts. Runningpnpm installexits successfully withAlready up to dateand leaves those conflict markers in place.Expected Behavior
pnpm installshould not use the optimistic repeat-install fast path whenpnpm-lock.yamlcontains conflict markers. It should resolve/recalculate the lockfile, including the updated patch hash, or fail instead of exiting successfully while the lockfile remains conflicted.Which Node.js version are you using?
v24.14.1
Which operating systems have you used?
If your OS is a Linux based, which one it is? (Include the version if relevant)
No response