deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Benchmark: oxlint beats ESLint 18x on Vue core, 13x with type-aware rules

A dev.to benchmark clocked oxlint at 0.24s versus ESLint's 4.4s on Vue core's 445 TypeScript files, and under a second with type-aware rules enabled, where ESLint needed 12s.

Benchmark: oxlint beats ESLint 18x on Vue core, 13x with type-aware rules

A hands-on benchmark published on dev.to measured oxlint against ESLint on Vue's core repository and found the Rust-based linter from VoidZero — the company started by Vue and Vite creator Evan You — an order of magnitude faster. More notably, the gap persisted once type-aware rules were switched on for both tools.

What was measured

The author linted a clone of Vue core — 445 TypeScript files, roughly 150,000 lines — inside a clean Node 20 container and reported the wall-clock median of repeated runs. Four configurations were tested: ESLint 9 with typescript-eslint's recommended rules, the same setup with the recommendedTypeChecked set, oxlint with its defaults, and oxlint with --type-aware.

The results: ESLint finished the syntactic pass in 4.4 seconds and oxlint in 0.24, an eighteen-fold gap. According to the post, oxlint's own run output put engine time at 75 milliseconds, meaning most of the 0.24 seconds went to Node starting up and npx resolving the binary rather than linting itself.

Type-aware rules were the real test

Rules such as no-floating-promises, no-misused-promises and await-thenable are the checks that catch meaningful bugs, and they need a type checker that knows what a value actually is. That is also what makes them costly: ESLint has to build a full TypeScript program before it can lint a line, and its recommendedTypeChecked run on this codebase took 12 seconds, nearly triple its syntactic pass.

The author went in expecting oxlint to skip this class of work — the common assumption being that fast linters handle cheap syntactic checks and leave type-aware analysis to ESLint. That assumption did not survive. oxlint's --type-aware flag, which runs type-based rules through a companion tool called tsgolint, completed the same tree in 0.9 seconds. In other words, oxlint with full type analysis still finished about five times faster than ESLint's purely syntactic run, and completed a comparable type-aware workload roughly thirteen times faster than ESLint.

The caveats

The benchmark is careful about what the numbers do and do not show. The rule sets are not identical: oxlint ran 96 rules in its default pass and 111 with type-awareness enabled, while typescript-eslint's sets have their own counts, so the comparison measures comparable coverage rather than byte-for-byte identical checks. The type-aware mode is experimental, sits behind a flag, and needs a separate package, oxlint-tsgolint, installed before the 0.9-second figure is reproducible.

There is also a deeper qualification: tsgolint is a Go-based reimplementation of the TypeScript type checker, not tsc itself. The author calls that a reasonable trade for linting speed, but precisely the kind of difference that warrants testing against your own codebase before trusting it in CI. And if a project depends on a specific ESLint rule or a custom plugin with no oxlint equivalent, no speed figure compensates for the missing check.

Why it matters

Linting speed determines where a linter can live in a workflow. At four to twelve seconds per run, linting gets deferred to CI, and pre-commit hooks tend to get bypassed with --no-verify. At sub-second cost, the same checks can run in editors, in hooks and as the first CI step without anyone being tempted to skip them.

The author's suggested setup is layered rather than a wholesale replacement: run oxlint as the always-on fast gate in hooks and early CI, catching the great majority of issues before anything slower starts, and keep ESLint for the specific rules and plugins it alone provides, executed once in CI instead of on every save. For TypeScript teams weighing tooling decisions, the broader takeaway is that type-aware linting no longer has to be slow — provided they are comfortable validating an experimental, non-tsc type checker against their own code.

  • #oxlint
  • #eslint
  • #typescript
  • #linting
  • #developer-tools

Related posts