Biome 完全ガイド【2026年最新・v2.3対応】|ESLint + Prettier を 1 ツールで置換・biome.json・Type Inference・Plugin (GritQL)・Monorepo ネスト設定・Vue/Svelte/Astro 対応・ESLint/Prettier からの移行まで実戦パターンで解説

Biome 完全ガイド【2026年最新・v2.3対応】|ESLint + Prettier を 1 ツールで置換・biome.json・Type Inference・Plugin (GritQL)・Monorepo ネスト設定・Vue/Svelte/Astro 対応・ESLint/Prettier からの移行まで実戦パターンで解説 TypeScript

TypeScript / JavaScript プロジェクトの「ESLint + Prettier + import sort + …」の設定地獄は、2026 年の Biome 2.x で実用的に終わりました。Rust 製の 1 バイナリで Prettier の 25 倍速いフォーマッタESLint の 15 倍速いリンタImport OrganizerCode Actionsをすべて提供し、biome.json 1 ファイルの設定で完結します。

2025 年 3 月の Biome 2.0 で Plugin System(GritQL)・Multi-file Analysis・Type Inference・Monorepo ネスト設定が入り、2026 年 1 月の v2.3 で Vue / Svelte / Astro の実験的サポートが実用域に。月間ダウンロード 1500 万を超え、2026 年は「ESLint / Prettier から Biome へ」の移行が主流になった年です。

この記事では 2026 年 4 月時点の Biome 2.3 系を前提に、セットアップから biome.json 設定、コマンド群、Type Inference による tsc 非依存リント、GritQL プラグイン、Monorepo 設定継承、Vue / Svelte / Astro サポート、ESLint / Prettier からの自動移行、VSCode / GitHub Actions 統合、Bun / Deno との使い分け、落とし穴まで体系的に解説します。

スポンサーリンク

2026 年 4 月時点の Biome バージョン整理

リリース 時期 主なハイライト
Biome 1.0 2023 年 8 月 Rome Tools からのフォーク。ESLint / Prettier を 1 バイナリ化(JS/TS/JSON 対応)
Biome 2.0 2025 年 3 月 Plugin System(GritQL)、Type Inference(tsc 非依存)、Multi-file Analysis、ネスト設定、Import Organizer v2、新 Assist Actions
Biome 2.1〜2.2 2025 年中 ESLint ルール互換性拡大、CSS / GraphQL パーサー改善、Tailwind ユーティリティ認識
Biome 2.3 2026 年 1 月 Vue / Svelte / Astro の実験フルサポート(パース・フォーマット・リント)、HTML フォーマッタ進化、Workspaces 改善
推奨 2026 年 4 月 Biome 2.3 系。新規プロジェクトは最初からこの系列
Biome の正体: 「Prettier の後継フォーマッタ」と「ESLint の後継リンタ」と「eslint-plugin-import の後継 Import Organizer」を Rust で書き直し、1 バイナリに統合したツールチェーンです。設定は biome.json 1 枚、起動は数ミリ秒、型情報もプラグインなしで扱える。「Linter / Formatter / Import Sorter を別々に設定していた時代」の終わりを告げる存在です。

インストールと初期セットアップ

Biome の導入(npm / pnpm / bun / deno)
# npm / pnpm / yarn いずれでも可
npm install --save-dev --save-exact @biomejs/biome

# Bun
bun add -d --exact @biomejs/biome

# Deno(dlx スタイル)
deno run -A npm:@biomejs/biome init

# ※ --save-exact は必須級。パッチでもフォーマット出力が変わるため、
# プロジェクトメンバーで同一バージョンを固定するのが鉄則
初期設定ファイルの生成
# biome.json を生成(デフォルト推奨値で)
npx @biomejs/biome init

# プロジェクトに biome.json が作成される
# $schema が付くので VSCode 等で補完が効く
biome.json ── 最小構成(v2.3 系)
{
  "$schema": "https://biomejs.dev/schemas/2.3.0/schema.json",
  "vcs": { "enabled": true, "clientKind": "git", "useIgnoreFile": true },
  "files": {
    "includes": ["**/*.{ts,tsx,js,jsx,json,css}"],
    "experimentalScannerIgnores": ["node_modules", "dist", ".next"]
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100,
    "lineEnding": "lf"
  },
  "linter": {
    "enabled": true,
    "rules": { "recommended": true }
  },
  "javascript": {
    "formatter": { "quoteStyle": "double", "semicolons": "always", "trailingCommas": "all" }
  },
  "assist": {
    "enabled": true,
    "actions": { "source": { "organizeImports": "on" } }
  }
}
設定ファイルの $schema: バージョン番号を URL に含む(schemas/2.3.0/schema.json)ため、Biome を上げた時は schema 行も更新します。VSCode の Biome 拡張を入れていれば補完で最新推奨が提案されます。

