vitest focused test committed to main: how to catch

TL;DR

Turn on the guardrail in CI, not in developers' heads. Set Vitest's allowOnly to false explicitly (it already defaults that way when CI env vars are present) and add the eslint no-focused-tests rule so .only never even gets committed. Belt and suspenders: CI fails the run if one slips through.

Problem

A describe.only or it.only got committed and merged, so CI ran a fraction of the suite green while most tests never executed.

Steps

1. Confirm CI sets a standard CI env var (most providers do). Expected: echo $CI prints true in a CI job.
2. In the vitest config set test allowOnly to false explicitly so it does not depend on env detection. Expected: a local vitest run with .only present fails with an only-related error.
3. Add eslint-plugin-vitest with the no-focused-tests rule to fail lint on .only. Expected: eslint flags any focused test before commit.
4. Add the lint step to CI before the test step. Expected: PRs containing .only fail fast at lint time.
5. Optional: add a pre-commit hook running the same lint rule. Expected: .only never reaches the remote.

When to use

• A focused test reached main and CI stayed green.
• You want CI to enforce full-suite runs.
• Vitest 2 or 3 with GitHub Actions, GitLab CI, or similar.

When not to use

• Developers need .only locally for debugging; the rule targets CI and lint, not local runs.
• You use Jest; use eslint-plugin-jest no-focused-tests instead.
• Your suite intentionally runs subsets via file filters or projects; that is filtering, not focusing.

Tool compatibility

• Vitest 2.x, 3.x: test.allowOnly config, defaults to false under CI.
• eslint-plugin-vitest: no-focused-tests rule.
• Any CI provider that sets CI=true (GitHub Actions, GitLab, CircleCI).

Variant phrasings

how to block it.only in CI

Same answer: allowOnly false plus the lint rule.

vitest ran only some tests in CI

Check for a committed .only first; then lock the guardrails in so it cannot recur.

Why it happens

.only is a local debugging aid that Vitest honors silently in dev. Nothing fails by default outside CI, so without an explicit guardrail a focused test sails through review and CI runs a partial suite.

Edge cases

• allowOnly relies on CI env detection; self-hosted runners that do not set CI=true need the explicit config.
• Some editors auto-insert .only via snippets; the lint rule catches those too.
• If you genuinely need focused runs in CI for sharding, use projects or file filters instead of .only.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstA9CFLbQF-kAazDcnXkc4Q