biomejs/biome

如果 JavaScript/TypeScript 项目里散落着一堆 lint 和格式化配置、想收拢到一个工具里干这些杂活，值得先试。它不是你现有规则集的直接替代品，切换前要先核对仓库依赖的 lint 规则。

解决什么问题

一个常见的 Web 项目，往往同时装着 ESLint 及若干插件、Prettier，再加 JSON 和 CSS 各自的格式化工具，每个都有自己的配置文件，各自还要接一遍编辑器。本地依次跑一遍很琐碎，CI 里也要调好几个命令，规则之间还可能互相打架。Biome 把 JavaScript、TypeScript、JSX、JSON 和 CSS 的格式化与检查合并到一个命令、一套 LSP 服务：本地跑 check --write 自动修复，CI 里跑 ci 按同样规则卡住。项目声明运行不依赖 Node.js，也不需要配置。

有什么不同

实现用 Rust，配一个保真解析器和 LSP 支持，README 把这当作性能与诊断质量的基础。通过 npm 安装后拿到的是原生二进制、编辑器集成（VS Code 或 Open VSX 扩展），以及一个覆盖 format、lint 和 check 的 CLI，一次遍历完成多项检查。想先体验的话，有一个编译成 WebAssembly 的 在线 playground，改规则的成本很低，不必先改仓库。

代价在于配置兼容性。项目主打“合理的默认值、无需配置”，这最适合新项目，或者愿意接受 Biome 自己规则集的团队。如果代码库依赖一长串 ESLint 插件和自定义规则，切换前得先逐项核对哪些能带过去。插件机制目前还是设计中的问题：在 2024 年 1 月的 RFC 讨论里，一位描述该项目的评论者说，当时讨论的主要方向是用 JS/TS 写插件（可能借助 Deno 的 crate）或者 WASM，并 公开征集插件系统意见。就算插件方案落地，也未必自动保留现有 ESLint 的规则语义。

谁值得试

适合：刚起步的 TypeScript/JavaScript 项目，希望用一个二进制完成格式化和检查、少写配置；或者想给 CI 加一步快速检查、同时让编辑器通过 LSP 应用同样规则的开发者。仓库里同时有 CSS 和 JSON 的话也合适，一个工具链能一起覆盖。不太适合：lint 行为依赖特定 ESLint 插件的项目，因为文档描述的设计核心是 Biome 自己的规则，不是接入现成 ESLint 配置。团队如果必须等成熟的第三方插件 API 才敢采用，那就该观察这个 RFC 怎么定，而不是默认它已经完成。

使用条件与边界

安装走 npm 包，文档也提供了不依赖 Node.js 的手动安装方式，对多数 Web 开发者来说普通包管理器路径就够用。编辑器体验依赖 VS Code 或 Open VSX 扩展提供一等 LSP 支持；不用这些编辑器，CLI 仍能完成格式化和检查。更深的限制在于对现有 ESLint 规则与插件的覆盖：迁移意味着要确认会丢掉哪些诊断、哪些需要重新配置。“无配置”的默认值也意味着第一次跑可能按与旧工具不同的方式重排或标记文件，要把切换当成一次真实的调整，而不是无声替换。

HotRepo 点评

HotRepo 自 2026-10-24 开始跟踪该项目，只在 2026-10-25 的日榜记录到一次：25,993 stars，当天 +8。仅此一条观察无法判断关注度是在上升还是消退，持久性目前不可判断。2024 年那条 HN RFC 讨论（1 分）只反映早期设计讨论，不构成当前采用情况的证据。决定前，最好核实项目的 语言支持与规则覆盖 是否对得上代码库实际依赖的 ESLint 规则。