2022/10/07 に公開1464 views
主にOSSプロジェクトで活用されているmonorepoバージョニングツール「Changesets」を社内プロジェクトに導入した話について、@potato4dが@spring-rainingに聞いてみました。
Changesetの仕組み
- https://github.com/changesets/changesets
- monorepo向けバージョニング&リリースツール
- 修正や機能追加があれば、
.changesetディレクトリに自動生成されたMarkdownファイル (Changeset) にChangelogを書く- その変更の粒度 (major/minor/patch) もMarkdownファイルで指定する
- パッケージがリリースされるまでChangelogが
.changesetに溜まっていく changeset publishすると、リリースされていないChangelogがCHANGELOG.mdに書き写された上でnpmやGitHub上のリリース作業が実行される
社内のプロジェクトにChangesetsを導入した経緯
- プロジェクト内で汎用のUIライブラリを用意する必要が生まれた
- 次のような条件を満たすmonorepo向けのバージョニングツールを探していた
- 様々な粒度のUIコンポーネントを提供する予定なので、monorepoにしたい
- 異なるバージョンのpackageを並行して使用される (=一斉にコンポーネントを更新できない) ので、各パッケージで独立したバージョン管理 (LernaでいうIndependent mode) にしたい
- 決まった人が実装するのではなく、プロジェクト内で必要になったタイミングで各自で実装・デプロイできるよう社内OSSのような形がとれるようにしたい
他のツールとの比較
- monorepo向けバージョニングツールとして
- Changesetsはmonorepo向けではあるが、特定のmonorepo管理ツールには依存していない
- 既存のmonorepoプロジェクトからバージョニングのみChangesetsに移行、というやり方も可能
- リリースツールとして
- Changesetファイルでリリース内容を決定するのが最大の特徴
- vs. semantic-release: commit messageから自動で生成する機能はなく、Changesetは手動で書く
- PRにChangesetが含まれているかをチェックするchangeset-botがある
- リリースの最小単位はcommitではなく、Changesetファイルという考え方
- vs. ship.js: Changesetと同じくリリースタイミングを制御できるが、ship.jsはリリース用のPRを作成するという考え方
- Changesetsはリリースするタイミングのみ手動で、それ以外は自動