Linter

Biomeのリンタはコードを静的に分析し、一般的なエラーを見つけて修正し、より優れた最新のコードを書くのに役立ちます。複数の言語をサポートし、全部で 449個のルール を提供しています。

CLIを使用してBiomeリンタをすぐに試すことができます。次のコマンドは、プロジェクトのルートからすべてのファイルに対してリンタを実行します：

1
npx @biomejs/biome lint

1
pnpm exec biome lint

1
bunx --bun biome lint

1
deno run -A npm:@biomejs/biome lint

1
yarn exec biome lint

または、1つまたは複数のフォルダを指定できます。たとえば ./src と ./public です：

1
npx @biomejs/biome lint ./src ./public

1
pnpm exec biome lint ./src ./public

1
bunx --bun biome lint ./src ./public

1
deno run -A npm:@biomejs/biome lint ./src ./public

1
yarn exec biome lint ./src ./public

このコマンドはファイルとディレクトリのリストを受け入れます。

パラメータとしてglobを渡すと、シェルがそれを展開します。BiomeはGlobをサポートしていません。展開の結果はシェルによって異なります。たとえば、一部のシェルでは、次のコマンドで再帰的なglob ** や代替 {} をサポートしていません：

1
biome lint ./src/**/*.test.{js,ts}

シェル展開にはパフォーマンスコストがあり、コマンドに渡すことができるファイル数にも制限があります。

globの使用は推奨されません。代わりに includes 設定を使用してください。

利用可能なすべてのオプションの詳細については、CLIリファレンスを確認してください。

ルール

リンタはルールに整理されています。ルールはコードスタイルを強制または拒否したり、バグにつながる可能性のあるものの使用などを目的としています。一般的に、ルールは他のルールと競合してはいけません（特に指示がない限り）。 Biomeのルールには命名規則があります。use* で始まるルールは何かを強制/提案することを目的としており、no* で始まるルールは何かを拒否することを目的としています。ルールがその概念の違反に遭遇すると、診断を出力します。

たとえば、noDebugger はJavaScriptコードでの debugger ステートメントの使用を拒否し、見つけた場合に診断を出力します。

Biomeリンタには言語に基づいて異なる推奨ルールのセットが付属しており、lint または check コマンドを実行する際にデフォルトのBiome設定（または設定なし）を利用すると、デフォルトで有効になります：

1
biome lint
2
biome check

各リントルールにはデフォルトの重大度があり、ルールのドキュメントを読むことで詳細を学ぶことができます。

ルールはグループに分けられています。たとえば、noDebugger ルールは suspicious グループの一部です。

Biomeは言語に依存しないルールをサポートしています。これらは複数の言語で機能するルールで、たとえば noUselessEscapeInString はJavaScriptとCSSの両方で無駄なエスケープシーケンスを報告できます。

他のリンタとは異なり、Biomeはコードフォーマットをチェックするルールを提供していません。Biomeフォーマッタがすべてのフォーマット決定を処理することを意図しています。

多くのルールは自動的に適用できるコード修正を提供しています。

Biomeは安全な修正と安全でない修正を区別しており、これらは若干異なる動作をします。主な違いとして、安全な修正はファイルの保存時に自動的に適用できますが、安全でない修正はできません。ただし、ユーザーはどの修正を安全と見なすかを上書きできます。

Biomeのリンタには自動的に有効になる推奨ルールのセットが付属しており、言語によって異なります。

安全な修正 (Safe fixes)

安全な修正は、コードのセマンティクスを変更しないことが保証されています。明示的なレビューなしに適用できます。

CLIから 安全な修正 を適用するには、--write を使用します：

1
npx @biomejs/biome lint --write ./src

1
pnpm exec biome lint --write ./src

1
bunx --bun biome lint --write ./src

1
deno run -A npm:@biomejs/biome lint --write ./src

1
yarn exec biome lint --write ./src

LSP互換エディタから、コードアクション source.fixAll.biome を使用して安全な修正を保存時に適用できます。適用方法については、拡張機能のドキュメントを参照してください。

安全でない修正 (Unsafe fixes)

安全でない修正は、プログラムのセマンティクスを変更する可能性があります。したがって、変更を手動でレビューすることをお勧めします。

CLIから 安全な修正 と 安全でない修正 の両方を適用するには、--write --unsafe を使用します：

1
npx @biomejs/biome lint --write --unsafe ./src

1
pnpm exec biome lint --write --unsafe ./src

1
bunx --bun biome lint --write --unsafe ./src

1
deno run -A npm:@biomejs/biome lint --write --unsafe ./src

1
yarn exec biome lint --write --unsafe ./src

LSP互換エディタから、保存時にすべての安全でない修正を適用することはできません。保存時にコードのセマンティクスを変更することは望ましくありません。ただし、個々のコード修正を確認して適用することを選択できます。

