Confession: I have been putting off a lint cleanup for four months. Not because it’s hard, but because every time I run the type-aware ESLint pass on a mid-sized TypeScript project, I go make coffee, come back, and it’s still going. So when Evan You published a four-month progress report on VoidZero at Cloudflare with the line “up to 18x faster than ESLint in large codebases”, my first reaction was suspicion, and my second was to open a terminal.
Short version for the impatient: the numbers are vendor numbers, the direction is believable, and Vite+ 1.0 is the first time the whole Rust-based JavaScript toolchain comes in one box. I haven’t measured any of it on my own repos yet, so this post is a reading of the announcement plus the exact checks I’m going to run before I let any of it near a client project. If you want the checks without the commentary, skip to the last section.
What actually shipped in four months
The post lists five things, and they are worth separating because they are different kinds of claims. The Oxc React Compiler compiles React apps 10x faster than the Babel version. Vitest 5 is up to 50% faster than Vitest 4. tsgolint, the type-aware engine behind Oxlint, is stable and runs 12 to 18 times faster than ESLint with typescript-eslint. Oxfmt is 7x faster than Prettier now that its JSON, CSS, SCSS, Less, GraphQL and YAML formatters are written in Rust. And Vite+ hit 1.0.
Notice the qualifiers. “Up to 50%” is a best case. “Up to 18x” is a best case on large codebases. “10x” for the React Compiler is a compile-step number, and compile time is rarely the slowest part of your build. Every one of these is a real speedup on some project, and none of them tells me what happens on mine. That’s not a knock on VoidZero, every vendor writes this way. It’s a reminder that a benchmark from the people who wrote the tool answers “can this be fast?” and not “will this be fast for me?”.
The other detail I liked is the stack argument. Oxc is the compiler, Rolldown is the bundler, Vite sits on top, Oxlint and Vitest use the same parts. When one layer gets faster, the layers above get faster for free. The logic holds up on paper, since a shared parser and shared AST mean one fix pays off in several tools, so I’m inclined to believe it.
The part I care about: type-aware linting
Linting with type information is the slow one, and it’s the one that catches real bugs. Floating promises, misused async callbacks, unsafe any flowing into a function. These need the TypeScript program in memory, and that’s where ESLint plus typescript-eslint spends its time.
According to the announcement, tsgolint supports 59 of the 61 typescript-eslint type-aware rules, and Oxlint can share a single TypeScript program between linting and type-checking instead of building it twice. That second part is the one I’d look at first, because most CI pipelines I’ve seen run tsc --noEmit and ESLint as two separate steps, and both of them pay to parse the whole project.
The config change they show is small:
import { defineConfig } from "oxlint";
export default defineConfig({
options: {
typeAware: true,
typeCheck: true,
},
});
Compare that with what I have today, which is an eslint.config.js with a parser option pointing at a tsconfig, a project service setting I had to look up twice, and a comment explaining why the slow rules are slow. Fewer moving parts is a win even if the speedup turns out to be 6x instead of 18x.
The two missing rules matter, though. If your team leans on one of the two typescript-eslint rules tsgolint doesn’t cover, you’ll be running both linters for a while. I don’t know which two they are, and the announcement doesn’t say, so that’s the first thing I’d check in the docs.
Oxfmt and the Prettier question
Formatters are a religious topic, so let me keep this practical. Oxfmt claims Prettier-compatible output, and the migration is two commands:
pnpm add -D oxfmt
pnpm oxfmt --migrate prettier
pnpm oxfmt
The risk with any Prettier replacement is the diff. If the output differs on even 0.5% of lines, you get a giant formatting commit that wrecks git blame, and I’ve already lived through that once with a different tool (I wrote about the one commit that broke my git blame with Laravel Pint). So the plan is boring: run Oxfmt on a branch, count changed lines, and add the formatting commit to .git-blame-ignore-revs if I keep it.
Speed on a formatter is also the least interesting win for me. On a small project, formatting time is already a few seconds. I’d switch for the single toolchain, not for the seconds saved.
Vite+ 1.0 and the decision fatigue argument
Vite+ bundles Vite 8, Vitest 5, Rolldown, Oxlint, Oxfmt and task caching with defaults chosen for you. Evan You’s pitch is that agents and humans both waste time on “which linter shall I use?” and that fewer choices means faster shipping. I half agree.
The half I agree with: a new project shouldn’t need six config files before the first commit. The half I don’t: defaults are great until the day you need to deviate, and then you’re reading a unified tool’s docs instead of five well-known ones. I have client projects pinned to specific ESLint plugins for framework reasons, and a “great defaults” toolchain doesn’t help those. I’d use Vite+ for new projects and leave the old ones alone until there’s a reason.
There’s also a framing I’m skeptical of. The post says that in 2026 the mission is making developers’ agents faster, because once inference is quick, a slow linter or type-checker becomes the bottleneck. That’s true as far as it goes. But if your agent loop spends 40 seconds waiting on a build, the fix is often to run less, not to run the same thing faster. Scoping a lint run to the changed files beats a 10x faster full lint on every iteration. Faster tools and smarter invocations stack, so do both.
Bundled dev and the React Compiler
Two more items deserve a mention. The first is Bundled Dev, formerly Full Bundle Mode, which uses Vite’s production bundler in development. It’s behind an experimental flag today, and the post says Cloudflare’s own dashboard already uses it for all internal developers. That’s a useful data point, since a big dashboard app is the kind of project where unbundled dev servers struggle with thousands of module requests.
import { defineConfig } from "vite";
export default defineConfig({
experimental: {
bundledDev: true,
},
});
The second is the Oxc React Compiler, enabled through @vitejs/plugin-react with compiler: true plus the oxc-transform-react package. I’ve written about how React 19.3 view transitions let me delete some hand-rolled timing code, and the compiler is the same category of change: less manual work in components. My hesitation is that a compiler is a correctness risk in a way a linter isn’t. A slower linter wastes time. A wrong compile output ships a bug. I’d want a full test run and a visual check before trusting it on anything with money attached.
What I’ll run before switching
Here is the checklist, in the order I’d do it on a real project. It takes about an hour, and it’s the honest way to test a vendor claim.
First, time your current baseline. Run your existing lint, type-check and test commands three times each and write down the median. Without a baseline, “18x faster” is a number you can’t verify.
for i in 1 2 3; do /usr/bin/time -f "%e s" pnpm eslint . ; done
for i in 1 2 3; do /usr/bin/time -f "%e s" pnpm tsc --noEmit ; done
for i in 1 2 3; do /usr/bin/time -f "%e s" pnpm vitest run ; done
Second, do the same with the new tools on a branch, with warm and cold caches. Cold-cache numbers are what CI sees, and warm-cache numbers are what you see locally. Third, diff the outputs: lint findings from both linters on the same commit, and formatter output on the same files. A faster tool that misses a class of bug is not a win. Fourth, check the two type-aware rules that tsgolint doesn’t cover against your config.
If you want to try it this week, pick your slowest repo, run the baseline loop above today, and post the three medians somewhere you’ll find them again. Then install Oxlint on a branch and compare. I’ll be doing the same on my own projects, and I’d rather you tell me the announcement’s numbers didn’t hold up for you than take my word or theirs. You can see the kind of projects I’d test this on in my portfolio.
Sources for the numbers above are in the VoidZero announcement on the Cloudflare blog, and the tools themselves live at Vite and Oxc.
