Un guide complet du débutant sur npm
e me souviens très bien d’une période au début de ma carrière de codage lorsque j’ai commencé à sentir que les choses s’éloignaient de ce que je savais et que je me dirigeais vers un ensemble plus complexe d’outils et de pratiques, ancrés dans la ligne de commande et quelque chose appelé npm .
Ceci est la première partie d’un guide du débutant où nous abordons le vaste sujet de Node Package Manager, ou npm. Nous tenons souvent ces trois petites lettres – npm – pour acquises lorsque nous les tapons dans la ligne de commande, mais npm fait partie d’un écosystème beaucoup plus vaste qui peut souvent être intimidant ou déroutant pour quiconque se lance pour la première fois. Ce guide vous aidera à démystifier cet écosystème et vous aidera non seulement à comprendre ce qu’est et fait le npm, mais aussi à vous sentir à l’aise de travailler avec lui.
Chapitres du guide
- À qui diable s’adresse ce guide ? (Tu es là!)
- Qu’est-ce que « npm » signifie ?
- Qu’est-ce que c’est que la ligne de commande ?
- Qu’est-ce que c’est que Node ?
- Qu’est-ce que c’est qu’un gestionnaire de paquets ?
- Comment diable installez-vous npm ?
- Comment diable installez-vous les packages npm ?
- Que diable sont les commandes npm ?
- Comment diable installez-vous un projet npm existant ?

Le développement moderne « back-of-the-front-end » – dont npm fait partie – semble complexe car c’est un nom pour de nombreux outils interconnectés. Lorsque vous ajoutez le fait que le monde frontal semble évoluer beaucoup plus rapidement qu’il ne le fait réellement, ce qui donne l’impression que vous serez laissé pour compte pour ne pas sauter tout de suite sur la nouveauté, tout cela peut sembler inaccessible.
C’est pourquoi nous lançons ce guide, pour rendre la technologie plus accessible pour que vous puissiez l’utiliser dans votre propre travail.
A qui diable s’adresse ce guide ?
Dans mon propre parcours d’apprentissage de développement personnel, je lisais des guides sur les technologies qui m’excitaient, puis j’arrivais à une partie qui disait « juste » npm install
ceci ou cela, et je poussais encore un autre soupir déçu et renonçais à utiliser tout ce qui était cool- regarder chose était. Ou, les jours plus aventureux, je pourrais copier la commande, mais finir inévitablement soit à une autre étape que je ne comprenais pas (« juste », disaient-ils toujours, « faites [quelque chose dont je n’avais aucune idée] »), ou obtenir un message d’erreur que le guide n’a pas expliqué qui m’arrête dans mon élan.
Quel que soit npm – quoi que fassent ces commandes et où que vous soyez censé les taper – personne n’avait jamais pris le temps de me l’expliquer. Et plus je lisais des guides rédigés par des personnes qui tenaient ces connaissances pour acquises, plus je me sentais isolé.
Si tout cela vous semble familier : cette série est pour vous .
Vous appartenez très probablement au groupe qui a été décrit ces dernières années comme « front-of-the-front-end ». Comme moi, vous connaissez probablement votre métier en matière de HTML et de CSS. Peut-être connaissez-vous aussi du JavaScript, soit du JavaScript « vanille », soit par le biais de jQuery. Quoi qu’il en soit, c’est bien, à la fois pour les besoins de cet article et en général.
Peut-être avez-vous même essayé un framework comme React ou Vue, mais vous avez principalement copié et collé des éléments pour que votre projet soit opérationnel, et vous ne saviez pas exactement ce que ces éléments faisaient réellement .
- Ce message est pour vous si vous sentez le grand fossé entre les définitions plus traditionnelles et « modernes » du développement frontal et si vous craignez de nuire à votre carrière si vous ne comblez pas ce gouffre.
- Ce message est pour vous si vous n’êtes pas vraiment sûr de ce qu’il en est des terminaux et des lignes de commande, et que vous préféreriez de loin ne jamais en toucher un.
- Cet article est pour vous si vous vous demandez pourquoi d’autres développeurs semblent aimer rendre les choses si compliquées , et quel est l’intérêt de tout ce bazar de ligne de commande, alors que vous pourriez simplement écrire du HTML, du CSS et du JavaScript simples à la place .
- Ce poste est pour vous si vous vous sentez exclu. Si vous sentez qu’il y a quelque chose, quelque chose de très important , que personne n’a jamais vraiment pris la peine de vous expliquer, et que vous craignez d’être le seul à ne pas comprendre.
Sachez ceci, mon collègue développeur front-end : vous n’êtes pas seul. Vous en êtes loin. Vous êtes exactement là où j’étais il n’y a pas si longtemps, et le souvenir instable de cet endroit est encore frais dans mon esprit.
Permettez-moi d’essayer de répondre aux questions que vous vous posez probablement – les mêmes que moi – de la manière dont j’aimerais que quelqu’un me pose des questions, avant même que je sache comment les poser.
Ce qui est couvert dans ce guide
Ce guide est une série d’articles. Ce n’est pas parce que ce genre de choses est extrêmement difficile à comprendre en soi ; c’est parce qu’il comporte de nombreuses parties, et chacune porte une explication à elle seule. C’est un vaste territoire avec un certain nombre de trous de lapin à explorer. Se concentrer sur une étape solide à la fois nous permet de passer du temps à rendre les choses claires et compréhensibles. Le but n’est pas de tout couvrir, mais je veux être plus complet que rapide.
Nous commencerons par parler de la configuration actuelle du terrain; ce qu’est npm, un peu d’où il vient et comment nous en sommes arrivés là. À partir de là, nous couvrirons ce qu’est Node lui-même, suivi de ce que sont les gestionnaires de paquets en général, avant de travailler réellement avec npm. Nous terminerons en installant Node et npm (s’ils ne le sont pas déjà), en initialisant un projet pour avoir une idée de son fonctionnement, et enfin, en installant un projet npm réel à partir de GitHub avec tous ses packages et commandes.
Certains (ou tous) de cela peuvent sembler très intimidants en ce moment, mais ne vous inquiétez pas. C’est pourquoi nous passons ensemble la longueur d’un guide entier.
Ce qu’il faut savoir avant de commencer
Je ferai de mon mieux pour supposer le moins possible de vous, au-delà du fait que vous êtes un développeur Web qui sait généralement comment créer un site Web avec HTML et CSS. Vous n’aurez pas besoin d’en savoir beaucoup sur JavaScript ou d’en écrire pour suivre ce guide, mais cela vous aidera certainement si vous avez au moins une compréhension fondamentale de ce qu’est JavaScript et de son fonctionnement.
JSON est le seul autre élément qu’il pourrait être utile de connaître avant de commencer. Si vous n’êtes pas familier avec JSON, cela vaut peut-être la peine de jeter un coup d’œil sur ce guide de JSON , ou du moins de le préparer lorsque nous arriverons à cette partie.
Au-delà de cela, je peux faire référence à des outils, des projets et des frameworks spécifiques tels que Bootstrap , React , Vue et SvelteKit , mais je ne supposerai pas que vous avez une expérience pratique avec eux, et je ne supposerai pas non plus que vous avez déjà utilisé npm ou la ligne de commande avant.
Prêt à commencer? Commençons par clarifier ce que nous entendons par « npm », par exemple ce qu’il signifie et comment il s’intègre dans le développement Web moderne.
L’une des choses qui rend cette nouvelle ère de développement frontal, riche en outils, si difficile à comprendre au début, c’est que, même si nous appelons souvent les choses par un nom singulier , elles ont tendance à être en fait composées de plusieurs pièces interconnectées. Il en va de même pour npm et l’écosystème qui l’entoure.
Par exemple : pensez à la façon dont nous nous référons à « Internet », même si le Web lui-même n’est pas une chose unique et unifiée, mais un ensemble de protocoles, de DNS, de serveurs, de navigateurs, de réseaux, de requêtes et de réponses, ainsi que de nombreux autres choses assemblées au fil des années d’itérations. D’ailleurs, même le navigateur lui-même est une machine avec de nombreuses parties.
Chapitres du guide
- À qui diable s’adresse ce guide ?
- Qu’est-ce que « npm » signifie ? (Tu es là!)
- Qu’est-ce que c’est que la ligne de commande ?
- Qu’est-ce que c’est que Node ?
- Qu’est-ce que c’est qu’un gestionnaire de paquets ?
- Comment diable installez-vous npm ?
- Comment diable installez-vous les packages npm ?
- Que diable sont les commandes npm ?
- Comment diable installez-vous un projet npm existant ?
npm est un ensemble de technologies
De la même manière, ce que nous considérons généralement comme « npm » (oui, tout en minuscules ) et « back-of-the-front-end » en particulier est un nom unique pour une collection de nombreuses technologies et systèmes individuels différents ; une sorte de machine Rube Goldberg pour générer du code convivial pour les navigateurs.
J’ai déjà mentionné la ligne de commande; c’est une grande partie de l’écosystème parce que c’est la façon dont nous interagissons avec lui. Mais plus à ce sujet dans le chapitre suivant .
Et puis il y a npm, qui appartient à une catégorie connue sous le nom de logiciel de «gestion de packages». Nous couvrirons cela aussi. En fait, vous me verrez probablement faire référence à npm en tant que gestionnaire de paquets tout au long de ce guide.
Et enfin, il y a Node lui-même, qui est si difficile à expliquer succinctement que je le décris souvent en paraphrasant Douglas Adams : c’est un langage de programmation qui ressemble presque — mais pas tout à fait — à du JavaScript.
npm gère les outils du projet
Pour brouiller davantage les pistes, de nombreux projets dans lesquels vous tapez npm install
dans la ligne de commande peuvent être livrés avec des outils préinstallés pour vous aider à faire une grande variété de choses dans votre projet, comme traiter votre code (par exemple, transformer le code Sass en CSS). Il existe de nombreux projets préconfigurés tout-en-un qui n’attendent que vous pour les installer et commencer ( Create React App , Next , Nuxt et SvelteKit , pour n’en nommer que quelques-uns). C’est pratique lorsqu’il est bien fait, bien sûr, mais cela ajoute également de la complexité, ce qui signifie que nous devons ajouter beaucoup plus de noms à notre liste de choses en arrière-plan.
Cette liste comprend souvent des outils comme Babel (pour compiler JavaScript), Sass (pour compiler CSS), webpack (pour le regroupement d’actifs), Vite (pour les serveurs de développement et autres outils), PostCSS (pour transformer une syntaxe en une autre) ; Autoprefixer (qui peut être un plug-in PostCSS pour les préfixes de fournisseur CSS) ; TypeScript (pour une syntaxe JavaScript supplémentaire) ; ESlint (pour vérifier la qualité du code); Plus joli (pour formater le code) et tester des bibliothèques comme Jest ou Cypress .

