gitにもlinterがあると知ったので、早速入れてみる。
commitlintとは
commitlint helps your team adhere to a commit convention. By supporting npm-installed configurations it makes sharing of commit conventions easy.
(commitlint は、チームがコミット規則に従うのに役立ちます。 npm でインストールされた構成をサポートすることで、コミット規約の共有が容易になります。)
commitlint - Lint commit messagesより引用。後半はgoogle翻訳
主にチームでコミットメッセージの規約を守るために使うらしい。今回個人で使うんですが。
インストール
% pnpm add -D @commitlint/{cli,config-conventional}
% echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.cjs
@commitlint/config-conventionalと@commitlint/cliの2つのインストールと、commitlint.config.jsの作成。
基本的にサイト通りなのだが、package.jsonで"type": "module"を設定している場合、
commitlint.config.jsの状態で実行すると、Error [ERR_REQUIRE_ESM]: require() of ES Module /commitlint.config.js from /loaders.js not supported.というエラーが出るので、拡張子を.cjsに変更する必要がある。
それ以外の場合は.jsで問題ないハズ。
huskyのインストール
commit時にcommitlintを実行するために、フックヘルパーのhuskyをインストールする。
% pnpm add -D husky
% pnpm husky install
huskyのフックを追加する
% pnpm husky add .husky/commit-msg 'npx commitlint --edit ${1}'
pnpmに書き換えて実行していたけど、コメントの中でnpxを使っていることに今気がつく。
% pnpm husky add .husky/commit-msg 'pnpm commitlint --edit ${1}'
ガイドの方には、'npx --no -- commitlint --edit ${1}'となっていたのだが、参考サイトは'npx commitlint --edit ${1}'だった。
--no --が何を指すのか分からず。。。
使ってみる
% git commit -m "test"
⧗ input: test
✖ subject may not be empty [subject-empty]
✖ type may not be empty [type-empty]
✖ found 2 problems, 0 warnings
ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
husky - commit-msg hook exited with code 1 (error)
commitしてみると、エラーがちゃんと起きる。
ちなみにvscodeのGUIからやってもエラーが起きる。
記述方法
入れたはいいがどういうコミットを記述するの？
ということで、エラーにあったサイトを見てみる。
In general the pattern mostly looks like this:
type(scope?): subject #scope is optional; multiple scopes are supported (current delimiter options: "/", "\" and ",")
ということで、type(scope?): subjectという形式で記述するらしい。
typeは指定されたワードしか使えないらしく、設定で変更可能。
具体的にtypeの使い分けをせっかくなので(？)chatGPTさんに聞いてみた。
(※commitlintのデフォルトで設定されている11個のtypeを提示して聞いています。)
以下は一般的なGitのコミットメッセージで使用されるプレフィックスの説明です。
1. `build`: ビルドシステムや外部依存関係の更新に関連するコミットです。ビルドプロセスやパッケージのバージョンアップなどが含まれます。
2. `chore`: その他の雑多なタスクや修正に関連するコミットです。ドキュメントの生成やリリーススクリプトの更新、設定ファイルの変更などが含まれます。
3. `ci`: 継続的インテグレーション（CI）や継続的デリバリ（CD）の設定やスクリプトの変更に関連するコミットです。
4. `docs`: ドキュメントの作成や更新に関連するコミットです。ドキュメントの追加、修正、削除などが含まれます。
5. `feat`: 新機能の追加に関連するコミットです。アプリケーションやライブラリに新しい機能を導入する場合に使用されます。
6. `fix`: バグ修正に関連するコミットです。既存の機能やコードの問題を修正するために使用されます。
7. `perf`: パフォーマンスの改善に関連するコミットです。コードやアルゴリズムの最適化、効率の改善などが含まれます。
8. `refactor`: コードのリファクタリングに関連するコミットです。機能の変更やバグ修正ではなく、コードの可読性や保守性の向上を目的とした変更が含まれます。
9. `revert`: 以前のコミットを取り消すためのコミットです。特定の変更を元に戻すために使用されます。
10. `style`: コードスタイルの変更に関連するコミットです。インデント、空白、セミコロンなどのスタイル変更が含まれます。
11. `test`: テストコードの追加や修正に関連するコミットです。テストカバレッジの向上や既存のテストの修正などが含まれます。
これらのプレフィックスは一般的なガイドラインであり、チームやプロジェクトによって使用方法が異なる場合もあります。重要なのは、チーム内で一貫性を持って使用することです。
その後ろのscopeは任意で、変更の範囲や場所、参照などを記述するらしい。
引用元にも書いている通り、/や\、,で区切ることで複数のscopeを記述することができる。
最後にsubjectで、変更の内容を記述する。
ここの説明の表現がとっても曖昧なのは、まだ試していないから。
詳しい内容は別途調べた方がいいかも。
vscodeの拡張機能
commitlint - Visual Studio Marketplace
入れると、vscode内のgitのコミットメッセージで、commitlintのルールに従っていないと赤線エラーが表示されるようになる。
終わりに
githubから直接commitする時などでも対応できるようにする方法(ci?)や、
設定はそこそこな項目があるので、チーム毎に色々と設定ができそう。
今回はシンプルにこの辺の初期設定でとりあえず使ってみようと思う。
ではでは〜
参考サイト
commitlint の紹介 - Qiita
commitlintというコミットメッセージのリンターを導入してみた（前編：huskyを使ってコミット前にリントする）