依存パッケージ管理

アプリ（apps/*）と共有パッケージ（packages/*）の両方を対象とする。

バージョン範囲の指定

バージョンはキャレット（^）による範囲指定を基本とする。上限を持たない >= は使わない。バージョンを1点へ固定するのは、パッケージマネージャの指定のように、揺れると環境全体が壊れる箇所に限る。

バージョンの集約

共通して使う依存のバージョンは pnpm-workspace.yaml の catalog に集約し、各 package.json は catalog: 参照で引く。catalog に載せるのは、2つ以上のパッケージが使う外部依存とする。単一のパッケージでしか使わない依存は、その package.json へ直書きする。内部の共有パッケージは workspace: プロトコルで参照する。

再現性の担保

pnpm-lock.yaml はリポジトリへコミットする。CI では pnpm install --frozen-lockfile を用い、lockfile と package.json がずれていればインストールを失敗させる。

更新の進め方

• 依存の更新は意図して行い、lockfile の差分をレビューで確認する。
• メジャーバージョンの更新では、公式の移行手順と破壊的変更を確認する。
• 更新後は lint・型検査・ビルド・テストで振る舞いを確かめる。
• セキュリティ修正は優先して取り込む。

新規依存の扱い

依存を増やす前に、本当に必要かを吟味する。標準の機能や既存の共有パッケージで賄えるなら、外部の依存を足さない。

汚染版への備え

依存の取り込みでは、供給網（サプライチェーン）の汚染に備える。

• 依存がインストール時に実行するスクリプトは既定で止め、ビルドが必要なパッケージだけを許可する。
• 公開されて間もないバージョンはすぐに取り込まず、一定の期間を置いてから使う。ただしセキュリティ修正は、期間を待たずに取り込む。

アプリと共有パッケージの違い

アプリ（apps/*）は範囲指定でよい。共有パッケージ（packages/*）は範囲を狭めすぎず、利用側と共有する依存は peer 依存として宣言する。