Rspack 推出 Rslint:一个用 Go 编写的 TypeScript-First Linter

本篇依然来自于我们的 《前端周刊》 项目!

由团队成员 掘金安东尼 翻译,欢迎大家 进群 持续追踪全球最新前端资讯!!

原文地址:socket.dev/blog/rspack...

Rspack 正式发布了 Rslint ------ 一个基于 typescript-go 构建的高速 TypeScript-first(以 TypeScript 为核心)Linter。这让 Rspack 加入了越来越多"工具链自带 Linter"的浪潮中。

和 Rspack 的 Rust 打包器不同,Rslint 完全用 Go 编写,并依赖微软的实验性编译器 typescript-go 。它最初是 @auvred 开发的 tsgolint(早期概念验证项目)的一个分支,如今被纳入 Rspack 的高性能工具链版图,作为新成员继续发展。

这意味着 Rstack 家族已经不再只是 Rust 打包器 Rspack,而是扩展到了代码检查与分析领域。Rspack 团队押注于 Go 和 typescript-go,来作为类型化 Linting 的核心基础。

特性与目标

Rslint 的 README 鼓励开发者把它理解为"TypeScript 版的 Rust Clippy",更像是一种 TypeScript 原生扩展,而不是传统 ESLint 插件。

它的目标是解决 ESLint 生态中长期存在的痛点:

  • 20--40 倍性能提升:依靠 Go 和 typescript-go,实现远超传统 ESLint 的速度。
  • 默认类型检查:无需复杂配置,就能直接进行基于类型的 Lint。
  • 兼容 ESLint 迁移:尽可能复用现有 ESLint 和 TypeScript-ESLint 配置,降低迁移成本。
  • TypeScript-first 语义:以 TypeScript 编译器作为唯一可信来源,避免边界条件下的不一致。
  • 跨模块分析:不再局限于单文件规则,而是支持项目级别的检查。
  • Monorepo 支持:通过 TypeScript 项目引用和 workspace 配置适配大仓。
  • 开箱即用:内置 TypeScript-ESLint 和常见 ESLint 规则,安装即用。
  • 可扩展性:开放 AST 和类型信息,支持深度语义分析的自定义规则。

目前,Rslint 仍处于实验阶段,但 Rstack 团队的野心远不止"又一个 ESLint 替代品"。

两条并行的"类型化 Linting"路径

有趣的是,Rslint 的发布几乎与 Oxlint 的类型感知 Linting 预览同步。Oxlint 也基于 typescript-go,但通过一个精简后的 tsgolint 分支来实现。

这意味着长期被认为"太慢"的类型化 Linting,现在逐渐进入了可行的落地阶段。

  • Rslint(Go + typescript-go) :直接继承 tsgolint 原型,目标是 TypeScript-first + ESLint 兼容 ,同时带来 20--40 倍性能提升
  • Oxlint(Rust + Oxc + typescript-go) :核心用 Rust 编写,但调用内置的 tsgolint 进行类型检查。这种混合模式允许 Oxlint 添加类型化规则(如 no-floating-promises),同时保留其 Rust CLI 和诊断体系。

两者都押注 typescript-go 能成长为高性能的类型分析基础,但区别在于:

  • Rslint 直接把它作为唯一的语义来源;
  • Oxlint 则把它嵌入到 Rust 工具链中。

这并不是"融合",而是 分化与专精:一条路径把类型化 Linting 当作 Go 版 TypeScript 编译器的自然扩展;另一条路径则当作 Rust 工具链的功能插件。

为什么突然冒出这么多新 Linter?

很多开发者会疑惑:为什么不整合到一个统一方案,而是不断造新 Linter?

原因其实有几点:

  • 架构差异:虽然都基于 typescript-go,Rslint 把它当核心,Oxlint 则是嵌入 Rust 管道。
  • 生态对齐:Rstack 更追求 TypeScript 原生的体验;Oxc 则坚持 Rust 工具链的一致性。
  • 演化路径不同:Rspack 选择"复活 tsgolint",走得更快;Oxc 则选择精简和内嵌,更贴合自身目标。

归根结底,每个工具链都想要端到端的一致性,而不是依赖其他生态的优先级。

工具链割裂下的 Linting

目前的趋势不是统一,而是 碎片化:每个高性能工具链都在自建自己的 Linter、Formatter、Bundler 和测试框架。

它们追求的是:

  • 更快的速度
  • 更紧密的集成
  • 更一致的开发者体验

类型化 Linting 只是最新的试验场。

对开发者来说,这种分化带来的是:更多针对性工具,但也意味着 更少的标准化。过去"用 ESLint 就行"的共识正在被打破,未来你选择哪个 Linter,很可能取决于你采用了哪条工具链。


👉 总结一句话:Rslint 的出现,标志着 TypeScript 生态进入"高速类型化 Linting"时代,但也揭示了工具链割裂带来的新选择与新困惑。

相关推荐
gnip7 小时前
企业级配置式表单组件封装
前端·javascript·vue.js
一只叫煤球的猫8 小时前
写代码很6,面试秒变菜鸟?不卖课,面试官视角走心探讨
前端·后端·面试
excel9 小时前
Three.js 材质(Material)详解 —— 区别、原理、场景与示例
前端
掘金安东尼9 小时前
抛弃自定义模态框:原生Dialog的实力
前端·javascript·github
hj5914_前端新手13 小时前
javascript基础- 函数中 this 指向、call、apply、bind
前端·javascript
薛定谔的算法13 小时前
低代码编辑器项目设计与实现:以JSON为核心的数据驱动架构
前端·react.js·前端框架
Hilaku13 小时前
都2025年了,我们还有必要为了兼容性,去写那么多polyfill吗?
前端·javascript·css
yangcode13 小时前
iOS 苹果内购 Storekit 2
前端
LuckySusu13 小时前
【js篇】JavaScript 原型修改 vs 重写:深入理解 constructor的指向问题
前端·javascript
LuckySusu13 小时前
【js篇】如何准确获取对象自身的属性?hasOwnProperty深度解析
前端·javascript