TypeScriptの型安全性を「最強のガードレール」に変える：ESLint型チェック徹底活用術
多くの現場で、ESLintは「コードの見た目を整えるもの」あるいは「初歩的なミスを防ぐもの」という認識で止まっています。しかし、TypeScriptと`@typescript-eslint`を組み合わせれば、ESLintは単なるリンターではなく、「コンパイル前に型安全性を担保する自動コードレビューアー」へと進化します。
本稿では、チームの生産性を劇的に向上させ、レビューコストを極限まで下げるための「型チェック活用術」を伝授します。
—
1. なぜ「型チェック付きESLint」が必須なのか
TypeScriptを使っていても、`any`の乱用や、`unknown`の放置、そして不適切な型推論により、実行時エラーの温床が生まれることは珍しくありません。
`@typescript-eslint/parser` を利用し、`parserServices` を介して型情報をESLintに渡すことで、「その変数が本当にその型なのか」を静的解析の段階で推論可能になります。これにより、型定義の抜け漏れを人間が指摘する前に、CI/CD上で自動的に弾くことが可能になります。
—
2. 実践的な `.eslintrc.js` ベストプラクティス構成
まず、ただプラグインを入れるだけでなく、以下の設定をベースに「型安全性の強度」を調整してください。
module.exports = {
parser: ‘@typescript-eslint/parser’,
parserOptions: {
project: ‘./tsconfig.json’, // 型情報を解析するために必須
},
plugins: [‘@typescript-eslint’],
rules: {
// 1. anyの利用を明示的に禁止。レビューでの指摘をゼロにする
‘@typescript-eslint/no-explicit-any’: [‘error’, { fixToUnknown: true }],
// 2. 戻り値の型推論に頼らず、明示的な定義を強制する
// 大規模開発では読みやすさと安全性が飛躍的に向上する
‘@typescript-eslint/explicit-function-return-type’: ‘error’,
// 3. 戻り値がない関数への意識付け
‘@typescript-eslint/explicit-module-boundary-types’: ‘error’,
// 4. 不必要な型アサーション(as)を禁止。
// 「as」を使うときは、本当に型を強制する必要があるか再考させる
‘@typescript-eslint/no-unnecessary-type-assertion’: ‘error’,
// 5. Promiseの未処理を検知。非同期処理のバグを撲滅する
‘@typescript-eslint/no-floating-promises’: ‘error’,
}
};
—
3. 開発スピードを最大化する「神プラグイン」と設定
効率的な開発には、ツールを「自分に合わせてカスタマイズする」のが鉄則です。
絶対に入れるべき神プラグイン
- `eslint-plugin-import`: インポート順序を自動整列させ、循環参照を検知します。
- `eslint-plugin-unused-imports`: 使われていないインポート文を自動削除します。これだけで不要なモジュールロードのデバッグ時間が消滅します。
VS Codeの自動化設定（`.vscode/settings.json`）
エンジニアが意識せずともルールが適用される環境を作ってください。
{
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: true, // 保存時にESLintルールを適用
“source.organizeImports”: “never” // importの整理はESLintに任せる
},
“eslint.validate”: [“typescript”, “typescriptreact”]
}
—
4. チーム開発における「共有ルール」の極意
技術的な設定以上に重要なのが、チーム内での「合意形成」です。以下のルールを運用に組み込んでください。
1. 「段階的導入」の戦略
既存の巨大なレガシープロジェクトにいきなり厳格なルールを適用すると、修正地獄に陥ります。まずは `warn` で導入し、CIで警告数を可視化してください。その後、`eslint-plugin-only-warn` を一時的に挟むのも手です。
2. 「型定義漏れ」を許さない習慣
`@typescript-eslint/explicit-function-return-type` を導入すると、最初は面倒に感じるかもしれません。しかし、「型定義を書く時間は、実行時バグを調査する時間の1/100」であることをチームで共有してください。
3. デバッグ効率を爆上げするショートカット
- `Ctrl/Cmd + .` (Quick Fix): ESLintの指摘に対し、このショートカットで「自動修正」を叩き続けるのがプロの作法です。
- `Ctrl/Cmd + Shift + P` -> `ESLint: Restart ESLint Server`: 設定を変更した際、インテリセンスが効かなくなったら即座に再起動。これを知らないエンジニアが一番時間を浪費しています。
—
結論：ツールに管理されるのではなく、ツールを「武器」にせよ
今回紹介した設定は、単なる「厳しさ」の押し売りではありません。型定義を強制することで、「コンパイラがあなたのコードの仕様書を読み込んでくれる」状態を作り出すためのものです。
型エラーや未定義のプロパティアクセスで悩む時間を減らし、本当に解決すべきビジネスロジックやアーキテクチャの設計に脳のリソースを割くこと。それこそが、最強のエンジニアリングチームの条件です。
今日、あなたのプロジェクトの `.eslintrc.js` に `no-floating-promises` を追加することから始めてみてください。その一行が、明日発生するかもしれない深刻なバグを未然に防ぐ、最強の盾になります。