undici-types 6.21.x: a trusted-publisher re-release would unblock current @types/node@20/22 under pnpm trustPolicy #5919

Hi, and thanks for restoring trusted publishing on the 6.x line in 6.23.0 (#4666).

An FYI with data, since the restoration doesn't quite reach the affected users:

• @types/node 20.x and 22.x pin undici-types ~6.21.0, up to the latest 22.20.4 (2026-09-19) and 20.19.43. Older ones pin ~6.19.2, ~6.19.8 or ~6.20.0.
• The only versions inside those ranges (6.19.3–6.19.8, 6.20.0, 6.21.0) were published without provenance after 6.19.1/6.19.2 had it.
• So pnpm's trustPolicy: no-downgrade still rejects them. The 6.23+ trusted releases fall outside the ranges.
• In a random sample of 200 stable npm releases replayed with pnpm 10.29.3, 16 of the 18 that failed did so because of undici-types 6.21.0 or 6.19.8, almost all through @types/node.
• For reach: @types/node versions with those pins account for roughly 175M of its 499M weekly downloads (all clients).

Reproduce (lockfile-only, read-only):

mkdir t && cd t
echo '{"name":"t","version":"0.0.0","private":true,"dependencies":{"@types/node":"22.20.4"}}' > package.json
printf 'trustPolicy: no-downgrade\n' > pnpm-workspace.yaml
npx pnpm@10.29.3 install --lockfile-only --ignore-scripts
# ERR_PNPM_TRUST_DOWNGRADE  High-risk trust downgrade for "undici-types@6.21.0"

Suggestion, only if it's cheap for you: publish undici-types@6.21.1 (same content as 6.21.0, or matching undici 6.21.x) through the current trusted-publisher workflow. ~6.21.0 would then resolve to a trusted release with no change needed in DefinitelyTyped.

We know the root issue is the policy's date-based design, and we have raised that with pnpm separately. Feel free to close this if it isn't worth a release.

Igor Santos-Grueiro