コマンド ── check / format / lint / ci / migrate

日常的に使う 5 つのコマンド
# ① 一括チェック(lint + format + import sort を全部)
npx biome check .

# ② 自動修正(修正可能なもの)
npx biome check --write .

# ③ unsafe な修正も含めて適用(慎重に)
npx biome check --write --unsafe .

# ④ フォーマットのみ / リントのみ
npx biome format --write .
npx biome lint .

# ⑤ CI 向け(書き換えず、差分があったら fail)
npx biome ci .
npx biome check --reporter=github .     # GitHub Actions の inline annotation

# 特定ファイルだけ
npx biome check src/utils/
npx biome lint src/server.ts

# stdin 経由(エディタ連携などで使う)
echo "const x =1;" | npx biome format --stdin-file-path=x.ts
check がデフォルトで使うコマンド: formatlint を個別に呼ぶより、biome check --write で 1 回走らせるのが定石。import の並び替え、コード整形、軽微なリント修正がまとめて入ります。biome ci は CI 専用で、書き換えを一切行わず差分があれば失敗する想定です。

biome.json の主要セクション

files ── 対象ファイルの制御

includes / experimentalScannerIgnores
{
  "files": {
    "includes": [
      "**/*.{ts,tsx,js,jsx,mjs,cjs}",
      "**/*.{json,jsonc}",
      "**/*.{css,scss}",
      "!**/generated/**"            // 先頭 ! で除外
    ],
    "experimentalScannerIgnores": [
      "node_modules", "dist", "build", ".next", ".turbo", "coverage"
    ],
    "ignoreUnknown": true
  }
}

formatter ── フォーマット規約

言語別の上書きも可能
{
  "formatter": {
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100,
    "lineEnding": "lf",
    "bracketSpacing": true,
    "attributePosition": "auto"
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "double",
      "jsxQuoteStyle": "double",
      "semicolons": "always",
      "trailingCommas": "all",
      "arrowParentheses": "always",
      "bracketSameLine": false
    }
  },
  "json": {
    "formatter": { "indentWidth": 2, "trailingCommas": "none" }
  },
  "css": {
    "formatter": { "quoteStyle": "double" }
  }
}

linter ── ルールと重大度

recommended をベースに個別調整
{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "correctness": {
        "noUnusedVariables": "warn",
        "noUnusedImports": "warn"
      },
      "suspicious": {
        "noExplicitAny": "error",
        "noFloatingPromises": "error"     // Type Inference ルール(後述)
      },
      "style": {
        "useConst": "error",
        "useImportType": "error"
      },
      "nursery": {
        "useSortedClasses": {
          "level": "warn",
          "options": { "attributes": ["className"], "functions": ["clsx", "cn", "tw"] }
        }
      }
    }
  }
}

ESLint + Prettier からの自動移行

既存プロジェクトに Biome を導入する時、migrate サブコマンドが .eslintrc / .prettierrc を読み取って同等の設定を生成してくれます。

3 コマンドで移行完了
# 1) Biome をインストール
npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome init

# 2) ESLint 設定を取り込む
npx @biomejs/biome migrate eslint --write

# 3) Prettier 設定を取り込む
npx @biomejs/biome migrate prettier --write

# 結果: biome.json に ESLint ルール互換と Prettier 整形規則がマージされる

移行後の package.json 整理

scripts の書き換え例
{
  "scripts": {
    "check":  "biome check .",
    "check:fix": "biome check --write .",
    "format": "biome format --write .",
    "lint":   "biome lint .",
    "ci":     "biome ci ."
  },
  "devDependencies": {
    "@biomejs/biome": "2.3.0"
  }
}
古いツールをアンインストール
# 依存を削減(動作確認後)
npm uninstall \
  eslint prettier \
  @typescript-eslint/parser @typescript-eslint/eslint-plugin \
  eslint-config-prettier eslint-plugin-import \
  eslint-plugin-unused-imports eslint-plugin-react-hooks

