eckorog2005/claude-skills

Mettre à jour les dépendances

L'objectif est un projet dont les dépendances sont à jour et sans vulnérabilités connues, livré sous forme d'une modification que l'utilisateur peut approuver : chaque étape vérifiée par les propres tests du projet, et chaque étape risquée isolée pour pouvoir être examinée ou annulée individuellement.

Le travail sur les dépendances échoue généralement de deux manières. La première est la mise à jour « big bang », où tout est mis à jour en même temps, quelque chose casse, et personne ne peut dire quelle mise à jour a causé le problème. L'autre est un « correctif » qui cache le problème, comme --force, --legacy-peer-deps, l'assouplissement d'une plage de versions, ou la suppression d'un avis de sécurité. Le workflow ci-dessous est conçu pour éviter les deux.

0. Déterminer ce qui a été demandé

• Vérification uniquement (« y a-t-il des vulnérabilités ? », « qu'est-ce qui est obsolète ? ») : effectuez les étapes 1 à 3, faites un rapport et arrêtez-vous. Ne modifiez pas les fichiers.
• Mise à jour (par défaut pour « mets à jour mes dépendances », « corrige les avertissements d'audit », « maintiens les paquets à jour ») : exécutez l'intégralité du workflow.
• Un seul paquet (« mets à niveau vite vers la v8 ») : effectuez les étapes 1 et 2, puis l'étape 6 pour ce paquet (ainsi que tous les paquets qui doivent bouger avec lui), puis les étapes 7 et 8.

1. Vérification préliminaire

1. Lisez les documents de contribution du dépôt (AGENTS.md, CLAUDE.md, CONTRIBUTING.md) et la configuration CI (.github/workflows/*) pour connaître les commandes de vérification (lint, typecheck, test, build) et la convention des messages de commit. Utilisez ce que le dépôt exécute réellement en CI. Si rien n'est documenté, utilisez les scripts définis dans le manifeste.

2. Assurez-vous que l'arborescence de travail est propre. Si ce n'est pas le cas, arrêtez-vous et demandez. Mélanger le travail non commité de l'utilisateur avec des commits de dépendances cause de réels problèmes.

3. Détectez les écosystèmes par leurs fichiers de verrouillage et manifestes (un dépôt peut en avoir plusieurs) :

   Fichiers	Référence
   package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock	references/node.md
   requirements*.txt, pyproject.toml, uv.lock, poetry.lock, Pipfile.lock	references/python.md
   Cargo.toml / Cargo.lock	references/rust.md
   go.mod / go.sum	references/go.md
   tout autre fichier (Gemfile.lock, composer.lock, …)	utilisez l'outil propre à l'écosystème, plus scripts/osv_check.py pour l'audit

   Lisez le fichier de référence correspondant. Il liste les commandes exactes et les pièges de cet écosystème.

4. Trouvez la version d'exécution ciblée par le projet : .nvmrc, engines, .python-version, requires-python, rust-version, la directive go, ou la version utilisée en CI. Certains paquets doivent suivre l'exécution, pas la dernière version. Par exemple, @types/node doit correspondre à la version majeure de Node sur laquelle le projet s'exécute, donc le mettre à jour vers une version majeure plus récente de Node permet au code d'utiliser des API qui planteraient en production. Considérez « la plus récente » comme un candidat, pas comme une cible.

5. Exécutez les commandes de vérification avant de modifier quoi que ce soit et notez le résultat. Si quelque chose échoue déjà, vous devez le savoir maintenant. Sinon, vous attribuerez à une mise à jour un échec qui existait déjà, ou vous livrerez une branche en échec. Si la ligne de base est rouge, informez l'utilisateur et demandez s'il faut continuer.

2. Inventaire

Collectez deux listes avec les outils de l'écosystème (voir la référence) :

• Vulnérabilités : l'outil d'audit natif. S'il n'est pas installé et ne peut pas être exécuté de manière éphémère, utilisez le scanner intégré : python3 <skill-dir>/scripts/osv_check.py <fichier_de_verrouillage>... (interroge osv.dev ; bibliothèque standard uniquement). Exécuter l'analyse OSV en plus de l'outil natif est peu coûteux et souvent rentable, car les outils natifs manquent parfois des avis de sécurité dans des copies imbriquées ou dupliquées d'un paquet.
• Paquets obsolètes : actuel → souhaité (dans la plage déclarée) → le plus récent.

Pour chaque vulnérabilité, déterminez quelle dépendance directe attire le paquet vulnérable et quelle version de cette dépendance directe la corrige. Les utilisateurs agissent sur les dépendances directes. Un nom de paquet transitive seul n'est pas exploitable.

3. Planifier et rapporter

Classez tout dans trois catégories et affichez le plan sous forme d'un petit tableau avant d'apporter des modifications :

1. Correctifs de sécurité : tout ce qui supprime un avis. Le plus urgent. Si le correctif nécessite une mise à jour majeure, c'est une mise à jour majeure (catégorie 3), mais listez-la en premier et dites qu'elle est motivée par la sécurité.
2. Mises à jour sûres : patch/minor dans le cadre de la gestion sémantique des versions (pour les paquets 0.x, un minor compte comme une rupture).
3. Majeures : tout le reste, une ligne chacune. Regroupez les paquets qui doivent bouger ensemble (un framework et ses plugins, un outil et ses définitions de types, les paquets qui partagent une dépendance homologue) et traitez chaque groupe comme une unité.

La sévérité compte pour l'ordre, et l'accessibilité compte pour l'explication. Un avis critique dans un exécuteur de test réservé au développement mérite toujours d'être corrigé, mais dites clairement qu'il est réservé au développement plutôt que d'alarmer l'utilisateur. Pour les demandes de vérification uniquement, ce rapport est la livraison. Incluez la sévérité, l'ID de l'avis, le chemin de dépendance et la version de correctif.

4. Branche

Créez chore/deps-AAAA-MM-JJ (la date du jour) à partir de la branche par défaut à jour, sauf si l'utilisateur est déjà sur une branche créée pour ce travail.

5. Correctifs de sécurité et mises à jour sûres

1. Appliquez les correctifs de sécurité dans la plage, réexécutez les commandes de vérification et commitez.
2. Appliquez les mises à jour sûres (patch/minor) ensemble, réexécutez les commandes de vérification et commitez. Si la vérification échoue, faites une recherche dichotomique : annulez la moitié du lot et réessayez jusqu'à trouver le coupable, puis retirez-le et traitez-le comme une mise à jour majeure.

Laissez le gestionnaire de paquets écrire le fichier de verrouillage. Ne modifiez jamais les fichiers de verrouillage à la main.

6. Majeures, une unité à la fois

Pour chaque unité majeure, dans l'ordre (celles motivées par la sécurité d'abord, puis les outils fondamentaux avant ceux qui en dépendent, par exemple le compilateur avant le plugin de lint qui en dépend) :

1. Lisez ce qui a changé. Trouvez le guide de migration ou les notes de version pour chaque version majeure que vous franchissez (v2→v5 signifie lire v3, v4 et v5). Les bonnes sources sont le CHANGELOG.md du projet, les versions GitHub, et la page « migration » du site de documentation. Extrayez les changements de rupture qui s'appliquent à ce code source : cherchez les API et clés de configuration supprimées ou renommées.
2. Vérifiez les homologues. Assurez-vous que la nouvelle version satisfait aux exigences des homologues et de l'exécution de tout ce qui l'entoure. Parfois, la dernière version majeure ne peut pas encore être adoptée parce qu'un plugin n'a pas rattrapé son retard. Dans ce cas, prenez la version la plus récente qui fonctionne, et enregistrez ce qui bloque le reste.
3. Mettez à niveau et corrigez. Mettez à jour l'unité, appliquez la migration (renommages de configuration, modifications d'API, codemods si le projet les fournit), et réexécutez les commandes de vérification jusqu'à ce qu'elles réussissent. Corrigez le code correctement. N'affaiblissez pas les tests, n'ajoutez pas de skip, ne taisez pas les erreurs de type avec any ou des échappatoires de style @ts-ignore pour arriver au vert.
4. Commitez l'unité seule, avec les notes de migration dans le corps du message.
5. Sachez quand vous arrêter. Si une unité nécessite une refactorisation importante ou une décision produit (fonctionnalité abandonnée, changement de comportement à l'exécution que vous ne pouvez pas vérifier), ou si vous ne pouvez pas la mettre au vert avec un effort raisonnable, annulez-la proprement (git checkout -- . jusqu'au dernier commit) et enregistrez-la comme différée, avec le blocage spécifique. Une mise à jour majeure différée avec une raison claire est un bon résultat. Un travail à moitié fait ne l'est pas.

7. Re-vérification et ré-audit

Exécutez à nouveau les commandes de vérification complètes et l'audit sur l'état final. Chaque avis doit maintenant être soit corrigé, soit expliqué. Pour un avis que vous n'avez pas pu corriger :

• S'il est transitive et que le parent n'a pas publié de correctif, un override/résolution qui épingle la version transitive corrigée est acceptable uniquement si cette version est sémantiquement compatible avec ce que le parent attend. Vérifiez-le, et notez-le dans la PR pour que quelqu'un le supprime plus tard.
• Si aucune version corrigée n'existe nulle part, dites-le, et évaluez si le chemin de code vulnérable est accessible dans ce projet.
• N'utilisez jamais de mécanismes d'ignorance/liste blanche pour faire passer l'audit silencieusement.

8. Livraison

Les commits suivent la convention du dépôt. Si le dépôt utilise les commits conventionnels et ne dit rien de plus précis, utilisez :

• fix(deps): ... pour un correctif de sécurité sur une dépendance d'exécution
• build(deps): ... pour les mises à niveau, et pour les correctifs de sécurité sur les outils de développement uniquement
• le résumé nomme le paquet et la cible, par exemple build(deps): mise à jour de vitest vers v5. Le corps liste les avis corrigés et les modifications de migration effectuées.

Poussez et ouvrez une PR (gh pr create) sauf si l'utilisateur a demandé autrement ou qu'il n'y a pas de dépôt distant. Utilisez ce corps :

## Résumé
<une ou deux phrases : ce qui a bougé, combien d'avis sont résolus>

## Sécurité
| Avis | Sévérité | Paquet (chemin) | Corrigé par |
|---|---|---|---|

## Mises à jour
| Paquet | De | Vers | Type | Notes |
|---|---|---|---|---|
<Type = sécurité / patch / minor / major ; Notes = modifications de migration effectuées>

## Différé
| Paquet | Plus récent | Pourquoi pas maintenant |
|---|---|---|
<homologue bloqué, nécessite refactorisation, épinglage d'exécution, ... ; « aucun » si vide>

## Avis restants
<aucun, ou chacun avec raison et évaluation d'accessibilité>

## Vérification
<les commandes exactes exécutées sur le commit final et leur résultat>

Terminez par un court résumé dans le chat : le lien de la PR, le nombre d'avis corrigés par rapport à ceux restants, et les mises à jour majeures différées avec des raisons en une ligne.