Type aware linting typescript projects, 12x faster

Linting a large TypeScript project is slow for a specific and unavoidable reason: the rules that catch real bugs need the type checker, and the type checker is doing the same work the compiler does. Type aware linting typescript projects has therefore always meant waiting. tsgolint reached stable v7 with benchmarks putting it 12 to 18 times faster than ESLint with typescript-eslint, by moving that work out of JavaScript.

Why the type-aware rules are the slow ones

Most lint rules are syntactic. Is this variable unused, is this line too long, is this import ordered — questions answerable from the parse tree alone, and fast.

The rules worth having are not syntactic. Knowing whether a promise was awaited, whether a value could be null at this point, or whether a template literal is stringifying an object requires knowing the types, which means running a full type-check across the program. That is why teams disable the type-aware rule set: not because the rules are wrong, but because a five-minute lint on every commit is untenable, and once it is disabled the bugs those rules catch come back.

What v7 brings to type aware linting typescript work

tsgolint is the type-aware linting engine behind Oxlint, handling the TypeScript semantic analysis that ESLint traditionally performed. It is built on typescript-go and tracks TypeScript v7.0.2.

The stable v7 release covers 59 of typescript-eslint's 61 type-aware rules, up from 43 at the December alpha. Benchmarks across four major projects on Apple M4 Pro hardware put it 12 to 18 times faster than ESLint with typescript-eslint.

The division of labour is worth understanding because it explains the speed. Oxlint, written in Rust, handles file discovery, configuration and the cheap syntactic rules, then hands the type-aware work to the Go binary. Two languages, each doing what it is good at, and neither of them JavaScript — which is the actual change here. The bottleneck was never the rule logic. It was doing whole-program type analysis in a single-threaded runtime that was not designed for it.

Coverage is the number that matters more than the speed. A linter that is twenty times faster and enforces half your rules is not a replacement, it is a second tool. Fifty-nine of sixty-one is close enough to be a genuine decision, and worth contrasting with Biome's comparable rule, which reportedly catches around 75% of the cases typescript-eslint identifies.

It is also a reasonable proxy for where JavaScript tooling is heading generally. The last few years have moved bundling, transpiling, formatting and now type-aware analysis into Rust and Go, one layer at a time, for the same reason each time — the work is CPU-bound and parallelisable, and the language the ecosystem is written in is neither. The interesting consequence is that toolchains increasingly are not extensible in JavaScript, which is a real loss for teams carrying custom in-house rules and a fair trade for the large majority who never wrote one.

The constraints are real

Three, and they will decide this for most teams before the benchmarks do.

TypeScript 7.0 or later is required for type-aware linting. If you are not there yet, that upgrade is the project, and everything here is downstream of it.

Legacy tsconfig options are unsupported, baseUrl among them. That one is common in older codebases, frequently load-bearing for path aliases, and migrating away from it touches every import in the project.

Correctness is still being refined. That is the maintainers' own characterisation and it should be read plainly: a rule that reports differently from typescript-eslint is a false negative you will not notice or a false positive that erodes trust in the tool.

There is also an ecosystem wrinkle worth knowing. The typescript-eslint team maintains its own fork of tsgolint, which they describe as an experiment that is not under active development. Two forks with different maintainers and different levels of commitment is a situation that usually resolves, but not always the way you hope.

The two forks are worth a moment's thought rather than a shrug, because they are not equivalent bets. One is maintained by the project shipping it as a product with a stable release behind it; the other is described by its own maintainers as an experiment. If you adopt, you are adopting the first, and the relevant question is what happens to rule parity as typescript-eslint continues to add rules. Coverage today is a snapshot, not a guarantee, and 59 of 61 can drift in either direction.

That is the ordinary risk of being early on tooling and it is manageable. The unmanageable version is discovering it six months after deleting the old configuration, when reverting means reconstructing a rule set nobody documented.

Whether the speed is worth anything to you

Work out where your lint time is actually spent before treating this as a win, because there are three quite different situations and only two of them benefit.

Lint runs in CI on every pull request. A five-minute lint becomes twenty seconds. That compounds: faster feedback means developers wait less, context-switch less, and are less inclined to skip checks. This is the clearest case.

Lint runs in the editor. The gain is qualitative. Type-aware diagnostics that are fast enough to appear as you type are a different experience from ones that arrive after a save, and it is the difference between a rule that changes behaviour and one that generates a backlog.

Lint runs on a pre-commit hook over changed files only. You may already be fine. If your hook takes four seconds, a twelve-fold improvement saves under four seconds and is not worth a toolchain migration on its own.

The honest summary is that this matters most to teams with large codebases and slow CI, and least to small projects where lint was never the bottleneck. That is worth saying because the benchmark number invites everyone to migrate, and most should not yet.

A fourth situation deserves mention because it is common and easy to misread: lint is fast but nobody trusts it, because the rule set was tuned years ago and now produces noise everyone suppresses. No amount of speed fixes that. If your team routinely adds disable comments, the problem is configuration rather than performance, and switching tools will carry the problem across intact.

What we would do

Run the comparison on your own repository rather than trusting a benchmark taken on someone else's. Lint performance is dominated by codebase shape — file count, depth of type inference, generic complexity — and a twelve-fold gain on one project can be threefold on another.

For a new TypeScript project starting today on TypeScript 7, adopting Oxlint with tsgolint is a reasonable default. There is no migration cost, the coverage is close to complete, and being early on tooling is cheap when there is no existing configuration to preserve.

For an established codebase, the sequencing is different. Measure lint time in CI and in the editor first — if it is not hurting, this is a solution looking for a problem. Confirm you are on TypeScript 7 and check your tsconfig for baseUrl and other legacy options, because those two together are the real cost. Then run both linters over the same code and compare output rather than trusting a coverage percentage, since the two rules you lose might be the two you rely on.

Keep the old configuration working alongside the new one for a release cycle rather than switching outright. It costs a little CI time and it means a rule gap or a false positive is a nuisance rather than an incident, which is the same caution we would apply to replacing any tool that gates a merge.

And keep in mind what linting is for. Its value is not catching bugs, which tests and types do better. It is removing a category of argument from code review so that reviewers spend their attention on design and correctness rather than on style and on whether a promise was awaited. That matters more now than it did two years ago, because review is where AI-assisted development bottlenecks — the point we made about AI coding agents moving the constraint to review. Anything that makes an automated check fast enough to run constantly buys back reviewer attention, and reviewer attention is the scarce thing.

That is the argument for caring about lint performance at all, and it is the one we would make on any web application or custom software project where the team is larger than three people.