pnpm(update-lockfile): grouped monorepo PR titled as an update but lockfile doesn't change the targeted package

[RahulGautamSingh]

Discussed in #43960

^{Originally posted by thasmo June 12, 2026}

Description

When a grouped rangeStrategy: update-lockfile PR targets a package that pnpm silently refuses to bump (because of an internal peer constraint), Renovate still opens/keeps a PR whose title advertises the update. The branch ends up containing only unrelated transitive updates from pnpm install, while the targeted dependency is unchanged.

Renovate should verify the requested packageName@newVersion actually landed in the regenerated lockfile and not ship a misleadingly-titled PR otherwise.

Reproduction

PR: thasmo/website#739

Possible Fix

After regenerating the pnpm lockfile, for each isLockfileUpdate upgrade verify its packageName reached newVersion in the new lockfile.
If not:

• don't push a lockfile artifact that contains only unrelated churn, and
• surface it (artifact error / info log) rather than silently shipping a misleadingly-titled PR.

Logs

Check discussion. Logs were too long to post in PR description

[viceice]

we should issue an artifact error in that case

[thasmo]

FYI, the repro is not representative anymore because Renovate managed to update the PR correctly after some time.