commitlintというコミットメッセージのリンターを導入してみた（前編：huskyを使ってコミット前にリントする）
オレオレなGitコミットからの卒業
現在の会社では基本的に案件ごとにレポジトリがあるのですが、基本的にGitはほぼ自分しか使っていないので、コミットメッセージは好きなように書いているのが現状です。
以前Next.jsの勉強で某テンプレを使っていたところ、コミット時にエラーが出て「？」となり、色々調べてみたらcommitlintというものを使ってコミット時にあるルールに従っているかリントしていることが分かりました。
将来的にチームでの実装も経験したい＆レポジトリの可読性を高め管理のしやすさを向上したいという思いから、commitlintを勉強したので記事にしました。
記事の中で「こうした方がイマドキだよ」とか「それはアカンで」みたいなやり方がありましたら指摘していただけますと幸いです🙏
commitlint is 何
commitlint＝コミットメッセージのリンターです。
Conventional Commitsという規約に則ってコミットメッセージを読み取るそうです。
commitlint 導入方法
インストール
インストールはWindows/Macで違うので注意です。
<!--Install commitlint cli and conventional config-->
npm install --save-dev @commitlint/{config-conventional,cli}
<!--For Windows:-->
npm install --save-dev @commitlint/config-conventional @commitlint/cli
設定ファイルの作成
プロジェクトルートに.commitlintrc.jsonというファイルを作成、下記を記述します。（お好きなファイル形式で。詳細はこちら）
{
"extends": ["@commitlint/config-conventional"]
}
オプションのカスタマイズも可能です。初めてなのでとりあえずデフォルトのまま進めます。
コミット作成前にリントする設定をする（husky）
コミットする前にリントして欲しいので、huskyのフックを使用します。
huskyのインストール
<!--Install Husky v6-->
npm install husky --save-dev
yarn add husky --dev
<!--Activate hooks-->
npx husky install
yarn husky install
Gitフックを有効にするためにActivate hooksの方もインストールします。
huskyフックの追加
コミットメッセージの入力完了後にcommitlintを呼び出すフックを作成します。
<!--husky上にcommit-msgというフックを作成。内容は`npx commitlint --edit $1`-->
npx husky add .husky/commit-msg 'npx commitlint --edit ${1}'
yarn husky add .husky/commit-msg 'yarn commitlint --edit ${1}'
上記コマンドを走らせると画像のようなファイルができあがります。
テスト
ここまで設定できたらいよいよちゃんと動くかどうかテストします。
まずは適当に変更をステージングされた状態にします。
そして規約から外れたメッセージでコミットします。
ちゃんとエラーを吐いてくれました。
続いて以下のメッセージで試しにコミットしたところ無事に通りました👏
feat: add commitlint
コミットメッセージの文法
Conventional Commitsでは基本的に以下の文法でコミットメッセージを書きます。
<型>[スコープ(任意)]: <タイトル>
[本文(任意)]
[任意(任意)]
とりあえず<型>と<タイトル>は必須ということですね。
型は以下の中から選びます。
[
'build',
'chore',
'ci',
'docs',
'feat',
'fix',
'perf',
'refactor',
'revert',
'style',
'test'
];
このタイプはAngularの規約が元になっているそうです。
Angularの規約を元にそれぞれ割り当てると下記のようになります。
型の割り当て
- build: ビルドシステムまたは外部依存関係に影響する変更 （スコープの例: gulp、broccoli、npm）
- ci: CI構成ファイルとスクリプトへの変更（スコープの例: Travis、Circle,、BrowserStack、SauceLabs）
- docs: ドキュメントのみの変更
- feat: 新機能
- fix: バグ修正
- perf: パフォーマンスの向上
- refactor: リファクタリング（バグ修正も機能追加も行わないコード変更）
- style: コードの意味に影響しない変更（空白、書式設定、セミコロンなど）
- test: 不足しているテストの追加または既存のテストの修正
その他、型（プレフィックス）については下記記事にも分かりやすく書いてあります。（規約が違いますが）
この辺はチーム毎に細かい取り決めを作った方がいいかもしれませんね。
以下に本記事の続編として、commitlintの型に則った書き方を簡単にする方法をまとめました。
参考サイト
Discussion