ci: gate web/frontend PRs on tsc --noEmit + vite build

[padak]

Why

Follow-up to PR #658 non-blocking finding NB-1, deferred there so the CI change gets its own review instead of riding a large feature PR.

.github/workflows/ci.yml covers only the Python side. A frontend PR's type errors ship to main undetected — #658 carried three commits' worth of frontend bugs caught only by manual tsc/build runs and a live browser pass, including a types.ts field-name mismatch (configId vs the Queue API's actual config) that made a whole table column render empty and a new button never render.

What

New .github/workflows/frontend.yml that runs in web/frontend:

1. npm ci
2. npx tsc --noEmit
3. npm run build (tsc -b && vite build — the same command hatch_build.py runs when bundling the SPA into the wheel)

Path gating: no existing workflow in this repo uses paths: filtering, so this introduces the scheme: triggers only on changes under web/** (plus the workflow file itself), so Python-only PRs never schedule a runner. It is a separate workflow file because paths: filters are trigger-level, not job-level. This is safe because the main ruleset has no required_status_checks rule (verified via gh api repos/keboola/cli/rules/branches/main — the merge gate is the human review), so a skipped run can never leave a required check pending. If frontend checks ever become required, the filter needs rethinking (in-job change detection, or a paths-ignore mirror that reports success).

Deliberately NO vitest step — maintainer decision requested

There are zero *.test.* / *.spec.* files under web/frontend/src. Notably, npx vitest run on the empty suite does not pass vacuously — it exits 1 with No test files found, so adding it now would fail every frontend PR. Options:

• (this PR) type-check + build only; add npm test when the first test lands — vitest's fail-on-empty default then also guards against the suite silently vanishing;
• alternatively add vitest run --passWithNoTests now — rejected here because it would pass vacuously and hide that nothing is tested.

Say the word if you prefer the other option.

Out of scope

web/backend (dev-mode BFF, TypeScript too) has no type-check gate either; it is not part of the wheel build. Can be added to this workflow later with an analogous job.

Verification

• Locally: npm ci, npx tsc --noEmit, npm run build all pass in web/frontend.
• This PR itself triggers the workflow (the workflow file path is in its own paths: filter), so the run visible on this PR is the live verification.

---

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[padak]

Review of #661 — ci: gate web/frontend PRs on tsc --noEmit + vite build

Generated by kbagent-pr-reviewer subagent. Verdict and findings below
are advisory; the human author retains every veto. CI-coverable issues
(lint, format, tests) are confirmed via make check, not duplicated here.

Summary

This PR adds .github/workflows/frontend.yml, a new GitHub Actions workflow that runs npx tsc --noEmit and npm run build in web/frontend on any PR/push touching web/**, closing a real gap surfaced by PR #658 (a types.ts field-name mismatch that shipped undetected because CI only exercises the Python side). The change is infrastructure-only (no src/, no CLI command, no plugin-sync surface touched), so most of the command-checklist playbook (3-layer compliance, OPERATION_REGISTRY, AGENT_CONTEXT, gotchas.md, etc.) is not applicable here. Verdict: APPROVE — the workflow is well-scoped, the path-filtering rationale is independently verified against the live branch-ruleset API, the new job already ran green on this very PR, and the deliberate omission of a vitest step is well-justified (an empty suite fails outright rather than passing vacuously).

Verdict

• Verdict: APPROVE
• Blocking findings: 0
• Non-blocking findings: 0
• Nits: 1

Blocking findings

(none)

Non-blocking findings

(none)

Nits

• [NIT-1] .github/workflows/frontend.yml:29 and :34 — paths: ["web/**", ...] also matches web/backend/**-only changes, which will schedule this frontend runner even though the job never touches web/backend. Given the PR explicitly scopes web/backend as future/out-of-scope work, narrowing to web/frontend/** (plus the workflow file itself) would avoid a wasted run on backend-only PRs until an analogous backend job is added.

Verification log

• gh pr view 661 --json title,body,files,additions,deletions,baseRefName,headRefName,labels,state → 1 file changed (.github/workflows/frontend.yml, +68/-0), state OPEN, conventional prefix ci: matches a CI-config-only change ✓
• git rev-parse --abbrev-ref HEAD → ci/frontend-typecheck-build, matches <branch> ✓ (no checkout needed)
• Read CONTRIBUTING.md (Checklist, Plugin synchronization map, Releasing a new version) and CLAUDE.md convention #17 — confirmed not applicable: no CLI command added/removed/renamed, no services//commands//client/ touched, no permissions.py surface affected.
• Read plugins/kbagent/agents/keboola-expert.md §1 — no CLI behavior changes to cross-check.
• gh api repos/keboola/cli/rules/branches/main → rule types are deletion, non_fast_forward, pull_request (review-count based) only; no required_status_checks rule present — independently confirms the PR description's core safety claim that a skipped/path-filtered workflow run can never leave a required check pending ✓
• grep -n "paths" .github/workflows/*.yml → frontend.yml is the only workflow using paths: filtering, confirming the PR's claim "no existing workflow in this repo uses paths: filtering" ✓
• grep -n "engines" web/backend/package.json → "node": ">=20"; grep -n "node-version" .github/workflows/ci.yml (build-windows job) → "20" — confirms the comment's claim that Node 20 matches both floors ✓
• find web/frontend/src -iname "*.test.*" -o -iname "*.spec.*" → empty — confirms "zero *.test.*/*.spec.* files" claim, justifying the deliberate omission of a vitest step ✓
• cat web/backend/package.json → has its own "build": "tsc -p tsconfig.json" script but no CI job — confirms the "Out of scope: web/backend" statement is accurate (not silently glossed over) ✓
• grep -n "checkout@\|setup-node@" .github/workflows/*.yml → actions/checkout@v5 and actions/setup-node@v6 are the versions already used consistently across ci.yml, release.yml, release-kbagent.yml, e2e.yml — new workflow matches repo convention, no stray pin ✓
• cache-dependency-path: web/frontend/package-lock.json reviewed against defaults.run.working-directory: web/frontend — correct: with: inputs to actions/setup-node are resolved relative to repo root regardless of the job's defaults.run.working-directory (which only affects run: steps), so the repo-root-relative path is correct, not a copy-paste bug ✓
• gh pr checks 661 → live reproduction: Type check + build (web/frontend) → pass, 33s, alongside check, test (3.12), test (3.13), Windows wheel build, and Devin Review — all green on this exact commit, directly confirming the PR's own "Verification" section claim that this PR triggers its own workflow ✓
• gh api repos/keboola/cli/issues/661/comments → no additional review comments beyond the check-status entries (Devin Review passed with no flagged findings) ✓
• make check was not re-run locally: the PR touches no Python source, and CI's check/test (3.12)/test (3.13) jobs already ran green on this exact commit (see gh pr checks above), which is a stronger signal than a redundant local run against unrelated HEAD state.

Open questions for the author

(none)