Build1 publisher3 min readPublished
Vite+ 1.0 ships VoidZero's Rust JavaScript toolchain as one package backed by vendor benchmarks
VoidZero's Vite+ 1.0 ships the Rust-based JavaScript toolchain as one package and claims type-aware linting 12 to 18 times faster than ESLint. Those numbers are VoidZero's own best cases, so any migration decision should start with timing your own lint and type-check steps.
The Engineer · Build desk

What happened
- tsgolint covers 59 of the 61 type-aware rules in typescript-eslint, and the announcement does not say which two are missing.
- Oxlint can build a single TypeScript program and share it between linting and type-checking, so the program is no longer built twice.
- Oxfmt is claimed at 7x Prettier's speed now that its JSON, CSS, SCSS, Less, GraphQL and YAML formatters are written in Rust.
- The Oxc React Compiler is said to compile React apps 10x faster than the Babel version.
- Vitest 5, which ships inside Vite+, is claimed at up to 50% faster than Vitest 4.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Teams that depend on either of the two uncovered rules will run ESLint beside Oxlint, maintaining two linter configs until tsgolint closes the gap.
- cost If Oxfmt's output differs from Prettier's on even 0.5% of lines, the switch lands as one large commit that must go in .git-blame-ignore-revs to keep git blame usable.
- decision The React Compiler figure covers only the compile step, so its value to a team depends on what share of total build time compilation actually takes.
Type-aware linting is the slow pass in a TypeScript project. Rules that catch floating promises, misused async callbacks and unsafe `any` need the whole TypeScript program in memory [17]. Building that program is where ESLint with typescript-eslint spends its time, according to a developer's breakdown of the announcement on dev.to [17]. tsgolint is the engine behind Oxlint's type-aware rules, and the announcement calls it stable [5].
Evan You's four-month progress report on VoidZero at Cloudflare describes the linter as "up to 18x faster than ESLint in large codebases" [1]. That qualifier puts the best case on big repos. For the figure to show up in your CI, three things have to hold: the repo is large, the type-aware rules are on, and lint takes a real share of pipeline wall-clock time. If lint is a short step, even 18x saves little. For planning I would use the bottom of the stated range, 12x [5], and still time it.
The shared program is the better piece of engineering. Most CI pipelines the dev.to author has seen run `tsc --noEmit` and ESLint as separate steps, and both pay to parse the whole project [16]. Building the program once removes one of those parses, whatever the per-tool multiplier turns out to be. In a pipeline that already runs tsc on its own, I'd test this first. The config the announcement shows is two flags [10]:
```js import { defineConfig } from "oxlint"; export default defineConfig({ options: { typeAware: true, typeCheck: true, }, }); ```
By comparison, the author's current `eslint.config.js` has a parser option pointing at a tsconfig, a project service setting, and a comment explaining why the slow rules are slow [21]. "Fewer moving parts is a win even if the speedup turns out to be 6x instead of 18x," the developer wrote [15].
Oxc is the compiler, Rolldown is the bundler, Vite sits on top, and Oxlint and Vitest use the same parts [7]. A shared parser and AST mean one fix pays off in several tools [7]. According to the dev.to author, Vite+ 1.0 is the first time the whole Rust-based JavaScript toolchain comes in one box [2]. It includes Vite 8 and Vitest 5 [14].
Oxfmt's case rests less on speed. Formatting a small project already takes a few seconds, the author notes [24]. Oxfmt claims Prettier-compatible output, and migration runs through `pnpm oxfmt --migrate prettier` [12]. The author plans to run it on a branch and count changed lines before keeping it [19]. "I'd switch for the single toolchain, not for the seconds saved," the developer wrote [20].
The dev.to post is a reading of the announcement plus a list of checks. Its author has not yet measured any of these tools on their own repos [13].
What to watch
- Documentation naming the two typescript-eslint type-aware rules tsgolint does not yet support.
- Independent timings of Oxlint's type-aware mode against ESLint with typescript-eslint on mid-sized TypeScript repos, outside the large-codebase best case.
- Changed-line counts from Oxfmt runs on existing Prettier-formatted codebases, testing the Prettier-compatible claim.