Oxlint Type-Aware Linting Goes Stable: 12× Faster

On July 22, 2026, the Oxc team marked type-aware linting in Oxlint as stable, closing a road that started with an alpha in December 2025. The engine behind it is tsgolint v7, built directly on TypeScript v7.0.2 — the same Go-based core that reshaped the TypeScript compiler.

It reads like a small release note. In practice it removes the last reason many teams were still running typescript-eslint.

The problem: two linters, one pipeline

The Rust-based linting generation — Oxlint at the front — delivered speed that was not close to comparable. But it operated on syntax only. It saw code as a tree of tokens and knew nothing about types.

That put rules like no-floating-promises and no-misused-promises out of reach. These are not cosmetic rules. They are the ones that catch a missing await, an abandoned promise, a condition that can never be false. So teams ran two linters in CI: Oxlint for speed, typescript-eslint for the rules that need type information. Two runtimes, two configs, two sets of rule names to keep aligned.

What changed

tsgolint is a Go engine that began as a prototype by @auvred inside the typescript-eslint project itself, then was donated to the Oxc organization. Rather than reimplementing a type system, it builds on the official typescript-go core — so the type analysis matches the real compiler, at compiled-language speed.

Published benchmarks, measured on an Apple M4 Pro (12 cores):

• VS Code — 83.2s down to 6.96s (12× faster)
• TypeScript — 27.2s down to 1.94s (14× faster)
• TypeORM — 13.2s down to 0.75s (18× faster)
• Vue.js — 12.3s down to 0.95s (13× faster)

Coverage matters more than the multiplier. The stable release supports 59 of 61 type-aware rules from typescript-eslint — 16 more than the alpha, including no-unnecessary-condition, prefer-optional-chain, prefer-readonly, and consistent-return.

Putting it to work

Type-aware linting ships as a separate binary alongside Oxlint:

pnpm add -D oxlint oxlint-tsgolint@7

Then from the terminal:

# run the rules that need type information
pnpm oxlint --type-aware

# also surface TypeScript compiler diagnostics
pnpm oxlint --type-aware --type-check

# per-rule timing breakdown
pnpm oxlint --type-aware --debug timings

Or commit it to .oxlintrc.json so local runs and CI agree:

{
  "options": {
    "typeAware": true,
    "typeCheck": true
  },
  "rules": {
    "typescript/no-floating-promises": "error",
    "typescript/no-misused-promises": "error",
    "typescript/no-unnecessary-condition": "warn"
  }
}

The distinction between the two options is worth internalizing. typeAware enables rules that consult the type checker. typeCheck additionally reports the compiler's own diagnostics through the linter — collapsing two previously separate pipeline steps into one command.

Real-world caveats

• Two rules of 61 are still unsupported. Before deleting typescript-eslint from a repo, diff the rules actually enabled against the supported list. Assuming full parity is the failure mode here.
• `typeAware` and `typeCheck` are root-only options. They cannot be switched on inside an overrides block for a single directory. CLI flags also take precedence over the config file — convenient in CI, confusing when local and CI results diverge.
• The TypeScript coupling is explicit. The version string v7.0.2000 means TypeScript v7.0.2 plus tsgolint patch 0. Upgrading TypeScript and upgrading the engine are one decision, not two, and the lockfile should reflect that.
• Install size grows. The engine is a standalone binary, roughly 21.8 MB on ARM64 Darwin after a 26.6% size reduction. On slim Docker images that number is not noise.

Takeaway

The direction has been consistent for two years: JavaScript tooling is migrating out of JavaScript and into compiled languages. Type-aware analysis was the last piece still outside that migration. With tsgolint stable, a CI pipeline can run one linter that understands types and finishes in seconds rather than minutes.

The value is not the multiplier. It is that a check measured in seconds runs on every file save, not on every pull request — and a check that runs constantly is the one that stops the bug before it lands.

Primary source: Type-Aware Linting Stable — oxc.rs