1. 導入：なぜ開発フローに「水際対策」が必要なのか
開発現場において、LinterやFormatterの実行忘れは日常茶飯事です。CI（継続的インテグレーション）でチェックすることも重要ですが、プッシュしてから「ビルド失敗」に気づくのではフィードバックループが遅すぎます。
今回紹介するHuskyとlint-stagedの組み合わせは、コミット直前（pre-commit）に自動で静的解析を行う仕組みです。これにより、汚れたコードがリポジトリに混入することを「水際でブロック」し、開発者の負担を最小限に抑えつつコード品質を一定に保つことができます。
2. 基礎知識：Huskyとlint-stagedの役割
本手法で利用する主要なツールについて解説します。
・Git Hooks: Gitの特定のタイミング（コミット時やプッシュ時など）でスクリプトを実行する機能。
・Husky: Git Hooksを簡単に設定・管理するためのツール。従来のシェルスクリプト管理の煩雑さを解消します。
・lint-staged: Gitのステージング領域（git addしたファイル）のみを対象にコマンドを実行するツール。プロジェクト全ファイルをスキャンする非効率さを排除し、高速なチェックを実現します。
3. 実装：導入手順
以下の手順でプロジェクトに導入します。ここではnpm環境を想定します。
1. 必要なパッケージのインストール
npm install husky lint-staged –save-dev
2. Huskyの有効化とフック設定の作成
npx husky init
3. package.jsonに設定を追加
後述するサンプルコードを参考に、設定を記述します。
4. サンプルプログラム：設定ファイル例
以下の設定をpackage.jsonに追加することで、コミット時に自動でLintとフォーマットが走るようになります。
{
“scripts”: {
“prepare”: “husky”
},
“lint-staged”: {
// .js, .tsファイルがステージングされた場合のみ実行
“.{js,ts}”: [
“eslint –fix”, // ESLintで自動修正を試みる
“prettier –write” // Prettierでフォーマットを統一する
]
}
}
また、.husky/pre-commit ファイルの中身を以下のように記述してください。
!/usr/bin/env sh
. “$(dirname — “$0″)/_/husky.sh”
ステージングされたファイルに対してlint-stagedを実行
npx lint-staged
5. 応用・注意点：現場でのトラブル回避
・強制コミットの回避策
どうしてもチェックをスキップしてコミットしたい緊急事態には、git commit –no-verify を利用します。ただし、乱用は厳禁です。
・実行時間の肥大化に注意
lint-stagedは対象を絞りますが、プロジェクトが大規模になるとeslintの起動自体に時間がかかる場合があります。その際はキャッシュオプション（eslint –cache）を併用することを推奨します。
・チーム間での共有
Huskyはnpm install時に自動でフックを有効化する設定（prepareスクリプト）を入れておくことで、メンバーが新しく環境構築した際にも自動で設定が反映されるようになります。
この仕組みを導入することで、「コードレビューでフォーマットの指摘をする」という不毛なやり取りをゼロにし、本質的なロジックの改善に集中できる環境を構築しましょう。
コメント