flutter-dependency-upgrades
Flutter Dependency Upgrades
Upgrade the smallest coherent version set with reproducible evidence. Do not run a collection-wide major upgrade, delete the lockfile, or add an override before understanding the project's constraints and the requested outcome.
Preflight
Read every relevant pubspec.yaml, the effective lockfile or Pub workspace resolution, Flutter/Dart SDK constraints, version-manager files, CI toolchain pins, enabled platforms, native build versions, code generators, generated-file policy, and pending worktree changes. Determine whether the repository is an application or published package because their lockfile and compatibility obligations differ.
Capture a clean baseline with the repository's established dependency retrieval, generation, analysis, tests, and representative target builds. If the baseline is already failing, separate that failure from the upgrade.
Upgrade deliberately
- Define the target: one package, a related package cohort, a security fix, a Flutter/Dart SDK, or a native toolchain requirement.
- Inspect current, upgradable, resolvable, and latest versions plus official changelogs, migration guides, SDK bounds, platform support, and known incompatibilities.
- Change one coherent layer at a time and preserve the repository's version manager, package sources, and architecture.
- Regenerate only through project-owned commands, inspect API and generated diffs, and review every unexpected lockfile change.
- Re-run the baseline checks and supported target builds before expanding the next upgrade cohort.
Use automated fixes only after reviewing their scope. Never treat a successful dependency resolution as proof that source, generated code, native builds, or runtime behavior remain compatible.