TSSLint, the lightweight TypeScript semantic linting tool created by Johnson Chu, has released version 3, bringing a reduced dependency footprint, improved migration paths from legacy linters, and what Chu has described as the “final major release” of the project.
TSSLint positions itself as the spiritual successor
to the now-deprecated TSLint. Unlike general-purpose linters such as ESLint, which operate as separate processes and often need to re-initialize type-checking context, TSSLint runs directly as a TypeScript Language Server plugin. By sharing the existing TypeChecker and operating on the native TypeScript AST without ESTree conversion, it provides near-instant diagnostics and fixes, addressing a common pain point in large-scale projects where editor lag during auto-fix on save can slow development.
The most significant change in v3 is the removal of the esbuild dependency for runtime operations. TSSLint now leverages Node.js’s native support for importing .ts files, reducing build complexity and improving startup speed. This change does require Node.js 22.6.0 or newer.
This release also introduces a TSL compatibility layer, consolidated via the TSL project by Arnaud Barre, for unified handling of TypeScript linting rules. The @tsslint/compat-eslint package has been re-introduced as a separate package, updating the integration logic for interoperability with the existing ESLint ecosystem. For teams still using the legacy TSLint, a new importTSLintRules feature allows direct import of TSLint rules into a TSSLint configuration, simplifying the migration path.
A new createIgnorePlugin API provides support for directive comments, allowing developers to configure ignore patterns in their configuration.
Developer tooling has also been improved with the introduction of tsslint-docgen, a new tool for automated rule documentation generation, along with updated JSDoc for the defineRules API. The CLI cache is now stored in the OS temporary directory, preventing cache files from polluting project folders.
There are several breaking changes that developers will need to address when migrating. The --projects CLI parameter has been renamed to --project, and createDisableNextLinePlugin has been renamed to createIgnorePlugin. The --threads option has been removed entirely, with the team citing benchmarks showing that multi-threading consumed approximately 2x the energy for only a 1.5x speed increase due to Node.js memory-sharing limitations. The team has indicated plans to introduce a more resource-efficient multi-threading solution in a future release.
Announcing the release on X, Chu described it as lighter and faster, noting the switch to native Node.js support for .ts imports. Vue.js creator Evan You has previously endorsed TSSLint as “the most efficient way to run type-aware lint rules while leveraging the existing TS language server.”
On the same X thread, someone asked:
Interesting, will this work in the Golang version of TypeScript?
Johnson Chu replied:
Currently, the answer is no. The community has already made attempts in this area with projects like tsgolint/oxlint/rslint. Therefore unless we have a significantly better solution here, tsslint will not attempt to duplicate the work.
Compared to ESLint with typescript-eslint, which remains the most widely adopted TypeScript linting solution, TSSLint’s approach of running inside the language server avoids the overhead of maintaining a separate type-checking process. Newer tools like Biome and oxlint offer significant speed improvements over ESLint through native implementations, but focus primarily on syntactic linting and do not yet provide the same depth of type-aware analysis that TSSLint achieves through its direct integration with the TypeScript compiler API.
TSSLint is incompatible with the upcoming TypeScript 7 native compiler (typescript-go), as it does not support Language Service Plugins.
TSSLint is open source and available on GitHub with around 600 stars at the time of writing.