# .eslintrc.* / .prettierrc.* / .eslintignore / .prettierignore を削除
rm -f .eslintrc.* .prettierrc* .eslintignore .prettierignore
ESLint ルール互換は 100% ではない: Biome は主要な ESLint ルール(typescript-eslint / import / unicorn / react-hooks 系)を多く移植していますが、すべては網羅していませんmigrate eslint 実行時に「対応なし」と表示されるルールは、プロジェクトにとって本当に必要か見直す機会。どうしても必要なルールは GritQL プラグイン(後述)で自作できます。既存の ESLint 設定は ESLint + Prettier 完全セットアップガイド を参考に、差分だけを Biome 側に移植していく形が現実的です。

Type Inference ── tsc 非依存の型認識リント

Biome 2.0 の目玉機能です。TypeScript コンパイラに頼らず、Biome が独自の型推論を実装したことで、従来 typescript-eslint が担っていた「型情報を使うリントルール」を Biome 単体で実行できます。速度は typescript-eslint 比で桁違いに速く、精度も実用レベル(公式で 75% 相当)に達しました。

noFloatingPromises ── await 漏れを検出
// biome.json で "suspicious.noFloatingPromises": "error" を有効化すると

async function saveUser() { return db.user.update({ ... }); }

function handler() {
  saveUser();                // ❌ Biome: Promise を await していない
}

async function ok() {
  await saveUser();          // ✓
  void saveUser();           // ✓ 明示的に無視する場合
}
typescript-eslint との違い: typescript-eslint は tsc のプロジェクト全体型チェック(parserOptions.project)を前提とするため、大規模プロジェクトでリントに数分〜数十分かかるケースがありました。Biome の独自型推論は CLI 起動から数秒で結果が出るため、CI のフィードバックループが劇的に短縮します。

Plugin System ── GritQL でカスタムリント

Biome 2 は GritQL(コード検索・変換専用の宣言的 DSL)で独自リントルールを書けます。ESLint プラグインの TypeScript による実装より、パターンマッチの書きやすさと実行速度で勝ります。

biome.json でプラグインを読み込む
{
  "plugins": ["./plugins/no-console-log.grit"]
}
plugins/no-console-log.grit ── console.log 禁止ルール
// 関数呼び出しのパターン: fn(args)
`$fn($args)` where {
  $fn <: `console.log`,
  register_diagnostic(
    span = $fn,
    message = "console.log はコミットしない。logger.* に置き換えてください。",
    severity = "error"
  )
}
plugins/prefer-object-spread.grit ── Object.assign → spread
`Object.assign($target, $source)` where {
  $target <: `{}`,
  register_diagnostic(
    span = $source,
    message = "オブジェクトリテラルには spread 演算子を使ってください"
  )
}
GritQL の強み: コードの構造(AST / CST)を「コードの見た目そのまま」で書いてマッチさせられます。ESLint ルール自作で必要だった「AST ノードタイプの暗記と visitor パターン」が不要に。社内独自ルールを書くハードルが大幅に下がります。

Multi-file Analysis ── ファイル横断の解析

Biome 2 はプロジェクト全体をインデックス化し、複数ファイルにまたがる情報を使ったリントができます。たとえば「他ファイルでも使われていない export を検出」「循環参照の検出」など、従来 ESLint では eslint-plugin-import のような別プラグインが必要だった処理を単体で実行します。

Multi-file Analysis を有効化
{
  "files": {
    "experimentalScannerIgnores": ["node_modules", "dist"]
  },
  "linter": {
    "rules": {
      "correctness": {
        "noUnusedImports": "error",
        "noUnusedVariables": "error"
      },
      "nursery": {
        "noPrivateImports": "error"   // パッケージ境界を越えた import を禁止
      }
    }
  }
}

Import Organizer v2 ── import 統合とカスタムグループ

基本: 同一モジュールの import を統合
// before
import { useState } from "react";
import { useEffect } from "react";
import { atom } from "jotai";
import { useAtom } from "jotai";

