vgv-very-good-analysis-upgrade

Par verygoodopensource · vgv-ai-flutter-plugin

Mettre à niveau le package lint `very_good_analysis` vers une nouvelle version dans les projets Dart/Flutter. Gère la montée de version, les corrections de lint et la création de PR.

npx skills add https://github.com/verygoodopensource/vgv-ai-flutter-plugin --skill vgv-very-good-analysis-upgrade

Améliorer very_good_analysis

Cette skill guide la mise à niveau complète de very_good_analysis dans un projet Dart ou Flutter. L'objectif est une PR propre et ciblée : uniquement le changement de version dans pubspec.yaml plus les modifications de code minimales nécessaires pour satisfaire les nouvelles règles de lint introduites dans cette version.


Normes fondamentales

Ces normes s'appliquent à chaque mise à niveau de very_good_analysis.

  • Gardez la PR ciblée — incluez uniquement le changement de version et les corrections de lint requises
  • Corrigez uniquement les nouveaux avertissements — ne pas aborder les problèmes préexistants dans la même PR
  • Évitez les changements de comportement — si une correction de lint altère le comportement à l'exécution, signalez-le pour révision
  • Vérifiez avec l'analyse — terminez avec un flutter analyze ou dart analyze propre

Avant de commencer

Confirmez deux choses avant de poursuivre :

  1. Version cible — si l'utilisateur n'a pas spécifié de version, récupérez la dernière depuis l'API pub.dev et utilisez-la. Ne posez pas de question — consultez simplement et continuez :

     curl -s https://pub.dev/api/packages/very_good_analysis | jq -r '.latest.version'

    Indiquez à l'utilisateur vers quelle version vous effectuez la mise à niveau avant d'apporter des modifications.

  2. Portée du projet — s'agit-il d'un package unique ou d'un monorepo ? Dans un monorepo, chaque sous-package avec son propre pubspec.yaml a besoin de sa propre mise à niveau (et potentiellement de sa propre PR).


Étape 1 — Mettre à jour la version dans pubspec.yaml

Localisez le(s) fichier(s) pubspec.yaml du projet. Mettez à jour l'entrée very_good_analysis sous dev_dependencies :

dev_dependencies:
  very_good_analysis: ^x.y.z # remplacez x.y.z par la version cible

Conservez le préfixe caret (^) — c'est la convention VGV. Ne modifiez rien d'autre dans le fichier.

Après édition, exécutez :

flutter pub get

(Pour un package Dart pur sans Flutter, utilisez dart pub get à la place.)

Utilisez le serveur MCP Dart/Flutter s'il est connecté et expose des commandes pub ; sinon exécutez via Bash.


Étape 2 — Exécuter flutter analyze

flutter analyze

Ou pour un package Dart pur :

dart analyze

Capturez la sortie complète. Vous recherchez les nouveaux avertissements ou erreurs introduits par la mise à niveau de version — les lints qui n'étaient pas signalés avant. Ignorez les problèmes préexistants non liés à la mise à niveau (ne corrigez pas les choses qui étaient déjà cassées ; cela appartient à une PR distincte).


Étape 3 — Corriger les avertissements de lint

Traitez les avertissements un par un. Gardez les corrections minimales et conformes au lint uniquement :

  • Corrigez uniquement ce que flutter analyze signale
  • Ne refactorisez, ne renommez, ne réorganisez rien au-delà de ce qui est nécessaire
  • Ne corrigez pas les avertissements de lint préexistants qui existaient avant la mise à niveau
  • Si un avertissement semble pouvoir nécessiter un changement de comportement (pas seulement de style), signalez-le pour révision humaine plutôt que de le corriger silencieusement

Après correction, réexécutez flutter analyze pour confirmer qu'aucun avertissement ne persiste.


Étape 4 — Vérifier que la correction est complète

Exécutez la passe d'analyse complète une fois de plus pour vous assurer que rien n'a été oublié :

flutter analyze

Résultat attendu : No issues found! (ou uniquement les problèmes préexistants que vous n'avez pas modifiés).

Si de nouveaux avertissements apparaissent qui n'étaient pas là après l'étape 2, traitez-les maintenant. Si les avertissements persistent après plusieurs tentatives, listez-les explicitement et demandez à l'utilisateur comment il souhaite procéder.


Étape 5 — Créer la PR

Indexez uniquement les fichiers modifiés :

git add pubspec.yaml pubspec.lock   # toujours inclure ces fichiers
# plus les fichiers .dart que vous avez édités pour les corrections de lint

Validez avec un message clair respectant les conventions du projet. Un bon défaut :

chore: upgrade very_good_analysis to x.y.z

Bump very_good_analysis from <old> to <new> and resolve
lint warnings introduced by newly enabled rules.

Puis envoyez et ouvrez une PR. La PR ne doit contenir rien d'autre — aucun travail de fonctionnalité, aucune refonte non liée, aucun nettoyage supplémentaire. Les relecteurs doivent pouvoir voir d'un coup d'œil que c'est purement une mise à jour de conformité de lint.

Si le projet utilise un modèle de PR, remplissez-le. Mentionnez spécifiquement les règles nouvellement activées si des avertissements ont nécessité des modifications de code.


Conseils et cas limites

Monorepos : Chaque package qui dépend de very_good_analysis a besoin de sa propre mise à niveau pubspec.yaml. Vous pouvez souvent exécuter flutter analyze à partir de la racine du repo pour mettre à jour tous les avertissements à la fois, mais pub get doit être exécuté par package.

analysis_options.yaml : very_good_analysis fournit son propre analysis_options.yaml qui est inclus par le fichier d'options du projet. Vous n'avez généralement pas besoin de modifier le analysis_options.yaml du projet — la mise à niveau dans pubspec.yaml suffit pour récupérer les nouvelles règles.

Changements de règles majeurs : Occasionnellement, une nouvelle version désactive une règle qui était précédemment activée, ou change sa gravité. Cela pourrait faire disparaître les problèmes précédemment signalés, ce qui est normal — ne les réintroduisez pas.

flutter pub get échoue : Si la résolution des dépendances échoue après la mise à niveau (conflits de version), enquêtez sur le conflit avant de poursuivre. Ne forcez pas la mise à niveau d'autres dépendances juste pour que la mise à niveau fonctionne — signaler le conflit à l'utilisateur.


Ressources supplémentaires

Voir reference.md pour un tableau de référence rapide des règles de lint courantes introduites par les mises à niveau de very_good_analysis et leurs corrections typiques (prefer_const_constructors, use_super_parameters, unnecessary_late, avoid_dynamic_calls, require_trailing_commas, unnecessary_null_checks).

Skills similaires