Toutes ces choses (et plus) entrent dans cette vaste catégorie générale d’outils qui viennent souvent avec des projets installés par npm – ou qui peuvent être installés et utilisés via npm – mais ne font pas réellement partie de npm lui-même. Ce ne sont que des exemples d’outils modernes qui nous aident à faire de belles choses avec notre code, et je les mentionne ici uniquement parce qu’il vaut la peine de noter la distinction, pour avoir une idée des limites dans ce vaste et nouveau monde.
Et au fait, si vous ne saviez pas ce que sont la plupart (ou aucun ) de ces outils mentionnés ci-dessus, ce n’est pas grave. Peut-être que vous ne les avez pas encore rencontrés, ou peut-être avez-vous travaillé sur un projet qui les avait installés sans les connaître par leur nom. Quoi qu’il en soit, tout cela n’est qu’un contexte supplémentaire.
Brisons ici
Si vous vous sentez déjà un peu dépassé à ce stade : ne vous en faites pas. L’élément clé avec lequel je veux que vous repartiez après avoir lu ce chapitre spécifique est que ce que nous considérons comme « npm » (ou peut-être plus simplement comme « tout ce truc en ligne de commande, back-end-y ») n’est pas vraiment une chose , mais un ensemble de choses qui fonctionnent ensemble pour faciliter le développement pour nous.
Et oui : bien que toute cette complication semble intimidante au départ, elle améliore en fait les choses. Je promets.
Alors que le front-end semble bouger très vite, non, vous n’êtes pas en reste . Vous avez peut-être juste un peu de formation continue pour vous rattraper.
Maintenant que nous savons ce que signifie npm et que nous avons une idée très générale de ce qu’il fait et de la manière dont il s’intègre dans le développement Web, nous devrions passer un peu de temps à examiner la ligne de commande, car c’est ainsi que nous interagissons avec npm.
Chapitres du guide
- À qui diable s’adresse ce guide ?
- Qu’est-ce que « npm » signifie ?
- Qu’est-ce que c’est que la ligne de commande ? (Tu es là!)
- Qu’est-ce que c’est que Node ?
- Qu’est-ce que c’est qu’un gestionnaire de paquets ?
- Comment diable installez-vous npm ?
- Comment diable installez-vous les packages npm ?
- Que diable sont les commandes npm ?
- Comment diable installez-vous un projet npm existant ?
Un aperçu de la ligne de commande
La ligne de commande est un endroit où nous pouvons taper (de manière assez prévisible) des commandes à exécuter directement par notre ordinateur. Il est extrêmement rapide et permet des autorisations d’administration plus importantes que la plupart des applications qui tentent de gérer la ligne de commande pour vous. Besoin d’installer quelque chose sur votre système, ou peut-être de le mettre à jour ? La ligne de commande peut le faire, sans parler de les désinstaller également. Heck, même les langages côté serveur peuvent s’exécuter sur la ligne de commande, ouvrant un large éventail d’outils et de techniques de développement.
C’est pour ces raisons que la ligne de commande est considérée comme un outil indispensable pour de nombreux développeurs. Même si vous n’êtes pas développeur, il y a de fortes chances que vous ayez rencontré la ligne de commande à un moment donné. Peut-être y avez-vous accédé lorsque vous avez ouvert l’application Terminal sous MacOS. Peut-être en avez-vous utilisé un intégré directement dans votre éditeur de code – VS Code et de nombreux autres éditeurs de code sont livrés avec un terminal intégré. Peut-être avez-vous même rencontré des applications de terminal tierces comme iTerm ou Hyper .

Si vous avez utilisé le terminal, il est possible qu’une grande partie de votre utilisation de la ligne de commande à ce stade ait simplement été de taper (ou de coller) des commandes que quelqu’un d’autre vous a données. C’est très bien; c’est souvent ainsi que nous faisons avancer les choses.
Mais prenons un moment pour comprendre exactement ce qu’est la ligne de commande et pourquoi elle est si largement utilisée.
Ligne de commande vs terminal
La « ligne de commande » et le « terminal » sont techniquement deux choses différentes et distinctes, mais sont souvent utilisés de manière interchangeable. Vous pouvez également entendre la ligne de commande appelée « shell » ou la voir abrégée en « CLI » qui est l’abréviation de « interface de ligne de commande ».
Mis à part les distinctions pédantes, les termes sont souvent utilisés pour signifier à peu près la même chose. Donc, juste pour garder les choses aussi simples que possible, je les utiliserai de manière interchangeable à partir de maintenant.
Ouverture de la ligne de commande
Peu importe comment vous voulez l’appeler, vous connaissez probablement la ligne de commande comme cette fenêtre effrayante, peut-être avec un fond sombre et du texte blanc (parfois verdâtre), où vous tapez des commandes que votre ordinateur semble comprendre, même si vous ne le faites pas.

Selon l’endroit et la manière dont vous travaillez sur la ligne de commande, l’une des premières choses que vous remarquerez peut-être est un signe dollar discret, , $
qui s’affiche sur la première ligne où vous pouvez commencer à taper. Vous l’avez peut-être même vu dans d’autres articles ou documentations.

