Rome构建工具实战：前端工程化新选择与踩坑经验分享
西门佳宜我的写法，亲测靠谱
去年我们团队在新项目里试水 Rome（现在叫 Biome 了），说实话一开始我是抗拒的——毕竟 ESLint + Prettier + Webpack 的组合已经用得滚瓜烂熟，换工具链等于自找麻烦。但折腾两周后，我真香了。Rome 最大的优势是「开箱即用 + 速度飞快」，但前提是你的配置和写法得对路。下面是我踩坑后总结的几条实战经验。
首先，别一上来就全盘替换。我见过有同事直接把旧项目的 ESLint 配置扔掉，结果一堆报错，最后又回滚。正确的做法是：先用 Rome 的默认规则跑一遍，看看哪些地方炸了，再针对性调整。比如，默认情况下 Rome 对 console.log 是零容忍的，但开发阶段你肯定需要它。这时候别急着关掉整个 linter，而是加个例外：
{
"linter": {
"rules": {
"recommended": true,
"suspicious": {
"noConsoleLog": "off"
}
}
}
}这样既保留了 Rome 的核心检查能力，又不影响调试。我一般会在 biome.json 里显式关闭几个高频误报的规则，而不是一股脑全关。
这几种错误写法，别再踩坑了
最让我头疼的不是 Rome 本身，而是团队成员乱改配置导致的「配置漂移」。比如有人为了图省事，在项目根目录下手动运行 rome init，结果生成了一堆重复配置，还覆盖了我们统一的规范。这种操作一定要禁止！
另一个经典错误是：在 CI 里只跑 rome check，却不跑 rome format。结果就是本地格式化过的代码，推到远程后 CI 报错说「格式不一致」。其实 Rome 的格式化和 linting 是分开的，必须两个都跑：
# 正确的 CI 脚本
npx @biomejs/biome check .
npx @biomejs/biome format --write .注意 --write 参数在 CI 里其实不应该加，否则会修改源文件。更稳妥的做法是用 --check 模式：
npx @biomejs/biome format --check .这样如果格式不合规，CI 直接失败，逼你本地先格式化好再提交。我们团队吃过这个亏，后来在 pre-commit hook 里也加了这两步，才彻底解决。
还有个隐蔽的坑：Rome 默认不处理 .ts 文件里的类型错误。很多人以为 linter 会报 TS 类型问题，其实不会！它只做语法和风格检查。如果你依赖 Rome 做类型校验，那完蛋了。必须配合 tsc --noEmit 或者用 VS Code 的 TypeScript 插件实时检查。这点文档里没强调，我踩过两次才记住。
实际项目中的坑
在真实项目里，Rome 最让人抓狂的是「路径解析」。比如我们有个 monorepo，子包之间互相引用，用的是 TypeScript 的 paths 映射：
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@utils/*": ["packages/utils/src/*"]
}
}
}结果 Rome 格式化时完全不认识 @utils/xxx 这种路径，报「无法解析模块」。折腾半天发现，Rome 不读 tsconfig.json！它有自己的模块解析逻辑，得在 biome.json 里单独配：
{
"resolver": {
"alias": {
"@utils": "./packages/utils/src"
}
}
}但注意，这个 alias 只支持相对路径，不能写成 packages/utils/src（少了开头的 . 就不行）。我一开始漏了点，查了好久才定位到问题。建议所有 alias 都用 ./ 开头，省得猜。
另外，Rome 对 JSX 的处理也有点怪。比如在 React 项目里，如果你用了 Fragment 简写 <>...</>，Rome 默认会把它转成 <React.Fragment>。虽然功能一样，但代码变啰嗦了。要保留简写，得在配置里关掉这个转换：
{
"formatter": {
"jsx": {
"fragment": "preserve"
}
}
}不然每次保存，你的 <> 都会被自动展开，团队里有人喜欢简写有人喜欢全写，直接引发冲突。这种细节最好在项目初期就统一好。
性能是真的快，但别迷信
很多人吹 Rome「快如闪电」，确实比 ESLint 快不少，但也不是万能的。我在一个 10w 行的大项目里试过，首次全量检查要 8 秒，而增量检查（只改一个文件）只要 200ms。但如果你开了太多自定义规则，或者项目里有大量动态 import，速度还是会掉下来。
我的建议是：别为了炫技加一堆花里胡哨的规则。Rome 的「recommended」规则集已经覆盖了 90% 的常见问题，剩下的 10% 如果不是强需求，就别折腾了。我见过有人硬要加一个「禁止使用 for 循环」的规则，结果格式化时卡死，最后还得删掉。
还有个小技巧：用 rome rage 命令可以快速收集环境信息，遇到奇怪问题时直接贴给社区，比自己瞎猜高效多了。我上次遇到 Windows 路径分隔符的问题，就是靠这个命令定位到是 node 版本兼容性问题。
结尾碎碎念
总的来说，Rome（Biome）是个好工具，但别把它当银弹。我的经验是：先用默认配置跑通，再根据项目痛点微调，别一上来就搞复杂配置。它最大的价值不是功能多，而是「减少配置成本 + 加快反馈速度」。只要你避开上面那些坑，基本能平滑落地。
以上是我个人在项目中踩坑后的总结，有些方案可能不是最优解，但胜在简单稳定。如果你有更好的实践，欢迎评论区交流——特别是 monorepo 或 Next.js 项目里的特殊配置，我还想多学两招。
