tsgolint v7、Goで書かれたtype-aware lintingをリリース

TypeScript向けのtype-aware linting（型情報を使うリンティング）に、Goで書かれた安定版の実装が登場しました。Oxcプロジェクトは2026年7月22日にtsgolint v7.0.2000を発表し、2026年9月11日のInfoQの報道がそれに幅広い注目を集めました。typescript-eslintの61のtype-awareルールのうち59を網羅しています。

この区別は、聞こえる以上に重要です。ほとんどのlintルールは、コードの形を読むだけで済みます。セミコロンの欠落、未使用の変数といったものです。type-awareルールは、ものが実際に何であるかを知る必要があります。Promiseがどこかでawaitされているかを問うことは、型チェッカーに問うことであり、その型チェッカーこそが遅い部分です。

だからこそ、これらのルールにはlintの実行を数分単位にしてしまうという評判があります。tsgolintはそのコストを避けるために型チェッカーを再実装してはいません。typescript-goの上に本物のTypeScriptプログラムを構築します。プロジェクトのGitHub READMEはtypescript-goを「MicrosoftのTypeScript実装」と説明し、コードネームProject CorsaのTypeScript 7を対象としています。

プロジェクト自身の数字が食い違う

ここで報道は気まずくなります。都合のよい方の数字を選ぶのではなく、率直に言っておく価値があります。

Oxcのブログ記事は、12コアのApple M4 Pro上での詳細な計測時間を示し、同等の設定でESLintとtypescript-eslintの組み合わせと比較しています。そこでは12倍から18倍の改善が示されています。microsoft/vscodeは83.2秒から6.96秒へ、microsoft/typescriptは27.2から1.94へ、typeormは13.2から0.75へ、vuejs/coreは12.3から0.95へです。

プロジェクト自身のREADMEは、ベンチマークを別の形でまとめています。同じ四つのリポジトリで22倍から34倍と報告し、このツールは「大規模なリポジトリでESLint + typescript-eslintより20-40倍高速」だと述べています。

どちらの主張も同じプロジェクトから出たもので、同じツールについて、同じ比較に対するものです。InfoQの報道は低い方の範囲を引用しています。この差についての説明を私たちは見ていませんし、どちらの数字も独立に再現されていません。ブログの12-18倍を、計算の過程が見える数字として扱ってください。そして、どちらかを前提に予算を組む前に、自分のリポジトリでベンチマークを取ってください。

ブログは、速さがどこから来るのかは説明しています。「構文だけで答えが出る場合に、高コストな型チェッカーへの問い合わせを避ける高速パス」です。あるルールは「VS Codeで35倍速く」なったと述べています。

バージョン1が存在しなかったプロジェクトのバージョン7

tsgolintは実験的な0.x系から安定版のv7へ一気に飛びました。マーケティング的な飛躍に見えますが、そうではありません。

バージョンは今、組み込んでいるコンパイラに追従します。v7.0.2000のうち7.0.2はTypeScriptのバージョンで、末尾のカウンターはtsgolint自身のパッチ番号です。この番号はTypeScriptのバージョンが動くたびにリセットされます。InfoQはその理由をこう引用しています。「tsgolintは現在、組み込んでいるコンパイラに合わせてバージョン付けされている」。実際の効果として、バージョン文字列を見れば、どの型チェッカーを手にするのかが分かります。

	詳細
安定版リリース	v7.0.2000、2026年7月22日
追従するTypeScript	v7.0.2
実装済みルール	61のうち59、12月のアルファ版の43から増加
最低TypeScriptバージョン	7.0
インストール	pnpm add -D oxlint oxlint-tsgolint@7
実行	pnpm oxlint --type-aware

このコードは、typescript-eslint組織内のプロトタイプとして、コントリビューターのauvred氏が作ったものから始まりました。Oxcのフォークは、その作者の許可を得て開発を引き継いでいます。

開発者にとっての意味

まず確認すべき制約はTypeScript 7です。ここでのtype-aware lintingには7.0以降が必要で、InfoQは、一部のレガシーなtsconfigオプションとTypeScript 6の機能がまだサポートされていないと指摘しています。ビルドがTypeScript 6の上にあるなら、これは計画に入れるべきものであり、今日の午後に導入するものではありません。

すでに7にいるなら、誠実な実験は一回の計測付き実行です。二つのパッケージをインストールし、自分のリポジトリに対してpnpm oxlint --type-awareを走らせ、既存のESLintの呼び出しと比べてください。自分の数字は誰のベンチマーク表よりも価値があります。しかも今回は、公開されている数字同士が一致すらしていないケースです。

欠けている二つのルールは、数が示す以上に重要です。届かなかった二つのうちどちらかが、チームが頼っているルールでないかを確認してください。12倍速く動いても、あなたのバグの種類を捕まえるルールを黙って落とすlintスイートは、悪い取引です。

ここには注目に値する、より広いパターンがあります。速度のために開発者ツールをコンパイル言語で書き直すことは、今年すでに日常的になりました。Debian Code Searchは最後のC依存を捨てて純粋なGoに移り、C版と同等の性能を出しました。moldリンカの作者はC++からRustへの書き直しを進めています。tsgolintが違うのは、難しい部分を書き直さなかった点です。Microsoft自身のコンパイラを組み込み、その周りを最適化しました。これは正しくあるための、はるかに安上がりな方法です。