ルールの基本原則

Biomeでは、ルールは情報を提供し、ルールがトリガーされた理由をユーザーに説明し、エラーを修正するために何をすべきかを伝える必要があります。ルールは次の基本原則に従う必要があります：

ユーザーにエラーを説明します。一般的に、これは診断のメッセージです。
ユーザーになぜエラーがトリガーされたかを説明します。一般的に、これは追加のノートで実装されます。
ユーザーに何をすべきかを伝えます。一般的に、これはコードアクションを使用して実装されます。コードアクションが適用できない場合、ノートでユーザーにエラーを修正するために何をすべきかを伝える必要があります。

ルールがこれらの基本原則に従っていないと思う場合は、イシューを作成してください。

リンタの設定

多くの場合、個人のニーズや組織/プロジェクトのニーズに基づいてリンタを変更したいと思うでしょう。 Biomeではリンタをカスタマイズでき、このセクションではその方法を学びます。

ルールを無効にする

ルールを off で無効にすることができます。

次の設定は、推奨ルール noDebugger を無効にします：

1
{
2
  "linter": {
3
    "rules": {
4
      "suspicious": {
5
        "noDebugger": "off"
6
      }
7
    }
8
  }
9
}

推奨ルールを無効にする

簡単な設定で推奨ルールを無効にできます。これは、いくつかのルールのみを有効にしたい場合に便利です。

1
{
2
  "linter": {
3
    "rules": {
4
      "recommended": false
5
    }
6
  }
7
}

ルールの重大度を変更する

Biomeのリントルールには独自のデフォルトの重大度が設定されています。デフォルトの重大度を適用したい場合は、"on" 設定を使用できます。

たとえば、noShoutyConstants はデフォルトで推奨されておらず、トリガーされると重大度が情報の診断を出力します。

このデフォルトに満足していて使用したい場合、設定は次のようになります：

1
{
2
  "linter": {
3
    "rules": {
4
      "style": {
5
        "noShoutyConstants": "on"
6
      }
7
    }
8
  }
9
}

デフォルトの重大度に満足していない場合、Biomeでは "error"、"warn"、"info" で変更できます。

"error" の診断は常にCLIをエラーコードで終了させます。この重大度は、特定のルールに属する違反がある場合にCIをブロックしたい場合に役立ちます。

"warn" はエラーと似ていますが、--error-on-warnings フラグが使用されない限り、CLIをエラーコードで終了させません。warn 重大度の可能な使用法は、特定のルールに対する診断がまだある間にCIをパスさせたい場合です。

"info" は、--error-on-warnings が渡された場合でも、CLIの終了ステータスコードに影響しません。

グループの重大度を変更する

さらに、グループレベルでリントルールの重大度を制御できます。これにより、グループに属するすべてのルールの診断重大度を制御できます。

たとえば、プロジェクトはバックエンドで実行されるコードであるため a11y ルールの使用を必要としない場合、アクセシビリティは懸念事項ではありません。次の例は、a11y グループに属するすべてのルールを無効にします：

1
{
2
  "linter": {
3
    "rules": {
4
      "a11y": "off"
5
    }
6
  }
7
}

コード修正を設定する

上記で説明したように、ルールは安全または安全でないコード修正を出力する場合があります。Biomeでは、安全な修正を安全でないものとして扱うように設定でき、その逆も可能です。コード修正を完全に無効にすることもできます。

コード修正は fix オプションを使用して設定できます。次の3つの値のいずれかを持つことができます：

none: ルールはコード修正を出力しません
safe: ルールは安全な修正を出力します
unsafe: ルールは安全でない修正を出力します

1
{
2
  "linter": {
3
    "rules": {
4
      "correctness": {
5
        "noUnusedVariables": {
6
          "level": "error",
7
          "fix": "none" // noUnusedVariablesにはコード修正が提案されません
8
        }
9
      },
10
      "style": {
11
        "useConst": {
12
          "level": "warn",
13
          "fix": "unsafe" // useConstのコード修正は安全でないと見なされます
14
        },
15
        "useTemplate": {
16
          "level": "warn",
17
          "fix": "safe" // useTemplateのコード修正は安全と見なされます
18
        }
19
      }
20
    }
21
  }
22
}

ルールまたはグループをスキップする

biome lint コマンドは、個々のルールまたはルールのグループを無効にできる --skip オプションを受け入れます。

たとえば、次のコマンドは style グループに属するすべてのルールと suspicious/noExplicitAny ルールをスキップします：

1
biome lint --skip=style --skip=suspicious/noExplicitAny

ルールまたはグループのみを実行する

biome lint コマンドは、個々のルールまたはルールのグループを実行できる --only オプションを受け入れます。

