standard-versionとgit-czを使って、CHANGELOGやバージョンを日本語で管理しよう!
この記事について
standard-version と git-cz を使った、バージョン・CHANGELOG 管理環境がある程度まとまってきたので、備忘録も兼ねてその環境の構築方法をまとめていきたいと思います 🏋️♀️
解決したい問題
- 簡単にバージョン管理したい
- コミットを簡単にしたい
- CHANGELOG.md を日本語で作成したい!
- コミットメッセージは日本語で!
standard-version とは?
Conventional Commitsに則ったコミットメッセージから、バージョンを更新したり CHANGELOG.md を作成することが出来ます。
カスタマイズも結構出来て、自分好みの CHANGELOG.md を出力することも可能です。
バージョンの決め方も自動でも手動でも決めることが出来るので、CI 連携も比較的しやすいと思います。
semantic-release との違いは?
standard-versionと似たようなライブラリで、semantic-releaseと言うのがあります。
これらの違いについて、standard-versionの README.md に説明が書いてあったので、引用します。
semantic-release is described as:
semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
While both are based on the same foundation of structured commit messages, standard-version takes a different approach by handling versioning, changelog generation, and git tagging for you without automatic pushing (to GitHub) or publishing (to an npm registry). Use of standard-version only affects your local git repo - it doesn't affect remote resources at all. After you run standard-version, you can review your release state, correct mistakes and follow the release strategy that makes the most sense for your codebase.
We think they are both fantastic tools, and we encourage folks to use semantic-release instead of standard-version if it makes sense for their use-case.
要約
semantic-releaseでは、Github リポジトリへのプッシュや、npm レジストリへの公開などのパッケージリリースフローを扱うが、standard-versionでは、ローカルの git リポジトリにのみ変更を与えるので、リモートへの影響がない。
という事らしいです。
なので、semantic-releaseの方が、OSS ライブラリ向けな感じがしますね。
その点、standard-versionは変更がローカルのみなので、OSS ライブラリではない普通のサービス開発などでも導入しやすいと思います。
git-cz とは?
Conventional Commitsに則ったコミットメッセージが書きやすくなるツールです。
一番の特徴としては、Emoji が扱えるところでしょうか。
Emoji を使うのは好き嫌いが分かれそうですが、コミットメッセージが読み易くなるので筆者は良く使用しています。後、書いていて楽しい 😊
また、日本語化も簡単にできるのでお勧めです。
環境構築
これから環境構築を行っていきますが、以下の環境下で構築していく事を想定しています。
要素 | バージョン |
---|---|
Node.js | v12.18.4 |
npm | v6.14.6 |
必要モジュールのインストール
git-cz をインストール
$> npm i -g git-cz
git-cz
は、ローカルインストールすることも可能です。
その場合は、以下のようにします。
$> npm install -g commitizen // commitizenをグローバルインストールする必要がある
$> npm install --save-dev git-cz // ローカルインストール
standard-version をインストール
$> npm i --save-dev standard-version
standard-version
は基本的に npm scripts を用いて使うため、ローカルインストールで大丈夫です。
設定ファイル
設定ファイルを記述していきます。
git-cz の設定
git-czは、changelog.config.js
というファイルで質問の内容や使用する Emoji を変更することが出来ます! なので、今回は質問の文言やコミットメッセージを日本語で表示・入力できるように設定してきます 🗾
module.exports = {
// Emojiを非表示にするか
disableEmoji: false,
// types一覧
// typesが設定されているのに、listに登録されてないとgit-czの実行時にエラーを吐く
// 入れる値は、typesのvalueプロパティで指定した値
list: [
'test',
'feat',
'fix',
'chore',
'docs',
'refactor',
'style',
'ci',
'perf',
'config',
'package',
],
// コミットメッセージの最大文字数
maxMessageLength: 64,
// コミットメッセージの最小文字数
minMessageLength: 3,
// 質問の種類
questions: ['type', 'scope', 'subject', 'body', 'breaking', 'issues', 'lerna'],
// scopesの種類
// 一つも指定されてない場合、scopeの質問は行われなくなる
scopes: ['無し', 'API', '機能', '環境構築', '型ファイル'],
// typesの種類を設定する
types: {
chore: {
description: 'ビルドプロセスまたは補助ツールの変更',
emoji: '🤖',
value: 'chore',
},
ci: {
description: 'CI関連の変更',
emoji: '🎡',
value: 'ci',
},
docs: {
description: 'ドキュメントの変更のみ',
emoji: '✏️',
value: 'docs',
},
feat: {
description: '新機能の追加や更新',
emoji: '🎸',
value: 'feat',
},
fix: {
description: 'バグ修正',
emoji: '🐛',
value: 'fix',
},
perf: {
description: 'パフォーマンスを向上させるコード変更',
emoji: '⚡️',
value: 'perf',
},
refactor: {
description: 'リファクタリング',
emoji: '💡',
value: 'refactor',
},
release: {
description: 'リリースコミット',
emoji: '🏹',
value: 'release',
},
style: {
description: 'マークアップ、ホワイトスペース、フォーマット、セミコロンなどの修正',
emoji: '💄',
value: 'style',
},
test: {
description: 'テストの追加・修正',
emoji: '💍',
value: 'test',
},
// 以下、独自で追加したtypes
config: {
description: '設定ファイルの追加・修正',
emoji: '⚙️',
value: 'config',
},
package: {
description: 'パッケージの追加・更新・削除',
emoji: '📦',
value: 'package',
},
},
};
ここで注意なのが、scope
の挙動です。
git cz
を実行して対話していく中で、デフォルトでは、 scopesプロパティ
で指定した値しか入力できません。 これは人によっては凄く不便かもしれませんので、その場合は cz-emoji の方を使ってください。使い方は git-cz と大体同じです。
standard-version の設定
次に standard-version の設定をしてきますが、環境によって大きく異なるため、この記事ではほとんどデフォルトの設定で記述し、 changelog.config.js
で独自に追加した types に対応する設定を行っていきます。
詳しい設定方法は、こちらの公式ドキュメントを参照してください。
{
"types": [
{
"type": "chore",
"section": "ビルドプロセスまたは補助ツールの変更",
"hidden": false
},
{
"type": "feat",
"section": "新機能",
"hidden": false
},
{
"type": "fix",
"section": "バグ修正",
"hidden": false
},
{
"type": "docs",
"section": "ドキュメント",
"hidden": false
},
{
"type": "style",
"section": "コードスタイル",
"hidden": false
},
{
"type": "refactor",
"section": "リファクタリング",
"hidden": false
},
{
"type": "perf",
"section": "パフォーマンスの向上",
"hidden": false
},
{
"type": "test",
"section": "テストの追加・修正",
"hidden": false
},
{
"type": "ci",
"section": "CI関連",
"hidden": false
},
{
"type": "config",
"section": "設定ファイル",
"hidden": false
},
{
"type": "package",
"section": "パッケージ",
"hidden": false
}
],
// リリースコミットのメッセージを変更する
"releaseCommitMessageFormat": "chore(release): 🏹{{currentTag}}"
}
package.json を設定する
npm scripts
を設定して、npm run ...
や yarn ...
などのコマンドで、CHANGELOG.md
の生成と git の tag 付けを出来るように設定します。
{
/* -- 省略 -- */
"scripts": {
"release:patch": "standard-version --release-as patch", // 例: v0.0.1 -> v0.0.2
"release:minor": "standard-version --release-as minor", // 例: v0.0.1 -> v0.1.0
"release:major": "standard-version --release-as major", // 例: v0.0.1 -> v1.0.0
},
/* -- 省略 -- */
}
使い方
設定が出来たら実際に使って行きます。
基本的には、以下のような流れで使用してきます。
- ファイルを変更して
git add
する -
git cz
をして対話を開始 - 質問に答えていく
- 上の事を繰り返す
-
CHANGELOG.md
を生成したくなったら npm scripts で定義したリリースコマンドを実行する - リモートにプッシュするなどする
最初に CHANGELOG.md を生成する場合
CHANGELOG.md
を初めて生成する場合は、
$ npm run standard-version --first-release
または、
$ yarn standard-version --first-release
を実行して、CHANGELOG.md
を生成してください。
その後は、上記の流れで出来ると思います。
終わり
以上で、環境構築は終わりです。お疲れ様でした 🙌
この記事の発展形として、Github Actionsなどの CI を用いたリリースフローなどがありますが、これはまた別の機会にでも解説したいと思います 👨💻
Discussion