Bun 1.4.3：組み込み型チェッカーbun check、実行前の--checkゲート

ファイル単位の--checkとプロジェクト検査の範囲の違い

ドキュメントは、tsc --noEmit && bun src/index.tsのような2段階構成をbun --check src/index.ts一つに置き換える表を示している。検査と実行の間の隙間を一つのコマンドにまとめた形だ。

ただし範囲は異なる。引数なしのbun checkはtsconfig.jsonのfiles、include、excludeが選ぶファイルを検査するが、ファイルに対する--checkはそのファイルと静的にimportされるファイルだけを見る。

ワーカー（new Worker）、名前を計算するimport()、TypeScriptファイル内のrequire()、コードが起動するプロセス、preloadで先に読み込まれるファイルは--checkの対象外だ。tsconfig.jsonがそれらを含めば、bun checkが対象にする。

package.jsonにcheckスクリプトがあるとbun checkはそのスクリプトを実行し、組み込みチェッカーはbun --checkで選ぶ。

通ったコマンドが実際に検査した範囲

エントリーポイントが通っても、別に起動したワーカーに型エラーが残っていることがある。エントリー検査は有用だが、ワーカーが検査された証拠ではない。

これは速度以前に範囲の問題だ。ソースのサブツリー、生成された型依存、別に実行されるプロセスごとに、どの呼び出しが検査を担うかを名指しすると空白が見えてくる。

適合性テスト100%と公開された不一致

リリースは、TypeScript 7.0.2の適合性テスト51,210件をすべて通過したとしている。

同時に、意図的に設定を誤らせたオープンソース72プロジェクトの比較で1件、strictを切った再実行で12件、オフラインのファジングで191件の不一致を公開した。

相当な互換作業の証拠ではあるが、あらゆるプログラムで同じ診断を保証する証明ではない。本記事ではチェッカーのベンチマークや互換テストを再実行していない。

同じリビジョンで診断を突き合わせるコマンド

現実的な試し方は、既存のプロジェクト全体のCI検査を残したまま、選んだ開発コマンドにだけ--checkを加える方法だ。ドキュメントとリリースノートが示すコマンドは次のとおり。

bun check
bun --check src/index.ts
bun test --check
bun build --check ./src/index.ts --outdir out

リリースノートは、同じプロジェクトでtscとbun checkの出力を比べる手順も示している。

bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txt

使い捨てのブランチに意図的な型エラーを入れ、コマンドが止まるか、別に読み込まれるファイルでも同じかを確かめるのが次の段階に見える。ここで得た結果ではなく、提案する確認である。

checkスクリプトの名前とBunバージョンの混在

ドキュメントは、型チェッカーを持たない旧Bunが"check": "bun check"スクリプトに出会うと、自分自身を際限なく再実行すると警告している。チーム全員がアップグレードしていなければ、スクリプト名をtypecheckにするようドキュメントは案内している。

宣言ファイルの生成は引き続きtscの役割で、エディターも自前のTypeScriptを使い続ける。

--checkの価値は選んだ実行経路を早く止めることにあり、その経路の外のカバレッジは引き続きプロジェクト全体の検査が守る。