こんにちは、newmoでソフトウェアエンジニアをしている @yui_tangです。
2024年11月23日に開催されたJSConf JP 2024にて、「Modular Monolith Monorepo -シンプルさを保ちながらmonorepoのメリットを最大化する-」というテーマで発表させていただきました。
スライド:
動画:
https://www.youtube.com/live/2BXwigWGjWQ?feature=shared&t=21596
JSConf JP 2024について
JSConf JPは日本最大級のJavaScriptカンファレンスです。newmoは初めてスポンサーとして本イベントに協賛させていただきました。今年も国内外から多くの開発者が集まり、JavaScriptエコシステムに関する知見が共有される貴重な場となりました。
発表内容
今回の発表では、newmoでプロダクト開発初期から取り組んでいるMonorepoでの開発について、特にModular Monolithの考え方を取り入れた設計アプローチと、それらを実現する為のアプローチの一つとしてのpnpmを活用したOne Version Ruleの実践、そして意思決定プロセスの具体例として、社内UIコンポーネントライブラリのDesign Docsを使った具体的なアプローチを中心にお話させていただきました。
セッション中、オフラインで発表を聞いていただいた方に質問を呼びかけたところ、Monorepoを実践している方が参加者の1/3程度、Modular Monolithを実践している方はいらっしゃいませんでした。そんな中多くの方が当セッションに来ていただきありがとうございました。
Modular MonolithやMonorepoについては、今後も当Tech Blogから情報を発信・共有していければと思います。
Q&Aの公開
以下、発表後に話しかけていただいた方々のQ&Aの一部を整理し記載しておきます。
Design Docsを書くのにどれぐらい時間をかけていますか?
扱うものによると思います。短いものだと1営業日以内で、長いもので5営業日程度です。 Tierが高くなるほどちゃんと調べて書くようになるので、時間をかける気がします。
One Version Ruleだとパッケージのアップデートが難しくなりませんか?
はい。One Version Ruleでは1つのバージョンしか使わないため、パッケージのアップデートをすると全てのアプリケーションに影響があります。基本的にはdefault catalog(catalog:)を使いますが、段階的にパッケージのアップデートをしていく際にはNamed Catalogsが利用できます。
Named Catalogsはあるパッケージのバージョンに名前をつけることができるため、アップデートしたパッケージを参照したいアプリケーションだけNamed Catalogsを参照することで段階的なアップデートが可能です。monorepo内で一時的に複数のバージョンがある状態を許容できるような仕組みになっています。
全てのアプリケーションがアップデートし終わったらdefault catalogsをアップデートして、再びOne Version Ruleを再開できます。
パッケージのアップデートは手動ですか？
当記事執筆時点だと手動です。
手動なのは、現時点だとDependabotやRenovateがpmpm catalogに対応してないためです。
ただし、利用するパッケージの数が線形的に増えないようにしているため、手動でも管理できる数しかありません。 そのため、パッケージの新しいバージョンがリリースされたタイミングで更新しています。
また、カタログの定義で意味あるグループに分けているのでグループ単位でアップデートすることが多いです。 意味のあるグループごとのパッケージでアップデートすることで、アップデート時に注意する点も分かりやすくなり、アップデートがやりやすくなっています。 基本的には自動テストが通ればマージしています。
将来的には自動アップデートにしたいです。この時にカタログのグループごとのPRを出せるようにすることで、人間も追いやすいアップデートが可能になるのではと考えています(グループごとのアップデートはrenovatebotのpackageRulesで実現できます)。
引き続きソフトウェアエンジニアを募集しています
newmoではMonorepoでModular Monolithでアプリを開発していきたいエンジニアを積極的に採用中です！
