npm, le gestionnaire de packages de nœuds: Guide du débutant


Node.js permet d’écrire des applications en JavaScript sur le serveur. Il repose sur le Runtime JavaScript V8 et écrit en C ++ – donc c’est rapide. À l’origine, il était conçu comme un environnement serveur pour les applications, mais les développeurs ont commencé à l’utiliser pour créer des outils pour les aider dans l’automatisation des tâches locales. Depuis, un tout nouvel écosystème d’outils basés sur les nœuds (tels que Grognement, Gorgée et Webpack) a évolué pour transformer le visage du développement front-end.

Pour utiliser ces outils (ou packages) dans Node.js, nous devons être en mesure de les installer et de les gérer de manière utile. C’est là qu’intervient npm, le gestionnaire de packages Node. Il installe les packages que vous souhaitez utiliser et fournit une interface utile pour travailler avec eux.

Dans ce guide, nous allons examiner les bases de l’utilisation de npm. Nous allons vous montrer comment installer des packages en mode local et global, ainsi que supprimer, mettre à jour et installer une certaine version d’un package. Nous allons également vous montrer comment travailler avec package.json pour gérer les dépendances d’un projet. Si vous êtes plutôt une personne vidéo, pourquoi ne pas vous inscrire à SitePoint Premium et regarder notre screencast gratuit: Qu’est-ce que npm et comment puis-je l’utiliser?

Mais avant de pouvoir commencer à utiliser npm, nous devons d’abord installer Node.js sur notre système. Faisons cela maintenant.

Installation de Node.js

Dirigez-vous vers le Node.js page de téléchargement et prenez la version dont vous avez besoin. Des programmes d’installation Windows et Mac sont disponibles, ainsi que des binaires Linux pré-compilés et du code source. Pour Linux, vous pouvez également installer Node via le gestionnaire de packages, comme indiqué ici.

Pour ce didacticiel, nous allons utiliser la v12.15.0. Au moment de la rédaction de cet article, il s’agit de l’actuel Version LTS (Long Term Support) de Node.

Conseil: vous pouvez également envisager d’installer Node à l’aide d’un gestionnaire de versions. Cela annule le problème des autorisations soulevé dans la section suivante.

Voyons où le nœud a été installé et vérifiez la version:

$ which node
/usr/bin/node
$ node --version
v12.15.0

Pour vérifier que votre installation a réussi, essayons le REPL de Node:

$ node
> console.log('Node is running');
Node is running
> .help
.break    Sometimes you get stuck, this gets you out
.clear    Alias for .break
.editor   Enter editor mode
.exit     Exit the repl
.help     Print this help message
.load     Load JS from a file into the REPL session
.save     Save all evaluated commands in this REPL session to a file

Press ^C to abort current expression, ^D to exit the repl

L’installation de Node.js a fonctionné, nous pouvons donc maintenant concentrer notre attention sur npm, qui était inclus dans l’installation:

$ which npm
/usr/bin/npm
$ npm --version
6.13.7

Mise à jour de npm

npm, qui signifiait à l’origine Node Package Manager, est un projet distinct de Node.js. Il a tendance à être mis à jour plus fréquemment. Vous pouvez consulter la dernière version disponible de npm à ce sujet page. Si vous réalisez que vous avez une version plus ancienne, vous pouvez mettre à jour comme suit.

Pour les utilisateurs Linux et Mac, utilisez la commande suivante:

npm install -g npm@latest

Pour les utilisateurs de Windows, le processus peut être légèrement plus compliqué. C’est ce qu’il dit sur le page d’accueil du projet:

De nombreuses améliorations pour les utilisateurs de Windows ont été apportées dans npm 3 – vous aurez une meilleure expérience si vous exécutez une version récente de npm. Pour mettre à niveau, utilisez Outil de mise à niveau de Microsoft, télécharger une nouvelle version de Node, ou suivez les instructions de mise à niveau de Windows dans le Installation / mise à jour de npm Publier.

Pour la plupart des utilisateurs, l’outil de mise à niveau sera le meilleur choix. Pour l’utiliser, vous devez ouvrir PowerShell en tant qu’administrateur et exécuter la commande suivante:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force

