chore(deps): clear the critical and all high Dependabot alerts

[mattglory]

Summary

Clears the one critical and every high-severity alert. Dev/test tooling only; nothing on the contract path changes.

	before	after
Root (npm audit)	13 (1 critical, 8 high, 4 moderate)	0
Web (npm audit)	23 (2 high)	20, 0 high/critical

What changed

Root

• vitest ^1.0.0 → ^4.1.11. The critical was vitest (fix ≥ 3.2.6); 4.1.11 also clears the follow-on @vitest/mocker advisory GHSA-82fw-gwwq-j7x9, which is only fixed at 4.1.11. Pulls vite 5 → 8.3, clearing the vite high. Same target as Dependabot's Bump vitest from 1.6.1 to 4.1.11 #39.
• overrides: { ws: ^8.21.0 }. Transitive ws couldn't be reached by a normal update: engine.io-client pins ~8.17.1 and @stacks/blockchain-api-client pins exactly 8.16.0.
• smol-toml 1.7.0 → 1.8.0 (transitive via @clarigen/cli, lockfile only).

Web

• overrides: { viem: { ws: ^8.21.0 } }. The only flagged copies were two ws@8.18.2 nodes pinned exactly by viem@2.31.0/2.32.0. Scoped to viem on purpose: walletconnect's ws@7.5.13 isn't affected, and a blanket override would push it across a major version. Merged into the existing overrides block, so the @types/react / @types/react-dom pins are intact.
• js-yaml 4.3.1 → 4.3.2 (lockfile only).

Verification

• Root suite 221/221, run twice, on vitest 4.1.11.
• Web next build clean: Next 16.3.4, TypeScript OK, all 6 routes prerender.
• Not verified locally: Node 20. CI runs Node 20; vite 8 needs ^20.19.0 and vitest 4 needs ^20, so this depends on setup-node resolving a recent 20.x. My machine is on Node 25.9. CI on this PR is the real check. If it fails on the engines floor, the fallback is vitest 3.2.7, which also clears the critical and passed 221/221 in testing.

Deliberately not changed

• The 15 moderate / 5 low web findings all hang off @stacks/connect. npm's suggested "fix" is a downgrade to 8.1.9, so they need an upstream release.
• vitest.config.js has a top-level singleThread: true. vitest's own type declarations show that option now exists only under poolOptions, so it's a silent no-op. Pre-existing, suite is stable without it, left alone.

Supersedes

Dependabot #39 (vitest), #41 (smol-toml), #46 (js-yaml). Not #38, #47, #30, which I haven't touched.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
web	Ready	Preview	Sep 21, 2026 6:53am UTC

[unixwhisperer]

Approving. Every number in the description reproduces, and the Node 20 risk you flagged is settled by CI.

Reproduced locally (Node 22.14, npm ci from the committed lockfiles)

	claimed	measured
Root npm audit	0	0 vulnerabilities
Web npm audit	20, no high/critical	20 — 5 low, 15 moderate, 0 high, 0 critical
vitest installed	4.1.11	4.1.11
Root suite	221/221	221/221 across 20 files

The test count matters more than the pass. vitest 1 → 4 is three majors, and the failure mode I was looking for is silent test loss — changed discovery semantics dropping files, leaving a green run that asserts less. 221 across 20 is identical to main, so discovery is intact. That's the check that makes "221/221" meaningful rather than reassuring.

Node 20: you flagged this as unverified and it's the one thing I couldn't reproduce either (I'm on 22.14). CI settles it — Test Smart Contracts is green on this PR, on Node 20, so the vite-8 ^20.19.0 and vitest-4 ^20 floors resolve fine under setup-node. No need for the 3.2.7 fallback.

Contract path untouched — confirmed by diff: no contracts/, no Clarinet.toml, no .github/. Four package files only.

The scoped viem: { ws } override is the right instinct — a blanket one would have dragged walletconnect's ws@7.5.13 across a major for no benefit, and the reasoning is written down where the next person will find it. Same for keeping the @types/react pins intact.

---

One thing, non-blocking and pre-existing — but this PR makes it worth naming

You noted singleThread: true is now a silent no-op under vitest's current types. Agreed it's out of scope, but it's slightly more than cosmetic in combination with the line four rows below it:

singleThread: true,   // ← no-op
isolate: false,       // ← very much not a no-op

The intent reads as "run serially and don't pay for isolation" — a sane pairing for simnet-backed tests. With singleThread dead, the effective config is isolate: false plus default file parallelism, which is the one combination of the two you wouldn't choose: files sharing a worker also share module state, and ordering becomes load-dependent.

It isn't biting — I've run this suite a dozen times across branches this week and it's been 221 every time, deterministic. So: not a defect, and definitely not yours to fix in a dependency PR. But "the guard someone intended isn't running" is worth a line somewhere rather than staying folded into a no-op. Under vitest 4 the equivalent is poolOptions: { threads: { singleThread: true } }, or fileParallelism: false.

Happy to open that as a one-line follow-up if you want it; equally fine to leave it given the suite's track record.

Agreed on what you left alone

The 15 moderate / 5 low web findings hanging off @stacks/connect genuinely need an upstream release — npm proposing a downgrade to 8.1.9 as the "fix" is not a fix, and taking it would be worse than the advisory. Right call to document rather than act.