Track: package.json dependency overrides (cookie / undici / esbuild) and their removal conditions

[lj-n]

Tracking issue documenting the overrides block added to package.json in #212, so the rationale isn't buried in a commit message and each pin has a clear removal condition.

All three are transitive packages flagged by npm audit (was 8 advisories: 7 low, 1 high → now 0). Overrides are resolver-level pins — pure lockfile changes, no source/runtime behaviour change (with one documented caveat for cookie, below).

"overrides": {
  "cookie": "^0.7.0",
  "undici": "^7.28.0",
  "esbuild": "$esbuild"
}

cookie — 0.6.0 → 0.7.2 (7× low, GHSA-pxg6-pf52-xh8x)

• Path: transitive via @sveltejs/kit (this one ships in the production server runtime — kit uses cookie's parse/serialize on every request).
• Why an override and not a kit bump: even @sveltejs/kit@latest (2.70.1) still pins cookie ^0.6.0. This is deliberate on SvelteKit's part, not neglect:
  • Maintainers judged the advisory low-impact / not applicable — it only bites if untrusted input becomes a cookie name/path/domain, which apps shouldn't allow. They closed the audit-complaint issues as not planned (SvelteKit depends on a "vulnerable" version of cookie lib sveltejs/kit#13089, #12903).
  • The fix in cookie 0.7+ is itself a breaking change: strict character validation (cookie names must be ASCII; out-of-bounds chars now throw instead of being silently accepted). Bumping it inside a kit 2.x minor would break apps using non-ASCII cookie names, so they deferred it to a major — breaking: upgrade to cookie v1 sveltejs/kit#13386 (breaking: upgrade to cookie v1) is merged into the version-3 branch and ships in SvelteKit 3.0.0-next.0.
• Caveat / why it's safe here: the override opts us into that stricter validation early. genug-da only sets ASCII, constant, non-user-controlled cookie names — session_token (src/lib/server/db/auth/utils.ts) and the theme cookie — all path: '/'. The edge case SvelteKit was cautious about does not exist in this app.
• Removal condition: drop this override when we upgrade to SvelteKit 3 (kit will depend on cookie v1 natively; leaving the override could even hold cookie back at 0.7.x).

undici — 7.24.7 → 7.28.0 (1× high, multiple advisories)

• Path: transitive via jsdom — test-only, not shipped in the production build.
• Why the override: 7.28.0 already satisfies jsdom's own range (^7.24.5), so this is a low-risk nudge to the top of the allowed range. Renovate's weekly lockFileMaintenance would also pull this eventually; the override makes it deterministic now.
• Removal condition: safe to drop once jsdom (or whatever pulls undici) resolves to a fixed undici on its own. Low urgency — harmless to keep.

esbuild — $esbuild (1× low, GHSA-g7r4-m6w7-qqqr)

• Path: a nested copy under vite (0.27.7). Dev-server + Windows-only file-read; not a production concern (and we develop on darwin).
• What $esbuild means: the $-reference pins every nested esbuild to whatever we declare at the top level (^0.28.1), deduping vite's private copy up to match. Self-maintaining — it follows our own esbuild bump automatically.
• Removal condition: drop once vite ships an esbuild >=0.28.1 in its own dependency range.

Related

• Fixed in fix: resolve 8 npm audit advisories via dependency overrides #212.
• Renovate note: the overrides act as a floor Renovate respects going forward, so these three can't silently regress. Optionally enabling transitiveRemediation in renovate.json would let Renovate auto-author overrides for future transitive advisories. See also the Renovate Dependency Dashboard (Dependency Dashboard #173).

[lj-n]

Correction on the Renovate note above: transitiveRemediation no longer exists — it was removed from Renovate's config schema upstream, so it can't be enabled. Its current successor is osvVulnerabilityAlerts, which I've enabled in renovate.json (broadens detection to the OSV database, platform-independent, on top of the GitHub-only vulnerabilityAlerts already active via config:recommended).

Caveat worth keeping in mind: osvVulnerabilityAlerts alerts primarily on direct deps and does not auto-author npm overrides for transitive ones the way the old transitiveRemediation did. So for transitive cases like cookie, a manual override (documented here) remains the mechanism.