Cela garantira que vous pouvez exécuter des scripts sur votre système. Ensuite, vous devrez installer le npm-windows-upgrade outil. Une fois que vous avez installé l’outil, vous devez l’exécuter afin qu’il puisse mettre à jour npm pour vous. Faites tout cela dans la console PowerShell élevée:

npm install --global --production npm-windows-upgrade
npm-windows-upgrade --npm-version latest

Modules packagés de nœuds

npm peut installer des packages en mode local ou global. En mode local, il installe le package dans un node_modules dossier dans votre répertoire de travail parent. Cet emplacement appartient à l’utilisateur actuel.

Si vous n’utilisez pas de gestionnaire de versions (ce que vous devriez probablement être), les packages globaux sont installés dans {prefix}/lib/node_modules/, qui appartient à root (où {prefix} est habituellement /usr/ ou /usr/local). Cela signifie que vous devrez utiliser sudo pour installer des packages à l’échelle mondiale, ce qui pourrait entraîner des erreurs d’autorisation lors de la résolution de dépendances tierces, ainsi qu’un problème de sécurité.

Changeons ça!

Société de livraison de colis
Il est temps de gérer ces packages

Modification de l’emplacement des packages globaux

Voyons quel résultat npm config nous donne:

$ npm config list
; cli configs
metrics-registry = "https://registry.npmjs.org/"
scope = ""
user-agent = "npm/6.13.7 node/v12.15.0 linux x64"

; node bin location = /usr/bin/nodejs
; cwd = /home/sitepoint
; HOME = /home/sitepoint
; "npm config ls -l" to show all defaults.

Cela nous donne des informations sur notre installation. Pour le moment, il est important d’obtenir l’emplacement actuel dans le monde:

$ npm config get prefix
/usr

C’est le préfixe que nous voulons changer, afin d’installer des packages globaux dans notre répertoire personnel. Pour ce faire, créez un nouveau répertoire dans votre dossier de départ:

$ cd ~ && mkdir .node_modules_global
$ npm config set prefix=$HOME/.node_modules_global

Avec ce simple changement de configuration, nous avons modifié l’emplacement d’installation des packages Node globaux. Cela crée également un .npmrc fichier dans notre répertoire personnel:

$ npm config get prefix
/home/sitepoint/.node_modules_global
$ cat .npmrc
prefix=/home/sitepoint/.node_modules_global

Nous avons toujours npm installé dans un emplacement appartenant à root. Mais parce que nous avons changé notre emplacement global de colis, nous pouvons en profiter. Nous devons réinstaller npm, mais cette fois dans le nouvel emplacement appartenant à l’utilisateur. Cela installera également la dernière version de npm:

npm install npm@latest -g

Enfin, nous devons ajouter .node_modules_global/bin à notre $PATH variable d’environnement, afin que nous puissions exécuter des packages globaux à partir de la ligne de commande. Pour ce faire, ajoutez la ligne suivante à votre .profile, .bash_profileou .bashrc et redémarrer votre terminal:

export PATH="$HOME/.node_modules_global/bin:$PATH"

Maintenant notre .node_modules_global/bin sera trouvé en premier et la version correcte de npm sera utilisée:

$ which npm
/home/sitepoint/.node_modules_global/bin/npm
$ npm --version
6.13.7

Astuce: vous pouvez éviter tout cela si vous utilisez un gestionnaire de version Node. Consultez ce didacticiel pour savoir comment: Installer plusieurs versions de Node.js à l’aide de nvm.

Installation de packages en mode global

Pour le moment, nous n’avons qu’un seul package installé globalement – le package npm lui-même. Alors changeons cela et installons UglifyJS (un outil de minification JavaScript). Nous utilisons le --global drapeau, mais cela peut être abrégé en -g:

$ npm install uglify-js --global
/home/sitepoint/.node_modules_global/bin/uglifyjs -> /home/sitepoint/.node_modules_global/lib/node_modules/uglify-js/bin/uglifyjs
+ uglify-js@3.7.7
added 3 packages from 38 contributors in 0.259s

Comme vous pouvez le voir dans la sortie, des packages supplémentaires sont installés. Ce sont les dépendances d’UglifyJS.