C’est une convention courante de préfixer les commandes avec un $
caractère, mais c’est une convention déroutante à coup sûr. C’est parce qu’il n’est pas nécessaire de le taper. Cela ne fait littéralement pas partie de la commande. Au lieu de cela, $
signifie une commande destinée à être exécutée dans un terminal.
Voici donc la première règle à connaître pour travailler avec la ligne de commande : si vous vous retrouvez à taper ou à copier une instruction qui inclut le $
caractère, sachez qu’il n’est pas nécessaire de l’inclure dans votre travail ; le terminal s’en occupe.
## No need to copy the $
$ npm run build
Vous pouvez voir quelque chose d’autre commencer une ligne au lieu de $
, comme >
, _
ou même une flèche. Encore une fois, quoi qu’il en soit, il n’est certainement pas destiné à être saisi ou collé directement dans la ligne de commande. Que la documentation ou d’autres didacticiels doivent ou non inclure le caractère de début d’une ligne est une conversation entièrement différente (dont Chris a longuement discuté ). Quoi qu’il en soit, cela a le potentiel d’être déroutant, donc je veux m’assurer que cela est appelé.
A quoi sert la ligne de commande ?
Les films et les émissions de télévision décrivent souvent un terminal comme quelque chose que les pirates utilisent rapidement dans une pièce sombre et isolée. C’est en partie simplement parce que cela fait un bon divertissement pour les gens qui ne connaîtraient probablement pas un vrai terminal à partir des lettres en cascade dans The Matrix . (Ils ne devraient pas non plus ; je ne pourrais pas dire si une opération décrite dans une émission de télévision est exacte, et je suis parfaitement satisfait de laisser cette distinction aux professionnels.)
Mais la ligne de commande n’est pas exactement pour écrire du code. Comme le nom « ligne de commande » l’indique, c’est pour écrire des commandes. Je suppose que vous pourriez dire que tout le codage est dans une certaine mesure des commandes, donc c’est certes un peu flou. Mais d’une manière générale, le code dans un terminal est écrit différemment de ce qu’il est dans un éditeur de code. Au lieu de cela, vous utilisez le terminal pour diriger votre ordinateur avec les commandes que vous souhaitez qu’il exécute immédiatement .
Les avantages de la ligne de commande
Vous vous demandez peut-être pourquoi les développeurs aiment travailler en ligne de commande en premier lieu. Vous préférerez peut-être une belle application ou une interface utilisateur graphique (GUI pour faire court, parfois prononcé « gluant ») où vous pouvez voir toutes vos options et trouver la meilleure visuellement. C’est parfaitement bien, et nous parlerons un peu des interfaces graphiques dans ce chapitre et en fournirons des exemples.
De nombreux développeurs pensent ainsi, même si cela n’en a pas l’air. Mais travailler dans la ligne de commande apporte certains avantages qui ne sont pas toujours faciles à reproduire dans une application visuelle.
Il vous accorde des privilèges système divins
La ligne de commande est ce que les informaticiens appellent un « environnement privilégié ». Cela peut sembler faire référence à une fraternité de Yale, mais cela signifie simplement que c’est un endroit où il y a très peu de restrictions sur ce que vous êtes autorisé à faire ; un endroit sans garde-corps.
C’est de là que vient la réputation redoutable de la ligne de commande : quelle que soit la commande que vous tapez, dans la mesure où elle est valide, elle est exécutée immédiatement et, souvent, de manière irréversible. Il est capable d’interagir avec les fichiers cachés que votre système d’exploitation essaie de vous empêcher de modifier. Vous avez le pouvoir d’accéder à n’importe quoi dans le système. Vous avez même le pouvoir d’interagir avec des fichiers de base similaires sur un serveur distant, et nous connaissons tous l’adage selon lequel une grande responsabilité vient avec ce type de pouvoir.
Il peut être utile de considérer la ligne de commande comme un agent de sécurité paresseux. Il suppose que vous savez toujours ce que vous faites et vous laisse passer l’entrée. Cela le rend un peu risqué, oui, mais cela le rend également très puissant et le choix parfait pour certaines tâches et projets.
C’est ultra rapide
Un autre avantage de la ligne de commande par rapport aux applications typiques est : c’est rapide .
Ce n’est pas toujours le cas; la vitesse de la ligne de commande a tendance à être surestimée et dépend largement de la tâche en question. Mais quand c’est plus rapide, cela peut souvent être plusieurs fois plus rapide. De plus, l’endroit où la ligne de commande brille vraiment a tendance à être exactement l’endroit où les projets de code ont le plus besoin de vitesse, c’est-à-dire le téléchargement et la création de fichiers.
Comme nous le verrons dans d’autres chapitres de ce guide, une partie essentielle de ce que fait npm consiste à installer des éléments sur votre machine (généralement dans un dossier désigné pour le projet sur lequel vous travaillez). C’est ce qui rend la ligne de commande idéale pour travailler avec un gestionnaire de paquets (nous verrons également ce que cela signifie) comme npm – il télécharge et transmet des fichiers entre ordinateurs – généralement beaucoup, beaucoup plus rapidement que, disons, en utilisant un navigateur pour faire il.
La ligne de commande permet à npm de générer des tonnes de fichiers à une vitesse incroyable. La possibilité d’exécuter une seule commande qui installe, met à jour ou supprime ces fichiers d’un seul coup à grande vitesse fait du terminal l’outil le plus rapide et le plus efficace pour de nombreuses tâches.
Il fait ce que les autres langages ne peuvent pas
Une autre raison pour laquelle travailler dans le terminal est si avantageux est que c’est l’endroit où de nombreux outils que vous pourriez vouloir utiliser dans votre projet sont déjà disponibles sans aucune configuration supplémentaire.
Mais revenons un peu en arrière.
Lorsque vous entendez l’expression « langage côté serveur », vous pensez peut-être à PHP, Ruby ou Java. Peut-être que ce sont même des entrées plus récentes dans l’espace, comme Rust ou Go. Vous savez peut-être déjà que Node appartient à cette liste, mais sinon, pardonnez-moi d’avoir un peu avancé.
Quoi qu’il en soit, lorsque la plupart des gens pensent à des langages côté serveur comme ceux-ci, ils ont tendance à penser à un serveur Web attendant des requêtes puis y répondant. WordPress, par exemple, reste inactif jusqu’à ce qu’il reçoive une requête qui lance PHP. Lorsque vous envoyez un nouveau tweet, c’est une requête sur les serveurs de Twitter qui finit par atteindre une méthode Ruby dans Rails.
Les langages côté serveur sont à juste titre considérés comme plus puissants, pour ainsi dire, que les langages Web. HTML, CSS et JavaScript sont formidables, mais ils ne peuvent pas fonctionner avec un système de fichiers, envoyer des e-mails, traiter des images, émettre des commandes système, interagir avec le système d’exploitation ou exécuter des tâches planifiées ; parmi beaucoup, beaucoup d’autres choses qu’une application ou un site Web pourrait avoir à faire. Par défaut, JavaScript dans le navigateur ne peut même pas s’exécuter à moins que quelqu’un ne regarde activement la page Web dans son navigateur.
Il est normal de considérer les langages côté serveur comme le puissant moteur derrière des applications et des logiciels plus robustes. Et, dans de nombreux cas, c’est exact. Mais prenons un moment pour reconnaître que dans le but d’exécuter du code, votre machine est un serveur. Pas un serveur Web cependant (ce pourrait être un, mais ce serait bizarre et probablement imprudent). Mais un serveur quand même.

Vous pouvez installer et exécuter n’importe lequel des langages côté serveur que nous avons mentionnés, et peut-être l’avez-vous déjà fait à un moment donné (ou du moins avez-vous essayé). Vous avez peut-être installé PHP pour pouvoir exécuter WordPress (bien qu’il existe de nos jours de bien meilleures façons de le faire ), ou vous avez peut-être installé Ruby pour pouvoir suivre des tutoriels sur Rails, à titre d’exemple.
Ou peut être pas. Peut-être n’avez-vous jamais installé un langage de programmation complet auparavant. Quoi qu’il en soit, sachez simplement que ces langages s’exécutent sur un serveur plutôt que sur un navigateur Web et, à cette fin, votre machine est un serveur.
Au-delà de cela, de nombreux outils que vous voudrez peut-être utiliser avec votre flux de travail de développement, comme Sass pour compiler CSS, fonctionnent en fait sur des langages côté serveur. Ainsi, l’utilisation de la ligne de commande vous place à l’endroit où tous les outils les plus puissants sont facilement disponibles.
Utiliser une application au lieu de la ligne de commande
Nous avons brièvement abordé les interfaces graphiques plus haut dans cet article. Il convient de noter que certaines tâches de ligne de commande ont des interfaces graphiques correspondantes qui rendent le travail avec la ligne de commande plus visuel et programmatique.
De bons exemples incluent GitHub Desktop (pour la gestion des référentiels de code) et CodeKit (pour le traitement, le regroupement et la compilation des actifs), bien que l’onglet Source Control dans VS Code soit également éligible. Même si les interfaces graphiques comme celles-ci sont généralement axées sur des tâches spécifiques, elles vous permettent de faire avancer les choses via une interface utilisateur visuelle agréable, dans une fenêtre d’application réelle située en dehors de la fenêtre du terminal.

