TypeScriptの「型」をただの飾りで終わらせない：ESLintで実現する、堅牢な開発環境の構築術
こんにちは。現場で泥臭くコードと格闘し、時に洗練された設計に酔いしれるエンジニアの皆さん。
多くのプロジェクトで「TypeScriptを使っているから安全だ」という言葉を耳にします。しかし、現場のコードを覗いてみると、至るところに `any` が散らばり、型定義が形骸化している場面に遭遇しませんか？
TypeScriptは本来、「型による静的解析」が魂です。しかし、IDEの補完に頼るだけではその恩恵の半分も受けていません。今回は、`@typescript-eslint` を駆使し、「人間が犯しやすいミスを、機械が先回りしてシャットアウトする」ための最高峰の設定術をお伝えします。
これをマスターすれば、明日からのあなたのコーディングは「デバッグに追われる日々」から「設計を愉しむ日々」へと劇的に変わります。
—
1. なぜ「静的解析」をここまで厳しくするのか？
そもそも、なぜわざわざESLintで型チェックを強化するのか。それは「実行時のエラーをコンパイル（ビルド）時、あるいはエディタ上での入力時に全て撲滅するため」です。
TypeScriptのコンパイラ（`tsc`）は強力ですが、ESLintと組み合わせることで、「コードの質」や「意図せぬバグの温床となる記述」をより厳格に排除できます。特にチーム開発では、このルールが「共通言語」となり、レビューコストを劇的に下げてくれるのです。
—
2. 構築：最強の型安全環境をセットアップする
まずは、最低限かつ最強の構成を作り上げます。プロジェクトのルートで以下のコマンドを叩いてください。
必要なパッケージを一括インストール
npm install –save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin
なぜこの構成なのか？
- `@typescript-eslint/parser`: ESLintがTypeScriptのコードを読み解くための「翻訳機」です。これがなければ、ESLintはTSの構文を理解できません。
- `@typescript-eslint/eslint-plugin`: TypeScript特有のコード品質を担保するための「チェックリスト」が詰まっています。
—
3. 核心：`.eslintrc.js` の設計思想
ただ設定をコピペするのではなく、「なぜこの設定が重要なのか」を理解してください。
// .eslintrc.js
module.exports = {
parser: ‘@typescript-eslint/parser’, // TSをパースするために必須
plugins: [‘@typescript-eslint’],
extends: [
‘eslint:recommended’,
‘plugin:@typescript-eslint/recommended’, // 推奨設定をベースに
],
rules: {
// 1. anyの利用を禁止する (型安全性の根幹)
‘@typescript-eslint/no-explicit-any’: ‘error’,
// 2. 明示的な戻り値の型を強制 (コードの可読性と意図の明確化)
‘@typescript-eslint/explicit-function-return-type’: ‘error’,
// 3. 未使用の変数をエラーにする (デッドコードの撲滅)
‘@typescript-eslint/no-unused-vars’: [‘error’, { argsIgnorePattern: ‘^_’ }],
},
};
この設定が現場にもたらす「震えるほどの利益」
1. `no-explicit-any`: これを `error` にするだけで、プロジェクトから「思考停止の逃げ道」が消滅します。エンジニアは「どうすれば型がつくか」を考えざるを得なくなり、結果として設計が洗練されます。
2. `explicit-function-return-type`: 関数が何を返すのかを明示させることで、外部ライブラリとの連携時に発生する「想定外のundefined」などを未然に防ぎます。
—
4. HelloWorld的な動作確認：型チェックの力を体感する
設定が終わったら、わざとダメなコードを書いてみましょう。`test.ts` を作成し、以下を記述してください。
// 悪い例: anyを使っている、戻り値がない
function getUserId(id: any) {
return id.toString();
}
const user = getUserId(123);
このファイルを保存した瞬間、VSCode上の `any` に赤波線が引かれ、IDEがこう囁きます。
> Unexpected any. Specify a different type.
これが「静的解析の洗礼」です。これを修正するプロセスこそが、あなたのエンジニアとしての筋力を鍛えるトレーニングになります。
—
5. 次のステージへ：Prettierとの共存
最後に、忘れてはいけないのが「整形」です。ESLintは「コードの正しさ」を、Prettierは「コードの美しさ」を担保します。
npm install –save-dev eslint-config-prettier eslint-plugin-prettier
`.eslintrc.js` の `extends` に `’plugin:prettier/recommended’` を追加するだけで、「動くし、美しい」コードがあなたの手元から溢れ出すようになります。
—
まとめ：ツールを「躾（しつけ）」る側に回ろう
開発ツールは、ただ使うものではありません。「自分の思考を補助し、ミスを肩代わりしてくれる相棒」として躾けるものです。
今回紹介したESLintの設定は、最初は厳しく感じるかもしれません。しかし、数週間もすれば「`any` が書けないこと」が当たり前になり、型定義を記述することに快感を覚えるようになるはずです。
さあ、今すぐプロジェクトに導入して、静的解析が導く「エラーゼロの世界」を体感してください。あなたのコードは、もっと安全に、もっと美しくなれるはずです。