導入：なぜリポジトリ全体ではなく「部分適用」が必要なのか
開発の現場で「コミットのたびに全ファイルのLintを実行していたら時間がかかりすぎてストレス……」と感じたことはありませんか？リポジトリの規模が大きくなると、解析だけで数分待たされることも珍しくありません。そこで役立つのが「lint-staged」というツールです。これは、今回修正した「ステージングにあるファイル（git addしたファイル）」だけに限定してLintを実行する仕組みです。この導入により、待ち時間を数秒に短縮し、開発のテンポを崩さずにコード品質を担保できるようになります。
基礎知識：lint-stagedの仕組み
lint-stagedとは、gitの「pre-commitフック（コミット直前に自動実行される処理）」を利用して、特定のファイルに対してコマンドを実行するツールです。
通常、Lint（静的解析）はプロジェクト内の全ファイルを対象にします。しかし、差分チェックを行うことで、変更のないファイルまで解析する無駄を省けます。これにより、CI/CDパイプラインの負荷軽減や、ローカルでのコミット作業の高速化が実現します。
実装：設定手順
導入には、Node.js環境で以下のパッケージをインストールする必要があります。
1. npm install –save-dev lint-staged husky
2. npx husky install
3. npx husky add .husky/pre-commit “npx lint-staged”
これで、コミット時に自動的にlint-stagedが走る準備が整います。
サンプルプログラム：package.jsonの設定例
プロジェクトのルートディレクトリにある「package.json」に、以下の設定を追加します。これにより、変更されたファイルの種類に応じて最適なコマンドが実行されます。
{
“lint-staged”: {
/ JavaScriptやTypeScriptファイルが変更された場合 /
“.{js,ts,jsx,tsx}”: [
/ ESLintでコードの品質チェックを実行 /
“eslint –fix”,
/ Prettierでコードのフォーマットを整える /
“prettier –write”
],
/ CSSやJSONファイルが変更された場合 /
“.{css,json}”: [
“prettier –write”
]
}
}
応用・注意点：現場で役立つポイント
現場で運用する上で、いくつか気をつけるべき点があります。
1. 実行環境のバージョンを揃える
チーム開発では、Node.jsやLintツールのバージョンが異なると「自分の環境ではエラーにならないのに、他の人の環境でエラーになる」という問題が起きがちです。`.nvmrc`などでバージョンを固定しましょう。
2. –fixの副作用に注意
`eslint –fix`を自動実行すると、コードが勝手に書き換わります。予期せぬ挙動を防ぐため、まずはローカルで十分にテストが通る状態であることを確認してからコミットしてください。
3. 重い処理の回避
単体テスト（Jestなど）をlint-stagedに含める場合、全テストを実行すると時間がかかります。Jestには`–findRelatedTests`というオプションがあり、これを使えば「変更したファイルに関連するテストのみ」を実行できるため、ぜひ併用を検討してください。
lint-stagedを活用して、待ち時間のない快適な開発環境を手に入れましょう！
コメント