Liste des packages globaux

Nous pouvons lister les packages globaux que nous avons installés avec le npm list commander:

$ npm list --global
home/sitepoint/.node_modules_global/lib
├─┬ npm@6.9.0
│ ├── abbrev@1.1.1
│ ├── ansicolors@0.3.2
│ ├── ansistyles@0.1.3
│ ├── aproba@2.0.0
│ ├── archy@1.0.0
....................
└─┬ uglify-js@3.5.3
  ├── commander@2.19.0
  └── source-map@0.6.1

La sortie, cependant, est plutôt verbeuse. Nous pouvons changer cela avec le --depth=0 option:

$ npm list -g --depth=0
/home/sitepoint/.node_modules_global/lib
├── npm@6.13.7
└── uglify-js@3.7.7

C’est mieux; maintenant, nous ne voyons que les packages que nous avons installés avec leurs numéros de version.

Tous les packages installés globalement seront disponibles à partir de la ligne de commande. Par exemple, voici comment vous utiliseriez le package Uglify pour réduire example.js dans example.min.js:

$ uglifyjs example.js -o example.min.js

Installation de packages en mode local

Lorsque vous installez des packages localement, vous le faites normalement en utilisant un package.json fichier. Allons-y et créons-en un:

$ mkdir project && cd project

$ npm init
package name: (project)
version: (1.0.0)
description: Demo of package.json
entry point: (index.js)
test command:
git repository:
keywords:
author:
license: (ISC)

presse Revenir pour accepter les valeurs par défaut, puis appuyez à nouveau pour confirmer vos choix. Cela créera un package.json fichier à la racine du projet:

