モノレポ（monorepo）とは
複数のプロジェクトやアプリケーションのコードを、一つのGitリポジトリで管理する開発手法のことです。
これは「マルチレポ（multirepo）」という、プロジェクトごとに個別のリポジトリを持つ手法とは対照的なアプローチです。
モノレポの具体的な構成例
モノレポの構成は、親となるリポジトリの中に、複数の独立したプロジェクトが子ディレクトリとして配置されているのが一般的です。
/my-monorepo <-- 親リポジトリ
├── /packages <-- プロジェクトをまとめるディレクトリ
│ ├── /web-app <-- 子プロジェクト1：ウェブアプリケーション
│ ├── /api-server <-- 子プロジェクト2：APIサーバー
│ ├── /ui-library <-- 子プロジェクト3：共通UIコンポーネント
│ └── /shared-utils <-- 子プロジェクト4：共通関数
└── package.json <-- リポジトリ全体の共有設定
この構成では、web-appとapi-serverはそれぞれ独立したアプリケーションですが、両方ともui-libraryやshared-utilsといった共通のコードを簡単に共有できます。
メリット
- コードの共有が簡単：複数のプロジェクト間でライブラリやコンポーネントを簡単に再利用でき、コードの重複を防げます。
- 大規模な変更の効率化：複数のプロジェクトにまたがる変更（例：共通ライブラリのAPI変更）を一度のコミットで安全に行うことができます。
- 一貫性の確保：ビルド設定やコーディングスタイルなどの開発環境を、リポジトリ全体で統一しやすくなります。
デメリット
規模による問題
モノレポには、複数のプロジェクトのコードがすべて含まれています。そのため、リポジトリのサイズが非常に大きくなり、クローンやフェッチに時間がかかることがあります。
- パフォーマンスの低下: リポジトリ全体の履歴が膨大になるため、
git cloneやgit pullのような基本的なGitコマンドの実行が遅くなる可能性があります。 - CI/CDの複雑化: 全てのコードが同じリポジトリにあるため、変更に関係のないプロジェクトのビルドやテストが実行されてしまう可能性があります。これはCI/CDの実行時間を無駄に増やします。
管理上の問題
- アクセス権の管理: 一つのリポジトリに全てのコードがあるため、プロジェクトごとに厳密なアクセス権限を設定するのが難しい場合があります。
- ビルド設定の複雑さ: 各プロジェクトが異なるビルドツールやプログラミング言語を使っている場合、一つのリポジトリで全てのビルド設定を管理するのが複雑になります。
- 学習コスト: モノレポ専用のツール（TurborepoやNxなど）を導入する場合、そのツールの使い方や設定をチーム全体で学ぶ必要があります。
これらのデメリットを、Turborepoのような専用ツールを使うことで大部分は解決できるため、複数リポジトリの管理に不満がある場合は、試してみる価値はあります。
turborepoを使ってみる
インストール
ドキュメントはこちら
pnpm add turbo --globalExampleプロジェクト
ドキュメントはこちら
git clone https://github.com/vercel/turborepo.git
cd turborepo/examples/basic
pnpm install ビルド
monorepo内のすべてのプロジェクトのビルド
turbo build- JavaScriptプロジェクトの場合、apps/*/package.json, packages/*/package.jsonのbuildコマンドを実行する
- apps/webでは、next/build
- apps/docsでは、next/build
- packages/*/には、ビルドコマンドなし
Devサーバーの起動
turbo dev- apps/webでは、next dev –turbopack –port 3000
- apps/docsでは、next dev –turbopack –port 3001