Rspack Introduces Rslint, a TypeScript-First Linter Written in Go

The Rspack team has announced Rslint as a new member of the Rstack family. Unlike Rspack’s Rust-based bundler, Rslint is written in Go and powered by Microsoft’s experimental typescript-go compiler. It began as a fork of tsgolint, an early proof-of-concept by @auvred, and is now being developed as part of Rspack’s broader high-performance toolchain.

This expands Rstack beyond its Rust-based bundler, Rspack, into linting and code analysis. By adopting tsgolint’s foundation, the Rspack team is betting on Go and typescript-go as the basis for typed linting.

Features and Goals#

The Rslint README encourages developers to “think of Rslint as Rust Clippy but for TypeScript," more like a TypeScript-native extension than a traditional ESLint plugin.

Rslint aims to address many long-standing pain points of the ESLint ecosystem:

• 20–40x faster performance than traditional ESLint setups, thanks to Go and typescript-go.
• Typed linting by default, without the complex configuration typically required by TypeScript-ESLint.
• Best-effort ESLint compatibility, reusing most existing ESLint and TypeScript-ESLint configurations to ease migration.
• TypeScript-first semantics, with the TypeScript compiler as the single source of truth to avoid edge-case mismatches.
• Cross-module analysis, providing project-level checks rather than only file-level rules.
• Monorepo support via TypeScript project references and workspace configurations.
• Batteries included, shipping with TypeScript-ESLint rules and popular ESLint rules out of the box.
• Extensibility, exposing AST and type information for writing custom rules with deep semantic analysis.

At this stage, Rslint is still experimental, but the Rstack team's ambitions go beyond being “just another ESLint clone.”

Two Parallel Bets on Typed Linting#

Rslint’s launch coincides with Oxlint unveiling its own type-aware linting preview, which integrates with typescript-go through a slimmed-down fork of tsgolint. Together, these two announcements show that typed linting, long considered too slow to pair with native-speed Rust or Go linters, is now moving into practical territory.

The approaches share DNA but diverge in packaging and ecosystems:

• Rslint (Go + typescript-go): Picks up the original tsgolint prototype wholesale, evolving it into a TypeScript-first linter that aims to be ESLint-compatible while delivering 20–40x performance gains.
• Oxlint (Rust + Oxc + typescript-go): Runs its linter core in Rust, but calls into a vendored version of tsgolint for type checks. This hybrid approach lets Oxlint add typed rules like no-floating-promises while keeping its Rust CLI and diagnostics pipeline.

Both teams are betting that typescript-go will mature into a fast, reliable foundation for type analysis. What’s different is the level of integration: Rslint is building directly on typescript-go as its single source of truth, while Oxlint is embedding it inside a Rust-native toolchain.

Instead of consolidation, we’re watching specialization and parallel bets on what “typed linting” should look like. One path treats typed linting as a Go-native extension of the TypeScript compiler; the other as a Rust toolchain feature that delegates type checks out to Go.

What’s Up With All the New Linters?#

Observers often ask why new linting projects emerge instead of consolidating under a single umbrella. In this case, there are a few factors that may be contributing to this trend.

In Rslint’s case, part of the explanation lies in architecture: while both Rslint and Oxlint build on typescript-go, Rslint treats it as its core whereas Oxlint embeds it inside a Rust pipeline. Ecosystem alignment also plays a role, with Rstack pursuing a TypeScript-native feel and Oxc integrating with its Rust toolchain. Reviving tsgolint was a quicker path for Rspack, while slimming and embedding it fit Oxc’s goals. Each stack is aiming for end-to-end consistency, which often favors owning the linter rather than depending on another ecosystem’s priorities.

Linting Splits Along Toolchain Lines#

Rather than converging on shared infrastructure, the ecosystem appears to be fragmenting into competing high-performance toolchains, each building its own linter, formatter, bundler, and test runner.

Each stack is chasing speed, tighter integration, and consistency of developer experience. Typed linting is simply the newest frontier where these competing visions are being tested.

For developers, this fragmentation means more specialized choices tailored to different workflows but also less standardization. The once-stable expectation of “just use ESLint” is giving way to a landscape where linting may depend on which toolchain you adopt.