Oxlint – 用 Rust 编写的 JavaScript linter

原文 ↗ Hacker News 讨论 ↗

一个用 Rust 编写的新 JavaScript linter——Oxlint——因在大型代码库中比 ESLint 快几十到上千倍而受到关注，尤其是在 CI 流水线中。评论者认可其性能和更简单的依赖故事，但也指出了重大权衡：规则覆盖有限、缺乏成熟的插件和自定义规则生态，以及有可能在多个 Rust 方案（如 Biome 和 Bun）之间进一步分裂工具链。围绕它的争论反映了一个更广泛的趋势：用编译型语言重写 JS 工具，在原始速度与简洁性之间，与可配置性、可扩展性和长期可维护性之间进行权衡。

性能与 CI 影响

  • 许多人对其相较 ESLint 报告的 50–100 倍提速印象深刻；有一个案例是：在 40+ 个 CI worker 上耗时 75 分钟 → 在单个 worker 上约 10 秒。
  • 有些人认为这会给大型 monorepo 和全仓库 CI linting 带来变革；也有人说 lint 很少是瓶颈，更偏好仅对变更文件进行 linting 或增量式方法。
  • 关于是否有必要进行全仓库 linting 的争论；支持部分 linting 很难的原因包括需要类型感知和跨文件规则。

规则、自定义与生态兼容性

  • 采用的最大阻碍：无法与 ESLint 约数百条规则以及丰富的插件生态（TypeScript、React、import rules、“rules of hooks”等）达到一致。
  • 一些人高度依赖自定义 ESLint 规则，把它们当作“持续的 codemod”和项目特定的静态分析，因此在出现对应替代方案之前，他们认为 ESLint 无可替代。
  • Oxlint 计划通过 Trustfall 查询和 YAML 支持自定义规则，被视为很有前景，但仍处于早期阶段。

DX、配置与工作流

  • ESLint 配置被广泛描述为复杂且脆弱，尤其是在 TypeScript/React 和多个重叠规则集并存时。
  • 有些人称赞那些“开箱即用”、只需极少配置的工具（Python 的 Ruff、Deno 内置的 linter/formatter、Go/Rust 的惯例），并希望在 JS/TS 中也有类似方案。
  • 也有人认为初始 lint 配置只是一次性成本，稳定的配置可以持续很多年。

与其他工具的比较

  • 经常被拿来比较的工具包括 Ruff（Python）、Biome（前身 Rome）、Bun、Deno、dprint、Pyright、mypy、TypeScript 本身。
  • 有人质疑为什么要选 oxlint 而不是 Biome；一种回答是：它更强调与 ESLint 的兼容性，不过据说 Biome 目前实现的 ESLint 规则更多。

Rust 重写与语言选择

  • 讨论把 oxlint 放在了更广泛的趋势中：用编译型语言（Rust、Go、Zig）重写 JS 工具链。
  • 支持者：巨大的速度提升、更好的 AST 内存布局、通过单一二进制便于分发、Rust 比 C/C++ 更易接触。
  • 批评者：性能问题可能掩盖了更深层的复杂性/技术债；为 JS 工具使用非 JS 语言会减少贡献者来源，并可能带来长期可持续性风险。

对 Linting 的理念

  • 对 linting 应当是轻量级/仅样式检查，还是应成为开发中深度静态分析核心，存在分歧。
  • 一些人认为重度 linting 越界且增加维护负担；另一些人则把强大的、项目特定的静态分析视为提升生产力和质量的重大“超能力”。