Comment gérer les dépendances npm de votre projet

Il est très courant de trouver des projets qui fonctionnent correctement en production, mais qui ne sont plus activement maintenus : ils sont en production, ils fonctionnent et le client considère le projet comme terminé.

Malheureusement, ce n’est pas tout à fait vrai. Nous avons tendance à oublier qu’un projet terminé et en production a tout de même besoin de maintenance. La plupart des projets doivent encore être révisés, et les incidents doivent être résolus lorsqu’ils surviennent. Si l’on comparait cela à l’achat d’un véhicule, ce serait comme aller chez le concessionnaire, choisir le bon modèle, payer et en profiter aussi longtemps qu’il est utile, sans jamais effectuer d’entretien périodique, n’est-ce pas ? Bien sûr que non — et il en va de même pour les logiciels.

Lors du développement de projets d’API REST ou d’applications CLI avec Node.js, il est très courant d’utiliser npm, le gestionnaire de paquets open source, pour intégrer des frameworks et des outils à ces projets.

Dans une certaine mesure, cette pratique est avantageuse, car elle peut nous aider à réduire le temps de développement. L’intégration de paquets stables, bien testés et maintenus par la communauté répond à certains besoins de notre projet. Toutefois, elle peut aussi se retourner contre nous et devenir problématique.

Nous allons examiner ci-dessous un scénario courant avec un projet Node.js. Certains de ces problèmes surviennent lorsque nous laissons un projet sans surveillance et sans maintenance évolutive ni préventive.

Cas particulier

Imaginez un projet d’API REST avec Node.js en production depuis 2 ans ou plus. Pendant ces deux années, personne n’a pris de mesures pour mettre à jour les dépendances ou les adapter à de nouvelles versions. Le paquet express a servi de framework de base pour les fonctionnalités CRUD. En outre, la bibliothèque jsonwebtoken a été utilisée pour générer des jetons de sécurité, et le paquet moment pour l’internationalisation des dates.

Problèmes possibles

L’utilisation de bibliothèques de dépendances relativement récentes peut constituer le premier problème : nous fondons une partie de notre solution sur des logiciels que la communauté n’a pas testés et dont l’évolution n’est peut-être pas régulière.

Deuxièmement, nous pouvons fonder une partie de notre solution sur des bibliothèques à « contributeur unique », comme je les appelle. Ces dépendances sont développées par une seule personne, qui publie les améliorations, assure la maintenance, résout les incidents et décide finalement, de façon unilatérale, de l’orientation du logiciel. Ces dépendances nous limitent considérablement.

Troisième problème : les dépendances qui en contiennent d’autres. Cela n’est toutefois pas visible au premier coup d’œil ; c’est ce que nous appelons communément le « Node Module Hole ».

Source : https://github.com/JoseJPR/tutorial-nodejs-snyk-vuln-cost/blob/master/assets/video.gif

Découvrez d’autres conseils à ce sujet ici.

Quelques solutions

1. Ai-je vraiment besoin de cette dépendance ?

Dans un projet Node.js, la première source d’information à consulter est sa documentation. La documentation de l’API Node.js propose de nombreux exemples pratiques de ce que nous pouvons réaliser nous-mêmes en utilisant l’API Node.js « nativement », sans dépendances externes.

2. Utiliser des micro-dépendances

Une fois que nous avons établi qu’il nous faut un composant pour répondre aux besoins de notre projet, nous devons trouver le bon. Nous pensons souvent, au premier abord, que le premier résultat qui s’affiche dans une recherche Google (ou dans le moteur de recherche npm) sera le plus adapté. Or, ce n’est souvent pas le cas. Nous devons nous arrêter, réfléchir et analyser quelle part des fonctionnalités de cette bibliothèque nous est réellement utile. Elle fait peut-être bien plus que nécessaire, ajoutant à notre projet une bibliothèque dont une grande partie restera inutilisée.

3. Analyser le marché

Nous devons faire quelques recherches et examiner les différentes options : l’écosystème npm est vaste et propose différentes bibliothèques qui font pratiquement la même chose. Mais laquelle choisir ? Nous pouvons utiliser des outils en ligne tels que Bundlephobia, qui compare la taille des paquets, ou npmtrends, qui compare notamment le volume de téléchargements et les contributions de la communauté.

Ces outils peuvent nous aider à choisir la bonne dépendance. Des informations comme sa taille, l’importance de la communauté qui la maintient, le nombre de versions publiées ces derniers mois ou le nombre de téléchargements peuvent constituer des indicateurs importants à prendre en compte.

4. Utiliser des outils préventifs

Snyk a publié l’extension open source Vuln Cost pour Visual Studio Code, qui permet de visualiser très facilement et rapidement le nombre de vulnérabilités de notre logiciel à partir du fichier package.json, voire de chaque fichier contenant un import de bibliothèque.

Dans un projet Node.js, nous pouvons actuellement injecter des dépendances à l’aide de require et de import, en les ajoutant en totalité ou en partie, si cela est possible. L’image ci-dessous montre clairement le résultat avec le projet décrit précédemment (express + jsonwebtoken + moment) :

Source : https://github.com/JoseJPR/tutorial-nodejs-snyk-vuln-cost/blob/master/assets/video.gif

Pour découvrir d’autres ressources sur l’utilisation de Vuln Cost, consultez les trois vidéos ci-dessous :

• Comment installer l’extension Vuln Cost dans Visual Studio Code

• Utiliser « require » pour importer des bibliothèques JavaScript et vérifier la présence de vulnérabilités

• Importer des bibliothèques JavaScript et vérifier la présence de vulnérabilités

Conclusions

L’un des défis auxquels le secteur des logiciels a toujours été confronté consiste à expliquer à l’utilisateur final que les logiciels doivent être maintenus et évoluer : ils doivent notamment s’adapter aux mises à jour des systèmes d’exploitation, gagner en performance et éliminer les éventuelles failles de sécurité.

Un autre défi consiste à dégager du temps pour que les équipes de développement puissent réfléchir, effectuer des mises à jour et se former afin de trouver les solutions les plus adaptées au développement de logiciels. La première option qui se présente n’est pas toujours la bonne.

Les quatre solutions présentées ci-dessus peuvent vous aider à développer une base de code facile à maintenir, de qualité, évolutive et plus sécurisée.