Mettre à jour les dépendances transitives avec PNPM : Corriger les vulnérabilités de sécurité sans tout casser

De nos jours, les vulnérabilités de sécurité sont un problème courant dans le développement logiciel. Heureusement, nous disposons d'outils comme GitHub Dependabot pour nous aider à garder nos dépendances à jour avec une détection automatique et des pull requests.

Cependant, cela ne fonctionne pas toujours comme prévu. Étant donné que certaines dépendances sont transitives, les mettre à jour peut être une tâche difficile pour ces outils car ils ne connaissent pas l'impact des changements et ne savent pas quelle décision prendre en cas de conflits. Nous devons gérer ces cas manuellement.

Méthodes qui ne fonctionnent pas#

• Les commandes officielles comme pnpm up dérangeront votre fichier pnpm-lock.yaml. Il y a un problème à ce sujet qui est toujours ouvert au moment de la rédaction.
• Installer la dernière version de la dépendance directe qui contient la dépendance transitive cible peut ne pas fonctionner. Si la dépendance directe n'a pas mis à jour les définitions de versions, la dépendance transitive ne sera pas mise à jour puisqu'elle a été résolue et verrouillée dans le fichier pnpm-lock.yaml.

La solution#

Le champ overrides est une fonctionnalité puissante dans PNPM qui vous permet de remplacer certaines résolutions de version. Nous allons utiliser cette fonctionnalité pour mettre à jour les dépendances transitives et rendre le changement aussi minimal que possible.

Prenons l'exemple de l'alerte Dependabot ci-dessus. Elle nous indique que le package follow-redirects a une vulnérabilité de sécurité, et la version corrigée est 1.15.6. Cependant, la dépendance directe gatsby utilise axios qui dépend de [email protected].

Étape 1 : Trouver la dépendance transitive#

Il existe de nombreuses façons de localiser la dépendance transitive, mais je recommanderais la manière la plus simple : rechercher dans le fichier pnpm-lock.yaml.

Et "pnpm why" ?

La commande pnpm why <package> est effectivement utile. Cependant, elle peut vous induire en erreur dans ce cas. Par exemple, lorsque je lance pnpm why follow-redirects, voici une partie de la sortie :

En réalité, il n'y a qu'une seule résolution pour follow-redirects dans le fichier pnpm-lock.yaml. La commande pnpm why peut vous montrer plusieurs chemins qui dépendent de la même version du package.

Étape 2 : Ajouter les overrides#

Le cas le plus simple est qu'une seule résolution existe dans le fichier pnpm-lock.yaml. Vous pouvez ajouter l'override directement dans le fichier package.json :

Si vous êtes dans un espace de travail, vous devez ajouter l'override au fichier package.json de la racine de l'espace de travail.

Étape 3 : Appliquer les modifications#

Exécutez pnpm install pour appliquer les modifications. Nous pouvons voir que le package follow-redirects est mis à jour vers 1.15.6 dans le fichier pnpm-lock.yaml avec des modifications minimales.

Vous pouvez maintenant supprimer le champ overrides du fichier package.json pour le garder propre. Ensuite, exécutez à nouveau pnpm install pour valider que les modifications peuvent être appliquées sans le champ overrides.

Dépannage#

Les étapes ci-dessus sont le cas idéal. Les choses peuvent ne pas toujours se dérouler comme prévu. Voici quelques conseils pour résoudre les problèmes :

La version est rétablie après avoir supprimé le champ "overrides"#

Cela peut se produire lorsque le package dépendant a une version fixe ou une plage qui n'inclut pas la version cible. Vérifiez le fichier package.json du package dépendant, dans ce cas, axios, pour voir si cela s'applique.

Le cas échéant, il vous faudra conserver le champ overrides dans le fichier package.json jusqu'à ce que le package dépendant mette à jour les définitions de version.

Il y a plusieurs résolutions pour la dépendance transitive#

Au fur et à mesure que le projet grandit, le fichier pnpm-lock.yaml peut fluctuer avec plusieurs résolutions pour le même package. Par exemple, il peut y avoir deux versions majeures du même package foo :

Le rapport de vulnérabilité indique que [email protected] présente un problème de sécurité qui est corrigé dans 1.0.1, et [email protected] n'est pas affecté. Nous ne pourrions pas simplement ajouter un override pour foo :

• Si nous ajoutons un override "foo": "^1.0.1", le [email protected] sera rétrogradé à 1.0.1. Cela pourrait casser le projet car [email protected] peut proposer de nouvelles fonctionnalités utilisées dans les packages dépendants.
• Si nous ajoutons un override "foo": "^2.0.0", le [email protected] sera mis à jour vers 2.0.0. Cela pourrait casser le projet car [email protected] peut avoir des modifications majeures.

En supposant que foo suive la Gestion Sémantique des Versions, nous pouvons ajouter un override comme ceci :

Cela ne mettra à jour que le [email protected] vers 1.0.1 et gardera le [email protected] inchangé.

Conclusion#

Avant que PNPM ne permette de mettre à jour les dépendances transitives directement, le champ overrides est un bon contournement pour corriger les vulnérabilités de sécurité sans tout casser. J'espère que cet article vous aide à gérer ces cas plus efficacement. Chez Logto, nous utilisons cette méthode pour maintenir nos dépendances à jour et sécurisées.