L’auteur a choisi le Open Internet/Free Speech Fund pour recevoir un don dans le cadre du programme Write for DOnations.
Grâce à des caractéristiques telles que ses bonnes performances d’entrée/sortie (E/S) et sa syntaxe JavaScript bien connue, Node.js est rapidement devenu un environnement d’exécution populaire pour le développement Web back-end. Mais à mesure que l’intérêt grandit, de plus grandes applications sont construites, et la gestion de la complexité de la base de code et de ses dépendances devient plus difficile. Node.js organise cette complexité à l’aide de modules, qui sont des fichiers JavaScript individuels contenant des fonctions ou des objets pouvant être utilisés par d’autres programmes ou modules. Un ensemble d’un ou plusieurs modules est communément appelé paquet, et ces paquets sont eux-mêmes organisés par des gestionnaires de paquets.
Node.js Package Manager (npm) est le gestionnaire de paquets par défaut et le plus populaire dans l’écosystème Node.js. Il est principalement utilisé pour installer et gérer des modules externes dans un projet Node.js. Il est également couramment utilisé pour installer une large gamme d’outils CLI et exécuter des scripts de projet. npm suit les modules installés dans un projet avec le fichier package.json
, qui réside dans le répertoire d’un projet et contient :
À mesure que vous créez des projets Node.js plus complexes, la gestion de vos métadonnées et dépendances avec le fichier package.json
vous fournira des builds plus prévisibles, puisque toutes les dépendances externes restent les mêmes. Le fichier gardera automatiquement la trace de ces informations ; si vous pouvez modifier le fichier directement pour mettre à jour les métadonnées de votre projet, vous aurez rarement besoin d’interagir directement avec lui pour gérer les modules.
Dans ce tutoriel, vous allez gérer des paquets avec npm. La première étape consistera à créer et comprendre le fichier package.json
. Vous l’utiliserez ensuite pour garder une trace de tous les modules que vous installez dans votre projet. Enfin, vous listerez les dépendances de vos paquets, mettrez à jour vos paquets, désinstallerez vos paquets et effectuerez un audit pour trouver des failles de sécurité dans vos paquets.
Pour suivre ce tutoriel, vous aurez besoin de :
package.json
Nous commençons ce tutoriel en configurant le projet exemple : un module Node.js fictif locator
qui obtient l’adresse IP de l’utilisateur et renvoie le pays d’origine. Vous ne coderez pas le module dans ce tutoriel. Cependant, les paquets que vous gérez seraient pertinents si vous les développiez.
Tout d’abord, vous allez créer un fichier package.json
pour stocker des métadonnées utiles sur le projet et vous aider à gérer les modules Node.js dépendants du projet. Comme le suffixe le suggère, il s’agit d’un fichier JSON (JavaScript Object Notation). JSON est un format standard utilisé pour le partage, basé sur des objets JavaScript et constitué de données stockées sous forme de paires clé-valeur. Si vous souhaitez en savoir plus sur JSON, lisez notre article Introduction à JSON.
Comme un fichier package.json
contient de nombreuses propriétés, il peut être lourd à créer manuellement, sans copier et coller un modèle provenant d’un autre endroit. Pour faciliter les choses, npm fournit la commande init
. Il s’agit d’une commande interactive qui vous pose une série de questions et crée un fichier package.json
en fonction de vos réponses.
init
Commencez par configurer un projet afin de vous entraîner à gérer les modules. Dans votre shell, créez un nouveau dossier appelé locator
:
- mkdir locator
Entrez ensuite dans le nouveau dossier :
- cd locator
Maintenant, initialisez l’invite interactive en entrant :
- npm init
Remarque : si votre code doit utiliser Git pour le contrôle de version, créez d’abord le référentiel Git, puis exécutez npm init
. La commande comprend automatiquement qu’elle se trouve dans un dossier compatible avec Git. Si un référentiel distant Git est défini, il remplit automatiquement les champs repository
, bugs
et homepage
de votre fichier package.json
. Si vous avez initialisé le référentiel après avoir créé le fichier package.json
, vous devrez ajouter ces informations vous-même. Pour en savoir plus sur le contrôle de version de Git, consultez notre Introduction à Git : installation, utilisation et branches.
Vous recevrez le résultat suivant :
OutputThis utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.
See `npm help json` for definitive documentation on these fields
and exactly what they do.
Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.
Press ^C at any time to quit.
package name: (locator)
Vous serez d’abord invité à indiquer la valeur name
(nom) de votre nouveau projet. Par défaut, la commande suppose qu’il s’agit du nom du dossier dans lequel vous vous trouvez. Les valeurs par défaut de chaque propriété sont indiquées entre parenthèses ()
. Puisque la valeur par défaut pour name
fonctionnera pour ce tutoriel, appuyez sur ENTER
(ENTRÉE) pour l’accepter.
La prochaine valeur à saisir est version
. Tout comme name
, ce champ est obligatoire si votre projet doit être partagé avec d’autres dans le dépôt de paquets npm.
Remarque : les paquets Node.js doivent suivre le guide de Semantic Versioning (semver). Par conséquent, le premier chiffre sera le numéro de version MAJOR
qui ne change que lorsque l’API change. Le deuxième chiffre sera la version MINOR
qui change lorsque des fonctionnalités sont ajoutées. Le dernier chiffre sera la version PATCH
qui change lorsque les bugs sont corrigés.
Appuyez sur ENTER
, de sorte que la version par défaut est acceptée.
Le champ suivant est description
, une chaîne utile pour expliquer ce que fait votre module Node.js. Notre projet locator
fictif permettrait d’obtenir l’adresse IP de l’utilisateur et de renvoyer le pays d’origine. Finds the country of origin of the incoming request
(Détermine le pays d’origine de la requête entrante) serait une description
appropriée, saisissez donc un texte de ce type et appuyez sur ENTER
. La description
est très utile lorsque les gens recherchent votre module.
L’invite suivante vous demandera la valeur du point d’entrée entry point
. Si quelqu’un installe et requires
(exige) votre module, ce que vous définissez dans entry point
sera la première partie de votre programme qui sera chargée. La valeur doit être l’emplacement relatif d’un fichier JavaScript, et sera ajoutée à la propriété main
du package.json
. Appuyez sur ENTER
pour conserver la valeur par défaut.
Remarque : la plupart des modules ont un fichier index.js
comme point d’entrée principal. C’est la valeur par défaut pour la propriété main
d’un package.json
, qui est le point d’entrée pour les modules npm. S’il n’y a pas de package.json
, Node.js essaiera de charger index.js
par défaut.
Ensuite, il vous sera demandé une test command
, un script exécutable ou une commande pour exécuter les tests de votre projet. Dans de nombreux modules populaires de Node.js, les tests sont écrits et exécutés avec Mocha, Jest, Jasmine ou d’autres frameworks de test. Puisque cet article ne couvre pas les tests, laissez cette option vide pour l’instant et appuyez sur ENTER
pour continuer.
La commande init
demandera alors le référentiel GitHub du projet. Vous n’en utiliserez pas dans cet exemple donc laissez-le également vide.
Après l’invite pour le référentiel, la commande demande des keywords
(mots clés). Cette propriété est un tableau de chaînes de caractères contenant des termes utiles que les gens peuvent utiliser pour trouver votre référentiel. Il est préférable d’avoir un petit groupe de mots vraiment pertinents pour votre projet, afin que la recherche puisse être plus ciblée. Inscrivez ces mots clés sous forme de chaîne de caractères, en séparant chaque valeur par une virgule. Pour cet exemple de projet, tapez ip,geo,country
(ip,géo,pays) à l’invite. Le package.json
final comportera trois éléments dans le tableau keywords
.
Le champ suivant dans l’invite est author
(auteur). Ceci est utile pour les utilisateurs de votre module qui veulent entrer en contact avec vous. Par exemple, si quelqu’un découvre un exploit dans votre module, il peut l’utiliser pour signaler le problème afin que vous puissiez le résoudre. Le champ author
est une chaîne de caractères au format suivant : "Name \<Email\> (Website)"
. Par exemple, "Sammy \<sammy@your_domain\> (https://your_domain)"
est un auteur valide. L’adresse e-mail et les données du site Web sont facultatives : un auteur valide peut être un simple nom. Ajoutez vos coordonnées en tant qu’auteur et confirmez avec ENTER
.
Enfin, la license
(licence) vous sera demandée. Elle détermine les autorisations et les limitations légales pour les utilisateurs de votre module. De nombreux modules Node.js sont open source, donc npm fixe la valeur par défaut à ISC.
À ce stade, vous devez examiner vos options de licence et décider ce qui convient le mieux à votre projet. Pour plus d’informations sur les différents types de licences open source, consultez cette liste de licences dOpen Source Initiative. Si vous ne souhaitez pas fournir de licence pour un référentiel privé, vous pouvez taper UNLICENSED
à l’invite. Pour cet échantillon, utilisez la licence ISC par défaut, et appuyez sur ENTER
pour terminer ce processus.
La commande init
affichera maintenant le fichier package.json
qu’elle va créer. Il ressemblera à cela :
OutputAbout to write to /home/sammy/locator/package.json:
{
"name": "locator",
"version": "1.0.0",
"description": "Finds the country of origin of the incoming request",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"ip",
"geo",
"country"
],
"author": "Sammy <sammy@your_domain> (https://your_domain)",
"license": "ISC"
}
Is this OK? (yes)
Une fois que les informations correspondent à ce que vous voyez ici, appuyez sur ENTER
pour terminer ce processus et créer le fichier package.json
. Grâce à ce fichier, vous pouvez conserver une trace des modules que vous installez pour votre projet.
Maintenant que vous avez votre fichier package.json
, vous pouvez tester l’installation de modules lors de l’étape suivante.
Il est courant dans le développement de logiciels d’utiliser des bibliothèques externes pour effectuer des tâches auxiliaires dans les projets. Cela permet au développeur de se concentrer sur la logique commerciale et de créer l’application plus rapidement et plus efficacement.
Par exemple, si notre exemple de module locator
doit faire une requête API externe pour obtenir des données géographiques, nous pourrions utiliser une bibliothèque HTTP pour faciliter cette tâche. Comme notre objectif principal est de renvoyer des données géographiques pertinentes à l’utilisateur, nous pourrions installer un paquet qui nous facilite les requêtes HTTP au lieu de réécrire ce code nous-mêmes, une tâche qui dépasse le cadre de notre projet.
Examinons cet exemple. Dans votre application locator
, vous utiliserez la bibliothèque axios, qui vous aidera à effectuer des requêtes HTTP. Installez-la en entrant ce qui suit dans votre shell :
- npm install axios --save
Vous commencez cette commande avec npm install
, qui va installer le paquet (pour être bref, vous pouvez utiliser npm i
). Vous listerez ensuite les paquets que vous voulez installer, séparés par une espace. Dans ce cas, il s’agit d’axios
. Enfin, vous terminez la commande avec le paramètre optionnel --save
, qui spécifie qu’axios
sera sauvegardé comme une dépendance du projet.
Lorsque la bibliothèque sera installée, vous verrez une sortie similaire à ce qui suit :
Output...
+ axios@0.19.0
added 5 packages from 8 contributors and audited 5 packages in 0.764s
found 0 vulnerabilities
Maintenant, ouvrez le fichier package.json
, en utilisant l’éditeur de texte de votre choix. Ce tutoriel utilisera nano
:
- nano package.json
Vous verrez une nouvelle propriété, comme surligné ci-dessous :
{
"name": "locator",
"version": "1.0.0",
"description": "Finds the country of origin of the incoming request",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"ip",
"geo",
"country"
],
"author": "Sammy sammy@your_domain (https://your_domain)",
"license": "ISC",
"dependencies": {
"axios": "^0.19.0"
}
}
L’option --save
a indiqué à npm de mettre à jour le package.json
avec le module et la version qui viennent d’être installés. C’est très bien, car les autres développeurs travaillant sur vos projets peuvent facilement voir quelles sont les dépendances externes nécessaires.
Remarque : vous avez peut-être remarqué le ^
avant le numéro de version pour la dépendance axios
. Rappelez-vous que la version sémantique est constituée de trois chiffres : MAJOR, MINOR et PATCH. Le symbole ^
signifie que toute version MINOR ou PATCH supérieure satisferait à cette contrainte de version. Si vous voyez ~
au début d’un numéro de version, alors seules les versions PATCH supérieures satisfont à la contrainte.
Lorsque vous avez terminé d’examiner le fichier package.json
, quittez-le.
Les paquets qui sont utilisés pour le développement d’un projet mais pas pour le construire ou le faire fonctionner en production sont appelés dépendances de développement. Ces dépendances ne sont pas nécessaires pour que votre module ou application fonctionne en production, mais peuvent être utiles lors de l’écriture du code.
Par exemple, il est courant que les développeurs utilisent des linters pour s’assurer que leur code suit les meilleures pratiques et pour garder un style cohérent. Bien que cela soit utile pour le développement, cela ne fait qu’augmenter la taille du module distribué sans apporter d’avantage tangible lorsqu’il est déployé en production.
Installez un linter comme dépendance de développement pour votre projet. Essayez cela dans votre shell :
- npm i eslint@6.0.0 --save-dev
Dans cette commande, vous avez utilisé l’indicateur --save-dev
. Cela permettra d’enregistrer eslint
comme une dépendance qui n’est nécessaire que pour le développement. Notez également que vous avez ajouté @6.0.0
à votre nom de dépendance. Lorsque les modules sont mis à jour, ils sont marqués avec une version. Le @
indique à npm de rechercher une balise spécifique du module que vous installez. Sans balise spécifique, npm installe la dernière version marquée. Ouvrez à nouveau package.json
:
- nano package.json
Cela montrera ce qui suit :
{
"name": "locator",
"version": "1.0.0",
"description": "Finds the country of origin of the incoming request",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"ip",
"geo",
"country"
],
"author": "Sammy sammy@your_domain (https://your_domain)",
"license": "ISC",
"dependencies": {
"axios": "^0.19.0"
},
"devDependencies": {
"eslint": "^6.0.0"
}
}
eslint
a été enregistré en tant que devDependencies
, avec le numéro de version que vous avez indiqué précédemment. Quittez package.json
.
node_modules
et package-lock.json
Lorsque vous installez un paquet dans un projet Node.js pour la première fois, npm crée automatiquement le dossier node_modules
pour stocker les modules nécessaires à votre projet et le fichier package-lock.json
que vous avez examiné précédemment.
Vérifiez qu’ils se trouvent dans votre répertoire de travail. Dans votre shell, tapez ls
et appuyez sur ENTER
. Vous verrez la sortie suivante :
Outputnode_modules package.json package-lock.json
Le dossier node_modules
contient toutes les dépendances installées pour votre projet. Dans la plupart des cas, vous ne devez pas commiter ce référentiel dans votre référentiel à version contrôlée. Au fur et à mesure que vous installez des dépendances, la taille de ce dossier augmentera rapidement. En outre, le fichier package-lock.json
conserve une trace des versions exactes installées de manière plus succincte, de sorte qu’il n’est pas nécessaire d’inclure node_modules
.
Alors que le fichier package.json
liste les dépendances qui nous indiquent les versions appropriées à installer pour le projet, le fichier package-lock.json
garde la trace de toutes les modifications dans package.json
ou node_modules
et nous indique la version exacte du paquet installé. Vous commitez généralement dans votre référentiel à version contrôlée au lieu de node_modules
, car c’est une représentation plus propre de toutes vos dépendances.
Avec vos fichiers package.json
et package-lock.json
, vous pouvez rapidement mettre en place les mêmes dépendances avant de commencer le développement d’un nouveau projet. Pour le démontrer, remontez d’un niveau dans votre arborescence de répertoires et créez un nouveau dossier nommé cloned_locator
au même niveau de répertoire que locator
:
- cd ..
- mkdir cloned_locator
Entrez dans votre nouveau répertoire :
- cd cloned_locator
Maintenant, copiez les fichiers package.json
et package-lock.json
depuis locator
vers cloned_locator
:
- cp ../locator/package.json ../locator/package-lock.json .
Pour installer les modules nécessaires à ce projet, entrez :
- npm i
npm vérifiera la présence d’un fichier package-lock.json
pour installer les modules. Si aucun fichier lock n’est disponible, npm lira le fichier package.json
pour déterminer les installations. Il est généralement plus rapide d’installer à partir de package-lock.json
, puisque le fichier lock contient la version exacte des modules et de leurs dépendances, ce qui signifie que npm n’a pas besoin de passer du temps à trouver une version appropriée à installer.
Lors du déploiement en production, vous voudrez peut-être ignorer les dépendances de développement. Rappelez-vous que les dépendances de développement sont stockées dans la section devDependencies
de package.json
, et n’ont aucun impact sur le fonctionnement de votre application. Lorsque vous installez des modules dans le cadre du processus CI/CD pour déployer votre application, omettez les dépendances dev en exécutant :
- npm i --production
L’indicateur --production
omet la section devDependencies
pendant l’installation. Pour l’instant, restez fidèle à votre modèle de développement.
Avant de passer à la section suivante, revenez au dossier locator
:
- cd ../locator
Jusqu’à présent, vous avez installé des modules npm pour le projet locator
. npm vous permet également d’installer des paquets de façon globale. Cela signifie que le paquet est disponible pour votre utilisateur dans l’ensemble du système, comme toute autre commande shell. Cette capacité est utile pour les nombreux modules Node.js qui sont des outils CLI.
Par exemple, vous pouvez vouloir parler sur votre blog du projet locator
sur lequel vous travaillez actuellement. Pour ce faire, vous pouvez utiliser une bibliothèque comme Hexo pour créer et gérer le blog de votre site Web statique. Installez la CLI d’Hexo de façon globale comme ceci :
- npm i hexo-cli -g
Pour installer un paquet de façon globale, vous ajoutez l’indicateur -g
à la commande.
Remarque : si vous obtenez une erreur de permission en essayant d’installer ce paquet globalement, il est possible que votre système exige des privilèges de super utilisateur pour exécuter la commande. Essayez à nouveau avec sudo npm i hexo-cli -g
.
Vérifiez que le paquet a été installé avec succès en entrant :
- hexo --version
Vous verrez une sortie semblable à :
Outputhexo-cli: 2.0.0
os: Linux 4.15.0-64-generic linux x64
http_parser: 2.7.1
node: 10.14.0
v8: 7.6.303.29-node.16
uv: 1.31.0
zlib: 1.2.11
ares: 1.15.0
modules: 72
nghttp2: 1.39.2
openssl: 1.1.1c
brotli: 1.0.7
napi: 4
llhttp: 1.1.4
icu: 64.2
unicode: 12.1
cldr: 35.1
tz: 2019a
Jusqu’à présent, vous avez appris à installer des modules avec npm. Vous pouvez installer des paquets pour un projet localement, soit comme dépendance de production, soit comme dépendance de développement. Vous pouvez également installer des paquets basés sur des fichiers package.json
ou package-lock.json
préexistants, ce qui vous permet de développer avec les mêmes dépendances que vos pairs. Enfin, vous pouvez utiliser l’indicateur -g
pour installer des paquets de façon globale, de sorte que vous puissiez y accéder que vous soyez dans un projet Node.js ou non.
Maintenant que vous pouvez installer des modules, dans la section suivante vous apprendrez des techniques pour administrer vos dépendances.
Un gestionnaire de paquets complet peut faire beaucoup plus qu’installer des modules. npm dispose de plus de 20 commandes relatives à la gestion des dépendances. Au cours de cette étape, vous allez :
Ces exemples seront réalisés dans votre dossier locator
, mais toutes ces commandes peuvent être exécutées globalement en ajoutant l’indicateur -g
à la fin de celles-ci, exactement comme vous l’avez fait lors de l’installation globale.
Si vous souhaitez savoir quels modules sont installés dans un projet, il est plus facile d’utiliser la commande list
ou ls
que de lire directement le fichier package.json
. Pour ce faire, entrez :
- npm ls
Vous verrez un résultat comme celui-ci :
Output├─┬ axios@0.19.0
│ ├─┬ follow-redirects@1.5.10
│ │ └─┬ debug@3.1.0
│ │ └── ms@2.0.0
│ └── is-buffer@2.0.3
└─┬ eslint@6.0.0
├─┬ @babel/code-frame@7.5.5
│ └─┬ @babel/highlight@7.5.0
│ ├── chalk@2.4.2 deduped
│ ├── esutils@2.0.3 deduped
│ └── js-tokens@4.0.0
├─┬ ajv@6.10.2
│ ├── fast-deep-equal@2.0.1
│ ├── fast-json-stable-stringify@2.0.0
│ ├── json-schema-traverse@0.4.1
│ └─┬ uri-js@4.2.2
...
Par défaut, ls
montre l’arbre des dépendances dans son intégralité - les modules dont dépend votre projet et les modules dont dépendent vos dépendances. Cela peut être un peu compliqué si vous voulez avoir une vue d’ensemble de ce qui est installé.
Pour n’imprimer que les modules que vous avez installés sans leurs dépendances, entrez ce qui suit dans votre shell :
- npm ls --depth 0
Votre sortie sera :
Output├── axios@0.19.0
└── eslint@6.0.0
L’option --depth
(profondeur) vous permet de spécifier le niveau d’arborescence des dépendances que vous souhaitez voir. Quand elle est définie sur 0
, vous ne voyez que vos dépendances de haut niveau.
Tenir vos modules npm à jour est une bonne pratique. Vous avez ainsi plus de chances d’obtenir les dernières corrections de sécurité pour un module. Utilisez la commande outdated
pour vérifier si des modules peuvent être mis à jour :
- npm outdated
Vous obtiendrez une sortie semblable à la suivante :
OutputPackage Current Wanted Latest Location
eslint 6.0.0 6.7.1 6.7.1 locator
Cette commande liste d’abord le Package
qui est installé et la version Current
(actuelle). La colonne Wanted
indique quelle version satisfait à votre exigence de version dans package.json
. La colonne Latest
indique la version la plus récente du module qui a été publiée.
La colonne Location
indique où se trouve le paquet dans l’arborescence des dépendances. La commande outdated
a l’indicateur--depth
comme ls
. Par défaut, la profondeur est 0.
Il semble que vous puissiez mettre à jour eslint
vers une version plus récente. Utilisez la commande update
ou up
comme ceci :
- npm up eslint
La sortie de la commande contiendra la version installée :
Outputnpm WARN locator@1.0.0 No repository field.
+ eslint@6.7.1
added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s
found 0 vulnerabilities
Si vous voulez mettre à jour tous les modules en une seule fois, vous pouvez entrer :
- npm up
La commande npm uninstall
peut supprimer des modules de vos projets. Cela signifie que le module ne sera plus installé dans le dossier node_modules
, ni ne sera vu dans vos fichiers package.json
et package-lock.json
.
Supprimer les dépendances d’un projet est une activité normale dans le cycle de vie du développement de logiciels. Une dépendance peut ne pas résoudre le problème comme annoncé, ou ne pas fournir une expérience de développement satisfaisante. Dans ce cas, il peut être préférable de désinstaller la dépendance et de construire son propre module.
Imaginez qu’axios
ne vous apporte pas l’expérience de développement que vous auriez souhaitée pour faire des requêtes HTTP. Désinstallez axios
avec la commande uninstall
ou un
en entrant :
- npm un axios
Votre sortie sera semblable à :
Outputnpm WARN locator@1.0.0 No repository field.
removed 5 packages and audited 176 packages in 1.488s
found 0 vulnerabilities
Il n’est pas dit explicitement qu’axios
a été supprimé. Pour vérifier qu’il a été désinstallé, listez à nouveau les dépendances :
- npm ls --depth 0
Maintenant, nous voyons seulement qu’eslint
est installé :
Output└── eslint@6.7.1
Cela montre que vous avez réussi à désinstaller le paquet axios
.
npm fournit une commande audit
pour mettre en évidence les risques de sécurité potentiels dans vos dépendances. Pour voir l’audit en action, installez une version obsolète du module request en exécutant ce qui suit :
- npm i request@2.60.0
Lorsque vous installerez cette version obsolète de request
, vous remarquerez une sortie semblable à ce qui suit :
Output+ request@2.60.0
added 54 packages from 49 contributors and audited 243 packages in 7.26s
found 6 moderate severity vulnerabilities
run `npm audit fix` to fix them, or `npm audit` for details
npm vous dit que vos dépendances ont des vulnérabilités. Pour obtenir plus de détails, vérifiez l’ensemble de votre projet avec :
- npm audit
La commande audit
affiche des tableaux de sortie mettant en évidence les failles de sécurité :
Output === npm audit security report ===
# Run npm install request@2.88.0 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Memory Exposure │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ tunnel-agent │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ request > tunnel-agent │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://npmjs.com/advisories/598 │
└───────────────┴──────────────────────────────────────────────────────────────┘
# Run npm update request --depth 1 to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate │ Remote Memory Exposure │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ request │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ request │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://npmjs.com/advisories/309 │
└───────────────┴──────────────────────────────────────────────────────────────┘
...
Vous pouvez voir le chemin de la vulnérabilité, et parfois npm vous offre des moyens de la corriger. Vous pouvez exécuter la commande update comme suggéré, ou vous pouvez exécuter la sous-commande fix
de audit
. Dans votre shell, entrez :
- npm audit fix
Vous verrez une sortie semblable à :
Output+ request@2.88.0
added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s
fixed 2 of 6 vulnerabilities in 243 scanned packages
4 vulnerabilities required manual review and could not be updated
npm a été en mesure de mettre à jour deux des paquets en toute sécurité, réduisant ainsi vos vulnérabilités dans les mêmes mesures. Cependant, vos dépendances présentent encore quatre vulnérabilités. La commande audit fix
ne résout pas toujours tous les problèmes. Bien qu’une version d’un module puisse présenter une faille de sécurité, si vous la mettez à jour vers une version avec une API différente, elle pourrait casser le code plus haut dans l’arbre des dépendances.
Vous pouvez utiliser le paramètre --force
pour vous assurer que les vulnérabilités ont disparu, comme ceci :
- npm audit fix --force
Comme nous l’avons déjà mentionné, cela n’est pas recommandé, sauf si vous êtes sûr que cela ne brisera pas la fonctionnalité.
Dans ce tutoriel, vous avez réalisé divers exercices pour démontrer comment les modules de Node.js sont organisés en paquets, et comment ces paquets sont gérés par npm. Au sein d’un projet Node.js, vous avez utilisé des paquets npm comme dépendances en créant et en maintenant un fichier package.json
- un enregistrement des métadonnées de votre projet, y compris les modules que vous avez installés. Vous avez également utilisé l’outil CLI de npm pour installer, mettre à jour et supprimer des modules, en plus de répertorier l’arborescence des dépendances de vos projets et de vérifier et mettre à jour les modules obsolètes.
À l’avenir, l’exploitation du code existant en utilisant des modules accélérera le temps de développement, car vous n’aurez pas à répéter les fonctionnalités. Vous serez également en mesure de créer vos propres modules npm, et ceux-ci seront à leur tour gérés par d’autres via des commandes npm. Quant aux prochaines étapes, expérimentez ce que vous avez appris dans ce tutoriel en installant et en testant toute la gamme des paquets disponibles. Voyez ce que l’écosystème fournit pour faciliter la résolution des problèmes. Par exemple, vous pouvez essayer TypeScript, un superset de JavaScript, ou transformer votre site Web en applications mobiles avec Cordova. Si vous souhaitez en savoir plus sur Node.js, consultez nos autres tutoriels Node.js.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!