言語 / 開発ツール · 最終検証 2026-05-10 · @biomejs/biome 2.4.x · 初公開 2026-05-09

Biome v2 で TypeScript / Astro / MDX を一本化する

Biome v2 系で lint + format を一本化する時の biome.json 設定、ESLint からの移行ポイント、Astro / MDX / monorepo での設定差分、よく詰まる点を実装観点で整理。

biome lint format typescript

検証日: 2026-05-09

使用バージョン: @biomejs/biome@2.4.x

環境: Node 22.12 / pnpm 10 / TypeScript 6.0

想定読者: ESLint + Prettier の組み合わせから移行を検討中の人 / 新規プロジェクトで lint + format を一本化したい人

Biome は Rust 実装の lint + format 統合ツール。v2 系で実用的な対応範囲が広がり、ESLint + Prettier の組み合わせから乗り換えても困らない段階に入りました。

なぜ Biome を試したか

ESLint v9 + Prettier v3 の組み合わせは、設定ファイルだけで 4 つ(.eslintrc / eslint.config.js / .prettierrc / .prettierignore)になりがちで、初期セットアップに毎回時間がかかります。 Biome は 1 ファイル(biome.json)で完結 + Rust 実装で 10〜100 倍速い + 公式が型 / lint / format を一手に責任を持つ、という性質が魅力。

ESLint + Prettier から Biome v2 への統合 (クリックで拡大)

最小設定(Astro 6.x + TypeScript 6 プロジェクト)

biome.json の最小構成例:

{
  "$schema": "https://biomejs.dev/schemas/2.4.8/schema.json",
  "vcs": { "enabled": true, "clientKind": "git", "useIgnoreFile": true },
  "files": {
    "includes": ["**/*.{ts,tsx,js,jsx,astro,mjs,cjs,json}"],
    "experimentalScannerIgnores": ["dist", ".astro", "node_modules"]
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "style": { "useImportType": "warn" }
    }
  },
  "javascript": {
    "formatter": { "quoteStyle": "double", "semicolons": "always" }
  }
}

これだけで、TypeScript / JavaScript / JSX / Astro frontmatter / JSON が整形 + lint されます。

lint + format が同じ AST を共有する意味

ESLint + Prettier では「parse 2 回 → lint AST と format AST が違う」ので競合する。Biome は 1 回 parse して同じ AST を lint/format で共有する:

Biome の単一 AST 設計 — parse コストを 1 回に圧縮 + lint と format の規約衝突を構造的に防ぐ (クリックで拡大)

これが「ESLint + Prettier より速い」「規約が衝突しない」の根拠。

まず詰まる 3 点

.astro ファイル内 frontmatter は対応するが、template 部分は限定対応(v2 系で改善中、<style> 内の CSS は別ツールが必要)
MDX の lint / format は別途必要 — Biome は .mdx を直接サポートしないので、prettier-plugin-astro / prettier の併用 or 諦める
useIgnoreFile: true にすると .gitignore を自動で読むが、.biomeignore を別途持ちたい場合は false にする必要

ESLint からの移行で詰まる差分

ルール体系が違う

ESLint の人気ルールに 1:1 対応はしません(設計が違う)。代わりに Biome 独自の lint rule セット(recommended で 200+ ルール)を使います。

ESLint ルール	Biome での対応
`no-unused-vars`	`correctness/noUnusedVariables`
`eqeqeq`	`suspicious/noDoubleEquals`
`prefer-const`	`style/useConst`
`import/no-duplicates`	`correctness/noDuplicateImports`
`react/jsx-key`	`correctness/useJsxKeyInIterable`
`@typescript-eslint/consistent-type-imports`	`style/useImportType`

ESLint で大量にカスタマイズしていた場合、全ルールが Biome に存在するわけではない。乗り換え時にいくつか諦める or 別ツール併用になります。

Prettier との format 互換性

Biome の format は Prettier と “ほぼ” 同じ(95% 互換を目標にしている)が、完全一致ではありません。

主な差分:

配列 / オブジェクトの改行判断
アロー関数の括弧
JSX 属性の改行

新規プロジェクトなら気にする必要なし。既存プロジェクトを乗り換える場合は、初回の biome check --write で大量の差分が出る可能性があるので、1 PR で format 差分を集中的に commit するのが安全。

scripts セクションの典型

package.json の scripts に lint / lint:fix / format / CI 用の lint:ci を分けて置く:

{
  "scripts": {
    "lint": "biome check .",
    "lint:fix": "biome check --write .",
    "format": "biome format --write .",
    "lint:ci": "biome check --error-on-warnings ."
  }
}

ローカル: pnpm lint:fix で自動修正、CI: pnpm lint:ci で warning も error 扱いに。

monorepo での使い方

biome.json は subworkspace ごとに置く か root に 1 つだけ置く かを選べます。

monorepo/
├── biome.json            # ← root 共通設定
├── packages/foo/
│   └── biome.json        # ← package 個別オーバーライド(任意)
└── packages/bar/

子の biome.json は親をベースに merge されます(extends 指定で明示も可能)。

{
  "extends": ["../../biome.json"],
  "files": { "includes": ["src/**"] }
}

VSCode 統合

Biome 公式拡張(biomejs.biome)を入れて、settings.json に:

{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "quickfix.biome": "explicit",
    "source.organizeImports.biome": "explicit"
  }
}

これで保存時に format + lint 自動修正 + import 整理。

評価

観点	評価	コメント
速度	◎	ESLint + Prettier 比で 10〜100 倍
設定の手軽さ	◎	`biome.json` 1 つで完結
ルール網羅	○	recommended で 200+、ESLint 独自ルールには未追従の物あり
Astro / MDX 対応	△	Astro frontmatter は OK、MDX 直接対応はまだ
エコシステム	○	VSCode / GitHub Action 公式提供あり

向く / 向かないケース

向く: 新規プロジェクト、ESLint カスタマイズが少ないプロジェクト、CI 速度を重視する場合
向かない: ESLint 独自プラグインを多用しているプロジェクト(eslint-plugin-jest / eslint-plugin-testing-library など、Biome に対応物がないものを多用している場合)
向かない: .mdx の lint / format が必須要件の場合(Biome 単独では不十分、別ツールと併用)