fix-ts-errors

TypeScript エラーの修正

型の問題は発生源で修正し、ワークスペースのチェックが 0 で終了するまで繰り返します。回避策は使いません。

ワークフロー

ステップ 1: 対象ファイルの特定

• ユーザーがファイルを指定した場合は、そのファイルを使います。
• ユーザーが「変更されたファイル」と指定した場合は、ステージ済みと未ステージの .ts および .tsx ファイルを対象に git diff --name-only HEAD を実行し、未追跡ファイルについては git ls-files --others --exclude-standard を実行します。
• 指定が不明確な場合は、対象ファイルを尋ねます。

ステップ 2: エラーを発生させる

ワークスペースの型チェックとして、pnpm type-check または turbo type-check、プレーンな TS プロジェクトの場合は bunx tsc --noEmit を実行します。その出力を修正ループの基準にします。

IDE の診断、LSP ツール、または mcp__ide__getDiagnostics は、チェックで既に報告されたエラーの位置を特定するためにのみ使います。IDE の診断はファイル単位であり、ワークスペースのパッケージ境界をまたぐと信頼できないため、範囲を絞る用途に限ります。判断基準にはしません。

ステップ 3: エラーの修正

エラーごとに、該当箇所の前後を読み、根本原因を把握してから、適切で型安全な方法で発生源を修正します。

以下の順序で修正します。不足しているインポートは追加します。型の不一致は、発生源で宣言を修正します。不足しているプロパティは、発生源の型定義に合わせます。null または undefined は、型ガードか早期リターンで絞り込みます。ジェネリック型の問題には、型パラメーターを明示します。

各エラーは、実際の型を使って解消します。不足しているインポートを追加する、ユニオン型を絞り込む、発生源でシグネチャを拡張する、または z.infer でスキーマから型を導出します。as が残るのは、サードパーティの型の問題を明記したコメントがある場合に限ります。

ステップ 4: 再検証

同じワークスペースのチェックを再実行します。0 で終了すれば成功です。

波線が消えたファイルがあっても、成功とは限りません。型を変更すると、そのファイルをインポートしている箇所にも影響するため、ワークスペースの境界まで影響を追います。新たなエラーが見つかった場合は、ステップ 3 に戻ります。

ステップ 5: 回避策の監査

チェックが成功したら、変更行を対象に、as const を除く as アサーション、@ts-ignore、@ts-expect-error、非 null アサーションの 4 種類すべての回避策を grep で検索します。

git diff -U0 HEAD -- '*.ts' '*.tsx' | grep '^+' | grep -E '\bas\b|@ts-ignore|@ts-expect-error|[]A-Za-z0-9_$)][!]([^=]|$)|["'\''"`][!]([^=]|$)' | sed 's/as const/__AS_CONST__/g'
git ls-files --others --exclude-standard -- '*.ts' '*.tsx' | tr '\n' '\0' | xargs -0 grep -nE '\bas\b|@ts-ignore|@ts-expect-error|[]A-Za-z0-9_$)][!]([^=]|$)|["'\''"`][!]([^=]|$)' | sed 's/as const/__AS_CONST__/g'

[!] グループは、後置アサーションに一致します。感嘆符の前に値を表す文字、閉じ引用符、角括弧、または丸括弧があり、その後に等号がない場合です。そのため、value!、value!.x、value![0]、value!()、"value"!、バッククォートで囲んだレシーバーはすべて検出されますが、!=、!==、!ready のような前置否定は検出されません。末尾の sed は行全体を削除するのではなく、as const のイディオムだけをマーカーに置き換えるため、同じ行に併記された回避策も検出できます。唯一の一致が __AS_CONST__ マーカーである行は、対応不要です。

import { x as y } のようなインポートのエイリアスは除外します。それ以外の一致はすべて、推論、絞り込み、型ガード、ジェネリクス、z.infer で導出した型などを使い、適切な型付けによって削除を試みます。削除するたびにチェックを再実行し、エラーが発生した場合はステップ 3 に戻ります。サードパーティライブラリの型の不足など、真に避けられない場合に限り回避策を残せます。その場合は、上流の Issue または型の問題を明記した 1 行のコメントを付ける必要があります。

ステップ 6: 報告

チェックが成功したら、見つかったエラーの数、修正内容、残っている回避策（as キャスト、@ts-ignore、@ts-expect-error、非 null アサーション）を簡潔に報告します。残存項目についてはそれぞれの数と、1 件ごとに 1 行の理由も記載します。目標は 0 件です。

ループの中断

修正と検証を 3 回繰り返してもエラーが残る場合は中断し、根本原因を説明して残りのエラーを示します。問題がファイル自体にあるのか、依存関係にあるのかを提案し、今後の進め方をユーザーに確認します。

重要なルール

• 共有ワークスペースのパッケージに誤った型がある場合は、そのパッケージ内で修正します。修正内容を報告して終了します。
• エラーが生成コードと手書きコードのどちらにあるかを確認します。コード生成の処理が古い場合は、コマンドを提案しますが、実行はしません。