Catégories
Astuces et Design

Un guide du débutant pour npm, le Node Package Manager – SitePoint

Node.js permet d'écrire des applications en JavaScript sur le serveur. Il est construit sur le runtime JavaScript V8 et écrit en C ++ – donc c'est rapide. À l'origine, il était conçu comme un environnement de 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 lors, un tout nouvel écosystème d'outils basés sur les nœuds (tels que Grunt, Gulp et webpack) a évolué pour transformer le visage du développement frontal.

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à que npm, le gestionnaire de packages Node, entre en jeu. 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 vous montrerons également comment travailler avec package.json pour gérer les dépendances d'un projet. Si vous êtes plutôt un passionné de 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 utiliser npm, nous devons d'abord installer Node.js sur notre système. Faisons-le maintenant.

Installation de Node.js

Rendez-vous sur la page de téléchargement de Node.js et récupérez 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 version 12.15.0. Au moment de la rédaction du présent document, il s'agit de la version LTS (Long Term Support) actuelle 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érifions 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 vérifier la dernière version npm disponible sur cette page. Si vous vous rendez compte que vous avez une ancienne version, 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é. Voici ce qu'il dit sur la 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 effectuer la mise à niveau, utilisez l’outil de mise à niveau de Microsoft, téléchargez une nouvelle version de Node ou suivez les instructions de mise à niveau de Windows dans le post Installation / mise à niveau de npm.

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 vous permettra d'exécuter des scripts sur votre système. Ensuite, vous devrez installer l'outil de mise à niveau npm-windows. Après avoir installé l'outil, vous devez l'exécuter pour 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 empaquetés par nœud

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 les packages globalement, ce qui pourrait entraîner des erreurs d'autorisation lors de la résolution des dépendances tierces, tout en étant 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 quelle sortie 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 l'instant, il est important d'obtenir l'emplacement global actuel:

$ 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 personnel:

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

Avec ce simple changement de configuration, nous avons modifié l'emplacement où les packages Node globaux sont installés. 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

Npm est toujours installé dans un emplacement appartenant à root. Mais comme nous avons changé l'emplacement de notre package global, 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é dans le monde – le package npm lui-même. Modifions 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 sur la sortie, des packages supplémentaires sont installés. Ce sont les dépendances d'UglifyJS.

Liste des packages globaux

Nous pouvons répertorier 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 deviendront disponibles à partir de la ligne de commande. Par exemple, voici comment utiliser 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 à l'aide d'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 dessus 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"
}

Conseil: si vous souhaitez générer plus rapidement un package.json utilisation des fichiers npm init --y.

Nous espérons que les champs sont assez explicites, à l'exception de main et scripts. le main est le principal point d’entrée de votre programme et le scripts Le champ vous permet de spécifier des 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 la documentation package.json sur npm et cet article sur l'utilisation de npm comme outil de génération.

Essayons maintenant d'installer Underscore:

$ 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 regardons package.json, nous verrons qu'un dependencies champ a été ajouté:

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

Gestion des dépendances avec package.json

Comme vous pouvez le voir, Underscore v1.9.2 a été installé dans notre projet. Le caret (^) à l'avant du numéro de version indique que lors de l'installation, npm récupérera la version la plus élevée du package, il peut trouver où seule la version principale doit correspondre (sauf si un package-lock.json fichier est présent). Dans notre cas, ce serait inférieur à la v2.0.0. Cette méthode de gestion des versions des dépendances (major.minor.patch) est connue sous le nom de versioning sémantique. Vous pouvez en savoir plus à ce sujet ici: Versionnement sémantique: pourquoi vous devriez l'utiliser.

Notez également que Underscore 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 empêcher 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 plus grande 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, tout ce que vous avez à faire est 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 verrons cela plus en détail plus tard.

Avant de terminer cette section, vérifions rapidement que Underscore 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 vous devriez voir (0, 1, 2, 3, 4) sortie à l'écran.

Désinstallation des packages locaux

npm est un gestionnaire de packages, il doit donc pouvoir supprimer un package. Supposons que le package Underscore actuel nous cause des problèmes de compatibilité. Nous pouvons supprimer le package et installer une ancienne version, 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 que nous voulons. Nous le faisons 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

Mise à jour d'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 Courant 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 que 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 node_modules dossier ou package.json fichier.

Vous pouvez continuer et l'essayer si vous le souhaitez. Supprimer le node_modules dossier, puis réexécutez npm i (c'est court pour npm install). npm réinstallera Underscore v1.9.1, même si nous venons de voir que la v1.9.2 est disponible. En effet, 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 de la package-lock.json fichier, les versions de package incohérentes se sont avérées un gros casse-tête pour les développeurs. Cela a été normalement résolu en utilisant un npm-shrinkwrap.json fichier, qui devait être créé manuellement.

Supposons maintenant que la dernière version d'Underscore corrige le bogue que nous avions précédemment et que nous voulons 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 qui possè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 à partir du terminal:

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

Réinstallation des dépendances de 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 avez 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 gonfler votre projet et les référentiels source avec des dépendances.

Gérer le cache

Lorsque npm installe un package, il en conserve une copie. Par conséquent, la prochaine fois que vous souhaitez installer ce package, il n'a pas besoin d'accéder au réseau. Les copies sont mises en cache dans le .npm dans votre répertoire 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é tous ces 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 pour les failles 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 ===

# Run  npm install express@4.17.1  to resolve 21 vulnerabilities
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ 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 , il montre le chemin de dépendance. Par exemple, le chemin express > accepts > negotiator signifie qu'Express dépend de la Accepts paquet. le Accepts le package dépend du negotiator package, qui contient la vulnérabilité.

Il existe deux façons de résoudre tous ces problèmes. On peut soit exécuter la commande npm install express@4.17.1 comme suggéré, ou exécutez npm audit fix. Faisons ce 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 dans 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 revoir 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 changements de rupture. Après avoir exécuté la commande, exécutez npm audit pour vous 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 les 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 lors de la liste des 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 npm Ninja.

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 la version 5.2+ de npm.

Une utilisation typique de npx consiste à exécuter des commandes ponctuelles. Par exemple, imaginez que vous vouliez faire tourner un simple serveur HTTP. Vous pourrait installez le package du serveur http globalement sur votre système, ce qui est parfait si vous utilisez http-server régulièrement. Mais si vous voulez simplement tester le package, ou si vous souhaitez garder vos modules installés globalement au minimum, vous pouvez changer dans le répertoire où vous souhaitez l'exécuter, puis exécutez la commande suivante:

npx http-server

Et cela fera tourner le serveur sans rien installer dans le monde.

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 (afin d'é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 frontal. Selon son co-fondateur, sa base d'utilisateurs change et la plupart de ceux qui l'utilisent ne l'utilisent pas du tout pour écrire Node. Au contraire, cela devient un outil que les gens utilisent pour assembler JavaScript en amont (sérieusement, vous pouvez l'utiliser pour installer à peu près n'importe quoi) et qui devient une partie intégrante de l'écriture de JavaScript moderne.

Utilisez-vous npm dans vos projets? Sinon, c'est peut-être le bon moment pour commencer.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *