Rome 死亡：Biome 繼承統一工具鏈夢想

2023 年，Rome Tools Inc. 宣佈停止營運，archive 了這個曾被稱為「ESLint + Prettier + Webpack + Babel 終結者」的專案。整個前端社群的反應是「又來了」。但這次的結局與多數失敗的開源專案不同——社群 fork 了 Rome，推出了 Biome。2026 年 1 月 Biome v2.3 發布，423+ lint rules、10-56x 比 ESLint 快、單一 binary 取代 ESLint + Prettier。Rome 的夢想，並沒有死。

---

前端工程師為什麼要關心這個故事

Rome 的願景從來不只是「另一個 Linter」。它的願景是：統一 JavaScript 生態系破碎的工具鏈——Linter、Formatter、Bundler、Minifier、Test Runner——全部用一個工具、一個配置、一個團隊維護。

這個願景沒有實現。但 Biome 正在用更務實的方式，實現了其中最關鍵的部分：一個工具同時是 Linter + Formatter。

如果你現在還在用 ESLint + Prettier 的組合，或者你的專案 linter 設定越來越複雜，這篇文章整理了 Biome 的現況和遷移評估。

---

Rome 的興衰史

Rome 的願景

Rome（2017 年啟動）是一個極度有野心專案：

• 用 Rust 開發：效能比 JavaScript 工具鏈快 10-100x
• 統一所有工具：Linter、Formatter、Bundler、Minifier、Test Runner、Cycle Compiler，全部同一個專案
• No配置：Opinionated（強烈主觀意見），預設值就是最佳實踐，不需要你去研究每個 rule

Rome 的終極目標：
Rome = Prettier（格式化）+ ESLint（檢查）+ Webpack（打包）+ Babel（編譯）
all in one, opinionated, blazingly fast

這個願景吸引了很多開發者，因為前端工具鏈的複雜度實在太高了。

Rome 失敗的原因

Rome 在 2021 年開始商業化，2023 年初宣佈停止營運。失敗的原因不是技術，而是：

1. 過度設計：試圖一次做太多事情，Bundler 和 Test Runner 一直遲遲不能穩定
2. Node.js 生態鎖定：Rome 的底層是 WASM + Node.js，生態系整合困難
3. 維護成本過高：一個 team 要維護五種工具的穩定，工作量過大
4. 行銷失誤：在工具還不夠成熟的時候就開始收費，社群流失

---

Biome：社群 fork 的精神繼承者

Biome 的起源

2023 年，Rome 被 archive 後，社群中的前 Rome 核心貢獻者主導了 Biome 的 fork。Biome 選擇了更務實的路：

Biome 的策略：
Rome 的技術 + 務實的範圍 + 社群驅動開發

Biome v1.0（2023/8）→ Biome v2.0（2025/3）→ Biome v2.3（2026/1）

Biome 的範圍比 Rome 小很多：只做 Formatter + Linter。這反而是正確的策略——Linter + Formatter 是最多人每天都用、最痛的两个工具。

Biome 的核心數據

維度	Biome	ESLint + Prettier
速度	10-56x 比 ESLint 快	JavaScript 工具，單執行緒
安裝大小	單一 binary（~30MB）	ESLint + Prettier + plugins（~200MB）
配置檔案	biomes.json（單一）	.eslintrc + .prettierrc（多個）
Lint Rules	423+	取決於 plugins
Language	Rust	JavaScript
支援	活躍社群	龐大社群

---

Biome 2.3 的新功能

Biome v2.3（2026 年 1 月發布）是目前的最新穩定版本：

1. 423+ Lint Rules

Biome 內建 423+ lint rules，涵蓋：

• JavaScript / TypeScript 正確性
• 樣式規範
• 安全性
• 性能優化
• Accessibility（無障礙）

// biome.json
{
  "$schema": "https://biomejs.dev/schemas/2.3.0/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "correctness": {
        "noUnusedVariables": "error"
      },
      "security": {
        "noDangerouslySetInnerHtml": "warn"
      }
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2
  }
}

2. Type-Aware Linting

Biome 可以利用 TypeScript 編譯器資訊，進行 type-aware linting，不需要另外的 plugins：

