deps: bump browserslist and drop the no-op dompurify override

[nadaverell]

Lockfile-only security follow-up to #2017. The production frontend build is byte-identical to main.

Changes

1. browserslist 4.28.4 → 4.29.3 fixes GHSA-73wf-gq98-2v4g (high). browserslist's data packages move with it: caniuse-lite, electron-to-chromium, baseline-browser-mapping, node-releases and update-browserslist-db.

• Everything was resolved with --before=2026-10-04T09:37:26Z, a 72h soak. The newest mover was published 2026-10-02.
• browserslist is reached only through ESLint → Babel at lint time. Vite's build targets and Tailwind's Lightning CSS targets are hardcoded, so this can't change the bundle, and the build diff below confirms it.

2. The root "overrides": {"dompurify": "3.4.0"} is removed. It never had a runtime effect:

• monaco-editor 0.55.1 imports a vendored DOMPurify 3.2.7 by relative path (esm/vs/base/browser/domSanitize.js → ./dompurify/dompurify.js). The built monaco chunk contains .version="3.2.7".
• No other package in the lock depends on the npm dompurify, and Radar source doesn't import it.
• So the override only made the lockfile, and Dependabot, report a patched version that the browser never ran.
• Without it, npm puts monaco's declared dompurify@3.2.7 under node_modules/monaco-editor/node_modules/. The DOMPurify alerts now describe what actually ships.

What this does NOT fix

Radar still ships DOMPurify 3.2.7 inside monaco. The real fix is monaco-editor ≥0.56, which vendors 3.4.15 (#1930), but that's blocked upstream:

• Runtime. monaco 0.56 added a package exports map that breaks the pre-0.56 deep path monaco-editor/esm/vs/editor/editor.worker.js. monaco-worker-manager 2.0.1, used by monaco-yaml's worker, still imports that path, so the Vite build fails to resolve it.
• Types. @monaco-editor/react 4.7.0, the latest stable, imports the same old path in its types, so Monaco collapses to any.

A Vite alias mapping monaco-editor/esm/vs/* onto the real files makes 0.57 build. Radar Hub bundles radar-app source with its own Vite config, though, so it would need the same alias in lockstep. That was deliberately deferred until upstream catches up.

The exposure is narrow. Monaco calls only sanitize() (with hooks and RETURN_TRUSTED_TYPE) to render hover markdown; most of the open advisories need IN_PLACE, setConfig or custom-element handling.

Verification

• npm ci passes, and npm ls --package-lock-only reports a valid tree.
• make tsc passes.
• Frontend tests pass:
  • packages/k8s-ui: 218 files, 4160 passed, 1 skipped.
  • web: 158 files, 1865 passed.
• npm run lint gives 0 errors and 444 warnings, the same as main.
• make build passes.
• Build diff: web/dist from this branch and from origin/main, each built from a clean npm ci, are identical across all 337 assets.
• Independent review: a second model did a read-only review and found no importer of the npm dompurify and no path from the browserslist data into production JS/CSS.
• visual-test: skipped. The bundle is byte-identical, so nothing rendered can differ.

---

Note

Low Risk
Changes are limited to lockfile and a removed no-op override; production web/dist is reported byte-identical to main.

Overview
This is a lockfile-only dependency hygiene PR: it bumps the browserslist toolchain (including caniuse-lite, electron-to-chromium, baseline-browser-mapping, node-releases, and update-browserslist-db) to address advisory GHSA-73wf-gq98-2v4g. That stack is used at lint/build tooling time (e.g. via ESLint/Babel), not as a direct change to app source.

It also removes the root package.json dompurify override (3.4.0). The lockfile now records dompurify@3.2.7 nested under monaco-editor, matching what Monaco actually vendors—so security reporting aligns with what ships, without changing production bundle output (per PR verification).

^{Reviewed by Cursor Bugbot for commit 007a93c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Remove the ineffective DOMPurify override

⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Remove the root DOMPurify override, which does not affect Monaco’s vendored sanitizer.
• Leave Monaco’s shipped DOMPurify 3.2.7 unchanged; an upstream-compatible Monaco upgrade remains
 necessary.

Diagram

graph TD
  Manifest["Root manifest"] --> Resolution["npm resolution"] --> Lockfile["Lockfile"] --> Monaco["Monaco editor"] --> Vendored["Vendored DOMPurify"] --> Frontend["Frontend bundle"]
  Lockfile --> Browserslist["Browserslist"] --> Lint["Lint tooling"]
  Monaco --> NpmPurify["npm DOMPurify"]

Loading

High-Level Assessment

Removing a misleading override is preferable to retaining a version pin that cannot patch Monaco’s vendored code. The checkout lockfile shows Browserslist 4.29.3 and Monaco’s npm DOMPurify 3.2.7, but the supplied diff contains only package.json; confirm the lockfile changes are included in the PR before presenting the Browserslist fix as part of this diff.

Files changed (1) +0 / -3

Other (1) +0 / -3

package.jsonRemove the root DOMPurify override +0/-3

Remove the root DOMPurify override

• Deletes the root pin to DOMPurify 3.4.0. Monaco imports its own vendored DOMPurify, so removing this pin does not patch the sanitizer shipped in the frontend.

package.json

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