モノレポ

アプリケーションやマイクロサービスの全コードを単一のモノリシックなリポジトリに保存するパターン

ポリレポ

アプリケーションやサービスごとに個別のリポジトリが存在するパターン

ポリレポのメリット

• 開発スピードを高められる
  • 個別のデプロイにより、独立した状態を保ったまま開発ができる
• プロジェクトごとに適切な技術スタックを選択できる
  • 個々のプロジェクトに最適な技術を採用することが可能
• プロジェクトごとにアクセス制御を行える
  • 機密性の高いプロジェクトへのアクセスを制限できる

ポリレポのデメリットと課題

• 横断的な対応が困難
  • ライブラリのバージョン管理が複雑になる
  • 同一ロジックの関数の更新が手間となる
• リンター、フォーマッターなどの設定ファイルがプロジェクトごとに管理されている
  • 更新が漏れているプロジェクトがあり、開発体験に差異が生じる
• 共通して使用しているライブラリがプロジェクトごとに管理されている
  • プロジェクトの数に比例してバージョン管理のコストが増大する
• 同一ロジックの関数がプロジェクトごとに定義されている
  • 更新の際のコストが高くなる
• コマンドを実行する際に、それぞれのプロジェクトのディレクトリに移動する必要がある
• プロジェクト全体を把握するのが難しい

モノレポのメリット

• コードの共有と再利用が容易
  • 共通のコードをリポジトリ内で共有できる
  • コードの重複を減らすことができる
• 横断的な変更が容易
  • 複数のプロジェクトに影響する変更を一度に行える
• 統一された開発環境
  • リンター、フォーマッターなどの設定を一元管理できる
  • 開発者間で一貫した開発体験を提供できる
• バージョン管理の簡素化
  • 単一のリポジトリで全てのプロジェクトを管理できる
  • 依存関係のバージョン管理が容易になる

モノレポのデメリット

• リポジトリのサイズが大きくなる
  • 全てのプロジェクトが単一のリポジトリに含まれるため、サイズが肥大化する
  • クローンやフェッチに時間がかかる可能性がある
• 開発速度が落ちる
  • ビルドとテストに時間がかかる
    • 全てのプロジェクトを一度にビルドやテストする必要があるため、時間がかかる
    • 修正に手間のかかるバグが少しあるだけでビルドできなくなる
• アクセス制御が難しい
  • 単一のリポジトリ内で、プロジェクトごとにアクセス制御を行うのが難しい
• リポジトリの管理が複雑になる
  • 多数のプロジェクトが同じリポジトリ内に存在するため、管理が複雑になる
• 共通コードの変更による影響がでかい
• 個別のデプロイが難しい
  • 単一のリポジトリ内で個別のプロジェクトをデプロイするのが難しい
  • デプロイのたびに全てのプロジェクトが影響を受ける可能性がある

https://circleci.com/ja/blog/monorepo-dev-practices/
https://kaminashi-developer.hatenablog.jp/entry/2023/05/22/goodbye-monorepo
https://qiita.com/john-Q/items/ef7c433a5f441ff89ffb
https://zenn.dev/okmttdhr/articles/a919bb29d9d5c9
https://www.graat.co.jp/blogs/ck1099bcoeud60830rf0ej0ix

GitHub Star History

lerna

• スター数が圧倒的に多い
• 2022年以降は伸びが緩やかになっている
  • 一時メンテナンスが止まっていたことが影響？
  • 現在はNxの開発元であるNrwlが引き継いでいる

Nx

• 2020年以降伸びている

Turborepo

• 2022年以降急激に伸びている
  • VercelがTurborepoを買収した影響？

bazel

• 伸び続けているが2024年あたりでNxに逆転されている
  https://star-history.com/#bazelbuild/bazel&boltpkg/bolt&lerna/lerna&moonrepo/moon&nrwl/nx&vercel/turbo&Date
  

必須要件

• 移行コストをなるべく抑えたい
• ライブラリのバージョン管理コストを下げたい
  • 共通化
  • 段階的にバージョンアップするフローを確率したい
• リンター、フォーマッターなどの設定ファイルを共通化したい

希望要件

• ディレクトリを移動せずにコマンドを実行したい
• ロジックを共通化したい
• 依存関係の可視化

npm trends

• Nxが2022年あたりから急激に伸びており圧倒的なダウンロード数になっている
  https://npmtrends.com/@microsoft/rush-vs-bolt-vs-lerna-vs-nx-vs-turborepo
  

State of JavaScript

https://2024.stateofjs.com/en-US/libraries/monorepo_tools/
npm workspaces, yarn workspaces, pnpmは無視して見る

使用率

• 2023年以降で、Nxが急激に伸びてlernaが落ちている
  

認知度

• 2023年以降で、Nxが急激に伸びてlerna,Turborepoが落ちている
  

興味度

• Turborepo,Nxが高い関心を持たれている
  

ライブラリの比較

https://qiita.com/john-Q/items/ef7c433a5f441ff89ffb#lerna

lerna

• 一時メンテナンスが止まっていたが、現在はNxの開発元であるNrwlが引き継いでいる
• Nxを内包している
• ビルドやテストの最適化をする場合、Nxの機能を使う

Nx

• VSCode と WebStorm/Intellijのエディタプラグインがある
• 他ライブラリと比較すると多機能
• プラグインが豊富
• 独自の概念があり学習コストが高い
• Nextだとバージョンアップが大変という話もある
• 大規模なサービスに向いている

Turborepo

• Vercelが開発している
• 同社のその他のツールとの連携が期待できる
• 必要な設定ファイルが turbo.json のみでシンプル
• Turborepo をやめたい場合に比較的容易に生の yarn Workspaces に戻せる
• 依存関係グラフは無骨

yarn workspaces

できること

• 複数のプロジェクトを1つのリポジトリで管理
• 依存関係の共有
• ロジックの共通化
• 特定のモジュールをワークスペースごとに個別管理

できないこと

• ビルドやテストのキャッシング
• ビルドの最適化
• 並列タスク実行の最適化
• 依存関係グラフの生成