pnpm lock file updates always fail with ERR_PNPM_OUTDATED_LOCKFILE when pnpm-workspace.yaml sets frozenLockfile: true

[aronstrandberg]

How are you running Renovate?

Self-hosted: renovatebot/github-action v46.1.19 (Renovate 43.260.3) on a pnpm 11 monorepo. The relevant code is unchanged on main, so this reproduces there too.

Describe the problem

If a repository's pnpm-workspace.yaml sets frozenLockfile: true (a drift guard so bare local pnpm install never rewrites the lock file — pnpm 11 reads settings from pnpm-workspace.yaml), then every npm-manager branch fails artifact generation:

ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with <ROOT>/npm-packages/lovite/package.json

Failure reason:
  - vite (lockfile: >=5.0.0 <8.0.0, manifest: >=6.4.3 <8.0.0)

Renovate records an artifact error and pushes branches with manifest edits but no pnpm-lock.yaml update. Every PR then fails CI at install time and carries a renovate/artifacts=failure status. The failure is deterministic — the lock file is out of date by construction because Renovate just edited the manifest.

Root cause

generateLockFile() runs pnpm install --lockfile-only [--recursive] [--ignore-scripts --ignore-pnpmfile] with no frozen-lockfile handling (lib/modules/manager/npm/post-update/pnpm.ts). On the pnpm side:

• pnpm's CI frozen default has a --lockfile-only carve-out, but the carve-out only applies while frozen-lockfile is unset; an explicitly-set value skips it (install.ts)
• only CLI flags take precedence over pnpm-workspace.yaml settings; pnpm_config_*/npm_config_* env vars lose to them (acknowledged by the pnpm maintainers in config/reader/src/index.ts L941–953)

So there is no self-hosted config workaround: no env var can override the setting, and Renovate's pnpm invocation accepts no extra flags. Affected repos must choose between their local drift guard and working Renovate pnpm updates.

Note: the pnpm update --no-save … --lockfile-only path (rangeStrategy=update-lockfile) is not affected — pnpm's frozen mode only gates plain installs (and pnpm update rejects frozen-lockfile flags entirely).

Minimal reproduction

https://github.com/aronstrandberg/renovate-pnpm-frozen-lockfile-repro — one workspace package with an outdated left-pad, valid lock file, and frozenLockfile: true. The readme includes a 3-command pnpm-only transcript (fails without --no-frozen-lockfile, succeeds with it, pnpm 11.5.3).

Proposed fix

Append --no-frozen-lockfile to the pnpm install --lockfile-only command (only there — pnpm update neither needs nor accepts it). A lock file regeneration command can never meaningfully run frozen. This mirrors two merged precedents that made lock file updates override repo-level "immutable install" settings:

• yarn: fix(npm): support frozen-lockfile in .yarnrc #18184 (scrubs --install.frozen-lockfile true from .yarnrc; Berry uses YARN_ENABLE_IMMUTABLE_INSTALLS=false)
• deno: fix(manager/deno): set --frozen=false default to update lock file correctly #43058 (deno install --frozen=false, "we should always override the frozen flag")

I have a PR ready with the one-line change plus updated tests (link in the first comment).

[aronstrandberg]

Fix PR: #44676