Une interface graphique est agréable à avoir en option, et même si je suis devenu assez à l’aise de travailler sur la ligne de commande au fil des ans, j’aimerais toujours qu’il y ait plus d’interfaces graphiques pour faire les choses que la ligne de commande rend possibles, à la fois pour ma propre convenance et d’abaisser la barrière à l’entrée pour les nouveaux développeurs.
Je crois que la raison pour laquelle il n’y a pas plus d’applications de ce type, c’est à cause de la vitesse. Il est beaucoup plus rapide et facile de créer une interface de ligne de commande (CLI) que de créer une application à part entière, souvent par ordre de grandeur. Donc, si nous voulons de belles choses aujourd’hui , la ligne de commande est souvent l’endroit où nous devons aller les chercher.
Et après
Nous venons de passer un peu de temps à nous familiariser avec la ligne de commande. Même si la ligne de commande n’est pas spécifique à npm, elle est essentielle pour travailler avec npm. C’est l’interface à partir de laquelle nous disons au système quoi faire, nous accordant des pouvoirs incroyables au niveau du système ou du serveur pour accomplir des tâches sur de grandes étendues à des vitesses vertigineuses. En tant que gestionnaire de packages, npm s’occupe d’installer, de mettre à jour et de supprimer des fichiers (entre autres) pour un projet Web. La ligne de commande est la façon dont nous communiquons avec npm pour faire tout cela.
Ensuite, nous allons décomposer un peu plus ce qu’est npm en nous concentrant sur la première lettre de l’abréviation : « n » pour Node. Qu’est-ce que c’est que ça et pourquoi est-ce dans le nom? C’est là que nous nous concentrons ensuite.
oici ce que vous devez savoir sur Node.js (ou simplement Node) et comment il se rapporte à npm dès le départ :
- Node est JavaScript, mais en tant que langage côté serveur.
- Cela est possible grâce à V8, le moteur JavaScript de Chromium, qui peut fonctionner seul, en dehors des limites du navigateur.
- Le JavaScript basé sur les nœuds et le navigateur peut être très différent et avoir des capacités différentes, bien que les deux soient JavaScript à la base.
- Vous n’avez pas besoin de connaître Node pour utiliser npm.
Comme vous le savez peut-être maintenant, npm signifie Node Package Manager (même si le site Web officiel de npm affiche des noms alternatifs amusants dans son en-tête à chaque chargement de page, comme « Ninja Pumpkin Mutants »).
La chose clé à comprendre tout de suite est la suivante : « Node » et « Package Manager » sont les deux grands éléments distincts qui se combinent pour créer npm.
Nous expliquerons ce qu’est un gestionnaire de paquets et pourquoi vous pourriez envisager d’en utiliser un lorsque nous passerons au chapitre suivant de ce guide npm. Pour l’instant, concentrons-nous sur la compréhension de ce qu’est Node, car il s’agit d’un élément clé pour comprendre le développement Web moderne.
Chapitres du guide
- À qui diable s’adresse ce guide ?
- Qu’est-ce que « npm » signifie ?
- Qu’est-ce que c’est que la ligne de commande ?
- Qu’est-ce que c’est que Node ? (Tu es là!)
- Qu’est-ce que c’est qu’un gestionnaire de paquets ?
- Comment diable installez-vous npm ?
- Comment diable installez-vous les packages npm ?
- Que diable sont les commandes npm ?
- Comment diable installez-vous un projet npm existant ?
Node est JavaScript, mais sans tout le navigateur
Vous connaissez probablement JavaScript principalement comme un langage qui s’exécute dans le navigateur, similaire à HTML et CSS. Oui, chacun de ces langages a des abstractions et des surensembles (comme HAML pour HTML, Sass pour CSS et TypeScript pour JavaScript, par exemple), ainsi que des compilateurs et des transpileurs et toutes sortes de choses qui les transforment en telle ou telle forme. Mais en fin de compte, ce que ces outils génèrent est du code vanille (c’est-à-dire pur) dans la syntaxe correcte, comme si les abstractions n’étaient jamais utilisées, à exécuter dans le navigateur et dans le navigateur seul.
C’est la chose qui m’a pris le plus de temps à comprendre, et qui, honnêtement, pourrait être un mémo manqué encore plus important que toute l’affaire npm. JavaScript n’a plus besoin d’un navigateur pour fonctionner. Ainsi, vous me verrez parfois faire référence à Node JavaScript pour faire la distinction entre celui-ci et le JavaScript « basé sur un navigateur ».
Langages côté serveur et langages côté client
À ce stade, je pense qu’il vaut la peine de prendre un moment pour explorer la distinction entre les langages côté client (HTML, CSS, JavaScript) et les langages côté serveur (essentiellement tous les autres). Je ne supposerai pas que vous ayez de l’expérience avec les langages côté serveur, comme PHP, Ruby ou Python, mais si le concept de langages côté serveur est entièrement nouveau pour vous, cela peut valoir la peine de lire ce qu’ils sont . (Pour résumer : ce sont des langages de code qui s’exécutent uniquement sur un serveur au lieu du navigateur, et ont généralement des capacités beaucoup plus larges et plus puissantes.)
Ceci est pertinent car il y a plusieurs années, vers 2009, il y avait des gens très intelligents qui aimaient vraiment JavaScript. En particulier, ils ont aimé la rapidité de JavaScript (en particulier par rapport aux langages dominants côté serveur à l’époque, notamment PHP et Ruby), et ils voulaient avoir JavaScript partout , pas seulement dans un navigateur.
Ryan Dahl est la figure la plus éminente d’entre eux, et est crédité de l’invention de Node (et plus récemment, Deno , qui est un anagramme de Node). C’est une chose amusante à savoir, mais qui n’est pas strictement pertinente pour ce sujet.
Comment fonctionne Node
Ce qui est pertinent, cependant, c’est que Node est essentiellement JavaScript en tant que langage côté serveur qui s’exécute en dehors du navigateur .
Comment est-ce possible? Sous le capot, chaque navigateur a son propre moteur JavaScript individuel. C’est la partie du navigateur qui exécute réellement JavaScript. Oui, c’est apparemment une partie distincte du navigateur et non une partie des mêmes éléments qui font le HTML et le CSS, ce qui, je suppose, a du sens quand on pense au fait que nous avons des API littérales entre le document et JavaScript. Heck, même le concept d’un DOM a plus de sens lorsque vous pensez au département qui gère JavaScript comme un bureau de fortune au bout du couloir du département HTML.
Le moteur JavaScript des navigateurs basés sur Chromium s’appelle V8, vraisemblablement d’après un type spécifique de moteur de voiture (pas la « boisson végétale » composée principalement de jus de tomate). V8 est de loin le moteur JavaScript le plus populaire. Grâce aux efforts de normalisation ECMAScript au cours des 15 dernières années environ, il n’y a plus vraiment de différences majeures entre les moteurs JavaScript en ce qui concerne les navigateurs. Le moteur utilisé dans Chrome ressemble beaucoup au moteur qui s’exécute dans Firefox, qui ressemble beaucoup à Safari, etc. La popularité de V8 ces jours-ci a moins à voir avec ses distinctions, et plus à voir avec l’ubiquité autonome de Chrome.
(Remarque : le moteur JavaScript de Firefox s’appelle SpiderMonkey. Ce n’est pas particulièrement pertinent, mais c’est une preuve supplémentaire que Firefox est le plus cool.)
Pourquoi est-ce important ? Eh bien, il s’avère que vous pouvez retirer le moteur JavaScript d’ un navigateur et, avec quelques modifications, l’exécuter tout seul, un peu comme si vous décidiez de retirer la chaîne stéréo d’une voiture, de bricoler un peu et de la rendre dans un système stéréo pour votre maison à la place. Le V8 (et, vraisemblablement, la chaîne stéréo d’une voiture) peut parfaitement fonctionner comme une unité autonome dans n’importe quel environnement.
En d’autres termes : V8 permet d’exécuter JavaScript n’importe où . C’est pourquoi nous avons du JavaScript « noeud » et du JavaScript « basé sur le navigateur ».
Node est presque (mais pas exactement) JavaScript
Pour récapituler : JavaScript est désormais un langage côté serveur ! Cela s’appelle Node, et cela pourrait signifier que vous n’avez même pas besoin d’apprendre quoi que ce soit sur les autres langages côté serveur. Nous sommes des développeurs front-end, et nous avons maintenant des super-pouvoirs .
Cela dit, cependant, Node et le JavaScript que vous avez l’habitude d’exécuter dans le navigateur sont à la fois similaires et très différents l’un de l’autre.
Au risque d’aller trop loin dans les mauvaises herbes ici : alors que les deux sont JavaScript à la base, et que le langage et la syntaxe sont les mêmes, de nombreux éléments de base de JavaScript dans le navigateur (comme le ou , et même le souvent window
pris document
pour -granted alert
) ne sont pas présents dans un environnement de nœud purement côté serveur. Il n’y a pas de fenêtre, bien sûr, lorsque le langage s’exécute tout seul, et non dans un navigateur. Les développeurs de New Node JavaScript sont souvent surpris d’apprendre que even fetch
est en fait une API de navigateur, et non du JavaScript « pur ».
N’ayez crainte cependant. console.log
est toujours votre meilleur ami, et il existe de nombreuses nouvelles fonctionnalités spécifiques à l’environnement de Node JavaScript qui diffèrent de l’implémentation de JavaScript par le navigateur, comme l’ process
objet, qui contient tous les détails sur tous les processus en cours d’exécution.
Node et son écosystème ont souvent, par nécessité, évolué dans une direction très différente de celle de JavaScript basé sur un navigateur au fil des ans. (A titre d’exemple évident : la syntaxe des importations entre les deux a été différente pendant des années, et commence seulement maintenant à fusionner à nouveau. Nous en reparlerons un peu plus dans le dernier chapitre .)
Node a longtemps eu le privilège de pouvoir se déplacer beaucoup plus rapidement que les navigateurs lorsqu’il s’agit d’acquérir de nouvelles fonctionnalités, et a également dû faire face à ses propres préoccupations. Il a commencé à alimenter les applications côté serveur de la même manière que Ruby et PHP le faisaient depuis des années, même lorsque les navigateurs essayaient encore de fusionner sur des normes. Cela a fait que Node JavaScript et JavaScript basé sur un navigateur ressemblent plus à des cousins qu’à des clones.
Voici ce que je pense être une analogie juste pour expliquer les différences entre les deux cousins JavaScript : considérez deux instruments de musique similaires, disons une contrebasse et une guitare basse électrique moderne. Les deux instruments sont accordés de la même manière et jouent les mêmes notes ; si vous en connaissez un, à bien des égards, vous connaissez en quelque sorte l’autre. Mais même s’il vous sera beaucoup plus facile d’apprendre l’un après avoir appris l’autre, jouer le nouveau sera très différent de ce à quoi vous êtes habitué.

