Type-aware TypeScript 7 linting.
Without the wait.

Type-aware linting at native speed.

Drop it into your project.

From v0.1.0 onward, jetlint ships prebuilt binaries via npm under the @jetlint/cli wrapper. Until then, install from source with Go.

# v0.1.0 and later (also works with pnpm, yarn, bun)
npm install --save-dev @jetlint/cli

# while v0.1.0 is in progress, build from source (Go 1.26+)
go install github.com/jetlint/jetlint/cmd/jetlint@latest

# run on a project
npx jetlint --project ./tsconfig.json

See the install guide for pnpm/yarn/bun commands, editor integration, and CI setup, or the rules reference for the full rule list.

Why jetlint exists.

AI coding tools work best when the loop around them is deterministic and fast. Types, lint, and tests are how a model knows whether the change it just made is good. The more of that signal you can produce in milliseconds rather than seconds, the tighter the loop gets and the better the outputs.

Type-aware lint is the slow link in that chain. typescript-eslint with type information is the right tool for the job, but on large codebases it's measured in seconds-to-minutes, which is too slow to sit inside an inner loop. With the TypeScript 7 native toolchain landing, the checker itself is finally fast enough that a thin linter on top can return type-aware diagnostics at interactive speed, especially when a daemon keeps the program warm between runs.

Standing on other peoples' shoulders.

jetlint is a thin layer over decisions made by much larger projects. The interesting problems (what the rules should mean, how the checker should answer type queries, how a linter should be structured) have already been solved well elsewhere. jetlint's contribution is wiring them together for the TS 7 native checker with a daemon in front.

• typescript-eslint: the rule semantics, the test fixtures jetlint validates against, and the configuration shape users already know. Every rule jetlint ships is a port of a typescript-eslint rule and is verified byte-for-byte against the upstream fixtures.
• microsoft/typescript-go: the native TypeScript 7 compiler. jetlint embeds it and asks it the same type questions tsc does. None of this would be possible without the work to make the checker available as a Go library.
• oxc / tsgolint: prior art for type-aware linting against the native checker. tsgolint proved the approach was viable and shaped a lot of jetlint's thinking about how to integrate with the Go checker.
• ESLint, Biome, and Oxlint: the broader lint ecosystem that defines what good diagnostics, good config ergonomics, and good editor integration look like.

How jetlint differs from tsgolint.

tsgolint and jetlint share the same foundation, the TypeScript 7 Go checker, and the same broad idea, so the obvious question is why both exist. The short answer: different goals, plus a personal one.

The project goal is byte-for-byte compatibility with typescript-eslint's published fixtures across as many type-aware rules as possible, so existing configurations move over unchanged. tsgolint targets a curated subset instead, which serves a different audience.

There's also a personal one. I wanted to learn what writing a linter against a real compiler actually feels like, even working at arm's length through AI tooling. tsgolint already existed and worked; jetlint exists in part because I wanted to understand the problem by building one.

Pre-1.0. Diagnostics work today; the API may still change.

jetlint is currently a research-grade port of typescript-eslint's type-aware rules against the TypeScript 7 native checker. The diagnostics are real; the API surface (CLI flags, config schema, exit codes) may still change. Feedback on the issue tracker shapes what stabilizes first.