Rslint: an ESLint-compatible linter built on TypeScript's native compiler

The problem Rslint targets: type-aware linting that costs too much

The expensive part of linting a TypeScript codebase is not parsing. It is building type information and then asking questions about it. ESLint alone does not have types, so type-aware rules come from typescript-eslint, which drives the TypeScript compiler through its own APIs. On a large project, that means a second full type-check pass on top of the one your build already does, and the cost scales with the number of files and the size of the program.

Rslint's answer is to stop treating the compiler as a separate dependency. The README describes it as powered by TypeScript's native compiler, and the stated goal is a faster drop-in experience with type-aware rules and optional type checking in the same run. The target user is a team with a TypeScript codebase, probably a monorepo, that has already paid the configuration cost of typescript-eslint and now pays a time cost on every lint run.

The README claims 20-40x faster linting performance compared to traditional ESLint setups. That number is the project's own claim, not something this article verifies; the README does not say what hardware, corpus or rule set produced it. Treat it as a direction, not a benchmark.

How Rslint works: TypeScript compiler semantics as the single source of truth

Rslint is a fork of tsgolint, the proof of concept by @auvred. The README explains the fork: tsgolint had no plans for continued development, so the Rslint team continued it. That lineage matters, because it explains the architecture. The design goal stated in the README is that TypeScript Compiler semantics are the single source of truth, which the project frames as eliminating edge-case bugs and guaranteeing consistency with what the compiler actually believes about your code.

The repository shows two language layers. The Go module is github.com/web-infra-dev/rslint, with cmd/ and internal/ holding the linter itself, and a go.work file alongside Cargo.toml and crates/. The go.mod replace directives point every github.com/microsoft/TypeScript/tsc/shim/* import at a local ./shim directory: ast, binder, checker, compiler, parser, project, scanner, tsoptions, vfs, and more. Rslint is not calling a TypeScript API over a process boundary. It compiles against shim packages that stand in for the compiler's internals.

The README also states that analysis is project-level by default, described as cross-module analysis rather than file-level linting. That is the second architectural decision with user-visible consequences: rules can reason about imports and types across module boundaries without a separate project graph pass, and monorepos with TypeScript project references are called out as first-class. The README credits the typescript-go project for the parsing and semantic analysis layer.

One more thing visible in the repository layout: rslint.config.ts sits at the top level, and the lint script is rslint --config rslint.config.ts. The project lints itself with itself.

Installing Rslint and running it for the first time

The README's Getting Started section does not inline install steps. It points to the guide at rslint.rs/guide/, and the npm package is @rslint/core. The commands below come from the repository's package.json scripts, which show how the project itself invokes the tool.

The lint script in package.json is the canonical invocation shape: the binary is named rslint and it takes a --config flag pointing at a TypeScript config file.

rslint --config rslint.config.ts

The repository keeps a JSON schema for that config, rslint-schema.json, so an editor can validate keys as you type. The README does not document individual rule names or config keys, so read the schema or the guide before writing rules by hand.

For the package itself, the release scripts publish the npm packages, and the README's badge links to @rslint/core on npmjs.com. The repository also carries a shim/ directory and a build:npm script, which is how the native pieces reach npm consumers. The README does not give a one-line install command, so take the install instruction from rslint.rs/guide/ rather than guessing a package name.

What you should expect on a first run: typed linting enabled by default, which the README lists as a goal, and analysis at project level rather than per file. If your tsconfig is not set up for project references, that is the first thing to check.

Where Rslint is the wrong tool

Compatibility is described as best effort. That phrase appears in the README's goals, and it is the honest framing of the main limitation. Most ESLint and TypeScript-ESLint configurations are supported, which reduces migration cost, but the README does not claim complete compatibility and does not publish a list of unsupported rules or config options.

The practical consequence is custom plugins. A team with in-house ESLint rules that reach into the ESLint rule API, or with plugins from the wider ecosystem, cannot assume those work. The README's extensibility claim is different in kind: it says Rslint exposes AST, type information and global checker data for writing custom rules with cross-module analysis. That is an invitation to write rules against Rslint's own surface, not a promise that ESLint plugins port over.

Second, the project is in an experimental phase. The README says so directly, and the version history backs it up: v0.8.0, v0.8.1 and v0.8.2 all landed within August 2026, and the repository's package.json is already at 0.9.2. Pre-1.0 with that cadence means configuration and behaviour can move between releases.

Third, the architecture is a commitment. Rslint is fast because it is fused to TypeScript's compiler internals through a shim layer. Projects that lint plain JavaScript without types, or that deliberately avoid a TypeScript program for speed, get less from that design and take on more machinery than they need.

Rslint and Oxlint: two different bets on why linting is slow

Oxlint is the obvious comparison, and it appears in the related searches. Both are non-JavaScript linters aimed at the same complaint: ESLint is too slow on large codebases. They diverge on the diagnosis.

Oxlint's approach is to reimplement lint rules in a fast systems language and analyze files largely independently, so the work parallelizes and no type program is required. Rslint goes the other way. It accepts the cost of building type information, and instead removes the duplication by reusing TypeScript's own compiler semantics rather than driving a separate TypeScript instance. The README's framing is explicit: TypeScript Compiler semantics as the single source of truth, and project-level cross-module analysis by default.

That difference decides which tool fits. If your rule set is mostly syntactic and your codebase is JavaScript or lightly typed TypeScript, an independent-file linter is the cheaper design and Rslint's type machinery is overhead. If your rule set leans on types, on cross-module reasoning, or on monorepo project references, Rslint's bet is the one that pays. The README does not publish a rule-by-rule comparison against Oxlint or ESLint, so check coverage against your own config before switching either way.

Maintenance cadence, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-08-27, which is the same day v0.8.2 was released. Three releases landed in August 2026: v0.8.0 on 2026-08-12, v0.8.1 on 2026-08-19, v0.8.2 on 2026-08-27. The package.json in the repository reports version 0.9.2, ahead of the latest tagged release, which is normal for a main branch between releases.

That cadence is the upgrade cost. A weekly minor bump at 0.x means pinning is the sane default, and it means reading release notes before moving. The README does not document a deprecation policy, a support window for older versions, or a rollback procedure, so plan on testing upgrades against your config rather than assuming they are drop-in.

The licence is MIT, stated in the README and in the Cargo.toml workspace package metadata. MIT is permissive: it allows commercial use, modification and redistribution with the licence text preserved. Rslint is also a fork of tsgolint, so if you are auditing provenance for a legal review, trace both the upstream project's licence and the typescript-go dependency rather than stopping at Rslint's own LICENSE file. That is an audit task, not legal advice.

The repository also declares a code of conduct and a contributing guide, and the README points to a Discord server for users and contributors.

Editorial conclusion

Adopt Rslint if you have a TypeScript or monorepo codebase where type-aware linting is slow enough to hurt, and you can accept an experimental tool that forks tsgolint and ships breaking changes between minor versions. Do not adopt it if you depend on custom ESLint plugins, on the ESLint plugin ecosystem beyond the rules it bundles, or on a stable configuration surface. Before committing, verify which of your existing rules are actually covered, check how your monorepo's project references resolve, and read architecture.md to confirm the package layout matches how you intend to run it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes