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({ tasks }: Props) @{
const pending = tasks.filter((task) => !task.done);
<section class="tasks">
@if (pending.length > 0) {
@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
oxlintthatoxc-tsrxinstalls, then gets live.tsrxdiagnostics, formatting, and validated quick fixes.
We want to upstream this to OXC
OXC for TSRX is an independent community project, and its end goal is for TSRX support to live in OXC itself. The reusable language core is kept small, isolated, and benchmark-gated so that OXC maintainers can review it with as little effort as possible. No OXC maintainer interest or endorsement is claimed.