{
  "name": "project",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Astuce: si vous voulez un moyen plus rapide de générer un package.json utilisation des fichiers npm init --y.

Les champs sont, espérons-le, assez explicites, à l’exception de main et scripts. le main est le point d’entrée principal de votre programme et le champ scripts Le champ vous permet de spécifier les commandes de script qui sont exécutées à différents moments du cycle de vie de votre package. Nous pouvons les laisser tels quels pour le moment, mais si vous souhaitez en savoir plus, consultez le documentation package.json sur npm et cet article sur l’utilisation de npm comme outil de construction.

Essayons maintenant d’installer Souligner:

$ npm install underscore
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN project@1.0.0 No repository field.

+ underscore@1.9.2
added 1 package from 1 contributor and audited 1 package in 0.412s
found 0 vulnerabilities

Notez qu’un fichier de verrouillage est créé. Nous y reviendrons plus tard.

Maintenant si nous jetons un œil package.json, nous verrons qu’un dependencies le champ a été ajouté:

{
  ...
  "dependencies": {
    "underscore": "^1.9.2"
  }
}

Gérer les dépendances avec package.json

Comme vous pouvez le voir, Underscore v1.9.2 a été installé dans notre projet. Le caret (^) au début du numéro de version indique que lors de l’installation, npm va extraire la version la plus élevée du package qu’il peut trouver là où seule la version majeure doit correspondre (à moins qu’un package-lock.json fichier est présent). Dans notre cas, ce serait tout ce qui est en dessous de la v2.0.0. Cette méthode de contrôle de version des dépendances (major.minor.patch) est appelée gestion des versions sémantique. Vous pouvez en savoir plus ici: Versionnage sémantique: pourquoi vous devriez l’utiliser.

Notez également que le trait de soulignement a été enregistré en tant que propriété du dependencies champ. Ceci est devenu la valeur par défaut dans la dernière version de npm et est utilisé pour les packages (comme Underscore) requis pour l’exécution de l’application. Il serait également possible d’enregistrer un package en tant que devDependency en spécifiant un --save-dev drapeau. devDependencies sont des packages utilisés à des fins de développement – par exemple, pour exécuter des tests ou transpiler du code.

Astuce: vous pouvez également ajouter private: true à package.json pour éviter la publication accidentelle de référentiels privés, ainsi que la suppression des avertissements générés lors de l’exécution npm install.

De loin la principale raison d’utiliser package.json spécifier les dépendances d’un projet est la portabilité. Par exemple, lorsque vous clonez le code de quelqu’un d’autre, il vous suffit d’exécuter npm i dans la racine du projet et npm résoudra et récupérera tous les packages nécessaires pour que vous puissiez exécuter l’application. Nous examinerons cela plus en détail plus tard.

Avant de terminer cette section, vérifions rapidement que le trait de soulignement fonctionne. Créez un fichier appelé test.js dans la racine du projet et ajoutez ce qui suit:

const _ = require("underscore");
console.log(_.range(5));

Exécutez le fichier en utilisant node test.js et tu devrais voir [0, 1, 2, 3, 4] sortie à l’écran.

Désinstallation des packages locaux

npm est un gestionnaire de packages, il doit donc être en mesure de supprimer un package. Supposons que le package Underscore actuel nous pose des problèmes de compatibilité. Nous pouvons supprimer le package et installer une version plus ancienne, comme ceci:

$ npm uninstall underscore
removed 1 package in 0.386s

$ npm list
project@1.0.0 /home/sitepoint/project
└── (empty)

Installation d’une version spécifique d’un package

Nous pouvons maintenant installer le package Underscore dans la version souhaitée. Nous faisons cela en utilisant le signe @ pour ajouter un numéro de version:

$ npm install underscore@1.9.1
+ underscore@1.9.1
added 1 package in 1.574s

$ npm list
project@1.0.0 /home/sitepoint/project
└── underscore@1.9.1

Mettre à jour un package

Vérifions s’il existe une mise à jour pour le package Underscore:

$ npm outdated
Package     Current  Wanted  Latest  Location
underscore    1.9.1   1.9.2   1.9.2  project

le Actuel La colonne nous montre la version installée localement. le Dernier La colonne nous indique la dernière version du package. Et le Voulait La colonne nous indique la dernière version du package vers laquelle nous pouvons mettre à niveau sans casser notre code existant.

Se souvenir du package-lock.json fichier de plus tôt? Introduit dans npm v5, le but de ce fichier est de s’assurer que les dépendances restent exactement la même chose sur toutes les machines sur lesquelles le projet est installé. Il est généré automatiquement pour toutes les opérations où npm modifie soit le node_modules dossier ou le package.json fichier.

Vous pouvez essayer ceci si vous le souhaitez. Supprimer le node_modules dossier, puis réexécutez npm i (c’est l’abréviation de npm install). npm réinstallera Underscore v1.9.1, même si nous venons de voir que la v1.9.2 est disponible. C’est parce que nous avons spécifié la version 1.9.1 dans le package-lock.json fichier:

{
  "name": "project",
  "version": "1.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "underscore": {
      "version": "1.9.1",
      "resolved": "https://registry.npmjs.org/underscore/-/underscore-1.9.1.tgz",
      "integrity": "sha512-5/4etnCkd9c8gwgowi5/om/mYO5ajCaOgdzj/oW+0eQV9WxKBDZw5+ycmKmeaTXjInS/W0BzpGLo2xR2aBwZdg=="
    }
  }
}

Avant l’émergence du package-lock.json fichier, les versions de package incohérentes se sont avérées un gros casse-tête pour les développeurs. Ce problème était normalement résolu en utilisant un npm-shrinkwrap.json fichier, qui a dû être créé manuellement.

Maintenant, supposons que la dernière version de Underscore a corrigé le bogue que nous avions précédemment et que nous souhaitons mettre à jour notre package vers cette version:

$ npm update underscore
+ underscore@1.9.2
updated 1 package in 0.236s

$ npm list
project@1.0.0 /home/sitepoint/project
└── underscore@1.9.2

Astuce: pour que cela fonctionne, Underscore doit être répertorié comme une dépendance dans package.json. Nous pouvons également exécuter npm update si nous avons de nombreux modules obsolètes, nous voulons mettre à jour.

Recherche de packages

Nous avons utilisé le mkdir commande plusieurs fois dans ce didacticiel. Existe-t-il un package Node doté de cette fonctionnalité? Utilisons npm search:

$ npm search mkdir
NAME                      | DESCRIPTION          | AUTHOR          | DATE
mkdir                     | Directory creation…  | =joehewitt      | 2012-04-17
fs-extra                  | fs-extra contains…   | =jprichardson…  | 2019-06-28
mkdirp                    | Recursively mkdir,…  | =isaacs…        | 2020-01-24
make-dir                  | Make a directory…    | =sindresorhus   | 2019-04-01
...

