Maison > interface Web > tutoriel CSS > Comment installer les packages NPM

Comment installer les packages NPM

Jennifer Aniston
Libérer: 2025-03-15 09:57:08
original
838 Les gens l'ont consulté

Comment installer les packages NPM

En savoir plus sur NPM! Dans le chapitre précédent, nous avons appris le Node et le gestionnaire de packages, et nous avons même installé Node et NPM et nous sommes familiarisés avec Node Version Manager (NVM). La prochaine partie de ce guide de débutant NPM présentera ce qui pourrait le plus vous soucier: l'installation du package NPM .

Chapitre du guide

  1. Pour qui est ce guide?
  2. Que signifie "NPM"?
  3. Quelle est la ligne de commande?
  4. Qu'est-ce que le nœud?
  5. Qu'est-ce qu'un gestionnaire de packages?
  6. Comment installer NPM?
  7. Comment installer le package NPM? (Votre emplacement actuel!)
  8. Qu'est-ce que la commande NPM?
  9. Comment installer un projet NPM existant?

Un exemple rapide

Nous pouvons installer notre premier package à l'aide de la commande npm install (ou abrégé en tant que npm i ) et le nom du package à ajouter au projet. Par exemple, le package de nœud de SASS est simplement appelé "SASS", ce qui signifie que nous pouvons l'ajouter au projet comme celui-ci (assurez-vous que vous êtes d'abord dans un nouveau dossier créé pour ce petit projet):

 NPM Installer Sass
Copier après la connexion

C'est ça! Après avoir entré cette commande, NPM commencera à fonctionner immédiatement:

Ce qui se passe dans les coulisses, c'est que NPM essaie de rechercher un package nommé SASS dans le registre des packages NPM. Si le package est trouvé (il le fait) NPM l'installe dans le dossier node_modules généré automatiquement dans le projet (plus à ce sujet plus tard) (situé dans le dossier racine du projet), y compris tout ce que le package doit exécuter. (C'est pourquoi vous voyez NPM ajouter 16 packages et examiner un total de 17 packages NPM au lieu du package SASS lui-même - il a également des dépendances!)

Après avoir exécuté la commande d'installation, vous remarquerez peut-être que vous ne voyez rien appelé "Sass" dans le dossier du projet, qui est différent de ce à quoi vous pourriez vous attendre. Étrangement, cependant, nous voyons trois nouveaux projets dans le dossier du projet: deux fichiers JSON nommés package.json et package-lock.json , et un nouveau dossier node_modules .

Qu'est-ce que c'est? Nous avons besoin de NPM pour installer SASS, pas tout ça. Cela ne fait pas partie de Sass… non? Oui, c'est correct, mais il y a une bonne explication pour expliquer pourquoi ces nouveaux projets sont générés dans le dossier du projet. Voyons ce qui vient de se passer.

Que se passe-t-il lors de l'installation d'un package

Lors de l'installation (ou de la désinstallation ou de la mise à jour) d'un package, NPM fait la plupart ou même les quatre choses suivantes:

  1. Mettez à jour le fichier package.json dans le projet au besoin;
  2. Mettez à jour le fichier package-lock.json (appelé "Fichier de verrouillage") avec tous les détails techniques;
  3. Installez le fichier de package réel - et tout autre package sur lequel le package d'origine peut dépendre (dans le dossier node_modules );
  4. Exécutez l'audit des packages installés.

Préordons-le un par un.

package.json et package-lock.json

Ces deux fichiers JSON fonctionnent ensemble pour assurer une journalisation précise de toutes les dépendances du projet (et toutes leurs dépendances, toutes leurs dépendances, etc.). La différence entre les deux est un peu technique, mais tout simplement: le fichier de verrouillage est un instantané précis et précis de l'arborescence de dépendance du projet, tandis que package.json est un aperçu de haut niveau qui peut contenir d'autres choses. Le package principal que vous avez installé peut être répertorié dans package.json , mais package-lock.json est l'endroit où vous suivez l'ensemble de l'arborescence de dépendance.

Le fichier de verrouillage ne doit pas non plus être mis à jour manuellement; Par conséquent, assurez-vous d'éviter de confondre les fichiers de verrouillage avec les fichiers package.json .

Lorsque vous partagez ou collaborez avec d'autres sur un projet, NPM connaît la source du projet et ce qui est installé dans le projet via ces deux fichiers. Grâce à ces informations, il peut copier avec précision l'environnement sur la machine d'une autre personne. Les deux fichiers doivent être soumis à votre référentiel GIT et servir de plan de dépendance pour votre projet. De cette façon, lorsqu'un autre développeur de votre équipe clace le référentiel et exécute la commande npm install , NPM sait exactement quels packages installer, vous gardant, vous et vos collègues, synchronisés.

Si vous ouvrez package.json , vous ne verrez pas grand-chose, mais cela vaut la peine et voyez ce qui se passe:

 {
  "dépendances": {
    "Sass": "^ 1.43.4"
  }
}
Copier après la connexion

Vous ne voyez peut-être pas le numéro de version exact (car le package a été mis à jour depuis l'écriture de cet article), mais vous devriez voir SASS dans l'objet JSON dependencies . Le nombre lui-même (dans ce cas 1.43.4) indique une version spécifique de SASS qui a été installée.

Comme une note latérale courte mais importante: le CHARCTER (^) au début du numéro de version permet à NPM d'installer des mises à jour mineures du package. En d'autres termes, il indique à NPM que le package SASS installé doit être au moins la version 1.43.4, mais peut être n'importe quelle version plus élevée 1.xx tant qu'elle est encore en dessous de 2.0.0. NPM choisit généralement la dernière version stable lors de l'installation du package, mais cela est ajouté pour permettre des mises à jour non destructives. Cette partie est appelée "versioning sémantique", qui est en soi un sujet de blog, mais n'est pas unique au NPM.

Quoi qu'il en soit, ce sont ces deux fichiers JSON. Discutons ensuite du dossier node_modules .

node_modules

node_modules est l'endroit où se trouvent tout le code de package réel ; Si vous ouvrez maintenant le dossier tout en suivant les instructions, vous trouverez un dossier SASS, mais il y aura également plusieurs autres dossiers.

La raison des autres dossiers est que lorsque le package est installé, il peut nécessiter que d'autres packages fonctionnent correctement (SASS nécessite évidemment). Par conséquent, NPM complète automatiquement le travail de recherche et d'installation de toutes ces dépendances. Comme vous pouvez le deviner, ces dépendances peuvent également avoir d'autres dépendances, de sorte que le processus sera répété et ainsi de suite jusqu'à ce que nous finissons à ramper l'arbre de dépendance à sa branche la plus éloignée et tout ce dont nous avons besoin est installé (ou jusqu'à ce que nous obtenions une sorte d'erreur, mais espérons-le non).

Par conséquent, les projets ont généralement des centaines ou même plus de sous-dossiers node_modules qui s'accumulent rapidement en termes d'espace disque. node_modules devient généralement très grand.

Si vous voulez savoir comment soumettre un grand dossier comme node_modules au référentiel d'un projet, notez que contrairement aux fichiers JSON, node_modules ne doit pas être attaché à Git et ne devrait même pas être partagé. En fait, l'exemple de presque tous les fichiers .gitignore (quels fichiers qui indiquent à Git lesquels doivent être ignorés lors du traçage d'un fichier) contient node_modules pour s'assurer que Git ne le touche jamais ou ne le suit jamais.

Alors, comment les autres personnes de votre équipe obtiennent-elles ces forfaits? Ils exécutent npm install (ou abrégé en npm i ) à partir de la ligne de commande pour télécharger les dépendances directement à partir de la source. De cette façon, il n'est pas nécessaire de commettre de grandes quantités de données ou d'extraire du référentiel d'origine.

Il faut prendre soin lors de l'installation de dépendances

Cet énorme réseau de dépendances et ses dépendances relatives éloignées peuvent provoquer cette situation: une sorte de bibliothèque de services publics qui fournit des services utiles peut être adoptée par de nombreux autres packages, qui à leur tour seront utilisés par de nombreux autres packages jusqu'à ce que le code d'origine soit finalement installé tranquillement sur une grande partie du site et de l'application.

Vous pouvez en fait laisser beaucoup d'autres choses lors de l'installation d'un package, ce qui peut sembler bizarre (sinon très effrayant). Cela a envie d'inviter un nouvel ami à votre fête en famille et l'ami se présente avec 20 invités non invités. Mais cela ne semble pas si étrange ou terrifiant pour les raisons suivantes:

  1. La plupart des packages NPM sont open source. Vous et n'importe qui d'autre pouvez facilement voir comment fonctionne l'internes et savoir exactement ce que fait le package. Vous pouvez également afficher le package sur le registre (npmjs.com) pour voir combien de fois il a été installé, lors de sa dernière mise à jour et d'autres informations connexes. Si un package est très populaire, vous pouvez raisonnablement être sûr qu'il est sûr.
  2. Il y a un énorme monde de fonctionnalités dont de nombreux projets ont besoin. Par exemple, considérez le formatage des dattes, le traitement des demandes et des réponses HTTP, de la limitation, de l'anti-titulaire ou de l'animation. Il n'est pas logique de réinventer la roue et de le coder manuellement chaque fois que vous l'utilisez dans un nouveau projet.
  3. L'installation d'un package n'est pas différente de l'installation d'une application sur votre téléphone ou de l'installation d'un plug-in sur un site Web WordPress . La différence est que nous n'avons pas la possibilité de mieux comprendre comment ces applications et plugins fonctionnent en interne, car nous gérons les packages et d'autres choses sur lesquelles ces applications et plugins peuvent compter. Il y a de fortes chances qu'ils introduisent également de nombreux packages plus petits d'une manière ou d'une autre.

Bien sûr, dans n'importe quel environnement où le code arbitraire peut être installé et exécuté, c'est une bonne idée d'être prudent. S'il vous plaît, ne vous méprenez pas. Je mentirais si je disais que les méchants n'ont jamais réussi à exploiter ce système. Mais sachez qu'il existe de nombreux processus qui peuvent empêcher les choses de mal tourner. En cas de doute, respectez les sacs les plus populaires pour que vous soyez bien.

Notez également que NPM exécutera un audit de sécurité automatique pour vous, ce qui nous amène au dernier point de cette section.

Qu'est-ce que l'audit NPM?

Lorsque nous avons déjà installé Sass, nous avons vu le message suivant lorsque le terminal a été terminé:

 <code>found 0 vulnerabilities</code>
Copier après la connexion

Cependant, vous pouvez voir quelques avertissements - comme mon ancien projet ci-dessous. J'ai décidé de le démarrer et d'exécuter npm install ( npm i ) après avoir été inactif pendant au moins quelques années. Voyons comment il fonctionne:

L'audit NPM indique des packages avec des vulnérabilités connues , et l'audit s'exécutera automatiquement lorsque vous installez le package. Si vous voyez des nouvelles comme celle-ci, ne vous inquiétez pas trop ; (Par exemple, il peut être possible qu'une seule méthode dans un package la rende vulnérable lorsqu'elle est utilisée de manière spécifique.)

Néanmoins, il est préférable de résoudre le problème que nous pouvons résoudre, ce que fait npm audit fix . L'ajout de fix à la fin indiquera à NPM de continuer et de mettre à jour une nouvelle version mineure de tout package avec une vulnérabilité connue. La section "Version mineure" est importante; Cela signifie que les mises à jour devraient être exécutées en toute sécurité de cette manière sans risque de briser le projet.

Si l'augmentation du numéro de version du package par un numéro de version mineure ne fonctionne pas, vous pouvez ajouter l'indicateur --force à la commande originale:

 Correction d'audit NPM - Force
Copier après la connexion

Cependant, c'est une opération dangereuse. L'autorisation de la «force d'utilisation» NPM signifie qu'il peut désormais installer des mises à jour de version majeures pour résoudre les vulnérabilités - ce qui signifie qu'il peut apporter des modifications significatives ou introduire l'incompatibilité. Je ne le recommande pas à moins qu'il n'y ait des vulnérabilités critiques que npm audit fix ne peut résoudre et que vous êtes disposé et capable de passer beaucoup de temps à dépanner après (si nécessaire).

Une note finale sur ce sujet: Parfois, vous pouvez résoudre certains problèmes inattendus dans votre projet NPM en supprimant node_modules et en relâchant npm install . Il s'agit de la méthode du "commutateur répété" du NPM, et je l'ai fait plusieurs fois moi-même.

Étapes suivantes

Maintenant que nous avons complètement exploré le trou de lapin qui fonctionne derrière NPM, revenons à l' opération réelle, d'accord?

← Chapitre 6 Chapitre 8 →

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Derniers articles par auteur
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal