Rubyでもモノリポしたい - 調査、おわわり編 -

Ruby でもモノリポしたい調査、おさわり編 @wtnabe 2025-12-20 (Sat) at ITBP 武蔵 Kanazawa.rb
meetup #160

モノリポって何？例えば Google - そもそもぜーんぶまとまっちゃってる Rails - Active なんとか群のまとまったリポジトリ React
- これも依存パッケージたっぷり

モノリポの動機 1. 依存管理ツールの力不足と煩雑なビルド設定 2. 複数のサブシステムからなる複雑なプログラムをビルドしたい 3. リポジトリをいくつもメンテしたくない

1. 依存管理ツールの力不足と煩雑なビルド設定 JS 向けは恐らくこういうニーズ ( 初期)npm は超富豪的アプローチで依存関係の競合を回避していたとにかくディスクを食う npm link
がうまく動かない問題やたらと多いツールチェイン Babel, Webpack, TypeScript などなどがついて回るクライアントサイドもサーバサイドもカバー Lerna, Turborepo, ...

2. 　複雑なビルド例えばBazel. Google はそもそもモノリポその中で複数言語、複数システムを横断するビルドが必要これ系で学習曲線をもう少し緩めるのが Nx など

3. 複数のリポジトリをメンテしたくないリポジトリとしては一つになっていてほしいが、実態は分かれるフロントエンドとバックエンド複数サブシステムライブラリのコレクションリポジトリがまとまっているとIssue もまとまる

今回の動機は3 ぐだぐだ言わずにまとめたい

要件 JS runtime に依存したくない（もちろんRuby が中心になるので）必要なインフラも増やしたくない（Docker とか）ということで落選は Lerna, Nx,
Rush, Turborepo, ...

実はRuby 製もある kamataryo/monorepo fastlane/monorepo: Scripts to migrate to a monorepo
kjellberg/monoz: Command line tool for managing ruby monorepos. 割と死んでる。現役は monoz くらい？

でも流行ってないこれは予想だけど、そもそもRuby は明示的なビルドプロセスが必要ない Rails のビルドはフロントエンドのアセットのためフロントエンドとバックエンドみたいな分離が起きない module にしてディレクトリ分けとく程度で割となんとかなる

今回はRuby 製は除外将来的にJS/TS 周りも一緒に扱えるようにしておきたかった

moon A developer productivity tooling platform. | moonrepo

Rust 製シングルバイナリでポンと置けば動くインストールが簡単 npm やOS レベルのパッケージマネージャで GitHub Actions のAction
も用意されてる CI でありがたい機能アリ

wtnabe の感じたmoon の考え方基本的にはタスクランナー単純なタスクだけじゃなくて依存関係も記述できる複数のプロジェクトに共通のタスクの定義が楽タスクの実態はプロジェクトの中身次第同じ名前の違う定義のタスクがあってよい

概念 workspace がリポジトリの全体像 project はその中の一ディレクトリに収まっている task はworkspace 全体に適用されるものとproject 固有のものがある

構造 workspace project task project

定義（設定） .moon/ workspace.yml tasks.yml projectA/ moon.yml projectB/ moon.yml

workspace.yml $schema: 'https://moonrepo.dev/schemas/workspace.json' # extends: './shared/workspace.yml' projects: - 'packages/*'

tasks.yml fileGroups: configs: - '.*.yml' - /moon.yml sourcess: - Gemfile
- ... tasks: lock-platform: command: | bundle lock --add-platform arm64-darwin && \ bundle lock --add-platform x86_64-linux config: command: "bundle config set path \"vendor/bundle\""

moon.yml language: ruby

mise と違うのか？ mise-in-place は最近流行りのツールフロントエンド目的、JS 目的ならmise でいいかもセットアップが楽っぽいけど、Ruby だと結局ruby-build moon
もproto という別プロジェクトでセットアップは進める予定目的とプロジェクトが整理されていて好印象

CI 向け機能 Git の使いこなしは要るが、変更のあったファイル群から該当プロジェクトだけCI/CD を適用させることが可能プロジェクトが増えていったらだいぶ効きそう

Rubyでもモノリポしたい - 調査、おわわり編 -

Rubyでもモノリポしたい - 調査、おわわり編 -

wtnabe

More Decks by wtnabe

Other Decks in Programming

Featured

Transcript

Ruby でもモノリポしたい調査、おさわり編 @wtnabe 2025-12-20 (Sat) at ITBP 武蔵 Kanazawa.rb

モノリポって何？例えば Google - そもそもぜーんぶまとまっちゃってる Rails - Active なんとか群のまとまったリポジトリ React

モノリポの動機 1. 依存管理ツールの力不足と煩雑なビルド設定 2. 複数のサブシステムからなる複雑なプログラムをビルドしたい 3. リポジトリをいくつもメンテしたくない

1. 依存管理ツールの力不足と煩雑なビルド設定 JS 向けは恐らくこういうニーズ ( 初期)npm は超富豪的アプローチで依存関係の競合を回避していたとにかくディスクを食う npm link

2. 　複雑なビルド例えばBazel. Google はそもそもモノリポその中で複数言語、複数システムを横断するビルドが必要これ系で学習曲線をもう少し緩めるのが Nx など

今回の動機は3 ぐだぐだ言わずにまとめたい

要件 JS runtime に依存したくない（もちろんRuby が中心になるので）必要なインフラも増やしたくない（Docker とか）ということで落選は Lerna, Nx,

実はRuby 製もある kamataryo/monorepo fastlane/monorepo: Scripts to migrate to a monorepo

今回はRuby 製は除外将来的にJS/TS 周りも一緒に扱えるようにしておきたかった

moon A developer productivity tooling platform. | moonrepo

Rust 製シングルバイナリでポンと置けば動くインストールが簡単 npm やOS レベルのパッケージマネージャで GitHub Actions のAction

概念 workspace がリポジトリの全体像 project はその中の一ディレクトリに収まっている task はworkspace 全体に適用されるものとproject 固有のものがある

構造 workspace project task project

定義（設定） .moon/ workspace.yml tasks.yml projectA/ moon.yml projectB/ moon.yml

workspace.yml $schema: 'https://moonrepo.dev/schemas/workspace.json' # extends: './shared/workspace.yml' projects: - 'packages/*'

tasks.yml fileGroups: configs: - '.*.yml' - /moon.yml sourcess: - Gemfile

moon.yml language: ruby

mise と違うのか？ mise-in-place は最近流行りのツールフロントエンド目的、JS 目的ならmise でいいかもセットアップが楽っぽいけど、Ruby だと結局ruby-build moon

CI 向け機能 Git の使いこなしは要るが、変更のあったファイル群から該当プロジェクトだけCI/CD を適用させることが可能プロジェクトが増えていったらだいぶ効きそう