// after(biome check --write で自動整理)
import { useEffect, useState } from "react";
import { atom, useAtom } from "jotai";
グループ順序のカスタマイズ(biome.json)
{
  "assist": {
    "actions": {
      "source": {
        "organizeImports": {
          "level": "on",
          "options": {
            "groups": [
              ":NODE:",                    // node:* モジュール
              ":BUN:",                     // bun:* モジュール
              ":PACKAGE:",                 // 外部 npm / jsr パッケージ
              ":BLANK_LINE:",
              ["@myorg/**", "@/**"],       // 社内パッケージ・パスエイリアス
              ":BLANK_LINE:",
              ["./**", "../**"],           // 相対パス
              ":BLANK_LINE:",
              ":TYPE:"                     // import type のみ末尾に
            ]
          }
        }
      }
    }
  }
}
import type の扱い: useImportType ルール(style.useImportType)を有効化すると、型にしか使わない import を自動で import type { ... } に変換してくれます。Bundler の tree-shaking が効きやすくなり、バンドルサイズが減ります。

Assist Actions ── 自動修正の拡張

オブジェクトキーの自動ソート
// before(useSortedKeys を有効化しているとき)
const config = { z: 1, a: 2, m: 3 };

// after
const config = { a: 2, m: 3, z: 1 };
biome.json ── Assist 個別設定
{
  "assist": {
    "actions": {
      "source": {
        "organizeImports": "on",
        "useSortedKeys": "on",
        "useSortedAttributes": "on"
      }
    }
  }
}

Monorepo ── ネスト設定と継承

Biome 2 は サブディレクトリにも biome.json を置け、親設定を継承できます。モノレポでパッケージごとに異なるルールを適用したい時に使います。

ルート biome.json
{
  "$schema": "https://biomejs.dev/schemas/2.3.0/schema.json",
  "vcs": { "enabled": true, "clientKind": "git", "useIgnoreFile": true },
  "formatter": { "indentStyle": "space", "lineWidth": 100 },
  "linter": { "rules": { "recommended": true } }
}
packages/api/biome.json ── 追加ルールだけ書く
{
  "$schema": "https://biomejs.dev/schemas/2.3.0/schema.json",
  "extends": "//",               // ルートを継承(// はプロジェクトルートを指す)
  "root": false,                 // サブプロジェクトであることを明示
  "linter": {
    "rules": {
      "suspicious": { "noConsoleLog": "error" }
    }
  }
}
Workspace 全体でチェック
# ルートから実行するとネストされた biome.json も尊重される
npx biome check .

# Turborepo / pnpm workspaces からも同じように呼べる
pnpm -r exec biome check .

Vue / Svelte / Astro 対応(v2.3 実験サポート)

Biome 2.3 は Vue .vue・Svelte .svelte・Astro .astro の各 SFC をパース / フォーマット / リント対象にできます(experimental)。

biome.json で各言語を有効化
{
  "files": {
    "includes": [
      "**/*.{ts,tsx,js,jsx,json,css}",
      "**/*.vue",
      "**/*.svelte",
      "**/*.astro"
    ]
  },
  "vue":    { "formatter": { "enabled": true } },
  "svelte": { "formatter": { "enabled": true } },
  "astro":  { "formatter": { "enabled": true } }
}
React / Vue / Svelte / Astro を混在するプロジェクト(Astro の islands)でも 1 ツールで統一: Astro 完全ガイドで触れているように、Astro は React / Vue / Svelte を同一プロジェクトで混在させられます。Biome なら 1 つの biome.json で全言語を管理でき、ESLint + vue-eslint-parser + svelte-eslint-parser + astro-eslint-parser + Prettier の 5 ツール並走地獄から解放されます。

VSCode / JetBrains 連携

VSCode 拡張のインストール
# 拡張 ID: biomejs.biome
code --install-extension biomejs.biome
.vscode/settings.json ── 保存時に自動整形
{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "quickfix.biome":        "explicit",
    "source.organizeImports.biome": "explicit"
  },
  "[typescript]":       { "editor.defaultFormatter": "biomejs.biome" },
  "[typescriptreact]":  { "editor.defaultFormatter": "biomejs.biome" },
  "[javascript]":       { "editor.defaultFormatter": "biomejs.biome" },
  "[javascriptreact]":  { "editor.defaultFormatter": "biomejs.biome" },
  "[json]":             { "editor.defaultFormatter": "biomejs.biome" },
  "[jsonc]":            { "editor.defaultFormatter": "biomejs.biome" }
}
JetBrains(WebStorm / IntelliJ): 公式プラグインが Marketplace にあります(Biome で検索)。設定画面で「Run Biome on save」「Run format」「Apply safe fixes」を有効化すれば VSCode と同じ体験になります。

CI/CD 統合 ── GitHub Actions / pre-commit