Il y a (mkdirp). Installons-le:

$ npm install mkdirp
+ mkdirp@1.0.3
added 1 package and audited 2 packages in 0.384s

Créez maintenant un mkdir.js fie et copiez-collez ce code:

const mkdirp = require('mkdirp');

const made = mkdirp.sync('/tmp/foo/bar/baz');
console.log(`made directories, starting with ${made}`);

Ensuite, exécutez-le depuis le terminal:

$ node mkdir.js
made directories, starting with /tmp/foo

Réinstaller les dépendances du projet

Commençons par installer un autre package:

$ npm install request
+ request@2.88.0
added 48 packages from 59 contributors and audited 65 packages in 2.73s
found 0 vulnerabilities

Vérifier la package.json:

"dependencies": {
  "mkdirp": "^1.0.3",
  "request": "^2.88.0",
  "underscore": "^1.9.2"
},

Notez que la liste des dépendances a été mise à jour automatiquement. Si vous souhaitez installer un package sans l’enregistrer dans package.json, utilisez simplement le --no-save argument.

Supposons que vous ayez cloné le code source de votre projet sur une autre machine et que nous souhaitons installer les dépendances. Supprimons le node_modules dossier d’abord, puis exécutez npm install:

$ rm -R node_modules
$ npm list --depth=0
project@1.0.0 /home/sitepoint/project
├── UNMET DEPENDENCY mkdirp@1.0.3
├─┬ UNMET DEPENDENCY request@2.88.0
  ...
└── UNMET DEPENDENCY underscore@1.9.2

npm ERR! missing: mkdirp@1.0.3, required by project@1.0.0
npm ERR! missing: request@2.88.0, required by project@1.0.0
npm ERR! missing: underscore@1.9.2, required by project@1.0.0
...

$ npm install
added 50 packages from 60 contributors and audited 65 packages in 1.051s
found 0 vulnerabilities

Si vous regardez votre node_modules dossier, vous verrez qu’il est recréé à nouveau. De cette façon, vous pouvez facilement partager votre code avec d’autres sans alourdir votre projet et vos référentiels sources avec des dépendances.

Gérer le cache

Lorsque npm installe un package, il en conserve une copie. Ainsi, la prochaine fois que vous souhaitez installer ce package, il n’a pas besoin d’atteindre le réseau. Les copies sont mises en cache dans le .npm répertoire dans votre chemin d’accès personnel:

$ ls ~/.npm
anonymous-cli-metrics.json  _cacache  index-v5  _locks  _logs  node-sass

Ce répertoire sera encombré d’anciens packages au fil du temps, il est donc utile de le nettoyer de temps en temps:

$ npm cache clean --force

Vous pouvez également purger tout node_module dossiers de votre espace de travail si vous avez plusieurs projets de nœuds sur votre système que vous souhaitez nettoyer:

find . -name "node_modules" -type d -exec rm -rf '{}' +

Audit

Avez-vous remarqué tout cela found 0 vulnerabilities dispersés dans la sortie CLI? La raison en est qu’une nouvelle fonctionnalité a été introduite dans npm qui permet aux développeurs d’analyser les dépendances à la recherche de vulnérabilités de sécurité connues.

Essayons cette fonctionnalité en installant une ancienne version de express:

$ npm install express@4.8.0

express@4.8.0
added 36 packages from 24 contributors and audited 123 packages in 2.224s
found 21 vulnerabilities (8 low, 9 moderate, 4 high)
  run `npm audit fix` to fix them, or `npm audit` for details

Dès que nous avons terminé l’installation, nous obtenons un rapport rapide indiquant que plusieurs vulnérabilités ont été trouvées. Vous pouvez exécuter la commande npm audit pour voir plus de détails:

$ npm audit

 === npm audit security report ===


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ negotiator                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ express                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ express > accepts > negotiator                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/106                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Timing Attack                                                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ cookie-signature                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ express                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ express > cookie-signature                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/134                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