たとえば、次のコマンドは、style/useNamingConvention ルール、style/noInferrableTypes ルール、および a11y に属するルールのみを実行します。ルールが設定で無効になっている場合、推奨ルールの重大度レベルは error に設定され、それ以外の場合は warn に設定されます。

1
biome lint --only=style/useNamingConvention --only=style/noInferrableTypes --only=a11y

ルールオプション

いくつかのルールにはオプションがあります。ルールの値を異なる形式にすることで設定できます。

level は診断の重大度を示します
options はルールによって異なります

1
{
2
  "linter": {
3
    "rules": {
4
      "style": {
5
        "useNamingConvention": {
6
          "level": "error",
7
          "options": {
8
            "strictCase": false
9
          }
10
        }
11
      }
12
    }
13
  }
14
}

ドメイン

ドメインは、ルールを技術、つまり_ドメイン_でグループ化できるBiomeの機能です。ドメインの例には、"react"、"solid"、"test" があります。

ドメインは：

独自の推奨ルールのセットを持ちます。
package.json ファイルで特定の依存関係を検出すると、Biomeが自動的に有効にできます。
追加のグローバル変数を定義できます。

Biomeのリンタは、最も近い package.json で特定の依存関係を検出すると、ドメインに属するルールを自動的に有効にします。たとえば、mocha 依存関係が検出された場合、Biomeは test ドメインの推奨ルールを有効にします。

ただし、package.json がない場合、またはデフォルトの設定が適用されない場合は、設定を介してドメインを有効にできます：

1
{
2
  "linter": {
3
    "domains": {
4
      "test": "recommended"
5
    }
6
  }
7
}

さらに、"all" 値を使用して、ドメインに属するすべてのルールを有効にできます：

1
{
2
  "linter": {
3
    "domains": {
4
      "test": "all"
5
    }
6
  }
7
}

ルールやグループと同様に、"off" 値でドメインに属するルールを無効にすることもできます：

1
{
2
  "linter": {
3
    "domains": {
4
      "test": "off"
5
    }
6
  }
7
}

各ドメインの詳細については、適切なページを参照してください。

リントルールを抑制する

抑制のページを参照してください。

エディタとの統合

LSP互換エディタとのファーストクラスの統合により、Biomeの動作の特定の側面を設定できます。

Biomeによって違反が検出されると、診断が任意の数のコードアクションとともにエディタに送信されます。これらのアクションは診断に対処することを目的としています。これらのアクションは：

可能なコード修正。このコード修正は、ルールがコード修正を持つ場合にのみ表示されます。コード修正は、安全か安全でないかに関係なく表示されます。
インライン抑制で診断を抑制します。
トップレベル抑制で診断を抑制します。

通常、カーソルを診断の範囲に配置して特定のショートカット（エディタによって異なります）を入力すると、可能なコードアクションを含むツールチップが表示されます。

デフォルトでは、これらのアクションは常にエディタによって表示されますが、オプトアウトすることができます。

保存時にアクションを適用する

source.fixAll.biome コードアクションを使用して、保存時にすべての安全な修正を適用するようBiomeに指示します。

1
{
2
  "editor.codeActionsOnSave": {
3
    "source.fixAll.biome": "explicit",
4
  }
5
}

1
{
2
  "code_actions_on_format": {
3
    "source.fixAll.biome": true,
4
  }
5
}

Use the source action code source.fixAll.biome

エディタの抑制

source.suppressRule.inline.biome を使用して、エディタがインライン抑制コードアクションを表示するかどうかを制御します：

1
{
2
  "editor.codeActionsOnSave": {
3
    "source.suppressRule.inline.biome": "never",
4
  }
5
}

1
{
2
  "code_actions_on_format": {
3
    "source.suppressRule.inline.biome": false,
4
  }
5
}

Use the source action code source.suppressRule.inline.biome

source.suppressRule.topLevel.biome を使用して、エディタがトップレベル抑制コードアクションを表示するかどうかを制御します：

1
{
2
  "editor.codeActionsOnSave": {
3
    "source.suppressRule.topLevel.biome": "never",
4
  }
5
}

1
{
2
  "code_actions_on_format": {
3
    "source.suppressRule.topLevel.biome": false,
4
  }
5
}

Use the source action code source.suppressRule.topLevel.biome

他のリンタからの移行

Biomeのリントルールの多くは、他のリンタに触発されています。 ESLintや typescript-eslint などの他のリンタから移行する場合は、ルールソースのページを確認してください。 ESLintから移行する場合は、専用の移行ガイドがあります。

biome migrate eslint コマンドを使用して、eslint 設定ファイルで定義されたルールを biome.json に移植します：
Terminal window
```
1
biome migrate eslint
```
次のコマンドを使用して、Biomeによってキャッチされる可能性のある新しいルールを抑制してプロジェクトをリントします：
Terminal window
```
1
biome lint --write --unsafe --suppress="移行のために抑制"
```
このコマンドは、Biomeが見つけたすべてのリント違反を、理由 "移行のために抑制" を使用して抑制します。これでリンタはエラーを出さなくなり、後の段階で抑制コメントを削除することができます。