.github/workflows/biome.yml
name: Biome
on: [push, pull_request]
jobs:
  biome:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: biomejs/setup-biome@v2
        with: { version: 2.3.0 }
      - run: biome ci --reporter=github .
.github/workflows/biome-npm.yml ── npm 版
name: Biome (npm)
on: [pull_request]
jobs:
  biome:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npx biome ci --reporter=github .
pre-commit hook(husky + lint-staged)
npm install -D husky lint-staged
npx husky init

cat > .husky/pre-commit <<'EOF'
#!/usr/bin/env sh
npx lint-staged
EOF
package.json ── lint-staged 設定
{
  "lint-staged": {
    "*.{ts,tsx,js,jsx,json,jsonc,css}": [
      "biome check --write --no-errors-on-unmatched"
    ]
  }
}

Bun / Deno / pnpm での使い分け

Biome はランタイム非依存なので、どのマネージャー・ランタイムとも組み合わせられます。

ランタイム別の呼び出し方
# npm / pnpm / yarn
npx biome check .
pnpm biome check .

# Bun
bunx biome check .
bun run biome check .

# Deno
deno run -A npm:@biomejs/biome@2.3.0 check .

# Docker(CI での pinning)
docker run --rm -v "$PWD":/src -w /src ghcr.io/biomejs/biome:2.3.0 check .
Bun の組込みフォーマッタとの違い: Bun には bun fmt のような組込みフォーマッタはありません(2026-04 時点)。Deno 2deno fmt / deno lint は Biome とは別実装で、Deno プロジェクト専用に最適化されています。「Node / Bun / Deno が混在するチーム」で規約を揃えるなら Biome が最適解です。

落とし穴と注意点

バージョンピン留めを忘れると CI が揺れる

Biome はパッチでも整形ルールが調整されます(不具合修正含む)。npm install --save-exact または package.json"2.3.0" のように正確なバージョンを固定しないと、PR ごとに整形差分が出て荒れます。CI の setup-biome action も version: 2.3.0 のように明示してください。

ESLint ルールで移行できないものがある

typescript-eslint の特殊ルールや、eslint-plugin-jsx-a11y の一部ルールはまだ Biome に移植されていません。本当に必要なら GritQL プラグインで自作するか、「そのルールは Biome で運用可能な形に落とす」リファクタリングを検討します。

experimentalScannerIgnores vs files.includes の !negation

node_modules をスキャン対象から完全に外す」には experimentalScannerIgnores、「通常の対象内で特定ファイルを除外」には includes の先頭 ! を使います。両者は役割が違うので混同しないように。

Vue / Svelte / Astro サポートは experimental

v2.3 時点で実用域に入っていますが、experimental 扱いなのでバージョン間でフォーマット結果が微妙に変わる可能性があります。影響範囲を絞るために、SFC ファイル専用 CI ジョブを別に切り出しておくと安全です。

Monorepo で設定を継承させたつもりで効かない

サブパッケージの biome.json で親を継承するには "extends": "//" を書く必要があります。書き忘れると「親の設定がまるごと無視され、サブ側だけの設定で動く」ため、意図せずリント緩和が起こります。ネスト設定の場合は必ず動作テストしてください。

useSortedKeys は既存コードで大量差分が出る

Assist の useSortedKeys を新規有効化すると、既存コード全体でオブジェクトのキー順が変わります。PR のレビューが困難になるので、導入コミットを単独で切るか、最初から有効化した状態でプロジェクトを始めます。

よくある質問