De même, alors qu’un développeur peut écrire un type de JavaScript et qu’un second développeur écrit dans un autre type de JavaScript, il est peu probable que leurs travaux se ressemblent.
Node est JavaScript, avec les capacités d’autres langages côté serveur mentionnés précédemment – des choses comme la lecture et l’écriture dans le système de fichiers, l’accès aux API au niveau du système, le courrier électronique, la capacité d’écouter et de répondre aux demandes, les tâches planifiées… le la liste continue.
Je n’en dirai pas plus ici, mais sachez simplement que même si les deux sont en fin de compte JavaScript, ils s’exécutent dans des environnements différents et sont chacun capables de faire certaines choses que l’autre ne peut pas faire. Même si vous avez déjà écrit du JavaScript basé sur un navigateur, Node vous semblera probablement un peu étranger au-delà de la syntaxe fondamentale et sera souvent utilisé de manière très différente.
Exécuter Node localement
Comme c’est généralement le cas avec les langages côté serveur, vous devez installer Node avant de pouvoir l’utiliser.
Node est généralement installé avec npm, ensemble, car la partie gestionnaire de packages a besoin de Node, et la partie Node est plus utile avec un gestionnaire de packages. (On pourrait dire qu’il s’agit d’un forfait . Non, je ne m’excuserai pas pour cette blague. Je suis un père, après tout.)
Je voudrais souligner à ce stade que vous n’avez pas besoin de savoir quoi que ce soit sur Node pour utiliser npm . Donc, même si je suis sur le point de couvrir ici quelques exemples de nœuds, veuillez considérer toute cette section comme quelque chose de bon à savoir, mais qui n’est pas essentiel à cette fin. Je pense qu’il est toujours utile d’avoir une idée un peu meilleure du fonctionnement de Node, juste pour brosser un tableau plus complet.
Nous verrons comment installer Node et npm dans un prochain chapitre de ce guide. Donc, si vous ne l’avez pas déjà installé, vous pouvez soit jeter un coup d’œil sur cette partie, soit revenir ici quand vous l’aurez prête. Quoi qu’il en soit, cela ne sera pas crucial pour suivre ce guide npm.
Si vous souhaitez l’essayer, vous pouvez créer un nouveau test.js
fichier et y mettre du JavaScript générique. Quelque chose d’artificiel comme le code suivant qui enregistre du contenu sur la console devrait faire l’affaire :
console.log('Look, ma, Node hands!')
const oneThroughFive = [1, 2, 3, 4, 5]
oneThroughFive.forEach(number => {
console.log(number)
})
Disons que vous enregistrez ce code, puis ouvrez la ligne de commande dans une fenêtre de terminal, naviguez jusqu’à l’emplacement du fichier (en utilisant cd
, ou « changer de répertoire ») et exécutez node test.js
pour obtenir la sortie suivante :
Look, ma, Node hands!
1
2
3
4
5
Vous pouvez également entrer node
par lui-même (pas de nom de fichier après) pour ouvrir un terminal interactif où vous pouvez exécuter du Node JavaScript arbitraire. Si vous avez déjà ouvert la console dans les DevTools de votre navigateur pour taper du code, c’est exactement ce que c’est, juste sur la ligne de commande avec Node à la place.
Essayez-le si vous le souhaitez, en supposant que Node est installé. Mais encore une fois, tout ceci est juste à titre d’illustration et n’est pas nécessaire pour utiliser npm.

Et après
Tout ce que nous avons couvert dans ce chapitre est astucieux et, espérons-le, vous aidera à vous montrer (quoique simplement) le fonctionnement de Node. N’oubliez pas que même si nous n’en avons couvert aucun exemple spécifique, Node est capable de faire tout ce qu’un langage côté serveur peut faire. Il n’est, espérons-le, pas trop difficile d’imaginer à quel point l’exécution de JavaScript pour faire pratiquement tout ce que vous pouvez imaginer au niveau du système ou même sur un serveur distant est très attrayante et avantageuse.
Le concept de Node a commencé comme un moyen d’exécuter JavaScript en dehors du navigateur. En tant que tels, nous avons des packages de scripts basés sur Node qui sont utilisés pour nous aider dans le développement frontal. Alors, comment installer ces packages et s’assurer qu’ils sont non seulement mis à jour, mais qu’ils peuvent être désinstallés ? C’est contenu dans les deux dernières lettres de l’abréviation npm : package manager .
En d’autres termes, npm est un outil qui gère les packages écrits en Node JavaScript. Qu’est-ce qu’un gestionnaire de paquets exactement et comment npm est-il considéré comme tel ? C’est la prochaine étape dans notre guide npm.
Si vous comptez les points, jusqu’à présent, dans ce guide npm, nous avons développé une compréhension générale de ce qu’est npm, notamment qu’il signifie Node Package Manager. Au cours du processus, nous avons discuté de l’importance de la ligne de commande et de son utilisation avec npm.
Nous avons également examiné spécifiquement le « n » dans npm – Node – et avons appris que Node ressemble beaucoup au code JavaScript que nous écrivons pour être exécuté sur des sites Web dans un navigateur. En fait, Node est JavaScript ; il s’exécute simplement en dehors du navigateur et est capable de faire des choses différentes de son homologue basé sur un navigateur.
Chapitres du guide
- À qui diable s’adresse ce guide ?
- Qu’est-ce que « npm » signifie ?
- Qu’est-ce que c’est que la ligne de commande ?
- Qu’est-ce que c’est que Node ?
- Qu’est-ce que c’est qu’un gestionnaire de paquets ? (Tu es là!)
- Comment diable installez-vous npm ?
- Comment diable installez-vous les packages npm ?
- Que diable sont les commandes npm ?
- Comment diable installez-vous un projet npm existant ?
Ce que nous entendons par « paquet »
Portons maintenant notre attention sur les deux dernières lettres de npm, à savoir la partie « gestionnaire de paquets ». Afin de bien comprendre ce qu’est npm, nous devons savoir ce qu’est un gestionnaire de paquets. Il s’ensuit donc naturellement que pour comprendre cela , nous devons comprendre ce qu’est un « paquet ».
« Package » est un terme fourre-tout pour tous les fichiers de code externes que vous intégrez à un projet et que vous utilisez d’une manière ou d’une autre. Peut-être avez-vous déjà utilisé jQuery , Bootstrap ou Axios sur un projet dans le passé. Ce sont des exemples courants de packages.
Nous appelons ces « packages » car ils sont « emballés » et prêts à être utilisés. Certains langages les appellent par d’autres noms (Ruby les appelle « gemmes » par exemple), mais le concept est le même. Au risque de trop simplifier, un package est un code que vous n’avez pas écrit mais que vous avez obtenu d’une source publique pour l’utiliser dans votre projet. Vous savez, code tiers.
Ou, si vous préférez les parodies musicales pour vos appareils mnémotechniques :
🎵 Quand il y a du code que vous choisissez
🎵 Ce n’est pas le vôtre, mais que vous utilisez
🎵 C’est un paquet
🎵 Quand c’est des trucs que vous installez
🎵 Que vous importez et appelez,
🎵 C’est un paquet
Les packages sont également souvent appelés « dépendances », car le code que vous écrivez dépend de leur présence. Le code écrit à l’aide de jQuery $
ne fonctionnera pas correctement si jQuery lui-même n’est pas déjà chargé, par exemple. (Pour cette raison, les gestionnaires de packages sont aussi parfois appelés « gestionnaires de dépendances ».)
Les packages peuvent être grands ou petits en termes de quantité de code qu’ils contiennent. Un paquet peut faire quelque chose d’énorme qui change la façon dont vous écrivez l’ensemble de votre projet (comme un framework entier), ou il peut faire quelque chose de très petit et ciblé que vous ne saupoudrez que là où c’est nécessaire (comme un widget ou une aide pour une tâche spécifique) .
Utiliser des packages sans gestionnaire de packages
Très probablement, si vous avez utilisé un package dans le passé, vous l’avez simplement appliqué avec une balise de script dans le HTML qui extrait d’une URL externe (idéalement d’un CDN ). Voici comment vous pouvez inclure jQuery dans le code HTML de votre site :
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
Une autre approche consiste à télécharger une copie du package, à l’ajouter aux fichiers de votre projet et à le lier localement, comme ceci :
<script src="/jquery.min.js"></script>
Ce que les gestionnaires de packages résolvent
Ces deux approches ont bien fonctionné pendant des années. C’est simple. C’est propre. Il vous permet généralement de «régler et d’oublier» en ce qui concerne le package. Alors pourquoi auriez-vous besoin d’autre chose ?
Vous pouvez probablement imaginer à quel point posséder une voiture peut sembler peu attrayant pour quelqu’un qui a facilement accès à un transport en commun pratique ou qui n’a pas besoin de voyager sur de longues distances. (Ce sera lié à la discussion sur le gestionnaire de paquets, je le promets. Restez avec moi.)
Si vous avez un accès facile à des transports en commun pratiques et efficaces, payer un prix élevé pour une machine massive que vous devez stocker quelque part, nettoyer régulièrement, entretenir et remplir de carburant coûteux n’apportera probablement pas beaucoup d’avantages de votre point de vue. Dans ce cas précis, les bénéfices sont négligeables ; les coûts sont relativement écrasants. Quelqu’un dans cette position hypothétique pourrait même se demander pourquoi quelqu’un veut une voiture !
J’évoque cette analogie parce qu’il peut être très difficile d’apprendre une nouvelle technologie lorsqu’elle résout un problème que vous n’avez pas , de la même manière que l’achat d’une voiture peut ne pas résoudre les problèmes de transport que vous avez déjà. Cela peut sembler une dépense massive et inutile.
Ce qu’un gestionnaire de paquets résout, alors, est plus une question de mise à l’échelle et de gestion des problèmes. Le simple lien vers un package dans une balise de script fonctionne bien, tant que :
- le nombre de projets que vous avez est gérable ;
- le nombre de personnes travaillant sur les projets est gérable ;
- le nombre de mises à jour à apporter aux packages est gérable ; et, surtout,
- chaque package utilisé dans vos projets est JavaScript ou CSS côté client (navigateur).
Ce dernier est le doozy, car il y a une pléthore d’outils que vous ne pouvez jamais utiliser si vous n’exécutez que des choses dans le navigateur (plus à ce sujet dans un instant).
Si vous cochez toutes ces cases, vous ne dépasserez peut-être jamais cette approche. Votre approche de développement pourrait ressembler à ceci :

