`pnpm audit` flagged two moderate vulnerabilities introduced by the
docs-site chantier (#154):
* esbuild ≤ 0.24.2 — dev-server reflection of arbitrary cross-site
requests (GHSA-67mh-4wv8-2f99).
* vite ≤ 6.4.1 — path traversal via optimized-deps `.map` handling
(GHSA-4w7w-66w2-5vf9).
Both come from VitePress 1.6.4's pinned dep tree
(`vitepress → vite@5.4.21 → esbuild@0.21.5`). The rest of the
workspace already runs vite 8.0.13 + esbuild 0.27.3 (via @nx/vite,
@analogjs/vite-plugin-angular, Vitest) — only the VitePress branch
was stuck on the vulnerable line.
The vite team did not backport the security fix to the 5.x line
(`vite@^5.4.22` is not published — latest 5.x stays at 5.4.21,
which is vulnerable). The only path forward is to let pnpm pick a
patched major. With the override below, pnpm resolves vitepress's
`vite ^5.0.0` constraint up to vite 7.3.2 — VitePress 1.6.4 runs
against it cleanly: `docs:build` succeeds in ~4 s and the Mermaid-
in-ADR-0009 regression fence still passes.
Pattern matches the existing `pnpm.overrides` entries in this
project (axios, follow-redirects, ip-address, etc.) — version-
selector form `<package>@<vulnerable-range>` so the override
becomes a no-op when the underlying dep eventually ships a clean
version of its own.
Why Renovate didn't propose this PR itself: vite and esbuild are
**transitive** dependencies (declared by vitepress, not by us).
Renovate's `vulnerabilityAlerts` flow handles direct deps; for
pnpm transitives it would have to write to `pnpm.overrides`
itself, which the v40 image doesn't do out of the box. The override
is the manual remediation that Renovate would write if it could.
Julien Gautier