ESLint 10发布：新版本实用亮点与迁移建议

就在最近，ESLint 发布了备受瞩目的 10.0 版本。回想几年前，每当 ESLint 进行一次大版本更新，开发者们总会第一时间去关注新增了哪些规则、性能有没有提升、运行速度是不是又“起飞了”。但现在，更多人的第一反应却变成了：它还能跑得动吗？

ESLint 10.0 终于来了。

放在几年前，大家会第一时间去看新规则、看性能、看是不是“起飞了”。

而如今，更多人的第一反应是：它还能不能用？

这倒不是 ESLint 做得不行了，而是我们有了更好的选择！

这一次，ESLint 做的是“清账”

如果你去细看 ESLint 10.0 的改动，会发现一个非常明显的特征：

没有颠覆式的新能力，也没有“效率暴涨”的故事，更多是在干一件事——把旧时代留下的东西彻底收拾干净。

eslintrc 正式退出历史舞台，Flat Config 成为唯一选择；

老 API 被移除，Node 版本门槛被抬高；

配置查找逻辑也终于变得更符合现代工程的直觉。

从工具作者的视角看，这一步非常必要。

但从使用者角度来看，获得感并不强。

更像一句话：“它终于不再拖后腿了。”

问题是，外面的世界已经变了

ESLint 在做整理的时候，前端工具链并没有停下来等它。

这两年，一个很明显的变化是：

大家开始认真讨论——ESLint 是不是必须的？

这个问题本身，就已经说明了一切。

oxlint：不聊理想，只想跑得快

oxlint 是尤雨溪团队推出的现代 lint 工具，完全用 Rust 编写。

出现一年多时间后，它已经不是一个实验品，而是一个非常能打的替代方案。

最新的 benchmark 给出的数据很直接：

在相同配置下，oxlint 的 lint 速度相比 ESLint 要快 50到100 倍。同一份代码，ESLint 可能要跑三十多秒，而 oxlint 多线程下只需 0.6 秒左右。

即便和同样基于 Rust 的 Biome 相比，oxlint 在纯 lint 场景下，通常也还能快接近 2 倍。

规则方面，oxlint 目前已经内置了超过 500 条核心规则，对大量常见 ESLint 规则的兼容性都很不错，而且可以直接读取 ESLint 的既有配置，迁移成本并不高。

从社区数据看，它的增长也非常快，目前累计下载量已经超过160万，而且还在持续上升。

现在再说 oxlint 只是“快”，已经不准了。

它是真正把 ESLint 的性能瓶颈，推向了历史。

Biome：不止于 lint

Biome 的定位和 oxlint 有些不同。

它不只是一个 lint 工具，而是想做一套统一的前端工具链。

lint、format、import sort 等功能全部内置，用一个 biome.json，就能覆盖过去 ESLint + Prettier + 各种插件的组合。

社区里的实际使用反馈也很直观：

在一些中型代码库里，Biome 做 lint + format 的整体耗时，往往比传统 ESLint + Prettier 要快 20 倍左右。

目前 Biome 内置了大约 300 多条 lint 规则，formatter 的兼容性也已经相当不错。

在 GitHub 上，它已经拿到了超过 23k star，是一个成长非常快的项目。

对新项目来说，这种“少装工具、少配配置”的体验，本身就是非常实在的生产力提升。

所以，ESLint 10.0 尚能饭否？

如果只看“能不能 lint”这件事，答案其实已经很清楚了。

在绝大多数项目里，oxlint 或 Biome 已经可以直接替代 ESLint，而且这是正在发生的事实。

不少大型乃至超大型开源项目，已经在社区分享过迁移案例：ESLint 整套移除，CI 时间从几十秒降到一两秒，本地开发几近无感。

而这种速度提升，并不是靠牺牲规则换来的。

日常项目真正用到的那部分 ESLint 规则，oxlint 和 Biome 基本都能覆盖。

在这种情况下，ESLint 已经不再是默认答案。

如果你的项目没有强依赖极少数特殊规则，那反而需要一个理由，去继续使用 ESLint。

ESLint 10 当然还能用。

只是现在，它更像是被绕开的那一个，而不是第一个被选择的工具。