1. 導入: なぜ–fixオプションが重要なのか
開発チームでコードを書いていると、「セミコロンがあるかないか」「クォーテーションはシングルかダブルか」といった細かな表記ゆれがコードレビューの時間を奪うことはありませんか？これらは本質的なロジックとは無関係ですが、放置するとコードの可読性を低下させます。ESLintの–fixオプションは、こうした機械的に解決可能な違反を自動で修正し、人間は「ビジネスロジックの設計」に集中するための強力な武器となります。
2. 基礎知識: ESLintと自動修正の仕組み
ESLintは、JavaScript/TypeScriptのコードを静的解析し、あらかじめ定義されたルール（コード規約）に基づいて違反を指摘するツールです。すべてのルールが自動修正に対応しているわけではありませんが、インデントの調整や不要なスペースの削除など、多くのスタイル系ルールはプログラムによって修正可能です。これを手動で行うのではなく、CLIやエディタの機能として実行することで、常に一定の品質を保つことができます。
3. 実装/解決策: CLIでの実行とエディタ連携
最も基本的な使い方は、ターミナルで以下のコマンドを実行することです。
ターミナルでの実行例:
npx eslint . –fix
また、現場で推奨されるのは、VS Codeなどのエディタで「保存時に自動修正（Fix on Save）」を有効にすることです。これにより、ファイルを保存するたびにESLintが裏側で動き、一瞬でコードを規約に適合させてくれます。
4. サンプルプログラム: 設定ファイルと検証用コード
まずは、自動修正を体験するために以下の構成を用意してみてください。
設定ファイル (.eslintrc.json) の例:
{
“rules”: {
// セミコロンを強制し、違反時は警告を出すルール
“semi”: [“error”, “always”],
// シングルクォーテーションを強制するルール
“quotes”: [“error”, “single”]
}
}
修正前のコード (index.js):
// セミコロンがなく、ダブルクォーテーションを使用している
const message = “Hello World”
console.log(message)
修正後のコード (npx eslint index.js –fix 実行後):
// 自動的にセミコロンが付与され、クォーテーションが変換される
const message = ‘Hello World’;
console.log(message);
5. 応用・注意点: 現場での運用ルール
現場で運用する際に注意すべき点が2つあります。
一つ目は「Gitコミット前の自動化」です。huskyやlint-stagedを導入し、コミット直前に自動修正を走らせる仕組みを作ると、修正漏れがなくなります。
二つ目は「ルール適用の範囲」です。あまりに複雑なルールを–fix対象にすると、意図しない挙動の変更を引き起こす可能性があります。自動修正はあくまで「コードの見た目（スタイル）」を整えることに限定し、ロジックに関するルールは警告（warning）に留めるなど、チーム内で運用ルールを明確にしておきましょう。コード品質を担保しつつ、開発スピードを落とさない「自動化」の恩恵を最大限に活用してください。
コメント