chore(release): bump to 0.76.3, fix all open npm Dependabot alerts - #541

Pull request overview

This PR prepares the 0.76.3 release by updating npm dependencies in web/backend and web/frontend to address Dependabot security alerts, and synchronizes the CLI/plugin version metadata and changelog accordingly.

Changes:

• Bump @fastify/static to ^10.1.2 in web/backend (plus associated lockfile updates).
• Apply frontend security remediation by updating audited dependencies and adding an npm overrides entry for dompurify (resolved to 3.4.12 in the lockfile).
• Bump the project version to 0.76.3 and propagate it across pyproject.toml, uv.lock, plugin/marketplace manifests, and changelog.py.

Reviewed changes

Copilot reviewed 6 out of 9 changed files in this pull request and generated no comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Review — chore(release): bump to 0.76.3, fix all open npm Dependabot alerts

Verdict: no blockers. The dependency work is correct, and the dompurify override in particular is the right call for a non-obvious reason (below). Findings are about the PR description and one piece of undocumented reasoning, not the change itself.

Verified against the lockfiles, not just npm audit

npm audit reports 0 vulnerabilities after overrides reshapes the tree, so it partly grades its own homework. I diffed installed versions main → PR and checked each against the advisories' vulnerable_version_range:

Also checked and clean:

• @fastify/static v9 → v10 is a major bump, but safe here. The only breaking change in v10.0.0 is setHeaders receiving FastifyReply instead of Response. web/backend/src/server.ts:47 registers only root / prefix / wildcard — no setHeaders, so nothing to migrate.
• Node floor. brace-expansion narrowed its engines to 20 || >=22; backend declares >=20 and CI pins Node 20 → consistent.
• _ui_dist is not a stale artifact. It's gitignored and populated by the hatch build hook at wheel-build time, so the frontend fix reaches shipped wheels without anything committed here.
• Version bump is consistent. main 0.76.2, latest release v0.76.2, 0.76.3 propagated to plugin.json / marketplace.json / uv.lock, changelog entry present. All checks green.

🟡 1. The override is load-bearing for a reason the PR doesn't state — please capture it

I initially read the override as redundant: the PR also bumps monaco-editor 0.55.1 → 0.56.0, and 0.56.0 pins dompurify at exactly 3.4.8, which looks patched. It isn't. Per the advisory data, 3.4.8 is still vulnerable to three of them:

• GHSA-c2j3-45gr-mqc4 — vulnerable <= 3.4.11, patched 3.4.12
• GHSA-cmwh-pvxp-8882 — vulnerable <= 3.4.10, patched 3.4.11
• GHSA-vxr8-fq34-vvx9 — vulnerable < 3.4.9, patched 3.4.9

Because monaco pins exactly 3.4.8 (not a range), npm has no choice but to materialize a nested vulnerable copy — the override is the only way to force it up. So this is the correct fix, not a workaround.

That reasoning is exactly what a future maintainer needs and can't reconstruct from a 3-line overrides block. It's also a standing commitment: it globally overrides an upstream exact pin, and once monaco ships a release pinning >= 3.4.12 nothing will flag it as removable. package.json can't carry comments, so a line in CONTRIBUTING.md or a web/frontend/README note would do:

overrides.dompurify exists because monaco-editor pins dompurify at an exact version that trails the patched release (0.56.0 → 3.4.8, vulnerable to GHSA-c2j3-45gr-mqc4). Re-check on every monaco-editor bump; drop the override once its pin is >= 3.4.12.

🟡 2. monaco-editor 0.55.1 → 0.56.0 isn't mentioned

npm audit fix pulled a minor bump of the editor component itself. The description only mentions the dompurify override, so the changelog line "No behavior change" is doing quiet work for a UI component bump. Given web/frontend has no tests, this is the one change in the PR that could plausibly alter runtime behavior — worth naming explicitly rather than leaving it in the lockfile diff.

🟡 3. Alert count is 23, not 22 — and it matters more than usual here

There are currently 23 open alerts, including postcss on web/backend/package-lock.json, which the description attributes to the frontend only. The PR does fix the backend copy (8.5.15 → 8.5.24), so this is a description bug, not a coverage gap.

Flagging it because after merge the alert list auto-closes: if one alert is left standing, nobody can tell whether it's a miscount in the description or genuinely unfixed. Stating 23 makes the post-merge check unambiguous.

🟡 4. AI attribution footer contradicts CONTRIBUTING.md:462

No AI attribution footers in PR descriptions

The body ends with 🤖 Generated with [Claude Code]. Since this repo squash-merges and GitHub pre-fills the squash commit message from the PR body, it lands in main's history unless overridden at merge time.

🟢 Note: CI doesn't cover web/backend

CI builds the wheel (which builds the frontend SPA) but never runs npm run build or npm test on the Node BFF, so the major @fastify/static bump rests entirely on the author's local tsc — that's why I checked setHeaders usage by hand rather than trusting the test plan. Not a blocker: web/backend is excluded from the distribution (pyproject.toml:85), so the blast radius is make web-dev, not shipped artifacts. Worth a follow-up issue if the BFF ever becomes shipped surface.

i️ Merge-train note (not this PR)

0.76.3 is correct against main (0.76.2) and stays correct if this lands first. Heads-up though: #535 and #538 both bump to 0.77.0 and will collide with each other — whichever merges second needs renumbering.

Approving — no blockers. Verified the fixes against the lockfiles rather than npm audit (which grades its own homework once overrides reshapes the tree): every flagged package lands on a version outside its advisory's vulnerable range, and the nested monaco-editor/node_modules/dompurify@3.2.7 is gone. The @fastify/static v9→v10 major is safe here — its only breaking change (setHeaders) isn't used in server.ts.

Two asks before the squash-merge, both on the description rather than the code:

1. Drop the AI attribution footer (CONTRIBUTING.md:462) — the repo squash-merges and GitHub pre-fills the commit message from the PR body, so it lands in main's history otherwise.
2. Mention the monaco-editor 0.55.1 → 0.56.0 bump that npm audit fix pulled in, and correct the alert count to 23. The count matters after merge: when the alert list auto-closes, a mismatch makes it ambiguous whether a leftover alert is a miscount or genuinely unfixed.

The overrides.dompurify entry is the right call and worth a one-line note somewhere durable — monaco pins dompurify at exactly 3.4.8, which is still vulnerable to GHSA-c2j3-45gr-mqc4 (patched 3.4.12), so the override is the only way up. Once monaco pins >= 3.4.12 nothing will flag it as removable.

Unrelated heads-up: #535 and #538 both bump to 0.77.0 and will collide with each other. This PR's 0.76.3 is fine either way.