Mais même dans ce cas, lorsque vous avez plusieurs <script>
balises, chacune étant liée à une version spécifique d’un script ou d’une bibliothèque, le seul moyen d’obtenir une visibilité sur les packages que vous utilisez et s’ils sont à jour date—est d’ouvrir manuellement le code HTML et d’examiner le code.
Ce n’est pas vraiment un problème en soi, mais c’est un problème qui croît de façon exponentielle à mesure que la taille et la portée d’un projet augmentent. Vous pouvez peut-être suivre manuellement quelques packages, mais comment pourriez-vous le faire alors que nous parlons de centaines, voire de milliers de packages ? Et même si vous pouviez les suivre manuellement, cela introduisait toujours un risque élevé d’erreur humaine.
Ce n’est pas le travail de HTML d’être la source de vérité pour tous les packages utilisés sur un projet. En plus de mélanger les problèmes, cela introduit également potentiellement des conflits lorsque vous essayez de fusionner des tâches non liées entre coéquipiers.
Tout cela est important, mais c’est la plus petite partie d’un problème plus vaste. Comprenez que JavaScript côté client n’est probablement pas le seul type de package que vous voudrez inclure dans vos projets pour toujours, même si c’est le cas pour le moment, et c’est là que les choses commencent vraiment à s’effondrer.
De nombreuses applications de production utilisent une combinaison des outils et packages suivants, voire tous :
- Sass (facilite l’écriture de CSS)
- PostCSS (améliore le CSS pour une efficacité et une compatibilité maximales)
- Babel (transpile le nouveau JavaScript pour qu’il s’exécute dans les anciens navigateurs)
- TypeScript (ajoute la vérification de type à JavaScript)
- Rechargement du module à chaud par un serveur de développement qui actualise automatiquement le navigateur pour afficher vos modifications
- Utilitaires supplémentaires pour le regroupement de code, la minification et/ou la concaténation
- Compression automatique des images
- Bibliothèques de tests
- Linters
Tout cela a l’air merveilleux – et ça l’est ! – mais remarquez que vous avez maintenant de multiples dépendances qui non seulement ne sont pas présentes dans vos balises de script, mais qui ne sont pas du tout prises en compte dans votre projet ! Il n’y a aucun moyen pour quiconque, y compris votre futur moi, d’avoir une idée des outils utilisés ou nécessaires pour faire fonctionner ce projet.
Et même si vous pouviez savoir exactement ce dont le projet avait besoin de cette façon, vous auriez toujours besoin d’aller localiser, télécharger et installer vous-même tous ces packages… manuellement. Selon le projet, cela pourrait facilement être une tâche d’une journée ou plus.
Tout cela signifie que votre flux de travail ressemble maintenant un peu plus à ceci :

Aussi pratiques que soient tous les outils ci-dessus, vous devez toujours les gérer . Les dépendances sont également des projets, et elles fournissent des mises à jour pour corriger les bogues et introduire de nouvelles fonctionnalités. En tant que tel, il n’est pas réaliste de simplement coller une balise de script dans le HTML avec un lien qui pointe vers un package sur un CDN, puis de l’appeler bon. Vous devez vous assurer que chaque élément est installé et fonctionne correctement, non seulement sur votre ordinateur, mais également sur l’ordinateur de chaque collaborateur.
Les gestionnaires de packages existent pour rendre les packages (ou dépendances) d’un projet gérables en sachant ce qui est installé, ce qui est disponible pour la mise à jour et si un package peut créer des conflits avec un autre. Et la beauté d’un gestionnaire de paquets est qu’il accomplit tout cela directement à partir de la ligne de commande, avec un minimum d’effort.
De nombreux gestionnaires de packages, en particulier npm, fournissent également des fonctionnalités supplémentaires qui ouvrent encore plus de possibilités pour rendre le développement plus efficace. Mais la gestion des packages est l’attraction principale.
Il y a des gestionnaires de paquets qui ne sont pas npm
Cette partie n’est pas très pertinente pour npm lui-même, mais par souci d’exhaustivité, je dois également mentionner que npm n’est pas le seul gestionnaire de packages JavaScript. Par exemple, vous pouvez voir Yarn référencé dans les exemples de code. Yarn et npm fonctionnent à peu près de la même manière, dans la mesure où une grande partie de l’interopérabilité entre les deux est volontairement intégrée.
Certaines personnes préfèrent un gestionnaire de paquets à un autre. Personnellement, je pense que les différences entre npm et Yarn étaient plus prononcées au début, mais les deux sont maintenant plus similaires qu’autrement.
Vous pouvez voir des exemples de code (dont certains dans les articles CSS-Tricks) qui font référence à la fois yarn
et npm
ensemble. C’est pour faire savoir au lecteur que l’une ou l’autre approche est bonne, plutôt que la nécessité d’utiliser les deux ensemble.
La syntaxe de Yarn et npm diffère parfois, mais lorsqu’un seul est présent, il est généralement trivial de convertir une commande ou un projet de l’un à l’autre. Fonctionnellement, il est rarement (voire jamais) important de savoir lequel vous utilisez, sauf, bien sûr, que tous ceux qui travaillent ensemble sur le même projet voudront utiliser le même pour assurer la compatibilité et la cohérence.
Alors que npm et Yarn constituent la grande majorité des gestionnaires de packages utilisés par les développeurs, il existe un autre gestionnaire de packages appelé PnPm qui est effectivement npm, mais plus performant et efficace. Le compromis est que PnPm nécessite un peu plus de savoir-faire technique dans certains cas, c’est donc un peu plus une option avancée.

Ce qui fait de npm le gestionnaire de paquets « standard »
Encore une fois, je n’évoque d’autres gestionnaires de paquets que pour illustrer que npm n’est pas le seul gestionnaire de paquets, mais c’est généralement la norme.
Qu’est-ce qui en fait le « standard » parmi les gestionnaires de packages ? D’autres langages, dont Ruby et PHP, ont des gestionnaires de packages depuis de nombreuses années ; JavaScript n’en avait vraiment pas de bons avant npm.
npm a commencé comme un projet open source indépendant, mais a été acquis par Microsoft en 2020 . Il comporte techniquement deux parties : le gestionnaire de paquets lui-même ; et le registre des packages, qui est une liste sans cesse croissante de près de deux millions de packages disponibles à installer.
Vous pouvez considérer npm comme la boutique d’applications pour tout ce que vous souhaitez utiliser sur un projet frontal ou basé sur un nœud. Trouvez ce que vous voulez et installez-le sur votre système via la ligne de commande. Vous pouvez mettre à jour ce package lorsqu’une nouvelle version est publiée, ou le supprimer complètement si le projet n’en dépend plus.
Une note sur npx
Vous pouvez également voir npx
des commandes flotter là-bas. npx fait en fait partie de npm, mais en utilisant npx
in a command au lieu de npm
, vous pouvez exécuter le code d’un package sans l’installer de manière permanente . NPX installe simplement ce dont il a besoin, l’exécute et le vide.
Ceci est utile si, par exemple, vous souhaitez exécuter un script d’installation. Plutôt que de télécharger le programme d’installation, puis de l’exécuter, npx vous permet simplement d’exécuter le programme d’installation directement, sans rien laisser sur votre machine par la suite. C’est comme l’invité de la maison qui nettoie après lui-même.
Un autre exemple intéressant : vous pouvez exécuter npx sass
(avec les arguments d’entrée et de sortie nécessaires) si vous souhaitez compiler les fichiers Sass de votre projet une seule fois sans vous soucier d’installer complètement Sass. Ce n’est probablement pas pratique dans la plupart des cas, mais si vous aviez juste besoin d’une compilation ponctuelle rapide ici et là, npx serait un moyen pratique de le faire, car cela signifie moins de packages installés qui doivent être mis à jour et maintenus.
Et après
D’accord, c’est donc une plongée profonde dans ce que nous voulons dire lorsque nous appelons quelque chose un gestionnaire de paquets. Dans le cas de npm, il est utilisé spécifiquement pour installer et gérer les packages Node, des outils qui aident à ajouter des fonctionnalités à un projet, à ajouter des commodités pratiques pour les développeurs… ou tout ce qui précède !
Ensuite, nous allons faire notre premier pas dans l’utilisation de npm. Et pour ce faire, nous devons l’installer sur notre système. C’est la prochaine étape de ce guide complet sur npm.
Vous avez l’impression d’avoir une assez bonne idée de ce qu’est un gestionnaire de paquets ? Nous avons certainement parcouru beaucoup de chemin en nous familiarisant avec tous les termes et concepts des gestionnaires de paquets, mais je dirais qu’il est grand temps que nous fassions quelque chose avec nos nouvelles connaissances. Mais d’abord, nous devons installer npm.
À cette fin, nous allons nous assurer que Node et npm sont installés, puis créer un petit exemple de projet pour vous donner une véritable expérience pratique de travail avec les bases de npm et à quoi cela ressemble d’utiliser npm dans votre front-end workflow de développement.
Chapitres du guide
- À qui diable s’adresse ce guide ?
- Qu’est-ce que « npm » signifie ?
- Qu’est-ce que c’est que la ligne de commande ?
- Qu’est-ce que c’est que Node ?
- Qu’est-ce que c’est qu’un gestionnaire de paquets ?
- Comment diable installez-vous npm ? (Tu es là!)
- Comment diable installez-vous les packages npm ?
- Que diable sont les commandes npm ?
- Comment diable installez-vous un projet npm existant ?
Confirmer si npm est déjà installé
Avant d’installer npm, nous devons confirmer s’il est déjà installé ! Si vous ne savez pas si npm est déjà installé sur votre système, ouvrez le terminal de votre choix, qu’il s’agisse de l’application Terminal sous MacOS, du terminal intégré dans un éditeur de code tel que VS Code ou d’un autre terminal auquel vous avez accès. la ligne de commande.
Prêt? Commencez par cette commande (notez que nous n’incluons pas le $
caractère dans ces exemples) :
node -v
Cette commande affiche la version actuelle de Node, c’est-à-dire si elle est installée. Si Node est installé, la ligne de commande répondra avec le numéro de version de Node actuellement installé :
v16.9.1
Votre version peut être différente, bien sûr. Dans tous les cas, le fait que vous voyiez un numéro de version confirme que npm est installé sur votre système ! Permettez-moi de souligner que les chiffres eux-mêmes ne sont pas importants , tant que nous obtenons un numéro de version.
Si npm ou Node n’est pas actuellement installé, vous verrez un message du type « Commande introuvable » à la place. Dans le cas peu probable où npm est installé mais que Node ne l’est pas (ou vice versa), il vaut probablement la peine de le désinstaller avant de continuer.
En supposant que vous ayez besoin d’installer npm et Node (et si ce n’est pas le cas, vous pouvez passer à la section suivante), nous allons suivre les conseils des instructions officielles de NPM et le faire via un programme appelé nvm .
Installation du gestionnaire de versions de nœud
Node Version Manager, ou nvm, vous permet d’installer, de mettre à jour et de désinstaller Node sur votre système, ainsi que de gérer plusieurs versions de Node entre lesquelles vous pouvez basculer.

