tsgolint reaches stable v7, bringing Go-based type-aware linting to Oxlint

tsgolint, the type-aware linting engine that powers Oxlint, has reached stable v7. It brings into Oxlint those lint rules that require semantic analysis of TypeScript, the ones that answer questions like "does this Promise actually get awaited with await?", but running at native Go speed instead of going through ESLint.

For those who build software with TypeScript day to day, the change is concrete: the most expensive step in linting, type-aware analysis, is exactly what stalls CI pipelines and slows down local feedback. That's the bottleneck tsgolint targets.

How the engine works under the hood

The architectural insight is not reimplementing a type checker. Instead, tsgolint builds real TypeScript programs on top of typescript-go, the official Go port of the compiler now distributed as TypeScript 7.

The division of labor looks like this:

• Oxlint, written in Rust, handles file discovery, configuration, and cheap syntactic rules (the ones that look at a single file).
• Type-aware work is delegated to the Go binary, which returns structured diagnostics.

The release ships alongside TypeScript v7.0.2 and covers 59 of the 61 type-aware typescript-eslint rules, up from 43 in the December alpha. The direct jump from the experimental 0.x line to a stable v7 is deliberate: tsgolint is now versioned against the compiler it embeds, and version v7.0.2000 matches TypeScript 7.0.2.

Getting it running

It takes two lines to get started:

pnpm add -D oxlint oxlint-tsgolint@7
pnpm oxlint --type-aware

Anyone who wants to see compilation errors alongside lint diagnostics, coming from the same TypeScript program, adds --type-check. Both flags can be pinned in an oxlint.config.ts or .oxlintrc.json file.

The release also brings per-rule timing measurement, exposed with:

oxlint --type-aware --debug timings

This makes it possible to see which type-aware rules dominate execution time, useful information when the goal is to trim CI time.

The numbers the team reports

The team's own benchmarks put the stable build at 12 to 18 times faster than ESLint with typescript-eslint, measured across the microsoft/vscode, microsoft/typescript, typeorm, and vuejs/core repositories, on an Apple M4 Pro.

| Item | Detail | |---|---| | Type-aware rules covered | 59 of 61 (was 43 in the alpha) | | Target TypeScript | v7.0.2 | | Speed gain | 12x to 18x vs. ESLint + typescript-eslint | | Repos tested | vscode, typescript, typeorm, vuejs/core |

These are the team's own numbers, not independent measurements: it's worth running them on your own monorepo before promising gains to leadership.

The long-term bet, and the counterpoint

Writing before the release, Jökull Sólberg assessed that the chosen path makes strategic sense:

Oxlint is making the right long-term bet, inheriting every future optimization the TypeScript team ships, while keeping the rule surface identical to typescript-eslint's.

>

-- Jökull Sólberg

The same argument shows up in a discussion about whether Biome should adopt typescript-go. Biome v2 synthesizes its own types without the compiler, and one analysis puts its noFloatingPromises rule at around 75% of the cases that typescript-eslint catches, a gap that Vite's creator, Evan You, has already questioned publicly.

The underlying point is both philosophical and practical: reusing the official compiler (tsgolint's path) versus reimplementing type inference (Biome's path). The former inherits correctness and optimizations for free, but ties the tool to the compiler's requirements.

What's still open

The release isn't without rough edges. The typescript-eslint team, whose contributor auvred created the original prototype, still classifies its own fork of tsgolint as an experiment that "is not under active development." On the oxc side, correctness is still being refined: users have already reported cases like an autofix that removed a type assertion that tsc actually required.

There's also an entry cost. Type-aware linting requires TypeScript 7.0 or higher, some legacy tsconfig options like baseUrl aren't supported, and projects using features removed in TypeScript 6 need to migrate first.

Those already using ESLint can translate their existing config with:

npx @oxlint/migrate --type-aware

following the migration guide from ESLint.

What changes for developers in Brazil

The bigger context is the rewrite of the JavaScript toolchain in native languages, from bundlers and formatters to the TypeScript compiler itself. Oxlint is the linter of oxc, the Rust tooling suite developed under VoidZero, the company Evan You founded to consolidate a historically fragmented tooling chain.

For Brazilian teams running large monorepos with timed CI, the promise is direct: fewer pipeline minutes spent on semantic linting and faster local feedback. But the caveats carry weight. Coverage of 59 of 61 rules is high, but it's not 100%; correctness is still maturing; and the dependency on TypeScript 7 can become a real blocker in codebases dragging along old tsconfig setups.

The most sensible path today is experimental: run Oxlint with --type-aware in parallel with your current ESLint setup, compare diagnostics on your own repositories, and measure CI time before switching for good. The team's focus right now is on the remaining rules, editor integration, and monorepo performance, the three points that will decide whether the tool is ready for production in your context.