Gérer le nouvel arbre de dépendances npm@3

Jusqu’à récemment, l’outil CLI de Snyk ne prenait en charge que npm@2. Tout a changé avec la sortie de snyk@1.9.0, qui a ajouté la prise en charge complète des nouvelles structures de répertoires de npm@3.

Nous souhaitions partager avec vous certains des défis techniques rencontrés et les nouveaux outils développés au cours du processus.

Qu’est-ce qui change avec npm@3 ?

Avec npm@2, les dépendances Node étaient installées dans le répertoire node_modules de chaque package Node concerné. Par exemple, les répertoires du module request se présentent ainsi :

request/node_modules
  ├── aws-sign2
  ├── aws4
  │   └── node_modules
  │       └── lru-cache
  │           └── test
  ├── bl
  │   ├── node_modules
  │   │   └── readable-stream
  │   │       ├── doc
  │   │       │   └── wg-meetings
  │   │       └── node_modules
  │   │           ├── core-util-is
  ...snipped

Comme vous pouvez le voir dans l’extrait ci-dessus, node_modules apparaît déjà à plusieurs reprises. Ce n’est pas si grave, mais cela peut entraîner de nombreuses duplications. Des utilitaires populaires comme lodash peuvent apparaître de très nombreuses fois dans un projet !

À l’origine, npm@2 effectue quelques opérations pour dédupliquer les dépendances, mais npm@3 aplatit complètement cette structure de répertoires afin d’éliminer toute duplication. Avec npm@3, le même package request se présente ainsi :

request/node_modules
  ├── ansi-regex
  ├── ansi-styles
  ├── asn1
  │   └── lib
  ├── assert-plus
  ├── async
  │   └── lib
  ├── aws-sign2
  ├── aws4
  ├── bl
  │   └── test
  ...snipped

Comme vous pouvez le voir, la structure est complètement différente, mais, point important, la façon dont Node charge les modules n’est pas affectée.

Quel est l’impact pour Snyk ?

Pour commencer, la logique de parcours des packages de la CLI a dû être entièrement réécrite. À l’origine, Snyk parcourait votre répertoire node_modules, puis examinait chaque sous-répertoire pour construire une représentation arborescente de vos packages. C’était relativement simple.

Sauf que la structure de répertoires plate de npm@3 ne représente plus du tout les relations entre vos packages. Par exemple, le package async dans la liste npm@3 ci-dessus est en réalité une dépendance du package form-data, lui-même une dépendance de request. Or, impossible de le voir dans l’arborescence des fichiers.

La résolution des packages de Snyk a donc été entièrement réécrite et extraite dans un module autonome appelé snyk-resolve-deps (open source sous licence Apache 2).

Ce module est utilisé dans l’outil CLI snyk, mais peut aussi être installé comme outil CLI autonome (la commande npm install -g snyk-resolve-deps installe un utilitaire appelé snyk-resolve).

snyk-resolve-deps commence par parcourir toute la structure de répertoires pour construire l’arborescence physique. Celle-ci est ensuite transmise à l’étape suivante, qui crée un arbre logique, c’est-à-dire une structure représentant les emplacements depuis lesquels les packages peuvent être chargés.

Les structures de répertoires de npm@2 et npm@3 sont donc toutes deux prises en charge et produisent un arbre virtuel semblable à celui-ci :

❯ snyk-resolve
  request@2.69.1
  ├── aws-sign2@0.6.0
  ├─┬ aws4@1.2.1
  │ └── lru-cache@2.7.3
  ├─┬ bl@1.0.2
  │ └─┬ readable-stream@2.0.5
  │   ├── core-util-is@1.0.2
  ...snipped

En définitive, Snyk peut désormais prendre en charge vos projets installés avec npm@3 aussi facilement que ceux utilisant npm@2. Nous sommes en mesure de trouver les chemins corrects pour appliquer les correctifs et de signaler précisément tous les chemins vulnérables.

En quoi est-ce différent de « npm ls » ?

Si vous connaissez les outils npm, vous avez sans doute déjà entendu parler de npm ls, qui permet d’afficher ces arbres.

La principale différence entre snyk-resolve-deps et npm ls, c’est que notre outil affiche l’arbre logique complet et toutes les voies par lesquelles un package a été intégré à votre projet.

En examinant la façon dont request est inclus dans le code npm (sur la branche 2.x), nous voyons que npm ls nous raconte une histoire (celle de ce qui est disponible sur le disque) :

Notre propre méthode de résolution raconte une autre histoire. Cela ne signifie pas que npm ls se trompe : nous voulons savoir exactement ce qui charge request, et notre outil snyk-resolve-deps peut nous le dire :

Comme vous pouvez le voir, le module request est utilisé comme dépendance par bien plus de packages que vous ne le penseriez au premier abord. Si ce package présentait une vulnérabilité, Snyk connaît désormais précisément les chemins vulnérables.

snyk-resolve-deps

Le package snyk-resolve-deps est disponible dès aujourd’hui sous licence open source Apache 2. Une fois installé globalement, il est accessible sous l’alias snyk-resolve.

L’utilitaire CLI propose différents filtres et options, notamment l’affichage --disk (très similaire à celui de npm ls) et --filter X ainsi que --count X, qui permettent de filtrer et de trouver les occurrences d’une dépendance spécifique. Pour en savoir plus, exécutez snyk-resolve --help.

Vous pouvez dès aujourd’hui exécuter npm install -g snyk pour tester anonymement n’importe quel package ou dépôt GitHub. Avec un compte gratuit, vous pouvez aussi commencer à surveiller vos projets pour détecter les vulnérabilités.