Vous obtiendrez une liste détaillée des packages présentant des vulnérabilités. Si vous regardez le Path champ, il montre le chemin de dépendance. Par exemple, le chemin express > accepts > negotiator signifie que Express dépend du Accepts paquet. le Accepts le paquet dépend du negotiator package, qui contient la vulnérabilité.

Il existe deux façons de résoudre tous ces problèmes. Nous pouvons soit exécuter la commande npm install express@4.17.1 comme suggéré, ou exécutez npm audit fix. Faisons le dernier:

$ npm audit fix

+ express@4.17.1
added 20 packages from 14 contributors, removed 7 packages and updated 29 packages in 1.382s
fixed 21 of 21 vulnerabilities in 122 scanned packages

La commande npm audit fix installe automatiquement toutes les mises à jour compatibles sur les dépendances vulnérables. Bien que cela puisse sembler magique, notez que les vulnérabilités ne peuvent pas toujours être corrigées automatiquement. Cela peut se produire si vous utilisez un package qui a subi une modification majeure qui pourrait interrompre votre projet actuel s’il était mis à jour. Dans de telles situations, vous devrez examiner votre code et appliquer manuellement le correctif.

Vous pouvez également exécuter npm audit fix --force si cela ne vous dérange pas de mettre à jour les packages avec des modifications majeures. Après avoir exécuté la commande, exécutez npm audit pour s’assurer que toutes les vulnérabilités ont été résolues.

Alias

Comme vous l’avez peut-être remarqué, il existe plusieurs façons d’exécuter des commandes npm. Voici une brève liste de certains des alias npm couramment utilisés:

  • npm i : installer le package local
  • npm i -g : installer le package global
  • npm un : désinstaller le package local
  • npm up: packages de mise à jour npm
  • npm t: exécuter des tests
  • npm ls: liste des modules installés
  • npm ll ou npm la: imprimer des informations supplémentaires sur le package tout en listant les modules

Vous pouvez également installer plusieurs packages à la fois comme ceci:

$ npm i express momemt lodash mongoose body-parser webpack

Si vous souhaitez afficher toutes les commandes npm courantes, exécutez simplement npm help pour la liste complète. Vous pouvez également en savoir plus dans notre article 10 trucs et astuces qui feront de vous un ninja npm.

npx

Vous pourriez également entendre parler de npx lors de vos voyages. Ne confondez pas cela avec npm. Comme nous l’avons appris, npm est un outil pour gérant vos packages, alors que npx est un outil pour exécution paquets. Il est livré avec npm version 5.2+.

Une utilisation typique de npx est pour exécuter des commandes ponctuelles. Par exemple, imaginez que vous vouliez lancer un simple serveur HTTP. Tu pourrait installer le package de serveur http globalement sur votre système, ce qui est très bien si vous comptez utiliser http-server régulièrement. Mais si vous souhaitez simplement tester le package ou si vous souhaitez réduire au minimum vos modules installés globalement, vous pouvez accéder au répertoire dans lequel vous souhaitez l’exécuter, puis exécuter la commande suivante:

npx http-server

Et cela fera tourner le serveur sans rien installer de manière globale.

Vous pouvez en savoir plus sur npx ici.

Conclusion

Dans ce didacticiel, nous avons abordé les bases de l’utilisation de npm. Nous avons montré comment installer Node.js à partir de la page de téléchargement du projet, comment modifier l’emplacement des packages globaux (pour éviter d’utiliser sudo) et comment installer des packages en mode local et global. Nous avons également couvert la suppression, la mise à jour et l’installation d’une certaine version d’un package, ainsi que la gestion des dépendances d’un projet.

Avec chaque nouvelle version, npm fait d’énormes progrès dans le monde du développement front-end. Selon son co-fondateur, sa base d’utilisateurs évolue et la plupart de ceux qui l’utilisent ne l’utilisent pas du tout pour écrire Node. Au contraire, il devient un outil que les gens utilisent pour assembler JavaScript sur le front-end (sérieusement, vous pouvez l’utiliser pour installer à peu près tout) et qui devient une partie intégrante de l’écriture de JavaScript moderne.

Utilisez-vous npm dans vos projets? Sinon, le moment est peut-être venu de commencer.

Close Menu