// TypeScript 型別錯誤，Biome 可以在 linter 層發現
function processUser(user: { name: string; age: number }) {
  return user.email; // ❌ TypeScript 錯誤：user 沒有 email 屬性
}

3. 單一 binary 取代 ESLint + Prettier

Biome 的一個安裝，包含了：

# 格式化
biome format --write ./src

# Lint 檢查
biome lint ./src

# 修復
biome check --write ./src

# 組織 import
biome organize-imports ./src

過去需要三個工具、三個配置做的事情，變成一個。

---

Biome 的實際使用

基本設定

// biome.json
{
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true
  }
}

與 Git hooks 整合

# 用 lefthook 或 husky 執行 pre-commit lint
npx lefthook install

# lefthook.yml
pre-commit:
  commands:
    lint:
      run: biome check --write ./src

CI/CD 整合

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: biomejs/setup-biome@v2
        with:
          version: 2.3.0
      - run: biome ci ./src

---

Biome vs ESLint + Prettier：什麼時候該遷移

Biome 的優勢場景

• 新專案從零開始：不需要遷移，直接用 Biome，設定簡單
• 小型團隊：只有 1-3 人的前端團隊，不想維護兩套工具的配置
• 效能敏感：CI runtime 想要縮短，Biome 的速度快 10-56x
• Opinionated 團隊：Biome 的預設值就是最佳實踐，不需要太多自定義

ESLint + Prettier 仍然合理的場景

• 大型複雜專案：已經有數百條 custom ESLint rules，自定義配置很深
• 需要特定 plugins：Biome 的 rule 覆蓋了多數場景，但不是 100%。如果你用到非常特定的 framework rules，可能還需要 ESLint
• 團隊多數人用 VSCode ESLint 插件：Biome 在 VSCode 的整合還在追趕 ESLint 的 DX

---

從 ESLint + Prettier 遷移到 Biome

步驟 1：安裝 Biome

npm install --save-dev @biomejs/biome

步驟 2：生成預設配置

npx @biomejs/biome init
# 這會生成 biome.json

步驟 3：Migration codemod

Biome 提供了從 ESLint/Prettier 遷移的 codemod：

# 從 ESLint 遷移
npx @biomejs/biome migrate eslint --config-path ./biome.json

# 從 Prettier 遷移
npx @biomejs/biome migrate prettier --config-path ./biome.json

步驟 4：驗證

# 格式化並檢查
npx biome check --write ./src

# 確認沒有錯誤
npx biome ci ./src

---

OXC：另一個值得關注的 Rust Linter

除了 Biome，還有一個新興的 Rust Linter 工具正在崛起：OXC（Oxc Compiler）。

OXC 的定位與 Biome 不同：OXC 更接近「高性能 JavaScript/TypeScript linter基礎設施」，它提供 library 而不是 end-user CLI。

# OXC 的 CLI 工具叫 oxlint
npx oxlint@latest ./src

Biome vs OXC：

• Biome：End-user導向，提供完整的 formatter + linter 體驗
• OXC：提供基礎設施，允許其他工具調用其 linting 能力

如果你在評估工具鏈，兩個都值得關注。

---

結語：Rome 的夢想，以另一種方式實現

Rome 死了，但它的願景在 Biome 身上以更務實的方式延續。

Biome 選擇只做 Linter + Formatter——放棄了 Rome 的 Bundler、Test Runner 野心——反而讓它真的成了一個可以 production 使用的工具，而不是一個永遠在開發中的願望。

如果你在 2026 年開始一個新專案，Biome 是一個值得評估的選擇。一個安裝、一個配置、一個 binary，取代 ESLint + Prettier 的組合。對於多數團隊來說，這個置換的價值是明確的。

對於已有深厚 ESLint 配置的團隊，不需要急著遷移。但 Biome 的出現，至少讓你知道「有一個更簡單的選項存在」。

---

*## 延伸閱讀

• VS Code 2026：AI 優先的開發體驗 — AI 輔助的程式碼工具
• Rollup 與 Rolldown — Rust bundler 的崛起

本文是「2026 前端工具演進」系列文章之一。*