個別リポジトリから Full Stack TypeScript の モノレポ(Nx)に移行した話

TSKaigi 2024 After Talk

Transcript

1. 個別リポジトリから Full Stack TypeScript の モノレポ(Nx)に移行した話 TSKaigi 2024 After Talk 溝口 晃 @mok_oshi
2. 自己紹介 名前 溝口 晃 (もこし) X: @mok_oshi 所属 techners株式会社 やってること 美容サロン向けの顧客・予約管理システム KaruteKun 技術 TypeScript / ReactNative / Next.js / Node / express ... など
4. • フル TypeScript で構築（Node.js / React / React Native） • バックエンド、アプリ、 Web、など７個ほどのアプリケーションが存在 • これらを個別リポジトリからモノレポに統合した話をします！
5. API サーバー (Node.js) モノレポ移行前 • 複数のアプリケーションを個別のリポジトリで管理 • テスト・デプロイフローも別々に作成 ◦ CI/CD は GitHub Actions で構築 Webアプリ (React) ネイティブアプリ (React Native) 社内ツール (React) … CI/CD CI/CD CI/CD CI/CD …
6. API サーバー (Node.js) モノレポ移行前の課題感 • 開発効率の悪さ ◦ あるフィーチャーを実装するときに ... ▪ リポジトリAで PR を作成してマージ → デプロイ ▪ リポジトリBで RP を作成してマージ → デプロイ ▪ … • 重複コードがコピペで量産される ◦ 特に Web アプリとネイティブアプリは機能がかぶることも 多く、重複コードが乱立 ◦ 言語は TypeScript で統一されていたので、コードの共有 はずっとやりたかった Webアプリ (React) ネイティブアプリ (React Native) 社内ツール (React) … CI/CD CI/CD CI/CD CI/CD …
7. モノレポ移行を決断(2021年) • 当時はまだチームに知見がなかったが、えいやで決断 ◦ 手探りで技術調査... ◦ 新興で勢いがありそうに見えた Nx を選定 ▪ （turborepo は当時まだなかったはず） • Nx では大まかに２種類の構成がある (package-based と integrated) ◦ integrated の形式で移行
8. Nx の package-based と integrated の補足 package-based • パッケージマネージャで提供されているワークスペースの拡張 • package.json を介して他モジュールを参照 integrated • TypeScript の path alias で他モジュールを参照 • 一つの package.json で依存関係を管理（Single Version Policy）
9. Nx の package-based と integrated package-based • パッケージマネージャで提供されているワークスペースの拡張 • package.json を介して他モジュールを参照 integrated • TypeScript の path alias で他モジュールを参照 • 一つの package.json で依存関係を管理（Single Version Policy）
10. Nx の package-based と integrated package-based • パッケージマネージャで提供されているワークスペースの拡張 • package.json を介して他モジュールを参照 integrated • TypeScript の path alias で他モジュールを参照 • 一つの package.json で依存関係を管理（Single Version Policy）
11. Nx の package-based と integrated package-based • パッケージマネージャで提供されているワークスペースの拡張 • package.json を介して他モジュールを参照 integrated • TypeScript の path alias で他モジュールを参照 • 一つの package.json で依存関係を管理（Single Version Policy） Nx-way に乗るためにこちらを選択
12. 移行作業（リポジトリの新設） • 新しいリポジトリを作成し、既存リポジトリのコード をディレクトリに分けて移植 ◦ （コミットログは維持する形で移行） apps/ server/ app/ web/ ope/ … API サーバー (Node.js) Webアプリ (React) ネイティブアプリ (React Native) 社内ツール (React) …
13. 移行作業（依存関係） • プロジェクト横断で一つの package.jsonに なる • 各リポジトリの package.json を 一つに マージ • lock ファイルは作り直し...！ → ライブラリのバージョンを揃えつつ、古いもの は一気にアップデート apps/ server/ app/ web/ ope/ … API サーバー Webアプリ ネイティブアプリ 社内ツール … package.json - yarn.lock package.json - yarn.lock package.json - yarn.lock package.json - yarn.lock package.json yarn.lock [NEW]
14. 移行作業 • テスト・ビルドなどのコマンド整備 • デプロイワークフローの整備 apps/ server/ app/ web/ ope/ … package.json yarn.lock Lint $ nx lint server Format $ nx fmt server Test $ nx test server Build $ nx build server Build $ nx build web …
15. 移行してみて • 開発者体験が良くなった！ ◦ 開発時のスイッチングコストの減少（異なるリポジトリ間を移動して開発したり...レビューのため に異なるリポジトリを交互に確認したり...） ◦ 環境構築が容易に • 少しずつ共通コードを切り出してモジュール化している ◦ 責務を意識。コードの依存関係が少しずつクリーンになっていく ▪ グラフ化もできる ◦ Nx の差分検知（affected）やキャッシュ機能によってテストの効率化 • tRPCが導入できた！（意図せぬ恩恵でした） • Nx の変更に追従するのが大変...