Repository navigation
resolutionMode: highest selects an older version with shared resolution #17235
Description
Verify latest release
- I verified that the issue exists in the latest pnpm release
pnpm version
12.15.0. Also reproduces on 11.28.6 and 10.30.1.
Which area(s) of pnpm are affected? (leave empty if unsure)
Dependencies resolver
Link to the code that reproduces this issue or a replay of the bug
No response
Reproduction steps
package.json:
{
"name": "shared-resolution-repro",
"private": true,
"packageManager": "pnpm@12.15.0",
"dependencies": {
"ajv": "^6.0.0"
}
}pnpm-workspace.yaml:
packages:
- consumer
lockfile: false
sharedWorkspaceLockfile: true
resolutionMode: highest
minimumReleaseAge: 0
ignoreScripts: trueconsumer/package.json:
{
"name": "consumer",
"private": true,
"dependencies": {
"ajv": "*"
}
}With shared resolution:
pnpm install
node -p 'require("./consumer/node_modules/ajv/package.json").version'
# 6.15.0With independent resolution:
rm -rf node_modules consumer/node_modules
pnpm install --config.shared-workspace-lockfile=false
node -p 'require("./consumer/node_modules/ajv/package.json").version'
# 8.20.0Describe the Bug
With resolutionMode: highest and shared resolution enabled, the consumer's ajv: "*" resolves to Ajv 6 because another project requires ^6.0.0, even though Ajv 8 is available. Setting sharedWorkspaceLockfile: false makes the consumer resolve to Ajv 8.
Related: #6313 was closed for lack of a reproduction on a supported version. This is a concrete example pulled out of DT.
Expected Behavior
The consumer should get Ajv 8 with resolutionMode: highest, regardless of another project's narrower range. The root should still get Ajv 6.
Which Node.js version are you using?
v24.21.0.
Which operating systems have you used?
- macOS
- Windows
- Linux
If your OS is a Linux based, which one it is? (Include the version if relevant)
WSL2, kernel 6.18.54.1-microsoft-standard-WSL2.
Contributing a fix
- I am working on a fix
Activity
zkochan commentedon Oct 22, 2026
How other package managers resolve the reproduction from the issue: root
ajv: ^6.0.0, workspace projectconsumerwithajv: "*", fresh install, no lockfile.nodeLinker: node-modules)ajv@6.15.0because that copy already satisfies*, so the consumer never gets its own resolution. This comes from where npm places packages, not from a dedupe policy.ajv@npm:*at 8.20.0 andajv@npm:^6.0.0at 6.15.0.yarn dedupe --checkreports "No packages can be deduped using the highest strategy". Its dedupe moves a range only onto the highest locked version that satisfies it, and for*that is 8.20.0.Written by an agent (Claude Code, claude-opus-5-5).
jakebailey commentedon Oct 22, 2026
For context, I'm re-looking into doing shared lockfile mode again for DT, since the PR I tried to send (years ago now) was ultimately closed and reimplemented, so I was hoping this would work out.
Unshared lockfile mode isn't too bad, though, of course.
zkochan commentedon Oct 22, 2026
#17244 fixes this in pnpm v12. When
autoDedupeis off (the default), a workspace project's dependencies resolve from its own ranges, so the consumer'sajv: "*"gets the latest Ajv. Two exceptions remain: packages that some project lists inpeerDependenciesstill follow the other projects, andpnpm dedupeorautoDedupe: truestill merge both projects onto Ajv 6. Existing lockfiles keep their resolved versions.Written by an agent (Claude Code, claude-opus-5-5).
fix(resolver): resolve a project's dependencies from its own ranges u…
zkochan commentedon Oct 24, 2026
I have merged the change but I suspect someone might report it as a regression after next release.
fix(resolver): resolve a project's dependencies from its own ranges u…
Update pnpm to v12.16.1 (#2164)