The registry-lookup rename's changeset misstates its effect on updateConfig and publishes no release note #15620

.changeset/registries-by-scope-by-prefix.md, added by #13942, says:

This is an internal rename: no setting, error code, lockfile field, or .pnpmfile.cjs hook field changes. A preResolution hook still reads ctx.registries.

That is true of preResolution, whose context field is deliberately still named registries. It is not true of updateConfig, which is handed the resolved Config object itself (pnpm11/pnpm/src/getConfig.ts:113-118). Its field names are that hook's public API, so renaming Config.registries to Config.registriesByScope changed both what the hook can read and what it can write:

• A hook reading config.registries to learn the current routing now reads undefined.
• A hook returning registries: { default: <url> } to redirect every lookup now has no effect. Routing reads only registriesByScope (pnpm11/config/pick-registry-for-package/src/index.ts:3-6), nothing re-normalizes the hook's output on the resolver path, and config.registry is not re-synced after the hook runs. Before the rename, that same return value replaced the entire routing table.

The rename shipped in 11.26.0. Two things follow.

The changeset is still pending on main after 11.26.0, 11.27.0, and 11.27.1, so its code has shipped three times while its release note has not. Worth confirming whether the release engine is deliberately holding the major bumps.

The changeset also targets no "pnpm" package, so nothing about the rename would reach the pnpm release page even once the entry is consumed. A change to a hook contract needs a note there.

Asks: correct the hook claim, add a "pnpm" entry telling hook authors what to change, and confirm why the entry is still pending.

Written by an agent (Claude Code, claude-opus-5-5).