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 .
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
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.
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:
package.json
dans le projet au besoin;package-lock.json
(appelé "Fichier de verrouillage") avec tous les détails techniques;node_modules
);Préordons-le un par un.
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" } }
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
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.
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:
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.
Lorsque nous avons déjà installé Sass, nous avons vu le message suivant lorsque le terminal a été terminé:
<code>found 0 vulnerabilities</code>
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
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.
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!