|
| 1 | +--- |
| 2 | +name: vgv-very-good-analysis-upgrade |
| 3 | +description: Upgrade very_good_analysis lint package to new version across Dart/Flutter projects. Handles version bump, lint fixes, and PR creation. |
| 4 | +allowed-tools: Read,Glob,Grep,Bash |
| 5 | +--- |
| 6 | + |
| 7 | +# Upgrade very_good_analysis |
| 8 | + |
| 9 | +This skill guides the full upgrade of `very_good_analysis` in a Dart or Flutter project. |
| 10 | +The goal is a clean, focused PR: nothing more than the version bump in `pubspec.yaml` plus |
| 11 | +the minimal code changes needed to satisfy any new lint rules introduced in that version. |
| 12 | + |
| 13 | +--- |
| 14 | + |
| 15 | +## Core Standards |
| 16 | + |
| 17 | +These standards apply to every `very_good_analysis` upgrade. |
| 18 | + |
| 19 | +- **Keep the PR focused** — include only the version bump and required lint fixes |
| 20 | +- **Fix only new warnings** — do not address pre-existing issues in the same PR |
| 21 | +- **Avoid behavior changes** — if a lint fix alters runtime behavior, flag it for review |
| 22 | +- **Verify with analysis** — end with a clean `flutter analyze` or `dart analyze` |
| 23 | + |
| 24 | +--- |
| 25 | + |
| 26 | +## Before You Start |
| 27 | + |
| 28 | +Confirm two things before proceeding: |
| 29 | + |
| 30 | +1. **Target version** — if the user didn't specify a version, fetch the latest from the pub.dev API |
| 31 | + and use that. Don't ask — just look it up and proceed: |
| 32 | + |
| 33 | + ```bash |
| 34 | + curl -s https://pub.dev/api/packages/very_good_analysis | jq -r '.latest.version' |
| 35 | + ``` |
| 36 | + |
| 37 | + Tell the user which version you're upgrading to before making any changes. |
| 38 | +
|
| 39 | +2. **Project scope** — is this a single package or a monorepo? In a monorepo, each sub-package |
| 40 | + with its own `pubspec.yaml` needs its own bump (and potentially its own PR). |
| 41 | +
|
| 42 | +--- |
| 43 | +
|
| 44 | +## Step 1 — Bump the version in pubspec.yaml |
| 45 | +
|
| 46 | +Locate the `pubspec.yaml` file(s) for the project. Update the `very_good_analysis` entry under |
| 47 | +`dev_dependencies`: |
| 48 | +
|
| 49 | +```yaml |
| 50 | +dev_dependencies: |
| 51 | + very_good_analysis: ^x.y.z # replace x.y.z with the target version |
| 52 | +``` |
| 53 | +
|
| 54 | +Keep the caret (`^`) prefix — that's the VGV convention. Don't change anything else in the file. |
| 55 | +
|
| 56 | +After editing, run: |
| 57 | +
|
| 58 | +```bash |
| 59 | +flutter pub get |
| 60 | +``` |
| 61 | +
|
| 62 | +(For a pure Dart package without Flutter, use `dart pub get` instead.) |
| 63 | +
|
| 64 | +Use the Dart/Flutter MCP server if it is connected and exposes pub commands; otherwise run via Bash. |
| 65 | +
|
| 66 | +--- |
| 67 | +
|
| 68 | +## Step 2 — Run flutter analyze |
| 69 | +
|
| 70 | +```bash |
| 71 | +flutter analyze |
| 72 | +``` |
| 73 | +
|
| 74 | +Or for a pure Dart package: |
| 75 | +
|
| 76 | +```bash |
| 77 | +dart analyze |
| 78 | +``` |
| 79 | +
|
| 80 | +Capture the full output. You're looking for new warnings or errors introduced by the version bump — |
| 81 | +lints that weren't flagged before. Ignore pre-existing issues unrelated to the bump (don't fix |
| 82 | +things that were already broken; that belongs in a separate PR). |
| 83 | + |
| 84 | +--- |
| 85 | + |
| 86 | +## Step 3 — Fix the lint warnings |
| 87 | + |
| 88 | +Work through the warnings one by one. Keep fixes **minimal and lint-compliance-only**: |
| 89 | + |
| 90 | +- Fix only what `flutter analyze` flags |
| 91 | +- Don't refactor, rename, or reorganize anything beyond what's needed |
| 92 | +- Don't fix pre-existing lint warnings that existed before the bump |
| 93 | +- If a warning looks like it might require a behavioral change (not just style), flag it for |
| 94 | + human review rather than silently fixing it |
| 95 | +
|
| 96 | +After fixing, re-run `flutter analyze` to confirm zero warnings remain. |
| 97 | +
|
| 98 | +--- |
| 99 | +
|
| 100 | +## Step 4 — Verify the fix is complete |
| 101 | +
|
| 102 | +Run the full analyze pass one more time to make sure nothing was missed: |
| 103 | +
|
| 104 | +```bash |
| 105 | +flutter analyze |
| 106 | +``` |
| 107 | +
|
| 108 | +Expected output: `No issues found!` (or only pre-existing issues that you haven't touched). |
| 109 | + |
| 110 | +If new warnings appear that weren't there after Step 2, address them now. If warnings persist |
| 111 | +after multiple attempts, list them explicitly and ask the user how they'd like to proceed. |
| 112 | + |
| 113 | +--- |
| 114 | + |
| 115 | +## Step 5 — Create the PR |
| 116 | + |
| 117 | +Stage only the changed files: |
| 118 | + |
| 119 | +```bash |
| 120 | +git add pubspec.yaml pubspec.lock # always include these |
| 121 | +# plus any .dart files you edited for lint fixes |
| 122 | +``` |
| 123 | + |
| 124 | +Commit with a clear message following the project's conventions. A good default: |
| 125 | +
|
| 126 | +``` |
| 127 | +chore: upgrade very_good_analysis to x.y.z |
| 128 | +
|
| 129 | +Bump very_good_analysis from <old> to <new> and resolve |
| 130 | +lint warnings introduced by newly enabled rules. |
| 131 | +``` |
| 132 | +
|
| 133 | +Then push and open a PR. The PR should contain **nothing else** — no feature work, no unrelated |
| 134 | +refactors, no extra cleanup. Reviewers should be able to see at a glance that this is purely |
| 135 | +a lint compliance update. |
| 136 | +
|
| 137 | +If the project uses a PR template, fill it in. Mention specifically which rules were newly |
| 138 | +enabled if any warnings required code changes. |
| 139 | +
|
| 140 | +--- |
| 141 | +
|
| 142 | +## Tips and edge cases |
| 143 | +
|
| 144 | +**Monorepos**: Each package that depends on `very_good_analysis` needs its own `pubspec.yaml` |
| 145 | +bump. You can often run `flutter analyze` from the repo root to surface all warnings at once, |
| 146 | +but `pub get` must be run per-package. |
| 147 | +
|
| 148 | +**analysis_options.yaml**: `very_good_analysis` ships its own `analysis_options.yaml` that is |
| 149 | +included by the project's own options file. You generally don't need to touch the project's |
| 150 | +`analysis_options.yaml` — the bump in `pubspec.yaml` is sufficient to pull in the new rules. |
| 151 | + |
| 152 | +**Breaking rule changes**: Occasionally a new version disables a rule that was previously |
| 153 | +enabled, or changes its severity. That might cause previously-flagged issues to disappear, |
| 154 | +which is fine — don't re-introduce them. |
| 155 | +
|
| 156 | +**flutter pub get fails**: If dependency resolution fails after the bump (version conflicts), |
| 157 | +investigate the conflict before proceeding. Don't force-upgrade other dependencies just to |
| 158 | +make the bump work — surface the conflict to the user. |
| 159 | + |
| 160 | +--- |
| 161 | + |
| 162 | +## Additional Resources |
| 163 | + |
| 164 | +See [reference.md](reference.md) for a quick-reference table of common lint rules introduced by `very_good_analysis` upgrades and their typical fixes (`prefer_const_constructors`, `use_super_parameters`, `unnecessary_late`, `avoid_dynamic_calls`, `require_trailing_commas`, `unnecessary_null_checks`). |
0 commit comments