【2024年版】ESLintとPrettierの完全調和：開発スピードを極限まで高める「無意識の品質管理」アーキテクチャ
開発現場において、LinterとFormatterのセットアップで時間を浪費するのは、最高峰のエンジニアとしては失格です。これらは「書くためのツール」ではなく、「脳の認知負荷をゼロにするための自動化レイヤー」であるべきです。
多くのチームがいまだに「設定の競合」という泥沼に足を取られていますが、2024年現在のベストプラクティスは極めてシンプル、かつ堅牢です。本稿では、コードの品質を担保しつつ、開発速度を加速させるための「論理的な解」を提示します。
—
1. 聖域の定義：ESLintとPrettierの役割分担
まず、多くの技術者が犯す最大のミスを正しましょう。`eslint-plugin-prettier` を使って「ESLint上でPrettierを動かす」という構成は、現代のフロントエンド開発においてはアンチパターンです。
- ESLintの役割: コードの「構造」と「ロジック」を精査する（`no-unused-vars`など）。
- Prettierの役割: コードの「見た目」を整える（インデント、改行など）。
これらを統合しようとすると、ESLintの実行プロセスに不要な負荷がかかり、エディタ上でのフィードバックが遅延します。「eslint-config-prettier」のみを使用し、両者を完全分離するのが、今のアーキテクトの定石です。
—
2. 決定版：生産性を最大化する設定構成
設定ファイルは「DRY原則」に従い、階層化して管理します。以下は、メンテナンス性と拡張性を両立させた `eslint.config.mjs` (Flat Config) の構成例です。
// eslint.config.mjs (ESLint Flat Config 形式)
import js from “@eslint/js”;
import tsParser from “@typescript-eslint/parser”;
import tsPlugin from “@typescript-eslint/eslint-plugin”;
import prettierConfig from “eslint-config-prettier”; // 競合するルールを無効化する必須ライブラリ
export default [
js.configs.recommended,
prettierConfig, // ← これを最後尾に置くことで、ESLintとPrettierの衝突を確実に防ぐ
{
files: [“/.{ts,tsx}”],
languageOptions: {
parser: tsParser,
parserOptions: { project: “./tsconfig.json” },
},
plugins: { “@typescript-eslint”: tsPlugin },
rules: {
// プロダクションで致命的となるバグを防ぐルールを厳格化
“@typescript-eslint/no-explicit-any”: “error”,
“@typescript-eslint/no-unused-vars”: [“warn”, { argsIgnorePattern: “^_” }],
},
},
];
なぜこれが最強なのか
- 高速性: `eslint-plugin-prettier` を排除することで、リンターの実行速度が劇的に向上します。
- 堅牢性: `eslint-config-prettier` がPrettierと競合するESLintルールをすべて無効化するため、二重管理の地獄から解放されます。
—
3. 実務で「差が出る」開発者体験（DX）の向上術
VS Code設定の「保存時自動修正」を極める
`.vscode/settings.json` に以下を記述し、チーム全員の環境を統一してください。これがチーム全体のコード品質を底上げする「強制力」になります。
{
“editor.formatOnSave”: true, // 保存時にPrettierを走らせる
“editor.defaultFormatter”: “esbenp.prettier-vscode”,
“editor.codeActionsOnSave”: {
“source.fixAll.eslint”: “explicit” // 保存時にESLintの修正も自動適用
},
“eslint.validate”: [“javascript”, “typescript”]
}
隠れたキーボードショートカット：`Shift + Alt + F` ではない
VS Codeの標準フォーマット機能に頼り切るのは危険です。大規模リポジトリでは「差分」が不明瞭になります。
- 推奨: `ESLint: Fix all auto-fixable Problems` をコマンドパレットから実行、あるいはこれにキーバインドを割り当ててください。これにより、エディタの警告を一瞬でクリーンアップする習慣が身につきます。
—
4. チーム開発で役立つ「自動化の防御線」
設定ファイルを作って終わりではありません。「ルールを破ることを不可能にする」のがテックリードの仕事です。
Husky + lint-staged を使ったコミットゲート
ローカルの環境差やミスを防ぐため、`git commit` 時に自動でLintを行うフローを構築します。
lint-stagedの設定例 (.lintstagedrc.json)
{
“.{js,ts,tsx}”: [
“eslint –fix”, // 修正可能なものは自動修正
“prettier –write” // 最後に整形を確定させる
]
}
この設定を組み込めば、開発者は「LintエラーでCIが落ちた」と怒られる前に、ローカルでクリーンな状態を担保できます。この「フィードバックループの短縮」こそが、開発スピードの源泉です。
—
5. アーキテクトの提言：真の品質とは
結局のところ、ESLintとPrettierは「コードの品質を担保する最低限のライン」に過ぎません。
本当に恐ろしいのは、ツール設定をいじって満足し、コードの「可読性」や「設計」という本質的な問題から目を背けることです。これらのツールに雑務を任せきりにして、我々エンジニアは「複雑なビジネスロジックをどうシンプルに書くか」「ドメイン知識をどうコードに落とし込むか」という、人間にしかできない高度な思考に脳のリソースを全振りする。
それが、現代のDevOps環境における「最強の開発スタイル」です。
今日からあなたのプロジェクトの `package.json` を見直し、無駄な依存関係を削ぎ落としてください。ツールが静かになった分だけ、あなたの生産性は確実に向上します。