エンジニアの皆さん、こんにちは。開発環境の深淵を探求するアーキテクトです。
ESLintとPrettier。今やモダンなJS/TS開発において「空気」のような存在ですが、皆さんはこれらを「単なるコード整形ツール」だと思っていませんか？実は、自動修正（`–fix`）という強力すぎる機能は、時に諸刃の剣となります。
今回は、ESLintがコードを「破壊」する瞬間と、それを防ぎながら開発生産性を最大化する「プロの運用術」を伝授します。
—
1. なぜ「自動修正」がバグを呼ぶのか？
ESLintの自動修正は、AST（抽象構文木）を操作してコードを書き換えます。しかし、AST上の論理的な修正が、実行時の振る舞いを変えてしまうケースが存在します。
危険なルールの筆頭格：`prefer-destructuring`
例えば、配列の要素を定数に代入するコードを考えてみましょう。
const user = users[0];
const name = user.name;
`prefer-destructuring` はこれを以下のように直そうとします。
const [user] = users; // ここに罠がある
const { name } = user;
一見スマートですが、元のコードが `users` が空配列（`[]`）の場合、`user` は `undefined` になりますが、代入は成功します。しかし、分割代入を行うと、存在しないインデックスへのアクセスでランタイムエラーを誘発する可能性が激増します。ESLintは「コードの見た目」は整えますが、「実行時の境界条件」までは完全に保護できないのです。
—
2. 安全な「自動修正」を構築するためのセットアップ
初心者のうちは、「とりあえず全部 `–fix` する」設定にしがちですが、それは非常に危険です。まずは、最も堅牢でモダンな構成を構築しましょう。
必要なパッケージのインストール
`eslint-config-prettier` を使い、Prettierと競合するESLintのルールを完全に無効化するのが鉄則です。
ESLint本体と、Prettierとの衝突を防ぐ設定を導入
npm install –save-dev eslint prettier eslint-config-prettier
最も重要な設定ファイル：`.eslintrc.json`
ルールは「厳しく」設定し、自動修正は「慎重に」行うのがエンジニアの矜持です。
{
“extends”: [
“eslint:recommended”,
“prettier” // Prettierのルールを優先し、競合を抑制する魔法の行
],
“rules”: {
// 自動修正でバグりやすいルールはあえて warn に留める
“prefer-destructuring”: [“warn”, { “object”: true, “array”: false }],
// 無意味なリネームは自動修正させない
“no-useless-rename”: “error”
}
}
—
3. HelloWorld的動作確認：安全なフィードバックループ
いきなり全てのファイルを書き換えるのではなく、まずは「検知」と「修正」のサイクルを分離しましょう。
ステップ1: 検知する（CI/ローカル）
まずは修正せず、問題だけを特定します。
–fixを付けずに実行し、エラー箇所を人間が確認する
npx eslint src/
ステップ2: 修正する（限定的）
全自動ではなく、特定のルールのみを対象にするのがプロの流儀です。
安全が確認されているルールだけを自動修正する
npx eslint –fix –rule “no-unused-vars: error” src/
—
4. 伝説のDevOpsリードからの「現場の知恵」
最後に、現場で事故を起こさないための「2つの鉄則」を授けます。
① `lint-staged` でコミット前に防波堤を作る
`git commit` 時に、変更したファイルだけを対象にlintを走らせます。これにより、破壊的な修正がメインブランチに混入するのを物理的に防げます。
// package.json に追記
“lint-staged”: {
“.{js,ts}”: [
“eslint –fix”,
“prettier –write”
]
}
② 「自動修正」はあくまで補助と心得よ
もし複雑なロジック修正を自動化したいなら、ESLintではなく jscodeshift を使った「コード変換（Codemod）」を検討してください。これらはASTレベルでの安全な変換を保証するために設計されており、ESLintの `–fix` よりも遥かに安全で強力です。
—
まとめ：ツールを「飼い慣らす」ということ
ESLintやPrettierは、あなたの「思考の補助」をするツールであって、「思考の代行」をするツールではありません。
- 自動修正は「整形」に留め、「ロジックの変更」は慎重に行う。
- 危険なルールは `warn` に設定し、警告を無視しない文化を作る。
- CI/CDパイプラインには常に `lint` を含め、人間が気づかない破壊を検知する。
これをマスターすれば、あなたのコードは美しく、そして何より「壊れにくい」ものへと進化します。さあ、安全で快適な開発ライフへ飛び込みましょう！