ESLintとPrettierの「デフォルト」を捨てよ——アーキテクトが語る静的解析の最適解
「`eslint:recommended`を入れておけば安心」という認識は、現代の複雑化した大規模開発においては、甘美な罠でしかない。
静的解析ツールは、単なる「文法チェッカー」ではない。それは、チームのコードベースに流れる「言語」を規定し、負債の蓄積を物理的に遮断するためのゲートキーパーだ。本稿では、ありふれた導入ガイドを飛び越え、CI/CDの実行時間からエディタのレスポンスまでを極限まで最適化するための「アーキテクトの作法」を伝授する。
—
1. 「recommended」が抱える隠れたコストと設定の断捨離
`eslint:recommended`は、あくまで「JavaScriptの一般的なバグを避けるための最小セット」だ。しかし、現代のReactやNext.js開発において、これらを盲目的に導入すると、不要なルールの衝突や、無駄なAST（抽象構文木）解析によるCIのビルド時間増大を招く。
効率的な設定の哲学
ルール定義は「継承」を最小限にし、必要なプラグインを「機能単位」で分離せよ。
// .eslintrc.js の最適化構成
module.exports = {
// 継承を最小化。eslint-config-prettierは「全ルールを無効化する」ための特殊な存在
extends: [
‘eslint:recommended’,
‘plugin:@typescript-eslint/recommended’,
‘plugin:prettier/recommended’ // これは最下位に配置し、フォーマット関連ルールを全て殺す
],
rules: {
// 冗長なルールを無効化することで、Linterの解析負荷を10-20%削減できる
‘@typescript-eslint/no-explicit-any’: ‘warn’,
‘no-console’: process.env.NODE_ENV === ‘production’ ? ‘error’ : ‘off’,
}
};
アーキテクトの視点:
PrettierをESLintのプラグインとして動かすのは、小規模プロジェクトでは便利だが、大規模開発では「分離」せよ。 ESLintは「構文の正しさ」を、Prettierは「行末のコンマ」を扱う。両者を分離してCLIで並列実行することで、CI/CDのパイプラインは劇的に高速化する。
—
2. フレームワーク別・現場で震えるほど役立つプラグイン選定
フレームワークごとに必要なのは「文法チェック」ではなく「設計思想の強制」だ。
React/Next.js の場合
`eslint-plugin-react-hooks` は必須だが、さらに `eslint-plugin-import` を導入し、モジュールの依存関係をグラフ化せよ。
// .eslintrc.js 依存関係管理の設定
{
“plugins”: [“import”],
“rules”: {
“import/order”: [“error”, {
“newlines-between”: “always”,
“alphabetize”: { “order”: “asc” }
}],
“import/no-cycle”: “error” // 循環参照を検知。これがないと大規模化で確実に崩壊する
}
}
Node.js (TypeScript) の場合
`@typescript-eslint/parser` の `project: ‘./tsconfig.json’` 指定はメモリを大量に消費する。CI環境では `tsconfig.eslint.json` を別途用意し、テストファイルや不要なモジュールを解析対象から除外することで、メモリ消費を最適化せよ。
—
3. CI/CDパイプラインへの埋め込みと高速化のハック
CIで `eslint .` を叩くのは素人のやり方だ。真のDevOps担当者は、差分のみを解析する。
husky + lint-staged を超える「CI差分Lint」
GitHub Actionsにおいて、全ファイルをLintするのは時間の浪費である。以下のコマンドをCIに組み込め。
マージベースとの差分ファイルのみを特定してLintを実行するスクリプト
FILES=$(git diff –name-only origin/main…HEAD | grep -E ‘\.(ts|tsx|js|jsx)$’)
if [ -n “$FILES” ]; then
npx eslint $FILES –max-warnings 0
fi
内部アーキテクチャの解説:
ESLintは内部でファイルをASTに変換し、それをメモリ上に保持する。ファイル数が増えれば増えるほどO(n)でメモリ消費が増加する。差分Lintは、単なる時間短縮だけでなく、CIコンテナのメモリ溢れ（OOM Killer）を回避する唯一の手段だ。
—
4. Dockerコンテナ環境における静的解析の完全自動化
開発環境の揺らぎを完全に排除するために、ESLintもDockerコンテナ内で完結させるべきだ。`docker-compose` でエディタのLSP（Language Server Protocol）と連携させるには、コンテナ内で実行されている `eslint-server` をホスト側から参照する設定が鍵となる。
docker-compose.yml
services:
app:
build: .
volumes:
- .:/app
# コンテナ起動時にLintプロセスをデーモンとして常駐させ、エディタとのパイプを太くする
command: npm run lint:watch
—
結びに：真のDevOpsエンジニアが目指す「自動化の先」
静的解析ツールを導入する目的は「バグを減らすこと」ではない。「エンジニアがコードのスタイルや些細な論理誤りに脳のリソースを使わなくて済むようにすること」にある。
Lintエラーが出るたびに人間が修正するのではなく、CIのパイプライン自体に自動修正（`eslint –fix`）を組み込み、PRに対して自動的にコミットをプッシュする「セルフヒーリング・パイプライン」を構築せよ。
あなたがツールを掌握し、ツールがコードを律する。この静寂こそが、最高峰の開発現場の風景である。さあ、今すぐ不要なルールを削ぎ落とし、あなたのパイプラインに真の効率性という名の「洗練」を実装せよ。