pnpm、そろそろ移行していいのでは

Transcript

1. 技術LT pnpm、そろそろ 移行していいのでは AI時代のgit worktree並列運用と、インフラ側の「めんどくさそう」の正体 赤神 青空 スカラコミュニケーションズ ／ ソーシャル・エックス
2. ▪ 話す人 スカラコミュニケーションズ／ソーシャル・エックス 自治体向けサービスやAIプロダクトの設計・開発 個人でもiOSアプリを企画から運用まで一人で 身近な「ちょっと困った」を起点にしたものづくり ふだんの道具 TypeScript / NestJS AWS CDK / Lambda / RDS Swift / SwiftData Claude Code 業務のAWS構成と個人開発の両方でぶつかった話をします。 今ココ 導入 2 / 15
3. ▪ブランチを切り替えるのでも、リポジトリを複製するのでもない worktree は、履歴を共有したまま場所を増やす $ git worktree add ../feat-a feat-a git switch 場所は1つのまま、中身を入れ替え る。 作業中の変更は退避が要る。 2つのブランチを同時に見られな い。 git clone 履歴ごと複製するので独立して動け る。 ディスクと fetch が重い。 リポジトリ自体が増える。 git worktree 履歴（.git）は1つのまま共有。 作業ディレクトリだけが増える。 同じブランチは二重に開けない。 消すときは git worktree remove。ディレクトリを直接消すとメタデータが残る（git worktree prune で掃除）。 今ココ 導入 3 / 15
4. ▪エージェントを並列で走らせると、作業ディレクトリはどんどん増えていく git worktree が、日常の道具になった worktree / feat-a Claude Code が作業中 main repo ひとつの履歴 worktree / feat-b Claude Code が作業中 worktree / fix-c Claude Code が作業中 ブランチを切り替えるのではなく、ブランチごとに「場所」を持つ。 今ココ 課題 4 / 15
5. ▪.gitignoreでも、node_modules は付いてこない 対象 ＝ git 管理外。新しい worktree の中身は空っぽ ◯ git が持ってくる ソースコード package.json lockfile 各種設定ファイル ✕ 持ってこない node_modules .env ビルド成果物 ローカルのキャッシュ worktree を作るたびに npm install が必要になる。 今ココ 課題 5 / 15
6. ▪worktree向き合い方は3つある ごとの node_modules 問題を、どう処理するか ① 毎回 install 一番安全で事故らない。 ただしディスクと時間を worktree 数 だけ食う。 今ココ pnpm という選択 ② pnpm に乗り換え ストアを共有するので、増えてもほ ぼ無コスト。 並列運用と相性がいい。 ③ symlink で共有 依存が完全に同じなら動く。 ブランチ間で依存がズレた瞬間に壊 れる。 6 / 15
7. ▪content-addressable pnpm は「実体をひとつ」にする なグローバルストア ＋ ハードリンク worktree A / node_modules worktree B / node_modules ~/.pnpm-store 実体はここに1つだけ worktree C / node_modules リンクを張るだけ npm は worktree ごとにフルコピー。pnpm はリンクを張るだけ。 2回目以降の install は、ネットワークもディスクコピーもほぼ発生しない。 今ココ pnpm という選択 7 / 15
8. ▪ ここで手が止まった 「pnpm は使いたい。けど、AWS 側でめんどくさいことになりそうで踏み切れ ない」 順番が逆だった。 めんどくさいのは「pnpm を使うこと」ではなく、 「今の構成がどうなっているかを確認していないこと」だった。 今ココ インフラの不安 8 / 15
9. ▪pnpm踏みうる地雷は、たった4つ 移行が AWS 構成に影響しうるポイントを、全部並べてみる ① Lambda の手動 zip ② phantom dependency ③ Amplify のビルド ④ CI のキャッシュ node_modules をそのまま zip すると、symlink 構造のま ま入って実行時に壊れる。 corepack enable か pnpm のバージョン明示が必要。設定 を一度触るだけ。 package.json に書いていない間接依存が、移行直後に軒並 みエラーになる。 setup-node のキャッシュ指定変更と pnpm/action-setup の追加。軽微。 ピンクが「壊れる」もの、グレーが「設定を直すだけ」のもの。 今ココ インフラの不安 9 / 15
10. ▪NodejsFunction CDK なら、そもそも痕跡が残らない は esbuild で依存をバンドルするので、node_modules の構造が乗らない pnpm の node_modules .pnpm ＋ symlink の特殊な構造 ▶ esbuild でバンドル NodejsFunction が自動で実行 ▶ 単一ファイルの .js symlink はゼロ／node_modules も無 い デプロイ成果物に、pnpm だったことの痕跡は残らない SAM + esbuild プラグインでも同じ。手動 zip のフローが残っていないかだけ確認する。 今ココ 結論と手順 10 / 15
11. ▪npm の残る宿題は phantom dependency だけ flat な構造では、書いていない依存も import できてしまっていた npm（flat） package.json に書いていない間接依存も import できる。 書き漏れに気づけない。 pnpm（厳格） 書いていないものは import できない。書き漏れが移行直後 に一気に表面化する。 @aws-sdk/* を直接依存に書いていなかった、が典型例 対処は「ビルドとテストを一度流して、赤くなったものを package.json に足す」だけ 今ココ 結論と手順 11 / 15
12. ▪技術的には可能。ただし 「ローカルだけ pnpm」は、やめておく lockfile の二重管理が地味に重い ✕ ローカル pnpm / リモート npm lockfile が2つになる 片方だけ更新する事故が起きる 依存解決の差でバージョンがズレる ローカルは通るのに CI で落ちる ◯ どちらも pnpm に揃える lockfile は pnpm-lock.yaml だけ CI も Amplify も pnpm で動かす corepack でバージョンを固定 再現性がそのまま担保される Amplify も CodeBuild も pnpm をサポートしている。分ける理由があまり無い。 今ココ 結論と手順 12 / 15
13. ▪ローカルで試すだけなら10分。地雷の有無は、実測してから判断する 移行は、だいたい4ステップ 1 2 3 4 pnpm import で package-lock.json から変換し、pnpm install pnpm build で、Lambda 用バンドルが今まで通り出るか確認 CI を直す（setup-node のキャッシュ、pnpm/action-setup） amplify.yml に corepack enable を足す 手動 zip が残っていた場合も、--shamefully-hoist で従来どおりの構造は作れる（pnpm の利点は一部捨てることになる）。 今ココ 結論と手順 13 / 15
14. ▪install速くなると、詰まる場所が移る が速くなっても、並列運用の障害は別のところに現れる ▪ worktree 作成スクリプトに pnpm install を組み込む 作った瞬間に使える状態にして、手動 install をゼロにする ▪ .npmrc で store-dir を固定する 既定でも共有されるが、明示しておくと事故りにくい ▪ 並列実行時のポート・テスト DB の衝突 worktree 名からポートを決めるなど、環境の分離が別途必要になる node_modules が速く揃うようになると、次はポートが足りなくなる。 今ココ まとめ 14 / 15
15. ▪ まとめ ▪ worktree を並列で回す運用は、pnpm の設計思想と相性がいい ▪ 「インフラがめんどくさそう」の大部分は、esbuild が既に消している ▪ 止まっていた理由は構成ではなく、確認していなかったことだった 怖いと思っていたものは、一度手を動かすと消えることがある 今ココ まとめ 15 / 15