Content
Biome 是面向现代前端工具链的一体化代码质量工具，试图用一个更高性能、更一致的工具同时覆盖格式化、lint 和部分代码检查能力。它经常被拿来和 ESLint、Prettier 对照，因为它的价值不只是“能做这些事”，而是把原本分散的工作流重新整合成一个统一入口。
Acceptance
Biome 是用 Rust 编写的代码质量工具,一个工具同时做 ESLint (lint) 和 Prettier (format) 的工作。
为什么能合二为一: Biome 用 Rust 自研了 JS/TS/JSON/CSS 解析器,一次解析生成 AST,同时跑 lint 规则和 format 规则。不存在”两个工具抢着改代码”的冲突。
速度: 比 ESLint + Prettier 快 10-100 倍。原因:Rust vs JavaScript 的执行效率差异 + 单次解析 vs 多次解析。
不能替代 tsc: Biome 做 lint + format,不做类型检查。TypeScript 的 tsc --noEmit 仍然需要单独跑。
前身: Rome (2020, Facebook 的 Jamie Kyle 发起) → 项目停滞 → 社区 fork 为 Biome (2023)。
Biome 2.x 变化: 配置 key 从 1.x 有较大变动(如 organizeImports 移除、files.ignore → files.includes、overrides[].include → overrides[].includes)。升级时需注意 schema 版本匹配。
Question
- Biome 的 Rust 实现意味着它不能用 JS 写 plugin——这对生态扩展性有什么影响?ESLint 的 JS plugin 生态是护城河吗?
- Biome 的”一次解析”优势在项目规模多大时才能体感到速度差异?小项目是否没必要换?
- Biome 能否最终替代 tsc 做类型检查?如果不能,瓶颈在哪?
See Also
-
MindGym M0 session (2026-04-13) — 选择 Biome 替代 ESLint+Prettier 的决策过程
-
Biome 2.x 升级遇到的配置不兼容问题(schema 版本 1.9.4 vs 2.4.11)
-
Biome 官方文档：formatter / linter / configuration / roadmap
-
TypeScript 官方文档：type checking 与 compiler architecture
YoYo’s Note
Biome 的存在证明了一个工具设计原则:当两个工具的职责有重叠且需要”胶水包”协调时,合并成一个工具往往是更好的方案。ESLint + Prettier + eslint-config-prettier 的三件套在 Biome 面前显得笨重。
但 Biome 的 trade-off 也很明确:Rust 实现意味着 plugin 生态不如 ESLint(JS 社区人人能写 ESLint plugin,但不是人人会 Rust)。目前 Biome 的规则集覆盖了 ESLint recommended 的大部分,但长尾规则可能缺失。
Answer
Biome 的 Rust 实现意味着它不能用 JS 写 plugin——这对生态扩展性有什么影响?ESLint 的 JS plugin 生态是护城河吗?
这会显著提高扩展门槛。ESLint 的强项就在于任何熟悉 JS 的团队都能快速写 rule 和 plugin,于是形成了极其丰富的长尾生态。Biome 虽然在性能和一体化体验上更强,但在“哪里都能补一条自定义规则”这件事上暂时没有 ESLint 灵活,所以 ESLint 的 plugin 生态确实仍是它的重要护城河。
Biome 的”一次解析”优势在项目规模多大时才能体感到速度差异?小项目是否没必要换?
通常在大项目、monorepo、CI 场景和频繁保存触发检查的日常开发里,差异会更容易体感到。小项目里,绝对时间本来就短,性能优势未必成为决定性因素,但统一工具链、减少配置冲突本身也仍然是价值。所以不只是“项目够大才值得换”,而是要看你更在意速度,还是生态兼容性。
Biome 能否最终替代 tsc 做类型检查?如果不能,瓶颈在哪?
短期内很难。因为类型检查不是简单的语法规则匹配,而是要理解 TypeScript 的完整类型系统、模块解析、声明文件、泛型约束和跨文件推导。Biome 当前的强项是语法层和风格层的一体化处理,而 tsc 的核心价值在于类型语义分析,这两者不是同一层工作。