エンジニアの皆さん、こんにちは。
コードを書くとき、「あ、セミコロン忘れた」「インデントが微妙にズレてる」といった些細なミスに時間を取られ、本来集中すべき「ロジックの設計」から意識が逸れてしまった経験はありませんか？
開発効率を突き詰めるプロフェッショナルにとって、「コードの見た目を整える」という作業は、人間にさせるべきではありません。 それはツールに任せて、脳のリソースを最も重要な「創造的解決」のために温存する。これが、一流の開発環境が備えるべき大前提です。
今回は、ESLintとPrettierを組み込み、`husky`と`lint-staged`を使って「コミットした瞬間に自動整形が完了している」という、極上の開発体験を構築する術を伝授します。
—
1. なぜ「全ファイル走査」は悪なのか？
プロジェクトが大きくなると、`npm run lint` を実行するたびに数十秒から数分待たされるようになります。これが開発のテンポを著しく損なう最大の要因です。
今回紹介する `lint-staged` の本質は、「今まさにコミットしようとしている差分（Staged Files）だけに絞って解析・整形を行う」という点にあります。何万行もある全ファイルを無視し、変更した数行だけを瞬時に最適化する。この「局所最適化」こそが、爆速のワークフローを生む鍵です。
—
2. 最強の布陣を構築する
まずは、必要なライブラリをインストールします。
husky: Gitフックを簡単に管理するライブラリ
lint-staged: 変更したファイルのみを対象にコマンドを実行するライブラリ
npm install –save-dev husky lint-staged
Huskyの初期化
Gitのフック（コミット前などのイベント）を有効化します。
huskyディレクトリを生成し、pre-commitフックを登録
npx husky init
このコマンドを実行すると、ルートディレクトリに `.husky/` フォルダが生成されます。
—
3. 「魔法」の設定ファイルを記述する
ここからが心臓部です。`package.json` に設定を書き込みます。`lint-staged`は、「どの拡張子のファイルを、どのコマンドで処理するか」を定義する設定ファイルです。
// package.json に追記する設定
{
“lint-staged”: {
“.{js,ts,tsx}”: [
“eslint –fix”, // ESLintで構文チェックし、自動修正可能なものは修正
“prettier –write” // Prettierで一貫したスタイルに強制整形
],
“.{json,md,css}”: [
“prettier –write” // 構造的データもPrettierで美しく保つ
]
}
}
次に、`.husky/pre-commit` ファイルを開き、中身を以下のように書き換えてください。
!/usr/bin/env sh
. “$(dirname — “$0″)/_/husky.sh”
ここが肝！コミット前にlint-stagedを実行し、
失敗したらコミットを中断（exit 1）させる
npx lint-staged
—
4. なぜこの設定が「現場」で最強なのか
このフローを導入すると、あなたのPC内部では以下のような「高度な連携」が自動で行われます。
1. Git Commit実行: あなたが `git commit` を打つ。
2. Huskyの介入: `pre-commit` フックが即座に割り込み、「待った」をかける。
3. lint-stagedの選別: Gitのステージングエリアにある「変更されたファイル」だけをピックアップ。
4. 自動浄化: ESLintとPrettierが対象ファイルをクリーンアップ。
5. 再ステージング: lint-stagedは、整形によって変更されたファイルを自動的にコミット対象として再ステージングします。
6. コミット完了: 完璧に整形されたコードだけが、リポジトリにコミットされる。
「汚いコードをリポジトリに入れない」という最強の品質管理と、「何も考えずにコミットすれば勝手に綺麗になる」という極上の体験が両立するのです。
—
5. 動作確認：HelloWorldのその先へ
実際に試してみましょう。わざと汚いコードを書きます。
// test.js
const hello=”world”
console.log(hello)
これをステージングしてコミットします。
git add test.js
git commit -m “テストコミット”
この瞬間、コンソールに `lint-staged` が走り、インデントやセミコロンが瞬時に修正され、何事もなかったかのようにコミットが完了します。再度ファイルを開いてみてください。
// 自動修正後の test.js
const hello = ‘world’;
console.log(hello);
完璧ですね。
—
最後に：先輩からのアドバイス
この設定を導入する最大のメリットは、「コードレビューの質が変わること」です。
レビューの際、インデントのズレや不要なスペースについて指摘する時間は無駄です。このワークフローを導入すれば、チーム全員のコードが「機械的に統一された状態」になります。結果として、レビューアーは「ロジックのバグ」や「より良い設計」といった、人間にしかできない高度な議論に集中できるようになります。
まずはあなたの今のプロジェクトに、この小さな「自動化」を組み込んでみてください。毎日のコーディングが劇的に楽になり、開発への集中力が一段階上のレベルに引き上げられることを約束します。
もし設定で詰まったら、いつでも聞きに来てください。効率化の旅を、ここから始めましょう。