fix(deps): Clear all 109 Dependabot alerts in the vizard lockfiles

[ovr]

Split out of #11853, which was getting large. Closes all 109 open Dependabot alerts across the three packages/cubejs-playground/vizard lockfiles — the preview shell and both downloadable starter templates — as 7 independently revertable commits, touching nothing outside packages/cubejs-playground/vizard/. The lockfiles could not simply be regenerated: a full regen floats the react-aria family from 3.32.x to 3.52.x, which dropped useMessageFormatter and breaks @cube-dev/ui-kit at build time, so every change here is a targeted yarn upgrade <pkg>@<range> or a stripped-and-re-resolved lockfile entry. Along the way react-router-dom and toml came out entirely — both were declared but never imported (react-router-dom appeared only as a manualChunks entry in vite.config.ts), and the starter templates now hand users a current @cubejs-client/* instead of ^0.35.0.

package	before	after	alerts
vite	5.1.4 / 5.1.6	7.3.6	45
js-yaml	4.1.1	4.3.2	12
minimatch	3.1.2, 5.1.6, 9.0.3	3.1.5, 5.1.9, 9.0.9, 10.2.6	11
postcss	8.4.31 / 8.4.35 / 8.4.36	8.5.28	12
react-router / @remix-run/router	6.22.3 / 1.15.3	removed	6
rollup	4.12.0 / 4.13.0	4.63.1	6
esbuild	0.19.12	0.28.2	3
uuid	8.3.2	11.1.1	3
picomatch	2.3.1	4.0.7	3
lodash	4.17.21	4.18.1	3
@babel/core	7.24.0 / 7.24.1	7.29.7	3
toml	3.0.0	removed	2

Check List

• Tests have been run in packages where changes have been made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

Verification

Nothing in PR CI installs or builds vizard — it is built only by publish.yml via lerna run build -> build:vizard -> build-apps.js — so every commit was verified locally with yarn build in packages/cubejs-playground/vizard, which builds both app templates, regenerates src/apps.json / src/stats.json, produces both download zips and both preview bundles, and then builds the preview site. @typescript-eslint 8 (needed to unpin minimatch@9.0.3) turns on caughtErrors: 'all', which flagged three never-read catch (e) bindings; they became optional catch bindings, and yarn lint is back to its pre-existing 13 problems / 2 errors — it was already red before this change and is not run by CI.

🤖 Generated with Claude Code

[claude]

Claude finished @ovr's task in 6m 42s —— View job

---

Review complete — no blockers; 0 high, 0 medium, 3 low (all posted inline)

Full review

• Gather context (diff, changed files, vizard build wiring)
• Review non-lockfile changes (package.json, config.ts, Vizard.tsx, vite.config.ts)
• Spot-check lockfile consistency vs package.json ranges
• Check prior review threads
• Post findings

What holds up