QBiome は ESLint や Prettier を完全に置き換えられますか?
A2026 年 4 月時点で「多くのプロジェクトで実用的に置換可能」です。ただし ESLint ルールの 100% 互換ではなく、特殊な typescript-eslint ルールや一部の React / JSX-a11y ルールは未対応です。まずは biome migrate で自動変換を試し、未対応ルールが自分のプロジェクトに必須かを見極めるのが良いアプローチです。既存の ESLint + Prettier の詳細構成は ESLint + Prettier 完全セットアップガイド を参考にしてください。
Q速度はどれくらい違いますか?
A公式ベンチマークでは Prettier の 25 倍・ESLint の 15 倍が提示されています。実プロジェクトでも、CI でフォーマット/リント合計 3 分かかっていたのが 10〜20 秒で終わるような桁違いの変化が多いです。Rust 実装・並列処理・起動コストの低さが効いています。typescript-eslint の型情報必須ルールを使っているプロジェクトでは、Biome 単体で同等機能が Type Inference として動くため CI 時間が劇的に減ります。
QBiome は React / Next.js のプロジェクトで使えますか?
A使えます。React の JSX / TSX は完全対応、React 19 の新記法(Actions、use、ref as prop)も問題なく整形されます。Next.js のプロジェクトでは experimentalScannerIgnores.next を入れ、app/ 以下の page.tsx / layout.tsx を対象にするのが基本構成です。Claude Code × Next.js フルスタック開発完全ガイドの構成とも相性抜群です。
QBiome と Deno の fmt / lint はどう違いますか?
ADeno 2 は組込みの deno fmt / deno lint を提供しますが、Deno プロジェクト専用です。Biome はランタイム非依存で Node / Bun / Deno / pnpm / Docker すべてで同じ設定・同じ結果が得られます。単一ランタイムならそれぞれの組込みツールで十分ですが、複数ランタイム混在や企業標準を揃えたい場合は Biome が選ばれます。
QBiome で typescript-eslint の “@typescript-eslint/no-unsafe-assignment” のような型情報必須ルールは使えますか?
ABiome 2 の Type Inference である程度代替できます。noFloatingPromisesuseAwaitnoMisusedPromises などが該当。ただし typescript-eslint の細粒度ルール(特に unsafe-* 系)の完全互換はまだです。厳密な型リントが重要なライブラリ開発では typescript-eslint と併用する選択もあります。アプリケーションでは Biome 単体で十分なことが多いです。
QBiome の設定をチームで統一するには?
A3 つの方法があります: ① biome.json を Git にコミットして共有(基本)、② 社内パッケージとして @myorg/biome-config を作り "extends" で継承、③ VSCode の拡張推奨(.vscode/extensions.json)で biomejs.biome を入れるよう促す。バージョンピン留め--save-exact)と CI での biome ci を組み合わせれば、ローカルで整形忘れがあっても PR ビルドで検出できます。
QVue / Nuxt や Svelte / SvelteKit プロジェクトで Biome は今使えますか?
A2026 年 4 月時点の v2.3 では experimental サポートの範囲で使えます。Svelte 5 の Runes 構文・Astro のコンポーネントは問題なく認識されます。ただし「完全な ESLint Vue 互換」ではないため、Vue 固有ルール(vue/multi-word-component-names など)が必要なら併用か自作プラグインで対応します。HTML 要素に関わるルールは今後の v2.4+ で強化される予定です。
Qプロジェクト規模が大きい場合、Biome は動きますか?
A10 万ファイル級のモノレポでも数秒〜十数秒で完走する事例が公式でも紹介されています。Multi-file Analysis の scanner は初回だけやや重いですが、インクリメンタル解析が効くため 2 回目以降は高速です。Monorepo なら rootbiome.jsonexperimentalScannerIgnoresnode_modules / dist / .next / .turbo / coverage を入れておくのが鉄則です。

まとめ

  • Biome 2.3 が 2026 年の標準: ESLint + Prettier + Import Organizer を 1 バイナリで置換、Prettier の 25 倍・ESLint の 15 倍の速度
  • 設定は biome.json 1 ファイルbiome check --write で整形 / リント / import 整理が一括
  • Type Inferenceで tsc 非依存の noFloatingPromises 等が動く。CI 時間を桁違いに短縮
  • Plugin System(GritQL)でコードの見た目そのままにカスタムルールが書ける
  • Multi-file Analysisで横断的な未使用検出・パッケージ境界チェックが単体で可能
  • Monorepo ネスト設定: "extends": "//" で親設定を継承しつつサブパッケージ固有ルール
  • Vue / Svelte / Astro の実験サポートで SFC 主体プロジェクトも 1 ツールで統一
  • ESLint / Prettier からの移行は biome migrate eslint/prettier --writeで自動化
  • バージョンピン留めは必須--save-exact + CI の version: 明示で安定運用

既存の ESLint + Prettier 構成の詳細は ESLint + Prettier 完全セットアップガイド、ランタイム選択は Bun 完全ガイドDeno 2 完全ガイド、フレームワーク連携は React 19 完全ガイドAstro 完全ガイドSvelte 5 完全ガイド、バックエンドとの連携は TypeScript × Hono 完全ガイドClaude Code × Supabase フルスタック開発完全ガイド もあわせて、Biome を核に据えた 2026 年型の開発体験を構築してください。