vibatorの設定
参考: npx vibator docs configuration で設定形式を、npx vibator docs rules で各ルールのオプションとデフォルト値を確認できます。
このスキルはワークフローであり、それらのドキュメントが契約（契約書）です。
設定は発見タスクです。適切な設定はプロジェクトが実際に何を含むかによって決まります。最初に調査し、次に記述し、最後に実行します。
基本ルール
- ゲートを通過させるために弱めてはいけません。 ルールを無効にしたり、予算を広げたり、現在失敗しているファイルを除外しても、問題は解決せず隠蔽されるだけです。指摘事項を修正するか、ルールを失敗させたままにしてその旨を伝えてください。唯一の行単位のエスケープは
// vibator-ignore: <理由>であり、理由は必須です。 - デフォルトと異なるものだけを設定してください。 すべてのルールは、設定がまったくなくても、それぞれのデフォルトの重大度で既に実行されます。すべてのデフォルトを再記述する設定は、重要な行を埋もれさせます。
includeとexcludeはルールのデフォルトを置き換えます。 マージはされません。絞り込む前に、引き続き必要なデフォルトをコピーしてください。- 実行を成功させるために
recommended: falseを決して設定しないでください。 これは設定が指定していないすべてのルール（合格しているものを含む）を無効にします。これは意図的な選択を表明するために存在し、その選択は人間の判断です。 - プロジェクトが拡張している設定ファイルは、あなたが編集するものではありません。 プリセットは複数のプロジェクトで共有される標準を定めています。ローカルで差分を設定するか、人間にプリセットの変更を依頼してください。
node_modules以下のファイルを編集して指摘を黙らせないでください。次のインストールで置き換えられます。
手順
-
有効なファイルから開始します。
vibator.jsonが存在しない場合は、npx vibator initを実行します。これにより、エディタにバリデーションを提供する$schema行が書き込まれます。次にnpx vibator listで、すべてのルールとそのデフォルトが表示されます。独自のルールを記述する前に、プロジェクトが既にプリセットを拡張しているか、拡張可能なプリセット（package.json内の@scope/quality形式のパッケージ、または兄弟リポジトリ間で同じ設定が繰り返されているもの）が存在するかを確認してください。拡張することは再記述することよりも優れています。「共有プリセットの上に構築する」を参照してください。 -
設定なしで一度実行します:
npx vibator --reporter json。これにより、どのルールが合格し、どのルールが失敗し、どのルールがオプション不足でクラッシュしたかが表示されます。診断結果の前に数を読んでください。400件の指摘があるルールは、今日400件すべてを修正するのではなく、決定が必要です（手順6を参照）。 -
デフォルトでオフのルールに必要なものを発見します。 各ルールは、プロジェクトの知識なしでは動作できないため、オフになっています。以下を探してください：
locale-parity: ロケールディレクトリ（locales/、i18n/、public/locales/）を見つけます。レイアウト（ロケールごとに1ディレクトリlayout: "directory-per-locale"、ロケールごとに1ファイル"file-per-locale"）と、どのロケールがソースかを確認します。codegen-drift:package.jsonのスクリプトでジェネレータ（db:generate、openapi、graphql-codegen）を読み取り、各ジェネレータが書き込むパスを見つけます。ジェネレータごとにname、command、pathsを持つエントリを1つ設定します。banned-patterns: プロジェクトのレビュー規則（CONTRIBUTING、スタイルドキュメント、繰り返されるレビューコメント）を読み取ります。「決してXをするな」というパターン形のすべてが、組み込みルールと同じくらい注意深く記述された、独自のmessage、expected、fixを持つエントリになります。no-deprecated-apis: tsconfigをリストします。モノレポでは、チェックする必要のある各プロジェクトをoptions.projectsに指定します。
-
既存のプロジェクトドキュメントをルールに結び付けます。
guidelinesを使用します。リポジトリにAGENTS.md、CLAUDE.md、またはルールが実施する標準を述べたスタイルドキュメントがある場合は、それをマッピングします："guidelines": {"AGENTS.md": ["tsdoc-coverage"]}。プロジェクトの標準が、出荷されたガイドラインにコンテキストを追加するのではなく、それを置き換える場合にのみ、ルールごとのdocsフィールドを使用します。 -
分割された標準には配列形式を使用します。 1つのルールを、異なるグロブとオプションで複数回実行できます：
"max-file-size": [ {"include": ["src/**"], "options": {"maxKb": 256}}, {"include": ["assets/**"], "options": {"maxKb": 4096}} ] -
レガシーコードベースには
--changedを使用して段階的に採用し、弱めないでください。 新しい作業はすぐにチェックし（npx vibator --changed、またはCIでプルリクエスト全体の差分に対して--since origin/main）、バックログを減らします。多くの指摘があるルールには、当面warnを使用します。指摘は表示されたままになり、ブロックはしません。offを「後で」の意味で使用しないでください。 -
結果を検証します。
npx vibatorを実行して確認します：有効化されたすべてのルールが実行され（クラッシュしたルールは設定バグであり、メッセージに何が欠けていたかが示されます）、残りの指摘は本物であり、オーバーライドしたものについてはnpx vibator explain <rule>で正しいガイドラインが表示されます。
共有プリセットの上に構築する
extends は . で始まるパス、またはパッケージ指定子を受け取り、それを宣言したファイルを基準に解決されます。後のエントリが前のエントリより優先され、ファイル自身の設定がそれらすべてより優先されます。
{
"extends": ["@acme/quality/vibator.json"],
"rules": { "max-file-size": "warn" }
}
マージはBiomeに従うため、そのスタックのユーザーが期待するように動作します。正しく理解すべき2つの結果：
- ベアな重大度は他のすべてを保持します。
maxKbとincludeを設定したプリセットの上に"max-file-size": "warn"と書くと、重大度のみが変更されます。予算とグロブは継承されます。それらを再記述する必要はなく、再記述することはプロジェクトがプリセットからサイレントに逸脱する方法です。 - 配列は置き換え、連結しません。 継承された
allowまたはpatternsリストに1つのエントリを追加するには、希望するリスト全体を記述します。これは意図的なものであり、継承されたエントリを削除することを可能にします。
差分のみを記述してください。プリセットがすでに述べていることを繰り返す設定は、それに同意しない設定と区別がつかず、次のプリセット更新はコピーしたフィールドに反映されません。
キュレーションされた選択として構築されたプリセットは "recommended": false を設定し、必要なルールをリストします。そのようなプリセットの下では、名前のないルールは実行されないため、ルールが欠けていると結論付ける前にこれを確認してください。
ガイドラインパスも同様に解決されます：プリセットによって指定された docs と guidelines のエントリはプリセットを基準に解決されるため、指摘はプリセットに同梱されているドキュメントを指します。あなた自身のパスは依然としてプロジェクトルートを基準に解決されます。
重大度ポリシー
error: 誤検知がほぼゼロの決定論的ルール。warn: まだ見たことのないコードベースについて間違っている可能性があるルール（env-example-syncはテキストを照合します；prefer-array-methodsは配列とSetを区別できません）、および大きなバックログを持つルールの暫定的な採用。off: 適用されないルール（ロケールがなければlocale-parityはありません）のみに使用し、通過するための方法としては決して使用しません。
よくある間違い
includeを記述してルールのデフォルトの除外（テスト、.d.ts）を失うこと。- ベアな重大度がそれらを破棄するという前提で、重大度オーバーライドの横にプリセットのオプションを再記述すること。そうはならず、コピーはプリセットの追跡を停止します。
- 環境にないサービスやシークレットを必要とするジェネレータで
codegen-driftを有効にすること。ルールはコマンドを実際に実行します。 - すべてのドキュメントを
guidelinesのすべてのルールにマッピングすること。実際にそのルールの標準を述べているドキュメントのみをマッピングしてください。 - 失敗している実行を終了するために、指摘を修正する代わりに設定を編集すること。人間がゲートを要求した場合、それを下げるのは人間だけが決定します。