tsgolint v7 ships type-aware linting written in Go

Type-aware linting for TypeScript now has a stable implementation written in Go. The Oxc project announced tsgolint v7.0.2000 on July 22, 2026, and InfoQ's report on September 11, 2026 brought it wider attention. It covers 59 of the 61 type-aware rules from typescript-eslint.

The distinction matters more than it sounds. Most lint rules only need to read your code's shape: a missing semicolon, an unused variable. Type-aware rules need to know what things actually are. Asking whether a promise is ever awaited means asking the type checker, and the type checker is the slow part.

That is why these rules have a reputation for making a lint run take minutes. tsgolint does not reimplement the type checker to avoid that cost. It builds real TypeScript programs on top of typescript-go, which the project's GitHub README describes as "Microsoft's TypeScript implementation" and targets at TypeScript 7, codenamed Project Corsa.

The project's own numbers disagree

Here the reporting gets awkward, and it is worth saying plainly rather than picking the friendlier figure.

The Oxc blog post gives detailed timings on an Apple M4 Pro with 12 cores, comparing against ESLint plus typescript-eslint on matched configurations. Those show a 12x to 18x improvement: microsoft/vscode from 83.2 seconds to 6.96 seconds, microsoft/typescript from 27.2 to 1.94, typeorm from 13.2 to 0.75, and vuejs/core from 12.3 to 0.95.

The project's own README summarizes its benchmarks differently. It reports 22x to 34x on the same four repositories, and states the tool is "20-40x faster than ESLint + typescript-eslint on large repositories."

Both claims come from the same project, about the same tool, against the same comparison. InfoQ's report cites the lower range. We have not seen an explanation for the gap, and neither figure has been independently reproduced. Treat the blog's 12-18x as the number with visible working behind it, and benchmark your own repository before budgeting for either.

The blog does explain where the gains come from: "fast paths that avoid expensive type-checker queries when syntax already gives the answer." One rule, it says, came out "35 times faster on VS Code."

Version 7 of a project that never had a version 1

tsgolint jumped straight from an experimental 0.x line to a stable v7, which looks like a marketing leap and is not one.

The version now tracks the compiler it embeds. In v7.0.2000, the 7.0.2 is the TypeScript version, and the trailing counter is tsgolint's own patch number, which resets whenever the TypeScript version moves. InfoQ quotes the reasoning: "tsgolint is now versioned against the compiler it embeds." The practical effect is that the version string tells you which type checker you are getting.

	Detail
Stable release	v7.0.2000, July 22, 2026
TypeScript tracked	v7.0.2
Rules implemented	59 of 61, up from 43 at the December alpha
Minimum TypeScript	7.0
Install	pnpm add -D oxlint oxlint-tsgolint@7
Run	pnpm oxlint --type-aware

The code began as a prototype in the typescript-eslint organization, created by the contributor auvred, and the Oxc fork carries it forward with that author's permission.

What this means for developers

The constraint to check first is TypeScript 7. Type-aware linting here requires 7.0 or later, and InfoQ notes that some legacy tsconfig options and TypeScript 6 features are still unsupported. If your build is on TypeScript 6, this is something to plan for, not to adopt this afternoon.

If you are already on 7, the honest experiment is a single timed run. Install the two packages, run pnpm oxlint --type-aware against your repository, and compare against your existing ESLint invocation. Your own number is worth more than anyone's benchmark table, and this is a case where the published numbers are not even consistent with each other.

The two missing rules matter more than the count suggests. Check whether either of the two that did not make it is one your team relies on. A lint suite that runs 12x faster but silently drops the rule catching your bug class is a bad trade.

There is a wider pattern here worth noting. Rewriting developer tooling in a compiled language for speed has become routine this year. Debian Code Search dropped its last C dependency for pure Go and matched the C version. The mold linker's author is rewriting it from C++ into Rust. What is different about tsgolint is that it did not rewrite the hard part. It embedded Microsoft's own compiler and optimized around it, which is a far cheaper way to be correct.