standard-version で便利にバージョニング＆CHANGELOG.md 自動生成

個人プロジェクトで CHANGELOG.md を standard-version のガイドラインに沿って自動生成しています。やり方の雑なまとめです。

yarn release:patch:candidate  # パッチリリース候補 タグ打ち
yarn release:patch            # パッチリリース タグ打ち

yarn release:minor:candidate  # マイナーリリース候補 タグ打ち
yarn release:minor            # マイナーリリース タグ打ち

yarn release:major:candidate  # メジャーリリース候補 タグ打ち
yarn release:major            # メジャーリリース タグ打ち

↑これだけで、バージョニングと CHANGELOG 生成できます；

• git のコミットログから CHANGELOG.md が自動生成・追記されて、
• その CHANGELOG.md を git add しつつ、
• package.json の version をパッチレベルごとに semver し、こちらも git add して、
• git commit

husky で git commit hooks に commitlint を設定する

CHANGELOG を生成するにあたって、一定フォーマットで揃えます。husky で git commit 時に commitlint を実行するようにして、フォーマットを強制しておきます。

yarn add --dev husky commitlint

package.json

:
  "devDependencies": {
    "@commitlint/cli": "^8.2.0",
    "@commitlint/config-conventional": "^8.2.0",
    "husky": "^3.1.0",
     :
  },
:
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
      "post-commit": "git update-index --again"
    }
  },
:

commitlint は Angular で使っているコミットメッセージのフォーマットをチェックできます。
以下は、先達諸兄のブログポストなど参考にして、私が設定しているフォーマットですが好み次第です。

こちらとても参考になりました。感謝です:

• https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• http://falsandtru.hatenablog.com/entry/git-commit-message

              type   scope(opt) verb title 
                 \      |        |     |
                 feat(android): add template url parameter to events   (<- without period)
(empty line) ->
        body ->  追加の情報あれば   (<- within 72 chars per line)
                 本文ではどのようにではなく何をとなぜを説明する

<type>:

• feat (new feature for the user, not a new feature for build script)
• fix (bug fix for the user, not a fix to a build script)
• docs (changes to the documentation)
• style (formatting, missing semi colons, etc; no production code change)
• refactor (refactoring production code, eg. renaming a variable)
• test (adding missing tests, refactoring tests; no production code change)
• chore (updating grunt tasks etc; no production code change)

<scope>:
scope is just a option, and will be empty in most case. if you want to define scope, then you can write.

<verb>:（１行メッセージでも動詞をしっかりしておくと割と意味が通る、気がする）

• add A (to B)
• remove A (from B)
• move A (from B to C)
• replace A with B
• make A B
• change A to B
• update A to B
• ensure that A
• use A (instead of B for C)
• fix A

During a rebase you may want to skip all hooks, you can use HUSKY_SKIP_HOOKS environment variable.HUSKY_SKIP_HOOKS=1 git rebase ...

standard-version でバージョニングする

特に何も設定していないのですが、そのまま使えています。

yarn add --dev standard-version

package.json

:
  "scripts": {
    :
    "release:patch:candidate": "standard-version --release-as patch --prerelease",
    "release:patch": "standard-version --release-as patch",
    "release:minor:candidate": "standard-version --release-as minor --prerelease",
    "release:minor": "standard-version --release-as minor",
    "release:major:candidate": "standard-version --release-as major --prerelease",
    "release:major": "standard-version --release-as major"
  },
:
  "devDependencies": {
    :
    "standard-version": "^7.0.1",
    :
  },
:

END