Comme vous le savez peut-être, les langages côté serveur ont leurs propres versions, par exemple, Node 17.1.0, plutôt que d’être liés aux versions de navigateur, telles que Chrome 96. Nous n’aurons besoin d’aucune version de Node mais de la dernière, donc ceci ne nous sera pas nécessaire pour le moment, bien que cela puisse être avantageux pour vous plus tard.
Je sais, cela peut sembler beaucoup de travail supplémentaire pour installer un programme juste pour en installer un autre, mais encore une fois, c’est le chemin recommandé, et faire les choses correctement dès le début les rend beaucoup plus faciles à long terme. Je préfère vous préparer au succès plutôt que de rendre les choses brièvement plus faciles au détriment d’une plus grande complexité plus tard.
Installation de nvm sous Windows
Si vous êtes sur Windows, vous aurez plus de facilité ici. Vous aurez spécifiquement besoin de nvm pour Windows, mais heureusement, Windows dispose déjà d’un programme d’installation que vous téléchargez et exécutez simplement. Les instructions se trouvent dans le référentiel NVM pour Windows sur GitHub.
- Téléchargez la dernière version de NVM pour Windows . Il peut être installé manuellement , si vous préférez.
- Ouvrez le terminal et exécutez la
nvm list available
commande pour voir une liste des versions de Node disponibles au téléchargement et à l’installation. - Exécutez la
nvm use
commande, suivie du numéro de version du nœud que vous souhaitez utiliser (par exemplenvm use 16.9.1
) pour utiliser une version spécifique. Vous pouvez également utiliser uselatest
,lts
ounewest
au lieu d’un numéro de version spécifique, oùnewest
est la dernière version installée .
Une fois installé, nvm fonctionnera de la même manière sur votre machine Windows que sur tout autre système.
Installer nvm sur MacOS
Pour installer nvm sur MacOS, la première étape consiste à le télécharger avec cette commande :
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
0.39.0
est la dernière version au moment de la publication, mais il peut être utile de vérifier le fichier readme d’installation de nvm et d’obtenir la dernière version, si elle est différente.
Une fois que vous avez collé cette commande dans le terminal et appuyé sur Enter, vous verrez votre terminal sortir un tas de choses qui n’ont pas vraiment d’importance. En fait, je vais vous confier un petit secret : personne ne lit la plupart du temps ce qui se trouve dans son terminal. Tout ce qui nous importe, c’est que…
- la commande finit par se terminer ; et
- cela ne se termine pas par un message d’erreur.
Si vous êtes invité à entrer une commande au milieu de l’installation, appuyez sur la qtouche pour quitter et continuer.
Vous saurez que la commande est terminée lorsque le curseur de saisie recommence à clignoter, indiquant que le terminal attend votre saisie. Vous pourriez même voir ceci juste après l’installation de nvm :
=> Close and reopen your terminal to start using nvm or run the following to use it now:
En supposant que vous ne voyez aucune erreur à ce stade, je recommanderais l’option la plus simple de quitter et de redémarrer l’application de terminal que vous utilisez avant de continuer. C’est une bonne façon de s’assurer que vous travaillez avec une table rase.
Comment installer npm via Node
Maintenant que nvm est installé, nous sommes prêts à faire ce que nous voulions vraiment faire en premier lieu : installer npm et Node sur notre système.
Ce n’est pas une mauvaise idée de confirmer que nvm est correctement installé en exécutant nvm -v
. Si le terminal vous montre le numéro de version installé, vous êtes prêt à partir ! Si ce n’est pas le cas, n’oubliez pas que vous devrez peut-être redémarrer votre application de terminal avant que l’installation ne soit entièrement terminée.
Maintenant que nous avons nvm, l’installation de Node est une commande super courte :
nvm install node
Assez simple, hein ?
Vous devriez voir un message du type Downloading and installing node v17.1.0
, même si le numéro de version peut ne pas correspondre, ce qui est bien. Vous obtiendrez la dernière version stable au moment de l’exécution. Attendez que la commande ait fini de s’exécuter – encore une fois, vous saurez que c’est fait une fois que vous serez de retour à l’invite par défaut et que vous pourrez taper plus de commandes.
Après cela, vous avez terminé ici ! Cette simple commande installe non seulement Node, mais elle installera également npm. Encore une fois, vous pouvez vérifier que tout est installé et à jour avec npm -v
et node -v
. Si tout va bien, vous obtiendrez un numéro de version.
Et après
Très bien, à ce stade, nous avons nvm pour installer et gérer Node, Node lui-même et npm pour gérer les packages Node. Ensuite dans ce guide npm, nous allons installer des packages dans un projet !
À présent, vous devenez assez bien informé avec npm ! Jusqu’à présent, nous avons décomposé les trois lettres de « npm » pour mieux comprendre les gestionnaires de nœuds et de packages. Dans le chapitre précédent , nous avons même installé Node et npm tout en nous familiarisant avec Node Version Manager, ou nvm. La prochaine étape de ce guide du débutant sur npm est probablement la raison pour laquelle vous êtes ici en premier lieu : installer des packages npm .
Chapitres du guide
- À qui diable s’adresse ce guide ?
- Qu’est-ce que « npm » signifie ?
- Qu’est-ce que c’est que la ligne de commande ?
- Qu’est-ce que c’est que Node ?
- Qu’est-ce que c’est qu’un gestionnaire de paquets ?
- Comment diable installez-vous npm ?
- Comment diable installez-vous les packages npm ? (Tu es là!)
- Que diable sont les commandes npm ?
- Comment diable installez-vous un projet npm existant ?
Un exemple rapide
Nous pouvons installer notre tout premier package avec la npm install
commande (ou npm i
en abrégé), suivie du nom des packages que nous voulons ajouter à notre projet. Par exemple, le package Node pour Sass s’appelle simplement « sass », ce qui signifie que nous pouvons ajouter à un projet comme celui-ci (assurez-vous simplement que vous êtes d’abord dans un nouveau dossier que vous avez créé pour ce petit projet) :
npm install sass
C’est tout ce dont vous avez besoin ! Tapez cela et npm se met directement au travail :

Ce qui se passe dans les coulisses, c’est que npm essaie de trouver un paquet nommé sass
dans le registre de paquets npm. S’il trouve ce package (ce qu’il fait), npm l’installe dans le projet dans un node_modules
dossier généré automatiquement (plus d’informations à ce sujet dans un instant ) situé dans le dossier racine du projet, y compris tout ce dont le package a besoin pour s’exécuter. (C’est pourquoi vous voyez que npm a ajouté 16 packages et audité un total de 17 packages npm, au lieu du package Sass seul – lui aussi a des dépendances!)
Une fois que nous avons exécuté la install
commande, vous remarquerez peut-être que vous ne voyez rien nommé « sass » dans le dossier du projet comme vous pourriez vous y attendre. Curieusement, cependant, nous voyons trois nouveaux éléments dans le dossier du projet : deux fichiers JSON nommés package.json
et package-lock.json
, plus un dossier entièrement nouveau node_modules
.

