Improve testing story by migrating to vite/vitest?

[ThisIsMissEm]

Proposal

Swap osprey_ui's build and test tooling from rsbuild/rstest to Vite/Vitest.

Raising this as a discussion rather than an issue because #235 was maintainer-directed ("@haileyok @cmttt is this what you had in mind?") and the reasoning for rsbuild over the alternatives isn't recorded anywhere I can find. If there was a reason, I'd rather hear it than quietly migrate away from it.

What's actually driving this: the frontend has no test story

The build tool is close to a coin flip. The test runner isn't.

• pnpm test runs rstest --passWithNoTests, so ui-quality is structurally incapable of failing on coverage. It reads as a passing test job to anyone glancing at the checks.
• There is exactly one test file in the whole frontend: src/components/event_stream/getSummaryFeaturesForEvent.test.ts, a pure-function test. No component tests, no e2e, no testing-library, no jsdom, no msw.
• @types/jest@24.0.23 is still in devDependencies — jest types, from 2019, with no jest installed and a different runner in use. Anyone writing their first test will be autocompleted toward globals that don't exist.

This is about to matter more. The rule-authoring UI (#403, backed by #487) renders differently depending on can_edit_rules, can_deploy_rules and rule_deployment_enabled, across three RuleStatus values. Those branches currently have no way to be verified except a human deliberately becoming each kind of user and looking.

Why Vitest specifically

	First published	Latest
@rstest/core	2025-06-10	0.11.11 (we pin 0.9.9)
vitest	2021-12-03	4.1.11

rstest is fifteen months old and pre-1.0. For rendering components and asserting on permission-dependent UI, Vitest's testing-library/jsdom story is four years old and exhaustively documented, where rstest's is new enough that we'd be debugging the runner alongside our own tests. With one test file in the repo, there is nothing to migrate and no sunk cost.

It also has a path beyond unit tests. Vitest's Browser Mode runs tests in a real browser (Playwright or WebdriverIO as the provider) rather than jsdom, which is the right level for "does the deploy dialog disable the button for an author" — and full E2E is Playwright, sharing the same Vite pipeline and config. Vitest doesn't claim to be an E2E tool itself, but the Vite ecosystem gives a continuous path from unit → component-in-browser → E2E. I couldn't find an equivalent story for rstest.

Why the bundler comes along

Vitest doesn't require Vite as the app bundler, so we could keep rsbuild and add Vitest. The argument for moving both is consistency: coop already uses Vite, and one toolchain across ROOST projects means contributors move between repos without relearning. That's worth more than either tool's benchmarks.

It also happens to be cheap, because there is no webpack lineage to preserve. #235 replaced react-scripts (create-react-app), not a hand-rolled webpack config, and rsbuild.config.ts is 25 lines that map 1:1 onto Vite:

rsbuild	Vite
pluginReact()	@vitejs/plugin-react
pluginSass()	built in (install sass)
server.host / server.port	same
loadEnv({ prefixes: ['REACT_APP_'] })	envPrefix: 'REACT_APP_'
source.define: { 'process.env': … }	define — identical shim
html.template: './public/index.html'	index.html moves to project root
output.distPath.root: 'build'	build.outDir: 'build'

No custom loaders, no aliases, no webpack plugins. I also checked the source for webpack-isms that would block an ESM-first bundler — require.context, require(), module.hot, !!loader! syntax, SVG-as-component imports, CommonJS — and there are none. Three process.env. reads, which the define shim above already covers.

Rough shape of the work

1. Replace @rsbuild/* with vite, @vitejs/plugin-react, sass
2. Move public/index.html to the project root, add <script type="module" src="/src/index.tsx">
3. Port the seven config lines
4. rstest → vitest; drop --passWithNoTests once there is something to run
5. Delete @types/jest
6. Add @testing-library/react + jsdom and one real component test, so the check can fail

Reasons not to

• rsbuild works. Swapping a functioning bundler is churn, and the CI time difference is unlikely to matter at this size.
• If someone picked rsbuild deliberately — Rspack's webpack-compatible plugin ecosystem, familiarity, a ROOST-wide direction I'm unaware of — that outranks consistency with coop, and I'd want to know before anyone spends time on it.
• The test-story problem can be solved without touching the bundler, by adding Vitest alongside rsbuild. That's the smaller change if the bundler question is contentious.

What I'd like from this discussion

Mainly: was rsbuild chosen for a reason that isn't written down? And if not, is aligning on Vite/Vitest with coop something we want, or would you rather keep the bundler and just fix the testing gap?

Related: #219 (SDLC checklist — "Tests for all commits" is unticked), #304, #302.