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

個人プロジェクトで CHANGELOG.md を [standard-version](https://github.com/conventional-changelog/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

<img width="1004" alt="スクリーンショット 2019-11-30 17.22.44.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43278/02d06d15-4fef-c102-2f9b-c48bee2d2e5d.png">


# 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__