How do I share a Vitest HTML report?

Run `vitest run --reporter=html` (with `@vitest/ui` installed), which writes `html/` — then drag that folder into Comma or PATCH `html/index.html` to the API. You get a URL that opens in any browser, with no `vite preview` step and no local server.

Why can't I just open the Vitest HTML report file directly?

Because it loads its results as a separate JSON module, and browsers block module fetches from `file://` origins. Vitest's own docs tell you to serve it — `npx vite preview --outDir html`. Publishing the bundle solves the same problem permanently and for everyone, not just for you.

Does the interactive UI still work at the URL?

Yes. Report HTML renders with scripts enabled inside a sandboxed iframe, and the results JSON travels with the bundle as an asset with its reference rewritten, so filtering, the failure detail panes and the module graph all behave.

How do I publish it from CI?

Run Vitest with the HTML reporter in the job, then PATCH the same report id on every run. One stable URL per suite, a revision per run, and red runs are worth publishing — use `if: always()` so a failing build still produces the report someone needs to read.

Can I comment on a specific failing test?

Yes. Threads anchor to the rendered content, so 'this is the flaky one, it's a fake timer' sits on that test instead of scrolling past in a channel, and it stays there on the next run.

Share a Vitest HTML report

Vitest's HTML reporter is a genuinely nice artifact — the failure tree, the diff for the assertion that blew up, the module graph — and it has an unusual property: you cannot open it by double-clicking it. The page loads its results as a JSON module, and file:// origins block module fetches, so the official instructions are to spin up vite preview first.

Which means the report exists in exactly one place: on the machine that ran the tests. Everything downstream is a terminal screenshot.

Publish the folder

npm i -D @vitest/ui
npx vitest run --reporter=html    # → html/

Drag html/ (or a zip of it) into the app:

index.html becomes the report body.
The results JSON, the bundle and the assets upload alongside it, and their relative references are rewritten to the uploaded copies — which is exactly the step file:// cannot do.
Scripts run inside a sandboxed iframe (allow-scripts, no allow-same-origin), so the filters and detail panes work.

One URL. No preview server, no "run this command first" in the message you send a teammate.

From CI

npx vitest run --reporter=html

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html html/index.html \
        --arg title "Unit tests — $GITHUB_SHA" '{title: $title, html: $html}')"

Run the step with if: always() (GitHub Actions), when: always (GitLab, CircleCI) or post { always { … } } (Jenkins). A green run's report is nice to have; a red run's report is the entire point.

PATCHing one report id keeps a single URL per suite and appends a revision per run — so "was this failing yesterday?" is a diff, not an archaeology expedition through expired artifacts.

What review adds

The value of a shared test report is not the pass count, it is the record of what the team decided about a failure:

Anchored threads on the failing test — see commenting on HTML.
Revisions, so a flake's history is visible rather than remembered.
Access per report — private, team, domain-gated, or named reviewers. See the sharing model.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total. A huge suite's results JSON is the file to watch; shard the suite if it gets close.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a test report →