Rslint: An ESLint-Compatible Linter Built on TypeScript's Native Compiler

The Problem: ESLint's Performance Ceiling

ESLint has been the standard JavaScript linter for years, but its architecture has a performance ceiling. It parses files with a JavaScript-based parser, then runs rules in a single-threaded process. For large TypeScript codebases, this becomes a bottleneck. Type-aware rules, which require type information, make it worse because they need a full type-checking pass. Rslint addresses this by building on TypeScript's native compiler, which is written in Go. The README claims a 20-40x speedup over traditional ESLint setups. That claim is bold, but the underlying mechanism is plausible: native code parsing and semantic analysis avoid the overhead of JavaScript's interpreter. This makes Rslint attractive for teams where linting time is a significant part of the development loop, especially in large monorepos.

How It Works: TypeScript Compiler Semantics as the Source of Truth

Rslint uses TypeScript's native compiler for parsing and semantic analysis. This is the same compiler that powers TypeScript 7.0, as mentioned in the README. The key difference from ESLint is that Rslint does not treat the AST as a separate artifact. Instead, it uses the compiler's own AST and type checker. This means type-aware rules have direct access to type information without a separate type-checking step. The README emphasizes 'TypeScript Compiler semantics as the single source of truth, ensuring 100% consistency.' That consistency eliminates edge-case bugs that arise when a linter's parser and the compiler's parser disagree. Another architectural feature is project-level analysis. Instead of linting file by file, Rslint can analyze across modules, which enables rules that need cross-file context, such as detecting unused exports or enforcing consistent import patterns. The project exposes AST, type information, and global checker data for custom rules, so you can write rules that do more than look at a single file.

Getting Started: Minimal Configuration by Default

The README points to the guide at rslint.rs for setup, but it does not include concrete commands in the README itself. However, the project is published on npm as @rslint/core, so the typical installation would be via npm. Based on the repository's structure, you would likely install the package and run a CLI command, but the exact syntax is not in the provided material. The README stresses 'Minimal Configuration: Typed linting enabled by default with minimal setup required.' This suggests that you do not need to configure parser options or type-aware settings explicitly. The project claims to ship with all existing TypeScript-ESLint rules and widely-used ESLint rules out of the box, which means you can start with a flat config or an eslintrc-style config and expect most rules to work. For a concrete example, you would need to consult the official guide, as the README does not include a sample configuration file.

Compatibility: Best Effort, Not a Guarantee

The README says Rslint is 'Best Effort ESLint Compatible' and 'Compatible with most ESLint and TypeScript-ESLint configurations.' That wording is careful. It does not promise full compatibility. The project is a fork of tsgolint, which was a proof of concept, and it is still experimental. This means some ESLint plugins and custom rules may not work. In particular, rules that rely on ESLint's specific AST node types or its traversal order might behave differently. Also, the project only ships with rules that are already implemented. If you have a custom rule that uses a third-party parser or a complex selector, you may need to rewrite it. The README mentions that the configuration design is influenced by typescript-eslint, but it is not a drop-in replacement for every setup. Teams with heavy reliance on niche plugins should test their rule set before migrating.

Limitations and Failure Modes

The most obvious limitation is that Rslint is experimental. The README explicitly says it is in an experimental phase, though under active development. That means the API and behavior can change between releases. Version 0.8.x is still pre-1.0, so breaking changes are likely. Another failure mode is the claim of 20-40x speedup. That number likely depends on the baseline. If your current ESLint setup is already using a fast parser and minimal rules, the speedup will be less dramatic. Also, because Rslint performs project-level analysis by default, it may have higher memory usage for very large projects, as it needs to hold the type graph in memory. The README does not mention memory constraints, but it is a known trade-off for cross-module analysis. Finally, if you use ESLint for non-TypeScript files, such as JSON or Markdown, Rslint may not support those. The README only mentions JavaScript and TypeScript, so it is not a universal linter.

The Alternative: typescript-eslint and ESLint

The direct alternative is typescript-eslint, the standard for type-aware linting in the ESLint ecosystem. Rslint is a fork of tsgolint, which was a proof of concept by a typescript-eslint contributor. The difference in approach is fundamental: typescript-eslint runs as an ESLint plugin, using the TypeScript compiler's type checker but still relying on ESLint's rule runner and parser. This means it inherits ESLint's performance characteristics. Rslint replaces the entire linter with a native implementation. So you keep the same rules and config, but you get a different engine. If you are happy with ESLint's performance and do not want to risk compatibility issues, typescript-eslint is the safe choice. If you need speed and are willing to accept experimental status, Rslint is the alternative. The README also credits the typescript-eslint team for influencing the configuration design, so the migration path is intended to be smooth.

Maintenance and License Implications

Rslint is MIT licensed, which means you can use it freely in commercial projects, modify it, and distribute it, as long as you include the original copyright notice. The project is part of the Rstack toolchain, which includes Rspack, Rsbuild, and other tools from web-infra-dev. This suggests ongoing investment from a larger ecosystem. The last push was in August 2026, and there have been three releases in that month, showing active development. However, because it is a fork of tsgolint, which has no current plans for continued development, the maintenance burden falls on the Rslint team. They have adopted a code of conduct from ByteDance, which indicates corporate backing. For upgrade cost, the experimental status means you should expect to update your config and possibly your custom rules as the project evolves. The README does not provide a migration guide, but the official guide at rslint.rs likely covers it. Before adopting, check the changelog for each release to understand breaking changes.

Editorial conclusion

Adopt Rslint if you manage a large TypeScript monorepo and need faster linting without sacrificing type-aware rules, especially if you are already using typescript-eslint. Do not adopt it if you require stable, production-grade tooling, as it is experimental and under active development. Before adopting, verify that your current ESLint plugins and custom rules are compatible, since the project only claims best-effort compatibility with most configurations. Check the official guide at rslint.rs for the latest setup instructions and confirm that your TypeScript version is supported.

Official sources

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