Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Rubyでもモノリポしたい - 調査、おわわり編 -
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
wtnabe
December 20, 2025
Programming
52
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Rubyでもモノリポしたい - 調査、おわわり編 -
Kanazawa.rb meetup #160「Rubyでもモノリポしたい」の発表資料です。
wtnabe
December 20, 2025
More Decks by wtnabe
See All by wtnabe
Ruby de Railway Oriented Programming
wtnabe
0
99
Bindanのススメ
wtnabe
0
60
そのオブジェクト、何を保証してくれますか? - GuideRailのススメ -
wtnabe
0
74
Effective Jekyll
wtnabe
0
97
5 min Jekyll/Liquid Plugin cooking
wtnabe
0
60
Ruby de Wasm
wtnabe
0
90
Cloud Native Buildpacksって結局どうなの?
wtnabe
0
76
Decoupled System with Turbo Frame
wtnabe
1
170
join-kanazawarb-or-7years-passed-since-it-was-borned
wtnabe
0
850
Other Decks in Programming
See All in Programming
Signal Forms: Beyond the Basics @ngBaguette 2026 in Paris
manfredsteyer
PRO
0
250
気圧・高度・GPSを記録&可視化するアプリ「Koudo」を作った話
hjmkth
1
240
「なぜそう決めたのか」を残し続ける仕組み ― Notion AI カスタムエージェント × Slack連携による設計判断の自動記録 - NIKKEI Tech Talk #47
niftycorp
PRO
0
170
Snowflake Summitでの新機能 CoCo / CoWork / snowflake-summit-2026-overall-what-new-coco
tatsuhiro
1
130
Signal Forms: Details & Live Coding @enterJS 2026 in Mannheim
manfredsteyer
PRO
0
130
The ROI of Quarkus for Spring Boot Applications
hollycummins
0
120
PHPで使える日時の表現と、その知り方 #frontend_phpcon_do
o0h
PRO
0
240
エージェンティックRAGにAWSで入門しよう!
har1101
8
1.5k
The NotImplementedError Problem in Ruby
koic
1
780
Oxcを導入して開発体験が向上した話
yug1224
4
310
AI時代のUIはどこへ行く?その2!
yusukebe
21
7.1k
Skillsは効率化、Agentsは"自分の拡張"——Builder時代のエージェント編成(CC Night 2026)
wemra
1
130
Featured
See All Featured
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
200
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
71
40k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Bash Introduction
62gerente
615
220k
What does AI have to do with Human Rights?
axbom
PRO
1
2.2k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
2k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
410
Technical Leadership for Architectural Decision Making
baasie
3
410
A Modern Web Designer's Workflow
chriscoyier
698
190k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
160
The World Runs on Bad Software
bkeepers
PRO
72
12k
Transcript
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 を適用させることが可能 プロジェクトが増えていったらだいぶ効きそう