Type aware lint rules: Oxlint vs. Biome 2

ESLint and TypeScript-ESLint are indispensable. Their type-aware rules—no-floating-promises, the entire no-unsafe-* family, and dozens more—have become the backbone of production-grade TypeScript codebases. They catch real bugs before a single test is run. The cost, unfortunately, is speed: a cold run of typescript-eslint on our monorepo at TripToJapan.com is 7 minutes. That is the tax we pay for safety.

A new breed of Rust-based linters is now orders-of-magnitude faster—but they ship without any type information.
Both Biome 2 and Oxlint (from the Vite/OXC family) can lint our entire codebase in < 1.5 s. The catch: their current rule sets are purely syntactic. You lose the guarantees that catch un-awaited promises, unsafe assignments, or calls to any-typed values—exactly the rules that justify typescript-eslint in the first place.

Biome is solving the problem with a ground-up type synthesizer.
Their new engine, Biotype, re-implements TypeScript’s checker in Rust. The first rule to ship, noFloatingPromises, proves the concept works. But each additional rule demands a comparable research effort, and every edge case in the TypeScript spec risks a silent deviation from official behaviour. As Evan You put it:

“Biome’s type-aware linting is based on a custom type synthesizer — it cannot guarantee full coverage or behavior alignment with official TS.”

Oxlint is taking a different bet: wait for the official TypeScript compiler to get fast.
Their experimental project tsgolint is a thin wrapper around tsgo, the Go port of the TypeScript compiler that the TS team is actively working on. The idea is simple: let the canonical checker do the heavy lifting, then run the 40 high-value typescript-eslint rules on top. Evan You summarised the rationale:

“We want to provide type-aware linting by actually getting the type info from TS for full alignment.”

Because tsgo is progressing rapidly—cold type-checking is already 5–7× faster in internal builds—Oxlint’s gamble is that the gap between “fast” and “accurate” will soon close entirely.

Meanwhile, the community is exploring a third path: piggy-back on the editor’s already-running language server.
Projects like tsslint (Volar) and tsl hook into the existing tsserver instance that VS Code spins up. This eliminates the duplicate memory footprint and gives near-instant feedback inside the IDE. The trade-off is that the model only works when the language server is alive; for CI or headless environments you still need a CLI solution. In short, clever—but not the universal answer.

My conclusion: Oxlint is making the right long-term bet.
By aligning with tsgo, they inherit every future optimisation the TypeScript team ships, while keeping the rule surface identical to typescript-eslint. Once tsgolint graduates from experimental to stable, Oxlint will wrap it and ship the full 40-rule suite in one release—no gradual catch-up, no behavioural drift. That is the moment we will drop the hybrid setup and run a single, blazing-fast linter that already understands our codebase.

Appendix: Timeline of Milestones

• April 2024 – Biome ships noFloatingPromises, first rule via Biotype
• May 2024 – typescript-eslint adds Project Service integration
• June 2025 – Oxlint 1.0 released, 30× faster than ESLint on syntax rules
• Q3 2025 (expected) – Biome expands to ~10 type-aware rules
• Q3–Q4 2025 (expected) – tsgolint lands in Oxlint as experimental
• Late 2025 – tsgo CLI reaches beta with 10× faster type-checking
• Early 2026 (speculative) – Oxlint + tsgolint becomes the recommended path for type-aware linting

Links