Qu’est-ce que c’est!? Nous avons demandé à npm d’installer Sass, pas tout ça. Cela ne fait pas partie de Sass… n’est-ce pas ? Eh bien, c’est exact, mais il y a une très bonne explication pour laquelle ces nouveaux éléments ont été générés dans le dossier du projet. Regardons ce qui vient de se passer.
Que se passe-t-il lorsque vous installez un package
Lorsque vous installez (ou désinstallez ou mettez à jour) un package, npm fait la plupart, sinon la totalité, des quatre choses suivantes :
- Met à jour le
package.json
fichier dans votre projet, si nécessaire ; - met à jour le
package-lock.json
fichier (appelé « lockfile ») qui contient toutes les spécificités techniques ; - installe les fichiers de package réels – et tous les autres packages dont le package d’origine pourrait dépendre (à l’intérieur du
node_modules
dossier); et - exécute un audit des packages installés.
Passons en revue ceux-ci un par un.
package.json
etpackage-lock.json
Ces deux fichiers JSON fonctionnent ensemble pour garantir un enregistrement précis de toutes les dépendances de votre projet (et de toutes leurs dépendances, et de toutes les dépendances de leurs dépendances, etc.). La différence est un peu technique, mais vaguement expliquée : le fichier de verrouillage est l’instantané détaillé et précis de l’arborescence des dépendances du projet, et est package.json
un aperçu de haut niveau, qui peut également contenir d’autres choses. Les principaux packages que vous installez peuvent être répertoriés dans package.json
, mais package-lock.json
c’est là que l’intégralité de l’arborescence des dépendances est suivie.
Le fichier de verrouillage n’est également jamais censé être mis à jour manuellement ; uniquement par npm. Veillez donc à ne pas confondre le fichier de verrouillage avec le package.json
fichier.
Lorsque vous partagez ou collaborez avec d’autres sur un projet, npm sait d’où vient le projet et exactement ce que vous avez installé dans le projet par ces deux fichiers. Il peut reproduire précisément cet environnement sur la machine de n’importe qui d’autre, grâce à ses informations. Les deux fichiers sont destinés à être validés dans votre référentiel Git et servent de plan de dépendance de votre projet. De cette façon, lorsqu’un autre développeur de votre équipe clone le référentiel et exécute la npm install
commande, npm sait exactement quels packages installer, ce qui vous permet de rester synchronisés avec votre collègue.
Si vous ouvrez package.json
, vous ne verrez pas grand-chose, mais cela vaut la peine d’y jeter un coup d’œil juste pour voir ce qui se passe :
{
"dependencies": {
"sass": "^1.43.4"
}
}
Vous ne verrez probablement pas ce numéro de version exact (puisque le package a été mis à jour depuis le moment de la rédaction), mais vous devriez le voir dans un objet sass
JSON . dependencies
Le numéro lui-même ( 1.43.4
dans ce cas) indique la version spécifique de Sass qui est installée.
En guise de tangente latérale brève mais importante : le caractère carat ( ^
) au début du numéro de version indique à npm qu’il est autorisé à installer des mises à jour mineures du package. En d’autres termes, il indique à npm que le package Sass installé doit être au moins version 1.43.4
, mais peut être n’importe quelle 1.x.x
version supérieure, tant qu’il est toujours sous 2.0.0
. npm choisit généralement la dernière version stable lorsqu’un paquet est installé, mais l’ajoute pour permettre des mises à jour ininterrompues. Ce bit s’appelle « version sémantique » et c’est un article de blog en soi, mais pas unique à npm.
Quoi qu’il en soit, cela couvre les deux fichiers JSON. Parlons node_modules
ensuite du dossier.
node_modules
node_modules
est l’endroit où réside tout le code du package ; c’est là que vos packages Node installés et tout ce qui les fait fonctionner sont réellement installés. Si vous ouvrez le dossier tout de suite pendant que vous suivez, vous trouverez un sass
dossier, mais également à côté de plusieurs autres dossiers.
La raison des dossiers supplémentaires est que lorsque vous installez un package, il peut avoir besoin d’autres packages pour fonctionner correctement (comme le fait clairement Sass). Ainsi, npm effectue automatiquement le travail acharné de recherche et d’installation de toutes ces dépendances. Comme vous l’avez peut-être deviné, ces dépendances peuvent également avoir d’autres dépendances qui leur sont propres, et donc le processus se répète, ainsi de suite, jusqu’à ce que nous ayons fini d’explorer l’arborescence des dépendances jusqu’à ses branches les plus éloignées et que tout ce dont nous avons besoin soit installé ( ou jusqu’à ce que nous ayons rencontré une erreur quelconque, mais espérons-le non).
Pour cette raison, il est courant qu’un projet ait node_modules
des centaines de sous-dossiers ou plus, qui s’accumulent rapidement en termes d’espace disque. node_modules
peut souvent devenir assez lourd.
Si vous vous demandez comment valider un dossier très volumineux comme node_modules
dans le référentiel d’un projet, voici une remarque importante : contrairement aux fichiers JSON, le node_modules
dossier n’est pas destiné à être validé dans Git , ni même partagé. En fait, à peu près tous les exemples de .gitignore
fichiers (le fichier qui indique quels fichiers Git doit ignorer lors du suivi des fichiers) incluent node_modules
pour s’assurer que Git ne le touche ou ne le suit jamais.
Alors, comment quelqu’un d’autre dans votre équipe peut-il obtenir ces packages ? Ils s’exécutent npm
install
(ou npm i
pour faire court) à 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 valider (ou d’extraire) des quantités massives de données vers et depuis le référentiel d’origine.
Faire preuve de prudence lors de l’installation des dépendances
Ce vaste réseau de dépendances et leurs arrière-arrière-grandes-dépendances peuvent conduire à des situations où une petite bibliothèque utilitaire d’un certain type qui fournit un service utile peut être adoptée par de nombreux autres packages, qui sont, à leur tour, utilisés dans de nombreux autres packages . , jusqu’à ce que le code d’origine soit finalement installé discrètement sur un pourcentage important de sites et d’applications.
Cela peut sembler fou (si ce n’est carrément effrayant) que, lors de l’installation de votre package unique, vous puissiez en fait laisser passer tout un tas d’autres choses . Cela peut donner l’impression d’inviter un nouvel ami à votre fête à la maison, qui se présente ensuite avec 20 inconnus non invités. Mais ce n’est pas aussi bizarre ou effrayant que cela puisse paraître, pour plusieurs raisons :
- La plupart des packages npm sont open source. Vous et n’importe qui d’autre pouvez facilement jeter un coup d’œil sous le capot et voir exactement ce que fait le paquet. Vous pouvez également rechercher le package dans le registre ( npmjs.com ) pour voir combien de fois il a été installé, quand il a été mis à jour pour la dernière fois et d’autres informations pertinentes. Si un paquet est assez populaire, vous pouvez être raisonnablement certain qu’il est sûr.
- Il existe un vaste monde de fonctionnalités dont de nombreux projets auront besoin. Considérez le formatage de la date, la gestion des requêtes et des réponses HTTP, la limitation, l’anti-rebond ou les animations, tout comme des exemples rapides. Cela n’a aucun sens de continuer à réinventer la roue et de coder à la main ces éléments chaque fois qu’ils sont utilisés dans un nouveau projet.
- L’installation d’un package n’est pas vraiment différente de l’installation d’une application sur votre téléphone ou d’un plugin sur un site WordPress . La différence est que nous n’avons pas le même aperçu du fonctionnement interne de ces applications et plugins que nous le faisons avec les packages, ni sur quelles autres choses ces applications et plugins pourraient s’appuyer. Il y a de fortes chances qu’ils tirent également de nombreux paquets plus petits, d’une manière ou d’une autre.
Un certain degré de prudence est une bonne idée dans tout environnement dans lequel on peut installer et exécuter du code arbitraire, bien sûr. Ne vous méprenez pas. Je mentirais si je disais que les mauvais acteurs n’ont jamais réussi à profiter de ce système. Mais sachez qu’il existe de nombreux processus en place pour éviter que les choses ne tournent mal. En cas de doute, restez avec les forfaits les plus populaires et tout ira bien.
Sachez également que npm exécute des audits de sécurité automatiques pour vous, ce qui nous amène au dernier point de cette section.
Qu’est-ce que c’est npm audit
?
Lors de l’installation sass
précédente, nous avons vu le message suivant dans le terminal une fois terminé :
found 0 vulnerabilities
Cependant, vous pouvez voir des avertissements à la place, comme mon ancien projet dans l’image suivante. J’ai décidé de le démarrer et de l’exécuter npm install
( npm i
) après qu’il soit resté assis pendant au moins deux ans. Voyons comment ça s’est passé :

Les packages avec des vulnérabilités connues sont appelés parnpm audit
, qui s’exécute automatiquement chaque fois que vous installez un package. Si vous voyez un message comme celui-ci, ne vous inquiétez pas trop ; de nombreuses vulnérabilités, en particulier dans la catégorie « modérée », comportent un risque réel très faible et peuvent n’être pertinentes que dans des situations très spécifiques. (Par exemple, il peut n’y avoir qu’une seule méthode dans un package, lorsqu’elle est utilisée d’une manière particulière, qui la rend vulnérable.)
Néanmoins, il est préférable de répondre à ce que nous pouvons, c’est-à-dire à quoi npm audit fix
sert la commande. L’ajout fix
à la fin indique à npm d’aller de l’avant et de mettre à jour vers une nouvelle version mineure de tout package présentant une vulnérabilité connue quelconque. La partie « version mineure » est importante ; les versions mineures ne sont pas censées contenir des modifications avec rupture, uniquement des mises à jour. Cela signifie qu’il devrait être sûr d’exécuter une mise à jour de cette manière sans risquer de casser votre projet.
Si l’ajout d’un numéro de version mineur au paquet ne suffit pas, vous pouvez ajouter l’ --force
indicateur à la commande d’origine :
npm audit fix --force
Il s’agit cependant d’une manœuvre risquée. Donner à npm l’autorisation « d’utiliser la force » 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 avec rupture ou introduire des incompatibilités. Je ne recommanderais pas de le faire à moins qu’il n’y ait des vulnérabilités critiques qui npm audit fix
ne peuvent pas être résolues et que vous soyez disposé et capable de passer beaucoup de temps après le dépannage, si nécessaire.
Une dernière note sur ce sujet : il est utile de savoir que vous pouvez parfois résoudre certains problèmes inattendus avec les projets npm en supprimant node_modules
et en réexécutant npm install
. C’est la façon dont npm « éteint et rallume les choses », ce que j’ai fait de très nombreuses fois moi-même.
Et après
Maintenant que nous avons exploré à fond le terrier du lapin du fonctionnement de npm sous le capot, revenons à faire les choses, d’accord ?