monorepo.tools を読む

https://monorepo.tools/

Monorepo ≠ Monolith

この２つの大きな違いは、パッケージ (ディレクトリ)　同士に明確な境界があるかどうか。境界がなく、依存が複雑になっているものは、Monolithである。

以下のブログに詳しいところは書いてある
https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c?gi=8102c34f08b3

Polyrepo (multi repo)

採用される最も大きな理由としては、Team Autonomy である。影響範囲が明確に閉じているので、チームで意思決定しやすいなどのメリットがある。しかし、独立であることによるメリットもあるけど、チーム間のコラボレーションでいくつかの弊害をもたらす。

• コードの共有
  • Publishしないと使えないとか
• コードの重複
  • 各チームで同じようなコードメンテナンスする羽目になる
  • 共通コンポーネントの切り出し方が重要だが、一般的に難しい
• 共通ライブラリの変更のしづらさ
  • 共通コンポーネントを切り出しても、今度は影響範囲が複雑になる
  • コードの変更がしにくくなり、負債に繋がりやすい
• 一貫していないツール
  • ツールが異なることへの精神的な障壁や学習コスト

Monorepo のメリット

• バージョニングがない
• １つのコミットですべての依存をチェックできる
• 開発者の流動性
  • 同じツールを使っているので、他のチームにcontributeしやすい

Monorepoのデメリットにも触れてほしいな

Monorepo の機能の紹介

• Local computation caching
  • ビルド結果とかをローカルにキャッシュするやつ
• Local task orchestration
  • taskの依存関係に従って、タスクの実行順などを最適化してくれるやつ
• Distributed computation caching
  • ビルド結果とかをリモートにキャッシュするやつ
• Distributed task execution
  • taskを複数の環境で分散実行できるやつ
• Transparent remote execution
  • ローカルから複数の環境 (リモート環境) のコマンドを実行できる
  • Bazelの大きな特徴らしい
• Detecting affected projects/packages
  • 差分ビルド、差分が見つかったら差分に関する依存を見つけて、自動で再ビルドがかかるやつ
• Workspace analysis
  • workspace間の依存関係を分析するやつ
• Dependency graph visualization
  • 依存グラフの可視化するやつ (↑とほぼ同じでは...?)
• Source code sharing
  • コードの共有方法
  • Nxはフォルダー単位で共有できるらしい
    • 普通はnpm packageだが... そもそもあんまりフォルダ単位したくない間ある
• Consistent tooling
  • 説明を見ると、異なる言語のビルドツールを使えるやつっぽい
  • あんまりよくわからん...
• Code generation
  • ビルドの設定など、Templateコードを生成するやつ
• Project constraints and visibility
  • プロジェクトの依存関係のルールの追加とかをするやつ

Nx はできることが多いみたいな表になっているけど、プラグインベースなのでできることが多いのはそのとおりだよねという感想