flutter-layered-architecture-library-update

Flutter-Layered-Architecture / ライブラリ更新

workspace 全体の pub パッケージ版を、ルートの dependency_overrides 経由で揃えて更新する。 SDK（Flutter／Dart 本体）の版調査は対象外。コマンド例は flutter / dart 本体で示す（mise / fvm 等はリポジトリ規約に任せる）。

いつ使うか

• flutter pub outdated で古くなった依存を洗い出すとき
• ルート dependency_overrides の版を上げる／揃えるとき
• 更新後の pub get・解析・テスト・ビルドで妥当性を確認するとき

いつ使わないか

• Flutter SDK の最新版・CHANGELOG 調査 → flutter-maintenance-check-latest-version
• workspace の package 一覧・レイアウト把握だけ → flutter-layered-architecture-workspace
• アプリ起動・ランタイムデバッグ → flutter-app-debug
• 文言／L10n → flutter-monolith-localization
• extension type 等の言語規約だけ → flutter-coding-rules

前提（なぜ overrides か）

Layered Architecture の workspace では、各 package の dependencies は多く any（または緩い制約）にし、実効バージョンはルート dependency_overrides で一括固定する慣習が多い。 個別 package の pubspec.yaml だけを上げても全体が揃わないため、更新の主戦場はルート overrides である。

作業手順

1. 現状を把握する

   • ルート pubspec.yaml の dependency_overrides と environment（sdk / flutter）を読む
   • 必要なら現在の解決結果（lock）も確認する

2. 更新候補を取得する

   flutter pub outdated
   

   • 機械処理するなら flutter pub outdated --json も可
   • Resolvable（および Current / Upgradable / Latest の関係）を見て上げられる版を判断する
   • 互換性や制約で上がらないものはスキップし、理由を残す

3. ルート dependency_overrides を更新する

   dependency_overrides:
     some_package: "^x.y.z"  # 必要に応じて更新
   

   • 子 package 側を ^… に変えず、overrides を正とする（慣習が any の場合）
   • 壊れる見込みが大きいメジャー上げは、CHANGELOG／移行ガイドを見てから、またはユーザー確認後

4. 依存を再解決する

   flutter pub get
   

   • アプリ package（多くは app/）がある場合は、そこでも flutter pub get する
   • iOS の CocoaPods 等は、リポジトリに手順があればそれに従う（無い場合は無理に Podfile.lock 削除を強要しない）

5. 妥当性を検証する（失敗時は次節の切り戻し）

   • Analyzer が通る
   • 関連テストが通る
   • 必要なら対象プラットフォームのビルドが通る

6. 結果を報告する（更新した／スキップした／検証したこと）

「妥当」の判断基準

• Analyzer が Success
• 各種テストが Success
• 最終的なプラットフォームアプリ（Android / iOS / Web 等）のビルドが Success（実施した場合）

問題が起きたときの対処順

1. 対象 package の README / CHANGELOG / 破壊的変更を確認する
2. コンパイルエラーを最小差分で直す
3. パッチ → マイナーの範囲で版を調整する
4. それでも無理なら 元の overrides に切り戻す（無理な上げっぱなしにしない）