「リリースノート頑張りたくないな」と思い、なるべく楽にそれなりのリリースノートを残せる方法を探った結果、lerna-changelogというLerna公式のツールが良さそうだったので、採用しました。hothouseではlerna-changelogで自動生成されたリリースノートを公開してます。何も書かないのは嫌だし、とは言えまだこの規模でリリース作業に苦労をしたくない。そんな温度感にちょうどマッチしてくれるツールです。使ってるリポジトリを見かけないので、紹介してみようと思います。requestをベースにリリースノートを作成するツールです。「PRベース」が他のツールと異なる点は、コミットメッセージやPRに命名規約を設けないことです。PRにつけたラベルごとにグルーピングし、PR1つ≒リリースノートの1行としてリリースノートを生成します。GitHubのトークンさえ渡せば、最後に打ったタグからHEADまでに含まれるPRを自動で収集・リリースノート化してくれる点も非常にありがたいです。使い方の流れとしては、PR出す(誰かから出される)PRに分類用のラベルを何か1つ以上つけるマージするlerna-changelogを実行し、リリースノートを生成のようになります。追加で必要なオペレーションはラベルつけるだけで、かつ私はラベルをつける癖がついているので、特に手間だと思っていません。ほとんど追加の手間なしに、リリースノートを生成できています。セットアップlerna-changelogを使うためのセットアップはざっくり2つあります。PR収集用のトークン生成(ガイド)PR分類用のラベルのマッピングを定義(ガイド)ラベルのマッピングを設定し忘れていると、PRはあるはずなのにリリースノートが空という現象が発生します。リポジトリに合わせてしっかり設定しましょう。hothouseではラベルのマッピングをこのように指定しています。}なおラベルはデフォルトではなく、azuさんのこのツールを使用させてもらいました。Scratchベンチマークとの対比リリース系で個人的に代表的だと思っているのは、semantic-releaseとconventional-changelogあたりかなと思っています。publish時に--conventional-commitsというオプションが使えるので、monorepoでの黄金パターンの1つなんだろうと思っています。—amendするの面倒なのと、コミットメッセージの分類適切じゃない問題が絶対的にあると思っており。分類は基本的に人力かつルールベースなので確実じゃないor間違うので、あまり信頼できないなと思っています。changesだったりすることがあるので。lerna-changelogはPRにタグをつけるだけなので、コミットのたびに分類に頭を使う必要がなく、精神衛生がとても良いです。PRの粒度を小さくしないと分類が難しいのはどちらも変わりませんし、分類が簡単になるわけでもありません。ラベルは後から簡単に付け消しできるので、マージした後には弄りにくいコミットメッセージよりは、ミスに優しいと思います。そもそも、「これ見やすいか?」と言われると、好みが分かれそうな気もします。私のPRのタイトルの書き方が下手なので、何が起こったかギリギリわかるかな、ぐらいだと思います。中身は仕組みの問題ではなく、私の問題なので、書式としてはいい感じなんじゃないだろうか、と思っています。使いやすくする一手間hothouseでは、npmへのpublishGitのタグ打ちGitHubへのタグpushリリースノートの生成GitHubのリリースの作成を全て一撃で倒すべく、こんなシェルを組んでます。publishとlerna-changelogで自動化されており、それらをつなぎ合わせるちょっとした手間をシェルで埋めて使っています。https://github.com/Leko/hothouse/blob/3f7f51a7045be8d47c8ef1764094a99929715e77/scripts/releaseリリース作業のハードルが下がると、リリースの頻度が上がり、結果的に早くバグ修正や機能追加が届けられるので、効果あると思います。楽だし気に入っているので、問題が出るまではこのままのやり方で進めてみようと思います。