TypeScript 7's Go-based compiler is reportedly around 10× faster, but the initial release does not expose the programmatic API that typed linting tools need. For now, tools such as typescript-eslint still rely on the TypeScript 6.0 API through a compatibility package, with a new API expected in 7.1.
That creates an awkward gap: build and type-check times may improve dramatically, while type-aware linting still uses the older checker. Biome can run some type-aware rules without loading the TypeScript compiler, but its inference-based results are only partially equivalent to full type checking and still require scanning the project. Other tools, such as oxlint, claim to provide faster type-aware linting with broader checker compatibility.
My repository currently runs linting, type checking in CI, and an automated review pass over the same changes, but I do not have good measurements showing which stage is responsible for the work. Are people pinning the TypeScript 6 API, using a faster approximate linter during development, trying an alternative tool, or simply waiting for the TypeScript 7.1 API?
4 Answers
The most useful preparation is to capture a baseline now. Save the complete typed-lint findings—file, rule, and location—not just the total count. When the new API arrives, you can compare the results and identify whether changed diagnostics come from real code issues, checker behavior, or rule changes. It is also safer to keep a compiler or linter upgrade separate from configuration changes so regressions remain attributable.
It may be worth trying oxlint if the main goal is reducing feedback time. One team reported cutting linting from roughly 30 seconds to about 2 seconds, while still getting type-aware diagnostics closer to full checker coverage than approximate inference-based rules. I would test it against your existing findings before treating it as a drop-in replacement, though.
I’m waiting for the official API rather than changing the setup twice. The compiler speedup is promising, but the API transition is likely to be more important for typed linting than the raw build benchmark. I upgraded briefly, hit the compatibility issue, and went back to the older version until the tooling is ready.
That is where I’m leaning too. The temporary compatibility package is useful, but it does not really unlock the main performance benefit for typed linting.
For editor feedback, I use the lightweight checks and let the full typed rules run in CI or on the changed project when needed. Biome’s type-aware rules can be useful for quick feedback, but they are not a complete replacement for rules that depend on the TypeScript checker, so I would treat them as an additional fast pass rather than assume they catch everything.
Watch the file filters during migration. Some wildcard patterns behave differently and are not recursive in the way you might expect, which caused missed files for us.