GillMacedo/expliquer-les-mises-à-jour-de-dépendances-Go

Explique pourquoi les versions des dépendances de modules Go ont changé entre deux révisions (une référence git ou deux répertoires). Pour chaque module dont la version a été augmentée, ajoutée, diminuée ou supprimée dans la liste de construction, il nomme la dépendance qui a nécessité la nouvelle version et la chaîne de retour vers go.mod, et il liste les dépendances qui ont forcé l'augmentation de la directive go. Utile lors de la révision d'une pull request Dependabot ou Renovate pour un module Go, lorsque go get ou go mod tidy a modifié plus de modules que demandé, ou lorsque la ligne go dans go.mod a augmenté.

Qu'est-ce que expliquer-les-mises-à-jour-de-dépendances-Go ?

Cet outil explique les changements de dépendances entre deux révisions d'un module Go, par exemple avant et après une mise à jour automatique par Dependabot ou Renovate. Il analyse les différences dans le graphe de dépendances en exécutant `go mod graph` et `go list -m -mod=readonly -json all` sur chaque révision (avec GOWORK=off), sans modifier les fichiers go.mod ou go.sum. Pour chaque module dont la version a changé (augmentée, ajoutée, diminuée ou supprimée), il identifie la dépendance racine qui a provoqué ce changement et expose la chaîne de dépendances jusqu'à go.mod. Il signale également les modules qui ont forcé l'augmentation de la directive `go` dans go.mod. L'outil supporte les comparaisons via `--base` (une référence git) ou `--old`/`--new` (deux répertoires). En sortie, il produit un rapport structuré avec des avertissements (WARN) pour tout changement non attendu, et un code de sortie de 0 si aucun avertissement, 1 en cas d'avertissement, ou 2 si le résultat n'est pas fiable (par exemple fichiers go.mod absents ou erreur réseau). Il s'utilise en ligne de commande avec `go run` depuis l'extension Claude.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/GillMacedo/whybumped/tree/HEAD/plugin/skills/explaining-go-dependency-bumps

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Expliquer les mises à jour de dépendances Go

L'outil fourni nécessite Go 1.22 ou plus récent, et git pour --base. Il exécute go mod graph et go list -m -mod=readonly -json all sur chaque révision, avec GOWORK=off. Ces commandes lisent les fichiers go.mod du module et de ses dépendances ; elles ne construisent ni n'exécutent aucun code, et elles ne modifient pas go.mod ou go.sum.

1. Choisir les deux révisions

  • Dans une pull request, l'ancien côté est la base de fusion : git merge-base origin/main HEAD. N'utilisez le nom de la branche que si l'utilisateur le demande.
  • --base REF lit les fichiers go.mod et go.sum de ce commit avec git archive, donc les modifications non validées dans l'arbre de travail constituent le nouveau côté. Utilisez --old DIR --new DIR pour deux répertoires.
  • Exécutez-le dans la racine du module (le répertoire contenant go.mod), ou passez --new MODULE_DIR. Dans un dépôt avec plusieurs modules, exécutez-le une fois par module dont le go.mod a changé.

2. L'exécuter

go run "${CLAUDE_PLUGIN_ROOT}/scripts/whybumped.go" --base "$(git merge-base origin/main HEAD)" --new MODULE_DIR
  • Si la pull request indique ce qu'elle avait l'intention de modifier (un titre Dependabot tel que "Bump google.golang.org/grpc from 1.63.2 to 1.67.1"), passez-le avec --expect google.golang.org/[email protected]. Alors tout autre changement est un AVERTISSEMENT, y compris les modules que go.mod a augmentés de lui-même.
  • Ajoutez --format json pour analyser le résultat.
  • Les dépendances doivent être dans le cache des modules ou téléchargeables depuis le proxy de modules dans l'environnement. Ne modifiez pas GOPROXY, GOFLAGS ou GONOSUMDB sauf si l'utilisateur le demande.

Codes de sortie

0 signifie aucun AVERTISSEMENT (ou --fail-on never). 1 signifie au moins un AVERTISSEMENT. 2 signifie que le résultat n'est pas fiable : le go.mod d'un côté est manquant, vide, tronqué, n'est pas un go.mod ou n'a pas de directive go ; go mod graph ou go list -m a échoué (souvent une entrée go.sum manquante, une version inconnue ou pas de réseau) ; leurs sorties sont en désaccord ; les deux côtés sont des modules différents ; un côté n'a aucune dépendance du tout ; ou la référence --base n'existe pas. Traitez 2 comme inconnu, jamais comme un succès, et montrez l'erreur à l'utilisateur.

Rapport

  1. Commencez par go-raised si présent : l'ancienne et la nouvelle ligne go, la dépendance qui nécessite la nouvelle version et comment elle est entrée dans le graphe. Si go.mod est allé plus loin qu'aucune dépendance ne le nécessite, dites-le.
  2. Regroupez les modifications de module par la ligne "pulled in through" : pour chaque module racine que go.mod exige, listez ce qu'il a augmenté ou ajouté. Ce sont les effets secondaires de cette mise à niveau.
  3. Les modifications requested sont des versions que seul go.mod demande. Pour un module // indirect qui est augmenté au-delà de ce qu'aucune dépendance ne nécessite, dites qu'il a été augmenté manuellement ou par go get -u, et qu'il pourrait rester à la version nécessaire si l'utilisateur souhaite un changement plus petit.
  4. Les modifications lowered et removed indiquent quel demandeur utilisait auparavant l'ancienne version et où ce demandeur est allé. Un module abaissé est une rétrogradation dans la construction ; mentionnez-le clairement.
  5. requirement-dropped signifie que go.mod a perdu une ligne tandis que la construction a conservé la même version via un autre module. go mod tidy fait cela lorsqu'aucun paquet n'a besoin du module. Si l'utilisateur n'a pas exécuté tidy, vérifiez que go.mod n'a pas été endommagé.
  6. Une chaîne passant par une version qui n'est pas sélectionnée est réelle : dans la sélection de version minimale, les exigences de chaque version dans le graphe comptent, même celles qui ont perdu face à une version plus récente.
  7. Ne modifiez pas go.mod sauf si l'utilisateur le demande. S'il souhaite un changement plus petit, la correction habituelle est go get module@version pour le module racine uniquement, puis go mod tidy, et exécutez à nouveau l'outil.

Skills associés