跳到主要内容

Biome

Biome 代表的是另一条代码规范路线：

  • 不再拆 ESLint + Prettier + 一些导入整理工具
  • 而是尽量把 lint、format、imports 这些能力收进一套统一工具链

如果项目一开始就想把规范链路做得更轻、更快，Biome 很值得认真看。

Biome 适合放在哪种项目里理解​

它通常更适合这些场景：

  • 新项目
  • 想减少工具切换
  • 更看重执行速度
  • 希望配置和编辑器体验更统一

对于深度依赖 ESLint 插件生态的老项目，Biome 也能看，但迁移时要先评估覆盖度。

它在解决什么问题​

很多前端项目的规范链路，最后会长成这样：

  • ESLint 查规则
  • Prettier 管格式
  • 额外工具整理 imports
  • 编辑器、CLI、CI 还各有一套命令

Biome 想做的是把这些日常动作尽量合到一起。

配置文件长什么样​

Biome 官方文档说明，配置文件一般是：

  • biome.json
  • 或 biome.jsonc

通常放在项目根目录。

一个更常见的前端项目配置可以这样写：

{
  "$schema": "https://biomejs.dev/schemas/2.3.11/schema.json",
  "files": {
    "ignore": ["dist", "build", "coverage", "node_modules"]
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100,
    "lineEnding": "lf"
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "semicolons": "always",
      "trailingCommas": "all"
    }
  },
  "assist": {
    "actions": {
      "source": {
        "organizeImports": "on"
      }
    }
  }
}

这份配置已经足够覆盖多数新前端项目的日常规范链路。

Biome 里最值得先理解的几层​

Formatter​

负责格式统一，角色上接近 Prettier。

Linter​

负责静态规则检查，角色上接近 ESLint 的一部分日常能力。

Assist / organize imports​

Biome 官方文档把导入整理放在 code action / assist 这一层。它不是靠额外一套 imports 工具拼出来的，而是和主工具链一起工作的。

导入整理怎么理解​

Biome 官方文档里，organizeImports 已经是一条独立能力。

配置一般像这样：

{
  "assist": {
    "actions": {
      "source": {
        "organizeImports": "on"
      }
    }
  }
}

如果项目里长期会为了这些问题争来争去，这层很有价值：

  • 内置模块放哪
  • 第三方依赖放哪
  • 别名导入放哪
  • import type 怎么排

Lint 和 format 为什么在 Biome 里更顺​

Biome 文档里有一个思路很清楚：

  • 格式由 formatter 决定
  • linter 不去重复承担格式规则

这点很重要，因为它天然避开了很多 ESLint + Prettier 之间的角色冲突。

CLI 常见怎么跑​

Biome 日常最常见的命令一般是：

biome check .
biome format . --write
biome lint .

更常见的团队入口往往会统一成 script：

{
  "scripts": {
    "lint": "biome lint .",
    "format": "biome format . --write",
    "check": "biome check ."
  }
}

如果希望工具更少、命令更统一，Biome 在这层会很舒服。

编辑器里怎么接​

Biome 官方文档里，导入整理和 fix-all 都支持编辑器 code actions。

VS Code 常见写法：

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.biome": "explicit",
    "source.organizeImports.biome": "explicit"
  }
}

这类接法的价值很直接：

  • 保存时就能把大部分低价值问题收掉
  • review 里剩下的更接近代码本身的问题

和 ESLint / Prettier 的关系怎么判断​

新项目​

新项目完全可以先从 Biome 起步，只要：

  • 所需规则覆盖够用
  • 编辑器支持顺
  • CI 命令清楚

老项目​

老项目更稳的判断要看两件事：

  • 是否深度依赖 ESLint 插件生态
  • 是否有很多框架专属规则必须保留

如果这两层依赖很重，迁移通常不要一把梭，最好分阶段。

一个更稳的迁移方式​

如果现有项目已经在跑 ESLint + Prettier，比较稳的迁移顺序一般是：

  1. 先在独立分支试跑 Biome
  2. 先只接 formatter
  3. 再评估 linter 覆盖度
  4. 最后再决定是否完全替换旧链路

这样做的好处是：

  • 不会一次性把所有风险压到主线
  • 能更清楚看到缺口到底在哪

哪些项目很适合直接上 Biome​

  • React / TypeScript 新项目
  • 工程链路想保持克制的项目
  • 团队人数不大，但希望规范自动化程度高
  • monorepo 里希望工具尽量少的项目

哪些项目要多看一眼再决定​

  • 有很多历史 ESLint 插件规则
  • Vue / React / Node 混合且自定义规则很多
  • 团队已经深度绑定某套 ESLint 生态
  • CI 和编辑器已经围着旧链路搭了很多东西

这不是说不能迁，而是迁之前最好先做覆盖评估。

更适合先记住的主线​

Biome 最大的吸引力，不只在“快”，而是：

  • 工具更少
  • 分工更清楚
  • 配置更集中
  • 本地、编辑器、CI 更容易说同一种话

如果规范链路本来就准备重做，Biome 很值得放进候选。

参考来源​