なぜやった？

プッシュして、CIの結果でstylelint,eslintのエラーに気づく事例が多々あったから

この部分をプッシュ前に気づけるうまい具合の仕組みないかなあと。。。

思ってた矢先にふと行った勉強会でhuskyを用いて、stylelintのエラーにローカルで気づけるようになったぜ！という発表を聞いていて、

「これ、俺もできそうだなあ。。。」と発表を聞きながら思って、やらずにはいられなくなりました。

huskyで何をした？

出典元：MarcoKerschbaum

husky: Git のコミットやプッシュなどを実行すると、設定した処理をその処理の前に実行してくれる仕組み
lint-staged: ステージングしたファイルに対して、特定のコマンドを実行してくれるパッケージ。huskyと相性がよく、一緒に使われることが多い

上記の2つ（husky + lint-staged）を組み合わせて、以下の仕組みを作成

ステージングしたファイルに対して、コミット時stylelint, eslintを実行して、警告の箇所を気づける仕組み

開発チームに導入するメリットとしては、

レビュー出す前にstylelint, eslintのケアレスミスに気付ける
レビュワーとしては、huskyで検知している部分は注視しなくて良くなるので、レビューの効率化にもなる

▼以下の記事がhuskyを導入するメリットについて、もっと深掘ってくれてます。 qiita.com

「コミット時に毎回lintが実行されたら、ちょっと待たされるのでは？」という疑問に解答

結論、「実行速度は長くても10秒くらいなので、開発の大きな障害にはならない」です。

やったことをおさらいすると、 ▼以下の内容を開発チームに導入しました。（まだ1ヶ月も経たない程度ですが。。。）

huskyでコミット時にステージングしたファイルに対して、eslintとstylelintを走らせる

ここで肝なのが、「"ステージングしたファイルのみ"lintが走っている」所です。

なので、1回のコミットでステージングに上げるファイル数がとんでもなく多い時以外は、実行速度については気になりません！約1ヶ月使ってみて、個人的には、実行速度について、大体5秒で長くても10秒くらいでした。

【ビフォーアフター】husky導入の前後

▼huskyを導入する前と後について、図解を用いて、ストーリー調などを駆使して、説明します。

【ビフォー】 husky導入前

以前の運用では、プッシュする時にCIの結果でstylelint・eslintのエラーに気づくケースが割とありました。

▼なので、下記みたいなレビュワーとのやり取りがちょこちょこありました。

自分「いやー今日も良いコード書いたわ」

自分「さっそくプルリク作ってレビューしてもらおっと。コミット。そしてプッシュ！」

レビュワーXさん「CIでstylelintのエラーで引っかかってます。修正してもらえますか？」

自分「ああ！ローカルでstylelintの実行しとけば！！もう1度stylelintの引っかかった箇所を修正してからプッシュ！」

ローカル開発環境からローカルリポジトリにgit commitし、リモートリポジトリにgit pushする。その後、CIの結果を待ち、stylelintのエラーに気づく。待ち時間およそ20分。 — ローカル開発環境からローカルリポジトリにgit commitし、リモートリポジトリにgit pushする。git pushの後、CIの結果を待ってからstylelintのエラーに気づく。待ち時間およそ20分。

【アフター】 husky導入後

コミットした時にstylelintとeslintのエラーが気づけるようになります

▼なので、下記みたく1人でエラーに気づくことができます

自分「いやー今日も良いコード書いたわ」

自分「さっそくプルリク作ってレビューしてもらおっと。コミット」

自分「あれ？コミットしたら何かエラーでたやんけ、なんでや」

自分「ああ、stylelintのエラーでてるやん」
コミット時のstylelintのエラー画面
自分「ここをこう直せばいいだけね！レビューでツッコまれる前に気づけたわ。さすがやな」