OXC for TSRX
Bring .tsrx into your OXC and Vite+ toolchain
One install, and your .tsrx files lint and format like .tsx does.
export function TaskList({ user, tasks }: Props) @{
const pending = tasks.filter((task) => !task.done);
<section class="tasks">
@if (user) {
@for (const task of pending; key task.id) {
<TaskRow task={task} />;
} @empty {
<AllDone />;
}
} @else {
<SignIn />;
}
<style>
.tasks { display: grid; gap: 0.5rem; }
</style>
</section>;
}
Fast, and it stays fast
Every number below is read from a committed benchmark report, and every one is a release gate: cross a frozen budget and the release fails.
Lint the same 1,000 files, three tools
Shorter is faster. Every tool crosses the npm boundary: each time is the npm command a project actually runs, Node launcher included.
Methodology, versions, and gates
- Corpus. Matched cross-tool bars use the same 1000 TSX files, byte for byte identical on every lane (515 KiB), linted with the
no-debuggerrule and nothing to report, on one machine (Apple M5 Pro). - What each time includes. Bar lengths show absolute median wall-clock time, taken from 20 measured processes after 5 warmups. Every lane runs through its own npm CLI entry point, so each bar carries that tool's Node launcher.
- The product lane. On all-TSX input,
oxlint-tsrximports the exact manifest-declared official Oxlint launcher in the same Node process with zero TSRX dispatch. - The mixed bar. The separately patterned mixed bar is the paired internal workload of mixed file types (20% TSRX by file count), not a rival tool. It proves 1 public canonical Node child, 1 native TSRX child, and 0 private adapter children.
- Gates. Hover any bar for its frozen ratio gate: the release fails if a future build breaks it.
- Versions. ESLint v10.7.0 with typescript-eslint 8.64.0; official Oxlint 1.74.0. Report
benchmarks/comparative/results-1785296573160.json(2026-07-29).
Release gates we ship against
Measured 2026-07-29 on one machine. Your hardware will differ.
-
Built on OXC, not a copy
Nothing is snapshotted and nothing is patched. Every OXC call lives in one small adapter crate.
-
A real parser you can call
Same API shape as official
oxc-parser, plus.tsrx, for codemods, bundler plugins, and analysis tools. -
Squiggles where you typed
Real OXC rules run on a temporary in-memory TSX copy, but what you see is anchored to your authored source.
-
Formatting that checks itself
Oxfmt layout is carried back into your TSRX, then reparsed and compared before anything reaches disk.
-
Speed you can check
Every number on this page is read from a committed benchmark report when the site is built.
-
Your editor already knows
The released official OXC VS Code extension picks up the project-local
oxlintthat@tsrx/oxcinstalls, then gets live.tsrxdiagnostics, formatting, and validated quick fixes.