fix(renovate): stop the pnpm version guard breaking every bot lockfile update

[l2ysho]

Note

TL;DR — fixes the always-failing renovate/artifacts — Artifact file update failure job by deleting one line from renovate.json. No change to package.json; the pnpm guard stays exactly as strict as it is on master.

Problem

Every open Renovate PR is red on renovate/artifacts ("Artifact file update failure"), and CI then fails with ERR_PNPM_OUTDATED_LOCKFILE — including on PRs that touch no lockfile at all. #855, #846, #797 and #882 are still stuck behind this.

Root cause

The pnpm version was pinned in three places, and one of them floated:

Place	Value
package.json → packageManager	pnpm@11.13.0
package.json → devEngines.packageManager	11.13.0, onFail: "error"
renovate.json → constraints.pnpm	^11.0.0 ← floats

Renovate resolved its pnpm from the floating range. Once pnpm 11.13.1 shipped on 2026-07-16, that range started resolving above the guard, so Renovate's pnpm install aborted and it never wrote pnpm-lock.yaml. No repo commit caused this — the range drifted on its own, which is why git log shows nothing. Last successful bot lockfile write: 2026-07-15 (#785, at pnpm 11.13.0).

Reproduced on unmodified master:

• pnpm 11.13.0 → installs fine
• pnpm 11.25.0 (what ^11.0.0 resolves to today) → [ERROR] This project is configured to use 11.13.0 of pnpm. Your current pnpm is v11.25.0

The uv locks still update correctly on the same PRs, which rules out a network or sandbox problem in Renovate's environment.

Changes

renovate.json only. package.json is byte-identical to master.

• Drop constraints.pnpm. This is the fix. Renovate now reads the version from the packageManager field, resolves exactly 11.13.0, and matches the guard.
• config:base → config:recommended. Deprecated alias that Renovate already maps to the new name. No behaviour change.
• pinVersions: false → rangeStrategy: "replace". Renovate's PinVersionsMigration already rewrote the old key to exactly this, so behaviour is unchanged — but dropping it without the replacement would have fallen back to the auto default and changed how every range update is written.
• Add internalChecksFilter: "strict" explicitly. Already the default, so no behaviour change; the three sibling repos all state it, and stating it here keeps the intent visible if the default ever moves.

The last three align this config with apify/crawlee, apify/apify-client-js and apify/apify-sdk-js, none of which declare constraints.

What this deliberately does not do

An earlier revision relaxed devEngines.packageManager.onFail to "warn". That is reverted — the guard is untouched. Two reasons:

• It was not needed. The floating constraints range was the whole cause.
• onFail also governs the package-manager name check, so "warn" stops blocking npm install at the repo root. That bypasses every pnpm-only setting in pnpm-workspace.yaml: the 1-day minimumReleaseAge supply-chain gate, the allowBuilds postinstall allowlist, and the @puppeteer/browsers override.

A range (^11.13.0) with onFail: "error" also clears the guard, but pnpm string-compares packageManager against devEngines.packageManager, so it warns "packageManager" will be ignored on every command, and corepack rejects a range outright.

Verification

Against a standalone pnpm 11.25.0 (what Renovate resolves) and npm 11.16.0:

Case	Result
ordinary PR branch, exact pin + onFail: "error"	exit 0 — the artifacts step stops failing
master's shape with constraints still present	exit 1 — reproduces the bug
CI path, pnpm 11.13.0, pnpm install --frozen-lockfile	exit 0, unchanged
npm install at the repo root	exit 1, EBADDEVENGINES — guard intact

renovate-config-validator validates the new config.

Known remaining case

A Renovate PR that bumps packageManager alone leaves devEngines behind and still aborts — #855 does exactly this. That is now one red PR instead of the whole queue, and it is fixed by a commit syncing both pins. apify/crawlee handles it the same way (apify/crawlee#4050).

After merge

The queued Renovate PRs need a rebase to pick up a valid lockfile. Expect #855, #846, #797 and #882 to go green on their next run.

Separate follow-ups (not in this PR)

• pnpm@11.13.0 is deprecated upstream as a broken release ("Please install pnpm v11.13.1 or newer"); its @pnpm/exe build ships without a working binary. Nothing breaks today because devEngines only compares version numbers and never downloads. Bumping the pin is a prerequisite for dropping devEngines entirely, which is the right long-term shape — without devEngines there is no onFail, so pnpm defaults to download, tries to install the broken 11.13.0, and hard-errors on every install.
• apify/apify-cli carries the same bug: constraints.pnpm: "^11.0.0" plus packageManager: pnpm@11.11.0 against devEngines 11.8.0. It survives only because its onFail is "warn", which hides the desync.
• fix(renovate): skip browser downloads during artifact update #884 proposes a different fix for the same symptom (browser downloads via a renovate.json env block). That diagnosis does not hold: Renovate's pnpm step runs --lockfile-only, which executes no postinstall scripts, and repo-level env requires the self-hosted allowedEnv allowlist (default []), which the Mend-hosted app does not grant.
• Renovate has automerge: true with automergeType: "branch", but the org ruleset requires 1 approving review on master — so branch automerge can never fire and the queue piles up. Worth switching to automergeType: "pr" with GitHub native auto-merge.

🤖 Generated with Claude Code

[l2ysho]

@B4nan can you take a look pls?

[B4nan]

are you sure this is actually needed? renovate works fine on other repos, they all use onFail: error, e.g. https://github.com/apify/crawlee/blob/master/package.json#L157

not sure if the version here needs to be complete, maybe having ^11.13.0 would work too? then you could keep the onfail error too

[l2ysho]

^11.13.0 should work but we get this in every install

[WARN] "packageManager" and "devEngines.packageManager" specify different
       versions of pnpm in package.json. "packageManager" will be ignored

I will try claude to find some different solution, probably drop contraint and keep onFail: error will be enough

btw sdk and client use warn also

[B4nan]

btw sdk and client use warn also

that's because they use pnpm 10, which proxies some commands to npm

anyway, i am not entirely sure this was a good move either, maybe we can just drop the devEngines completely until they are properly supported everywhere. it sucks we have multiple places where we specify those things, and iirc devEngines are the newest (and likely the future standard) one.

[l2ysho]

if i remove devEngines there will be no check at all but with no constraint defined, it should pick one from packageManager field, this should be what we want (?)

[l2ysho]

@B4nan rebased, description updated. WDYT? just drop constraint (same as crawlee, sdk)