monorepo

モノレポスタイル開発はソフトウェア開発手法です。このような：

複数のプロジェクトが、同一リポジトリ内にある

プロジェクトは相互依存可能で、コードも共有できる

変更を行う場合、モノレポでは全てのプロジェクトで再ビルドや再テストをしない。その代わり、変更の影響を受ける可能性のあるプロジェクトだけを再ビルドと再テストする

利点

モノレポはコードの共有とプロジェクトをまたがるリファクタリングをシンプルにし、ライブラリやマイクロサービスとしてマイクロフロントエンドの作成コストを大幅に下げます

CIが高速になる。大規模な場合は1000倍早くなる

チームがモノレポ内でも独立して活動できる。もし2つのプロジェクトAとBが相互依存でない場合、どんなときも相互に影響を及ぼすことはありません。

チームBに...壊れたテストがあったとしても、チームAは、まったく気にしなくていいです。

ツールによってコードへの依存関係をpolyrepoよりも強制できる

リポジトリ内のライブラリへメタデータを追加することで、それを基にした制約を定義することが可能です。たとえば、プレゼンテーションコンポーネントがステートを管理するコードに依存できないことを静的に保証できます。

多くのツールではフォルダごとに所有権を設定できる

Github CODEOWNERS

あなたがアプリAを更新するプルリクを出したら、スーザンが承認する必要があります。もし、アプリBのみを触る場合はボブが承認します。また、プルリクがAとBに触れる場合、スーザンとボブの承認が必要です。

便利なサポートツールがある

相互依存のグラフを生成できる

Nxならnx dep-graph

それぞれツールが違って覚えること多い

リポジトリまたぎのコードシェアが難しい

packageを作る必要がある

リポジトリの間で互換性のない3rd partyのバージョンの問題

結構解決されてない？

結果、shared repoを誰も立てたがらないので基本コピーになる

共有ライブラリのバグや破壊的変更があったと気にパッチ当てるのが大変

monorepoだとバージョン違いは起きないと言っている

欠点

開発体制は再考する必要があるかも

長期にわたるfeatureブランチは許容されないため、即座にレビューをするような体勢を作る必要がある

monorepo で最も感じる変化は、Pull Request を作る時かもしれません。

通常リポジトリが複数ある場合、Pull Request は変更に影響がある各リポジトリに作り、順序よくマージし、バージョンの依存関係を更新しなければなりません。

monorepo では、1つの Pull Request に複数のコンポーネントの変更を含められるため、機能変更の依存管理がしやすく、Pull Requestごとのデプロイ環境の提供が容易になります。

実際に、メルカリ Shops では Pull Request ごとに独立した環境をデプロイする機能が稼働しており、 monorepo の恩恵を受けて開発しています。

monorepo で開発をすると、全ての変更、Pull Request が目に入ることになります。

リポジトリを分割した場合、通常は自分が担当するリポジトリしか見ないことが多い

monorepo では自分が普段関わらない領域の変更も目に入ってくるため、システム全体がどういった変更がなされているのか、何が起きているかのトラッキングがしやすくなります。

yarn/npmとの併用は困難