Biome 2.6 开始格式化 Markdown、YAML 和 SCSS：一个工具收口的代价

之前 Biome 的定位很清楚：JS、TS、JSON 的格式化与 lint，用 Rust 写，主打速度。2.6 把 Markdown、YAML、SCSS 也纳进来了。

好处

少装三四个工具，配置集中在一处，CI 里少跑几个进程。对中小项目，这种收口确实省心，也不用再为 Prettier 的插件版本冲突头疼。

代价

格式化器越通用，边界情况越多。Markdown 的换行与列表缩进、YAML 的锚点与多行字符串、SCSS 的嵌套与注释，各家格式化器的取舍都不一样。迁移时最容易出问题的是“格式化后 diff 巨大”，把真正的业务改动淹没在几万行空白变更里。

迁移建议

第一步只开检查不开写，跑一遍看差异量；第二步对差异大的目录单独加忽略规则，比如自动生成的文件、历史文档；第三步把格式化提交和业务提交分开，别混在一个 PR 里，否则代码评审形同虚设。

一个判断

工具收口是趋势，但收益主要在中小项目。在大仓库里，一次全量格式化的风险往往大于省下的那几个进程。

顺带看一眼同周的其他更新

Bun 到 1.4.4，Electron 到 45，pnpm 到 12.16。前端工具链的版本节奏快到需要专门的节奏管理，建议把这类升级合并到固定的窗口，别让它随时打断业务开发。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

一次全量格式化的差异是真的吓人。我们上次换格式化器，一个合并请求改了八千行，评审等于没做。现在都是按目录分批，格式化单独一个提交。

少装三四个工具、配置集中一处，中小项目确实省心，Prettier 插件版本冲突的坑也能避开。但格式化越通用边界越多，YAML 锚点、SCSS 嵌套各家取舍不同。我们迁移最怕格式化后 diff 巨大，把业务改动淹没在几万行空白变更里。建议先在小仓库灰度，CI 开 check-only 再推全量。

少装三四个工具、配置集中一处，中小项目确实省心，Prettier 插件版本冲突的坑也能避开。但格式化越通用边界越多，YAML 锚点、SCSS 嵌套各家取舍不同。我们迁移最怕格式化后 diff 巨大，把业务改动淹没在几万行空白变更里。建议先在小仓库灰度，CI 开 check-only 再推全量。