[FEAT] Add --format oxlint / Oxlint formatter support (parity with ESLint) #868
Description
Vitest currently supports formatting test results for ESLint via --format eslint, which enables editor integrations, CI annotations, and unified tooling workflows.
As Oxlint adoption grows, Vitest should offer first-class formatter support for Oxlint as well, matching the existing ESLint formatter.
Why this matters (DX + performance)
- Oxlint is significantly faster than ESLint, especially in large monorepos and CI environments
- Teams migrating from ESLint → Oxlint lose formatter parity when using Vitest
- Formatter support enables:
- Inline editor diagnostics
- CI annotations (GitHub Actions, etc.)
- Consistent tooling across linting + testing
- Vitest already has the abstraction and precedent here — this is ecosystem alignment, not a new concept
In practice, many teams are now:
- Using Oxlint for linting (speed, Rust-based, low overhead)
- Using Vitest for tests
- Forced to fall back to ESLint formatters or custom glue, which undermines the value of faster tooling
Proposed API
vitest run --format oxlint
// or
// vitest.config.ts
export default defineConfig({
test: {
outputFile: {
oxlint: 'oxlint.json',
},
},
})Exact shape is flexible — the core requirement is official Oxlint-compatible output, not community workarounds.
Why this belongs in Vitest (not external plugins)
- ESLint formatter support is already built-in
- Formatter output is tightly coupled to Vitest’s reporter internals
- First-party support ensures:
- Stability across releases
- Correct mapping of test failures → diagnostics
- Confidence for teams standardizing on Oxlint
Summary
Vitest positions itself as a modern, fast test runner.
Adding Oxlint formatter support would:
- Align with Vitest’s performance-first philosophy
- Remove friction for teams moving off ESLint
- Improve DX in editors and CI
- Keep Vitest ahead of ecosystem shifts rather than reacting later