境界の消滅：ESLint v9 “Flat Config” 時代におけるPrettierとの完全分離戦略
エンジニア諸君、コードの「静的解析」と「フォーマット」という二つの概念を、未だに「なんとなく共存」させていないか？
かつて我々は `eslint-config-prettier` に依存し、膨大なルールの競合を力技でねじ伏せてきた。しかし、ESLint v9による「Flat Config (`eslint.config.js`)」への完全移行は、この古い因習を断ち切る絶好の機会だ。本稿では、ライブラリ依存を極限まで減らし、アーキテクチャレベルで「役割」を分離する、真にモダンで高効率な構成術を伝授する。
—
1. なぜ「依存」を排除すべきなのか？
結論から言えば、パフォーマンスと管理コストのためだ。`eslint-config-prettier` は、ESLintの全ルールを精査し、Prettierと競合する可能性のあるものを「すべて無効化」する。これは実行のたびに巨大なルールセットをメモリにロードし、パースするという無駄なオーバーヘッドを生んでいる。
モダンなアーキテクトは、「ESLintはAST（抽象構文木）による構文解析と型安全性の担保」に専念させ、「Prettierは単なる文字列の再構成」として切り離す。この二つをパイプライン上で完全に直交させるのが、真の最適解だ。
—
2. 最小構成：Flat Configによる「完全分離」の設計
`eslint.config.js` を以下のように設計せよ。ここではプラグインを読み込ませるだけで、競合回避のための設定は一切不要だ。
// eslint.config.js
import eslint from ‘@eslint/js’;
import tseslint from ‘typescript-eslint’;
export default tseslint.config(
eslint.configs.recommended,
…tseslint.configs.recommended,
{
// ここには論理的な品質ルールのみを記述する
// フォーマット系のルールは「一切記述しない」
rules: {
‘@typescript-eslint/no-explicit-any’: ‘warn’,
// …他の品質ルール
}
}
);
なぜこれで機能するのか？
答えは簡単だ。「ESLintにフォーマットのルールを一切書かない」からだ。`eslint-config-prettier` を使って「上書き無効化」するのではなく、最初から「品質に関与しないルール」をESLintのロード対象から除外する。これが、設定ファイルが爆発的に肥大化するのを防ぐ唯一の解法である。
—
3. CI/CDパイプラインにおける「超高速」並列実行
多くの現場で、CIのボトルネックは「LintとFormatの連続実行」にある。これを効率化するには、パイプラインのアーキテクチャをこう変えろ。
独自自動化スクリプト：`lint-check.sh`
!/bin/bash
並列実行でCPUリソースを使い切る
lintとformatを非同期で走らせ、どちらか一方でも死ねば即終了する
ESLint: メモリ消費を抑えるため –cache を必ず有効化し、ローカルの .eslintcache を利用
Prettier: –check で変更有無のみを判定し、CIのログを汚さない
npx eslint . –cache &
ESLINT_PID=$!
npx prettier . –check &
PRETTIER_PID=$!
wait $ESLINT_PID
ESLINT_EXIT=$?
wait $PRETTIER_PID
PRETTIER_EXIT=$?
if [ $ESLINT_EXIT -ne 0 ] || [ $PRETTIER_EXIT -ne 0 ]; then
echo “Quality check failed: Formatting or Linting error.”
exit 1
fi
DevOps的知見：
Docker環境では、`–cache-location` をボリュームにマウントさせることで、2回目以降のCI実行速度が劇的に向上する。キャッシュは単なるデータではない、ビルドパイプラインの「記憶」である。これを疎かにするな。
—
4. 内部アーキテクチャとメモリ最適化ハック
大規模プロジェクト（数千ファイル超）において、`eslint` はメモリを大量に消費する。以下のハックを適用せよ。
1. `–max-old-space-size` のチューニング:
`node –max-old-space-size=4096 $(which eslint) .`
デフォルトのメモリ制限は、巨大なTSプロジェクトではしばしばGC（ガベージコレクション）の頻発を招く。明示的にヒープメモリを割り当てることで、解析速度は体感できるレベルで安定する。
2. Lint-stagedの極致:
コミットフックでは、必ず `–changed` だけでなく、プロジェクト全体の依存関係も考慮したインクリメンタルな検証を組むこと。`lint-staged` の設定で `prettier –write` を先に実行し、その後に `eslint –fix` を走らせる順序を遵守せよ。これにより、ESLintが修正したコードに対してPrettierが再度介入する「無限ループ的な競合」を防げる。
—
結論：ツールに支配されるな、制御せよ
今回の設計術の核心は、「ツールを統合するのではなく、責務を分離し、制御すること」にある。`eslint-config-prettier` という魔法の杖に頼る時代は終わった。
我々エキスパートは、ツールの内部構造を理解し、パイプラインの計算資源を最適化し、開発者が「コードを書くこと」以外のストレスを感じない環境を構築しなければならない。今日から君のプロジェクトの `eslint.config.js` を開き、不要な依存を削ぎ落とし、静的解析という名の「品質の門番」を、より研ぎ澄まされたものに再構築したまえ。
それが、伝説的なDevOpsリードとしての、次の一手であるはずだ。