Why monorepo ?

TL;DR

  • monorepoは銀の弾丸ではない
  • frontend / backend 両方を書く場合、GraphQL / Swagger 等を用いた開発の場合などには有用

monorepoの今

JavaScript / TypeScript におけるmonorepoは babel での利用から有名になったかと思います。 lerna の登場以降ライブラリの更新も落ち着き、導入されている企業も多いのではないでしょうか。

メリット・デメリットに関してはいくつか解説の記事があるかと思いますので、この記事ではmonorepo開発のワークフローとその際の注意点などを記載したいと思います。

monorepo開発のワークフロー

Single lint, build, test and release process.

Single lint

build

workspace 内にある複数のpackageを1つのrepository で操作するのに対してメリットを最大限活かすことになると、package間での依存関係が生まれます。

lerna で提供されている --include-dependencies オプションはpackage間の関係を解決するために便利です。

test and release process

  • テストに関してですが、2種類の方法があります
    1. <rootDir>/package.json に共通の設定を定義し、テストを実行する
      • pros
        • 構築が容易
        • 1つのcoverage reportを生成できる
      • cons
        • 複数の前提を持ったアプリのテストに適応が難しい (ex. frontend, backend)
    2. workspace ごとにテストの設定を定義し、個別の設定環境(babel ,tsconfig, etc) を前提にテストを実行する
  • リリースノートに関しては lerna-changelog を採用しています
    • github を使ったリリース管理にはPRをベースとしたリリース管理としてちょうど良いです

CADDi におけるmonorepo導入

一部のプロジェクトにて試験的にmonorepo環境を lerna + yarn workspace 機能を用いて導入しています。

  • GraphQL / gRPC定義の共有
  • マイクロサービス内で利用される共通ライブラリの管理
  • 型定義情報を基準に作成した factory 情報の管理
  • components / hooks といった汎用性の高い関数の提供

抜粋した中の一部ですが、弊社ではこれらをメンテナンスする担当者が共通であることが多いことなどから、統一した管理が行われていることにもメリットを感じています。

また、node.js では依存するdependency が多いこともあり、ライブラリのバージョン管理を行う上でも役に立つ場合があります。

これからmonorepoを始める方に

npm v7よりnpm workspace が利用できるというアナウンスがありましたが、yarn workspacenrwl/nx, lerna/lerna を使わない標準の仕組みでmonorepoができるようになるかもしれません。

monorepo化のデメリットであるプロジェクトが肥大化しそうな場合や、複数dockerファイルを管理する方法などまだまだ改善の余地もありますが、疎結合な設計を行うことでOSS公開への敷居が下がることなどメリットもあります。

便利なものを公開して世の中を良くしてゆきましょう。

Refs