こんにちは。開発現場の最前線で、数多のプロジェクトの「技術的負債」を焼き払い、生産性を最大化してきたアーキテクトです。
今日は、現代のJavaScript/TypeScript開発において避けては通れない「ESLint」と「Prettier」の、一段上の設定術をお話しします。
多くの現場で、`eslint.config.js` は「とりあえずコピペしてきた呪文」になりがちです。しかし、設定ファイルが「ただの動くJS」である限り、プロパティ名を打ち間違えたり、誤った設定値を渡しても、誰も教えてくれません。
「設定ファイル自体をTypeScriptの型安全な恩恵の中に置く」。これが、大規模開発でバグを未然に防ぎ、チームメンバー全員の脳内負荷を劇的に下げる鍵です。さあ、深淵を覗きに行きましょう。
—
1. なぜ「設定ファイルを型安全にする」必要があるのか？
これまでのESLintは、設定の誤りを実行するまで気づけませんでした。「`rules`のスペルを間違えた」「プラグインのオプション構造が違う」といったミスで、CIが落ちたり、期待通りにLintが動かなかった経験はありませんか？
`eslint.config.js` を `eslint.config.ts` に昇華させることで、IDE（VS Codeなど）があなたの書くコードをリアルタイムで解析し、「その設定項目は存在しません」「型が一致しません」と教えてくれるようになります。これは、「設定ミス」という、最もデバッグが困難な無駄な時間を根絶するための投資なのです。
—
2. 最強のセットアップ：TypeScriptでESLint設定を組む
まずは、ESLintの最新仕様である「Flat Config」を、型安全に構築するステップを踏みます。
インストール
最小構成で、型定義を含めてインストールします。
必要なパッケージをインストール
@eslint/js は標準の推奨ルール、typescript-eslint はTSの解析に不可欠です
npm install -D eslint @eslint/js typescript typescript-eslint
`eslint.config.ts` の作成
ここで重要なテクニックを紹介します。`eslint.config.js` ではなく、TypeScriptで記述し、`tsx` を介して実行させる手法です。
// eslint.config.ts
import eslint from ‘@eslint/js’;
import tseslint from ‘typescript-eslint’;
// tseslint.config を使うことで、設定全体を型安全な関数でラップします
export default tseslint.config(
// 1. ESLint標準の推奨ルールを適用
eslint.configs.recommended,
// 2. TypeScript用の推奨ルールを適用
…tseslint.configs.recommended,
// 3. プロジェクト固有のカスタマイズ
{
rules: {
// 型定義によるオートコンプリートが効くので、設定ミスがゼロになります
‘@typescript-eslint/no-explicit-any’: ‘error’,
‘no-console’: ‘warn’,
},
}
);
実行の仕組み
ESLintは標準では `.ts` を直接読めません。しかし、`tsx` を使うと非常にスマートに解決できます。`package.json` を以下のように書き換えてください。
{
“scripts”: {
// ESLintコマンド実行時に –config で TypeScriptファイルを指定
// tsx を噛ませることで、実行時に即時コンパイルされ、型チェックが効いた状態で読み込まれます
“lint”: “eslint . –config eslint.config.ts”
}
}
—
3. なぜこれで「毎日のコーディングが楽」になるのか？
このセットアップの真髄は、「IDEとの共鳴」にあります。
あなたが `eslint.config.ts` を書いているとき、VS Codeは `typescript-eslint` が提供する型定義を読み込みます。
- `rules` の中に存在しないルールを書こうとすると、波線で警告が出る。
- 設定値の候補がインテリセンスで表示される。
- チームに新しいメンバーが入ったとき、設定が「型」というドキュメントによって自己説明的になる。
これらは、マニュアルを読み込むよりも遥かに速く、そして確実に「正しい設定」へと導いてくれます。
—
4. Prettierとの統合：衝突を完全に排除する
よくある罠が「ESLintとPrettierのルール競合」です。これを防ぐには、「フォーマット関連のルールは全てPrettierに任せ、ESLintはコード品質（ロジック）に集中させる」のが現代の最適解です。
npm install -D eslint-config-prettier
これを `eslint.config.ts` に追加するだけで、Prettierと競合する可能性のあるESLintのルールが自動的に無効化されます。
import eslintConfigPrettier from ‘eslint-config-prettier’;
export default tseslint.config(
// …他の設定
eslintConfigPrettier // 最後にこれを追加することで、競合ルールを上書き無効化する
);
—
アーキテクトからのアドバイス
設定ファイルを「ただの設定」と捉えるか、「コードベースを守るための防波堤」と捉えるかで、エンジニアとしての成長速度は大きく変わります。
最初は少し面倒に感じるかもしれません。しかし、一度この「型安全な設定」を構築してしまえば、プロジェクトがどれだけ巨大化しても、設定ミスによる謎の挙動に悩まされることはなくなります。
「コードの品質は、ツールを定義する品質から始まる」。
この哲学を持って、ぜひ今日からあなたのプロジェクトを「鉄壁」にしてください。何か詰まったら、いつでも聞いてくださいね。応援しています。