モノレポ構成

モノレポとは

モノレポは、関連する複数のパッケージを1つのリポジトリに置く構成です。対義語はポリレポ(パッケージごとに別リポジトリ)です。

repo/
├─ package.json          # workspaces を宣言
├─ src/                  # 公開アプリ
└─ apps/
   └─ admin/             # 管理画面(別パッケージ)

{ "workspaces": ["apps/*"] }

「1つの巨大なアプリ」ではありません。 パッケージは分かれたまま、置き場所と履歴を共有します。

何が変わるか

最大の利点は横断変更が1つのPRに収まることです。共通ライブラリの破壊的変更と、それを使う側の追随を同時にレビューできます。ポリレポではここが「先にライブラリを出して、次に利用側」という手順になり、途中の状態が壊れます。

代償はCIの時間

パッケージが増えるほど、全部を検査すると遅くなります。そのため [[CI/CD]] 側で「何が変わったか」による絞り込みが必要になります。

• 変更されたパスで判定する — 文書だけの変更ならビルドとE2Eを飛ばす、など
• 依存関係をたどる — 共通パッケージが変わったら、それを使うパッケージも検査する
• キャッシュを効かせる — 依存の導入とビルド成果物を再利用する

この絞り込みを入れないままパッケージを増やすと、PRごとに全部が走ってCIが待ち時間の中心になります。 モノレポで失敗する典型がここです。

設定は共有するか分けるか

• 共有するもの — リント規則、書式、コミット規約、[[ブランチ戦略]]。揃っていないと横断変更のたびに衝突します
• 分けるもの — 各パッケージのビルド設定、テスト設定、依存。パッケージの性質が違えば無理に揃えません

判断の目安は「横断変更のときに邪魔になるか」です。邪魔になるものは共有し、パッケージ固有の事情は分けます。

言語ごとの仕組み

• npm / pnpm / yarn workspaces — JavaScript。ルートの workspaces にパッケージを列挙する
• [[Cargoワークスペース構成]] — Rust。Cargo.lock を全体で1つ持ち、再ビルド範囲が分かれる
• Nx / Turborepo — 依存グラフから「変更の影響を受けるパッケージ」だけを再ビルドする層を足すツール

仕組みは違っても、依存の向きを一方通行に保つという設計の要点は共通です。相互依存が生まれると、分けた意味が消えて再ビルド範囲も広がります。

初学者向けポイント

• ルートの設定ファイルがすべてのパッケージに効くとは限りません。除外設定に含まれていないパッケージが検査対象になっていた、という取りこぼしが起きます
• パッケージ間の参照はビルド順に依存します。片方がビルドされていないと型が見つからないエラーになります
• [[マイクロサービス]] とは無関係です。サービスを分けるかどうか(実行時の話)と、リポジトリを分けるかどうか(開発時の話)は独立して決められます

関連技術とのつながり

• [[Git]] — 履歴が1本に揃うことが横断変更の前提になる
• [[CI/CD]] — 変更範囲による絞り込みを入れないと待ち時間が増える
• [[ブランチ戦略]] — 複数パッケージが同居するため運用の取り決めが要る
• [[Cargoワークスペース構成]] — Rust における同じ構成の実装
• [[マイクロサービス]] — 実行時の分割。リポジトリの分割とは独立した判断

Q: モノレポの最大の利点はどれ?
- [ ] リポジトリの容量が小さくなる
- [x] 複数パッケージに跨る変更を1つのPRで完結できる
- [ ] CIの実行時間が必ず短くなる
解説: 共通ライブラリの変更と利用側の追随を同時にレビューできます。CIはむしろ絞り込みを入れないと遅くなります。

Q: モノレポで失敗する典型的な原因はどれ?
- [x] 変更範囲による絞り込みを入れず、PRごとに全パッケージを検査してしまう
- [ ] パッケージを分けすぎること
- [ ] Gitの履歴が1本になること
解説: パッケージが増えるほど全件検査は遅くなり、CIが待ち時間の中心になります。

Q: モノレポとマイクロサービスの関係として正しいのはどれ?
- [ ] モノレポではマイクロサービスにできない
- [x] リポジトリを分けるか(開発時)とサービスを分けるか(実行時)は独立して決められる
- [ ] マイクロサービスは必ずポリレポにする
解説: 別々の判断軸です。モノレポで複数サービスを管理する構成も一般的です。