Dependabot npm PRs always fail: it drops the lockfile's `overrides:` header

[williamzujkowski]

Symptom

Every Dependabot PR touching astro-site/pnpm-lock.yaml fails all five
site checks in 8–17 seconds, before any audit runs:

ERR_PNPM_LOCKFILE_CONFIG_MISMATCH
Cannot proceed with the frozen installation. The current "overrides"
configuration doesn't match the value found in the lockfile

Seen on #532 and #537.

Updated evidence: resolution can regress too

Reproduced on September 8 against bot PR #564, original commit d0160c50bdd2ff98067db65088a7780c3656104d, using pnpm 10.33.0. Besides deleting the overrides: header, the bot changes satori@0.33.4 from overridden fflate@0.7.5 back to fflate@0.7.3. Native pnpm install --lockfile-only restores both metadata and resolution; frozen install then succeeds. The older serialization-only diagnosis below is therefore insufficient for current updates.

Upstream report with immutable manifests/lockfiles, CI failure, and reproduction: dependabot/dependabot-core#16232. The hosted updater version/code path is still unverified. Keep this issue open until upstream behavior or a tested permanent configuration change resolves it. Do not repair only the header: regenerate and inspect the resolved graph.

Historical diagnosis from #537 (superseded by #564)

Dependabot applies pnpm.overrides during resolution but omits the
overrides: header when it serialises the lockfile. pnpm install --frozen-lockfile compares that header against package.json, finds it
missing, and refuses.

The resolution really is correct — #537's tree contains fast-uri 3.1.7, which
can only be there because of the ^3.1.6 override:

package	main	#537
fast-uri	3.1.7	3.1.7
vite	8.1.5, 8.2.2	8.1.5, 8.2.2
yaml	2.8.3, 2.9.0	2.8.3, 2.9.0
brace-expansion	5.0.9	5.0.9

Those observations led to a serialisation-only hypothesis at the time. PR #564 disproves that generalization: at least the parent-scoped override also loses its resolution.

Not caused by the duplicate overrides block

I initially diagnosed this as the duplicated top-level overrides in
package.json and fixed that in #533. That was wrong — #537 was opened
3m43s after #533 merged, without the duplicate, and fails identically.
(The duplicate was still worth removing: it was dead config that had drifted
from the live block. See the correction comment on #533.)

Workaround, per PR

git fetch origin <dependabot-branch>:<local>
git checkout <local>
cd astro-site && pnpm install --lockfile-only    # restores the overrides: header
pnpm install --frozen-lockfile                   # the command that was failing

Then re-verify normally: pnpm build, pnpm check, pnpm lint,
pnpm run audit, pnpm test:unit.

Worth deciding

Three options, roughly in increasing order of effort:

1. Keep fixing by hand. Honest, but it is a tax on every npm bump, and the
   failure looks alarming (5 red checks) for a reason that has nothing to do
   with the dependencies being bumped.
2. A small workflow that regenerates the lockfile on Dependabot branches
   and pushes the result. Needs contents: write on a Dependabot-authored
   branch, which is a permission worth thinking about carefully.
3. Report upstream to dependabot-core and reference the issue here.

Not urgent — the gate is failing closed, which is the correct direction. But
it should not be rediagnosed from scratch next time.

[williamzujkowski]

September 8 backlog follow-up: there is currently no open Dependabot PR against which to reproduce or verify a permanent fix. The documented per-PR pnpm install --lockfile-only followed by frozen install remains the bounded workaround. Required checks remain fail-closed.

Inspected upstream Dependabot helper selection: it selects pnpm10 for lockfile v9. Similar pnpm11 override behavior is not proof of this incident's cause. No speculative override migration or write-token repair workflow was introduced. Keep this issue open for the next actual bot update; capture its updater version/log and verify the regenerated dependency resolution before changing automation.

[williamzujkowski]

Backlog grooming (2026-09-12): watch item. Keep open for the next real Dependabot PR; the documented lockfile regeneration workaround remains the safe path and no speculative write-token workflow should be added.