リンタグループ

リンタはルールを グループ に分けます。グループは、ルールが属するある種のカテゴリを提供することを目的としています。この情報は、有効/無効にするルールを選択する際や、開発者が新しいリントルールを作成する際に役立ちます。

Accessibility

アクセシビリティの問題を防ぐことに焦点を当てたルール。

Complexity

単純化できる複雑なコードの検査に焦点を当てたルール。

Correctness

不正確または役に立たないことが保証されているコードを検出するルール。

Nursery

まだ開発中の新しいルール。

Nurseryルールは、まだバグやパフォーマンスの問題がある可能性があるため、安定版では設定による明示的なオプトインが必要です（推奨とマークされている場合でも）。ナイトリービルドではデフォルトで有効になっていますが、不安定であるため、最終的に安定化されたときに推奨されることを意図しているかどうかに応じて、診断重大度はエラーまたは警告に設定される場合があります。Nurseryルールは安定すると他のグループに昇格するか、削除される場合があります。

Performance

コードをより高速に実行するため、または一般的により効率的にするための方法を検出するルール。

Security

潜在的なセキュリティ上の欠陥を検出するルール。

Style

一貫性のある慣用的なコードの書き方を強制するルール。デフォルトでは、これらのルールはエラーではなく警告のみを生成します。

Suspicious

不正確または役に立たない可能性が高いコードを検出するルール。

よくある質問（FAQ）

なぜルールXは安全でない修正を持っているのですか？安全に見えます

Biomeチームが修正を安全でないとマークすることを決定する理由はさまざまですが、ほとんどの場合、次のことに要約されます：

リントルールやコード修正まだ開発中である。
ルールの修正はプログラムのセマンティクスを変更する可能性があるため、ユーザーが修正をオプトインする必要がある。
ルールの修正は、入力中や保存中のDXを悪化させることがある。例として、 noUnusedVariables は未使用の変数の名前に _ を追加します。これは、入力中や保存中のプログラマーのDXを悪化させる可能性があります。この動作は設定で変更できます。

コード修正がこれら3つのガイドラインに従っていない場合、チームがルール修正を安全にすることを忘れた可能性があります。イシューを開くかPRを送信してください！

なぜBiomeリンタはv1と比べて遅いのですか？

Biome v2以降、スキャナーと呼ばれるツールでアーキテクチャを拡張しました。スキャナーは、プロジェクトファイルをクロールし、モジュールグラフや推論された型などの重要な情報を作成する役割を担っています。

このような情報は、noFloatingPromises、noUnresolvedImports、noImportCycles などの一部のルールに必要であり、これらのルールはスキャナーなしに機能しません。一般的に、projectドメインに属するルールの場合です。

スキャナーはオプトインであり、projectドメインに属するルールが有効になっている場合にのみ起動されます。

テストに基づいて、おおよそ次の数値に気づきました：

	Scannerなし	Scannerあり
~2k ファイル	~800ms	~2s
~5k ファイル	~1000ms	~8s

また、チームはこのパフォーマンスへの影響を認識しており、ソフトウェアのこの部分のパフォーマンスを改善することを約束していることも言及する価値があります。

低速化の調査と緩和に関するアドバイスについては、低速化の調査ガイドを参照してください。

メモリや時間に関して異常な数値に気づいた場合は、リポジトリへのリンクを含むイシューをファイルしてください。サポートいたします。

なぜBiomeはそんなに多くのメモリを使用しているのですか？

Biomeを使用するエディタの拡張機能を使用している場合、そのプロセスの1つが大量のメモリを使用していることに気づくかもしれません。

これは通常、projectドメインに属するルールの1つを有効にした場合に発生します。

Biome v2以降、ツールチェーンはTypeScriptを使用して型を推論し、より強力なルールを提供できるようになりました。これを実現するために、Biomeは推移的な依存関係のものを含む node_modules フォルダ内の .d.ts ファイルをスキャンします。

これは愚かなミスのように見えるかもしれませんが、言語の動作方法により、これは意図的です。ライブラリは 依存関係から型をエクスポートできますが、エンドユーザーはそれに依存していない可能性があります。

たとえば、Validator 型をエクスポートするライブラリ @org/foo に依存している可能性がありますが、この Validator はライブラリ @other-org/validator から来ており、これは @org/fooの依存関係です。ただし、ライブラリ @other-org/validator はプロジェクトの直接の依存関係ではありません。

チームは制約を認識しており、時間とリソースをかけてインフラストラクチャの最適化に取り組みます。