• The @cubejs-client bump is a real bug fix, not just hygiene. Both templates' src/App.tsx:1,30 use the v1 API — import cube from '@cubejs-client/core' and <CubeProvider cubeApi={...}> — neither of which exists in the ^0.35.0 range the manifests declared. Anyone who downloaded a starter zip and ran yarn install got a package that could not typecheck. ^1.7.37 fixes that, and all three lockfiles resolve @cubejs-client/{core,react,ws-transport} to 1.7.37 consistently.
• react-router-dom and toml really are unused. Nothing under vizard/src imports either; the only surviving toml hit is src/monaco/config.ts:24, a Monaco language id, unrelated to the npm package. The manualChunks entry at vite.config.ts:15 was correctly trimmed with it.
• chart.js / react-chartjs-2 removal from the antd template is correct — ChartViewer.tsx there renders an antd <Table> and imports no chart library; both packages are gone from that template's lockfile too. The directory name is unchanged, so build-apps.js:153 still parses react-typescript-antd-table into framework/language/library/visualization the same way, and nothing in vizard/src keys off the template's package.json name.
• No cross-platform regression in the lockfiles. All 26 @esbuild/* and 25 @rollup/rollup-* platform entries are present at 0.28.2 / 4.63.1 — a hand-edited lockfile easily drops the non-host ones and breaks macOS/Windows installs; these did not.
• Spot-checked resolutions are internally coherent. uuid@^11.1.1 and picomatch@^4.0.3 are genuinely requested by their new parents (@cubejs-client/core and vite/tinyglobby respectively), not ranges retyped to force an upgrade; lodash@^4.17.15 (from archiver-utils) and js-yaml@^4.1.0 (from eslint/@eslint/eslintrc) are floated in place, which is the legitimate way to do this. react-aria stays at 3.32.1 as the description explains.
• The catch (e) → catch changes (src/config.ts:12 ×2, src/Vizard.tsx:52) are behaviour-preserving; the bindings were never read.

Findings (all low, all posted inline)

#	Where	Concern
1	vizard/.nvmrc:1 (commented on package.json:41)	Pinned Node 18.19.1 no longer satisfies vite 7 / @vitejs/plugin-react 5 engines (^20.19.0 || >=22.12.0). Release CI runs Node 24 so publishing is fine; local nvm use && yarn build is not.
2	vizard/package.json:18	@cubejs-client/react is declared but never imported in src — kept alive only by the clients manualChunks entry, the same situation that justified dropping react-router-dom here.
3	both templates' package.json	eslint: ^8.56.0 sits below @typescript-eslint 8's peer floor ^8.57.0 || ^9. Works today (lockfiles resolve 8.57.0), but the shipped manifest advertises an invalid range.

Not verified

• No install/build run. yarn install was not permitted in this environment, so the lockfiles were reviewed statically (resolution/range consistency, platform-binary completeness, orphan entries) rather than by installing. The description's local yarn build in vizard/ remains the load-bearing verification, and nothing in PR CI will repeat it — the first CI exercise of these lockfiles is publish.yml.
• Alert closure not independently confirmed. list_dependabot_alerts was not available to this run, so the "109 alerts" claim is taken from the description; the version bumps themselves check out against the lockfiles.

Review threads

The listing returned 0 threads on this PR (none mine, none human) — nothing to resolve, and no finding was skipped as a duplicate.

• branch [`dependabot-vizard-alerts`](https://github.com/cube-js/cube/tree/dependabot-vizard-alerts)

[claude]

@cubejs-client/react is in exactly the position react-router-dom was in before this PR: nothing under vizard/src imports it — the only reference is the clients entry in vite.config.ts:17, which forces it into a manual chunk and so into the preview bundle. @cubejs-client/core next to it is imported, but only for types (src/types.ts:1, src/Vizard.tsx:1, src/Setup.tsx:11), so the clients chunk is shipping two runtime libraries the preview never calls.

Dropping @cubejs-client/react and the clients manualChunks entry (leaving @cubejs-client/core as a devDependency for the types) applies the same rule the react-router-dom/toml commit already established. Out of scope if you'd rather keep this PR purely lockfile-shaped — but then the two cases read inconsistently.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.67%. Comparing base (9b444bd) to head (24f450d).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #11900   +/-   ##
=======================================
  Coverage   60.67%   60.67%           
=======================================
  Files         240      240           
  Lines       19297    19297           
  Branches     3914     3914           
=======================================
  Hits        11709    11709           
  Misses       7040     7040           
  Partials      548      548           

Flag	Coverage Δ
cube-backend	60.67% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[claude]

Claude finished @ovr's task in 5m 34s —— View job

---

Review round 4 — no new findings; 3 prior threads re-affirmed, 0 resolved. (0 new high/medium/low)

Review detail

• Gather context (commits, non-lockfile diff, base 9b444bd)
• Review the seven source/manifest changes
• Verify the removals (react-router-dom, toml, chart.js) against actual imports
• Cross-check every lockfile resolution against the declared ranges
• Scan the three lockfiles for lingering vulnerable transitives
• Handle prior review threads
• Post outcome

Review threads

Listing returned 3 unresolved threads, all mine. 0 resolved — each concern is still reproducible on the branch:

thread	site	concern
PRRT_kwDOCOH19M6i9rUg	packages/cubejs-playground/vizard/package.json:41	packages/cubejs-playground/vizard/.nvmrc:1 still pins 18.19.1; vite 7 and @vitejs/plugin-react 5 both declare engines: ^20.19.0 || >=22.12.0 — verified, the file is unchanged in this branch
PRRT_kwDOCOH19M6i9rh6	packages/cubejs-playground/vizard/package.json:18	@cubejs-client/react is unused — still only vite.config.ts:17 (manualChunks.clients), never imported from src/
PRRT_kwDOCOH19M6i9rnu	antd template package.json:26	eslint: ^8.56.0 sits below the @typescript-eslint 8 peer floor of ^8.57.0

Both findings I arrived at this round (the vite 7 Node floor, and @cubejs-client/react as dead weight by the same test that dropped react-router-dom) are substantively the first two threads, so nothing new was posted inline.

What I verified

• Removals are real. react-router-dom appears nowhere under vizard/ outside the old manualChunks entry, and toml only as a Monaco language id string (vizard/src/monaco/config.ts:24) — not an import. chart.js/react-chartjs-2 are genuinely unused by the antd template: its ChartViewer.tsx renders antd's <Table> only. All three are gone from the corresponding lockfiles, and chart.js is still present in the chartjs template's lockfile where it belongs.
• The @cubejs-client bump is a correctness fix, not just an alert sweep. Both templates already use the v1 API — CubeProvider cubeApi={…} at apps/react-typescript-antd-table/src/App.tsx:34 — which does not exist in the ^0.35.0 they declared.
• Lockfiles match the manifests. Every declared range has a matching entry at the claimed version in all three lockfiles (vite@^7.3.6 → 7.3.6, @typescript-eslint/* @^8.70.0 → 8.70.0, @vitejs/plugin-react@^5.2.0 → 5.2.0, minimatch 3.1.5/5.1.9/9.0.9/10.2.6, postcss 8.5.28, rollup 4.63.1, esbuild 0.28.2, uuid 11.1.1, js-yaml 4.3.2, lodash 4.18.1, picomatch 4.0.7, @babel/core 7.29.7). The surviving @vitejs/plugin-react@^4.2.1 in the preview lockfile is not a stale orphan — @cube-dev/ui-kit declares it as a runtime dependency (yarn.lock:232).
• No lingering vulnerable transitives in any of the three: nanoid 3.3.19, brace-expansion 1.1.18/2.1.4/5.0.9, cross-spawn 7.0.6, @babel/runtime 7.29.7, prismjs 1.30.0, semver 6.3.1/7.8.5, ws 7.5.13, debug 4.4.3.
• The catch {} conversions are safe — all three bindings were unused, and both template tsconfigs target ES2020.
• The package rename is inert. build-apps.js keys the zip name, preview path and stats.json off the directory name (build-apps.js:112, :153), not package.json's name; vizard-react-typescript-chartjs is referenced nowhere else in the repo. src/apps.json and src/stats.json are build artifacts, not tracked, so they cannot go stale.
• Node 24 in release CI (publish.yml:33) is comfortably above vite 7's floor, which is why the thread above is scoped to local dev only.

I could not independently confirm the "109 alerts closed" count — list_dependabot_alerts is not granted to this run, and gh api …/dependabot/alerts is outside the allowed commands.

· branch [`dependabot-vizard-alerts`](https://github.com/cube-js/cube/tree/dependabot-vizard-alerts)

[claude]

Claude finished @ovr's task in 4m 43s —— View job

---

Review: no new findings — 1 prior finding still live (.nvmrc Node pin), 1 resolved

Full review

• Gather context (diff, changed files)
• Review non-lockfile source changes
• Verify removed deps are truly unused
• Verify lockfile/package.json consistency
• Check prior review threads
• Post findings

Verified

Removed deps are genuinely unused. react-router / toml have no import anywhere under packages/cubejs-playground/vizard/ (only the manualChunks entry at vite.config.ts:15, now dropped). chart.js / react-chartjs-2 are unreferenced in the antd-table template — ChartViewer.tsx:20 renders an antd <Table> and ignores the chartType prop it receives. Both are gone from that template's lockfile too, so the download zip shrinks rather than shipping a dangling range.

@cubejs-client 0.35 → 1.7.37 is API-compatible with the template code. cubejs-client-core/src/index.ts:1016 still ships the default cube(token, options) factory the templates call at App.tsx:31, and cubejs-client-react/src/CubeProvider.tsx:32 still takes the cubeApi prop. useCubeQuery(query, { subscribe, skip }) signature is unchanged.

Lockfiles are internally consistent — every range in the three package.jsons has a matching entry, no orphaned react-router / @remix-run / toml / chart.js blocks in the shell or antd-table locks, and the resolved versions match the table in the description (vite 7.3.6, esbuild 0.28.2, rollup 4.63.1, postcss 8.5.28, js-yaml 4.3.2, minimatch 3.1.5/5.1.9/9.0.9/10.2.6, picomatch 4.0.7, lodash 4.18.1, uuid 11.1.1). eslint@^8.57.0 resolves to 8.57.1, which satisfies @typescript-eslint 8's ^8.57.0 || ^9 peer bound.

Vite 7 in CI is fine. publish.yml and all of cubejs-docker/*.Dockerfile are on Node 24, so build:vizard → build-apps.js → yarn install && yarn run build per template runs above vite 7's engine floor.

The antd-table name rename is cosmetic and safe. build-apps.js:153 and convert-apps.js key everything off the directory name, and src/app-name.ts resolves through VIZARD_PARAMS_MAP; no code reads the templates' package.json name. Both templates are private: true, so the previously duplicated name was never published — but two workspaces sharing one name was still a trap.

The optional-catch-binding conversions (Vizard.tsx:52, both src/config.ts:12) are behaviour-preserving; neither binding was read.

Not posted inline

@cubejs-client/core is used only for type-only imports in the preview shell (src/types.ts:1, src/Vizard.tsx:1, src/Setup.tsx:11) and so belongs in devDependencies, and the templates now need Node 20.19+ via vite 7 without declaring an engines field. Both predate this PR in spirit and neither breaks the build; flagging as context rather than a change request.

Review threads

The listing returned 3 threads, all mine, on one page.

• Resolved 1: PRRT_kwDOCOH19M6i9rnu (templates' eslint peer range) — both template package.jsons now declare eslint: ^8.57.0, fixed by 0c8db1a. Replied on the thread before resolving.
• Re-affirmed 2 still-live threads: the .nvmrc Node pin, and @cubejs-client/react remaining a runtime dependency of the shell with no src import while still listed in the clients manualChunks entry at vite.config.ts:18.
• Skipped 1 new finding as a duplicate: packages/cubejs-playground/vizard/.nvmrc:1 still reads 18.19.1 while vite ^7.3.6 and @vitejs/plugin-react ^5.2.0 both require Node ^20.19.0 || >=22.12.0, so nvm use && yarn build in vizard now hard-fails locally. That is thread PRRT_kwDOCOH19M6i9rUg verbatim, so no second comment.

• [`dependabot-vizard-alerts`](https://github.com/cube-js/cube/tree/dependabot-vizard-alerts)

[claude]

Claude finished @ovr's task in 7m 45s —— View job

---

Reviewed — no blockers; 1 low posted inline, 1 prior thread re-affirmed

Review detail

• Fetch PR diff (9b444bd..HEAD, 11 files)
• Review non-lockfile source changes
• Cross-check lockfile resolutions against the claimed versions
• Check the dropped .nvmrc against the build path
• Resolve stale review threads / dedupe findings
• Post findings

What holds up

The targeted-upgrade approach is verifiable from the lockfiles themselves. All three resolve vite@7.3.6, esbuild@0.28.2, rollup@4.63.1, postcss@8.5.28, js-yaml@4.3.2, picomatch@4.0.7, uuid@11.1.1, minimatch at 3.1.5/5.1.9/9.0.9/10.2.6 and @babel/core@7.29.7, with react-router, @remix-run/router and toml gone from every lock and no duplicate entries left for the bumped packages. react-aria is still pinned at 3.32.1 (vizard/yarn.lock:3093), which is the constraint the description says a full regen would have broken. Commonly-alerted transitives are all on patched versions too — brace-expansion 1.1.18/2.1.4/5.0.9, cross-spawn 7.0.6, nanoid 3.3.19, ws 7.5.13, semver 7.8.5.

Spot-checking the hand-edited entries for internal consistency: vite@7.3.6's deps (esbuild "^0.27.0 || ^0.28.0", fdir ^6.5.0, picomatch ^4.0.3, postcss ^8.5.6, rollup ^4.43.0, tinyglobby ^0.2.15, fsevents ~2.3.3) each have a matching key, as do @typescript-eslint/typescript-estree@8.70.0's minimatch "^10.2.2" and every remaining minimatch range. @vitejs/plugin-react@^4.2.1 and react-refresh@^0.14.0 survive in the root lock, but that is correct, not leftover — @cube-dev/ui-kit@0.33.2 declares @vitejs/plugin-react "^4.2.1" as a runtime dependency (vizard/yarn.lock:232).

The dep removals check out against the source. react-router-dom and toml have no importer anywhere under vizard/, and chart.js/react-chartjs-2 are genuinely unused by the antd template — its ChartViewer.tsx:1-2 imports only @cubejs-client/core and antd. The @cubejs-client/* bump from ^0.35.0 to ^1.7.37 fixes a real mismatch rather than creating one: both templates already call CubeProvider cubeApi={…} (apps/react-typescript-antd-table/src/App.tsx:35), which is the v1 prop name, and cube is still the default export at packages/cubejs-client-core/src/index.ts:1016. Dropping the package-local .nvmrc is safe for CI — nothing referenced it (only drivers-tests.yml:332 reads the root one, 24.18.0), and publish.yml builds on Node 24, so vite 7's engine floor is met where build:vizard actually runs. The three catch (e) → catch changes are the minimal fix for caughtErrors: 'all'.

Posted inline

• low apps/react-typescript-antd-table/package.json:30 — neither downloadable template declares engines, so a user unzipping the starter on Node 18 hits vite 7's engine failure with nothing in the template announcing the new floor; the only Node pin in the tree is deleted by this PR.

Review threads

The listing returned 2 of my own unresolved threads. Resolved 1 (vizard/package.json:41, the stale .nvmrc pin — the file is gone as of 24f450d). Re-affirmed 1 that still applies: vizard/package.json:18 — @cubejs-client/react remains a dependency and stays in manualChunks.clients (vite.config.ts:17) although nothing under vizard/src imports it, so rollup still pulls it into the preview bundle as a chunk root. Same shape as the react-router-dom entry this PR removed from that list.

Not verified

npm view and running Node were blocked in this sandbox, so the existence of each resolved version on the registry and a real yarn install --frozen-lockfile / yarn build were not re-run here; the version consistency above is read out of the committed lockfiles. list_dependabot_alerts was also unavailable, so the "all 109 cleared" count is not independently confirmed — what is confirmed is that no entry for the listed packages remains at a vulnerable version.

· [`dependabot-vizard-alerts`](https://github.com/cube-js/cube/tree/dependabot-vizard-alerts)

[claude]

vite 7 requires Node ^20.19.0 || >=22.12.0 and @vitejs/plugin-react 5 the same, but neither starter template declares engines, and the only Node pin in the tree (vizard/.nvmrc, 18.19.1) is deleted in this PR. A user who downloads the zip on Node 18 — still the pin this repo shipped until this commit — gets vite's bare You are using Node.js 18.x. Vite requires Node.js version 20.19+ or 22.12+. and no hint from the template that the requirement changed.

Adding the field to both apps/*/package.json makes yarn install say it up front:

  "engines": {
    "node": "^20.19.0 || >=22.12.0"
  },

Fix this →