ざっと作ったmonorepoをメンテナブルにするまでに必要なこと [ODIN]

turborepoでざっと作ったmonorepoが、それぞれのパッケージやアプリ間で複雑な依存関係を作るようになったため、ビルドが通らなくなったり、ビルドが通ったら手元の開発環境が動かなくなったりしました。その状態からメンテナブルにするまでのステップを調査しました。

ebiyy

あるべきmonorepo構造として、サブパッケージをただの役割の分離とせず、プライベートNPMパッケージとしたほうが、同様のエラーもなくなります。最初は大変なものの、あるべきmonorepo構造になると思われます。

ebiyy

こちらがあるべきmonorepo構成としてわかりやすい。
詳細はリンク先

input CHANGELOG
git push with modify code
merge (base branch)
git action -> auto gen PR
PR merge -> npm package release
npm package option upload (codecov)

こちらも

ebiyy

monorepoにプライベートnpm packageを含む方法

ebiyy

セマンティックバージョンの考え方

major: 大規模な変更や互換性のない変更があった場合に、1つ上げます。
minor: 互換性のある新機能が追加された場合に、1つ上げます。
patch: バグ修正が行われた場合に、1つ上げます。
セマンティックバージョニングの判断基準は、変更内容によって異なります。以下に、一般的に考慮される要素を示します。

大規模な変更や互換性のない変更があった場合は、majorを上げます。例えば、API仕様が大幅に変更された場合や、重大なバグが発生している場合にmajorを上げます。
互換性のある新機能が追加された場合は、minorを上げます。例えば、新しい機能が追加された場合や、既存の機能が改善された場合にminorを上げます。
バグ修正が行われた場合は、patchを上げます。例えば、脆弱性の修正や、機能の改善などが含まれる場合にpatchを上げます。

gen chat gpt