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.
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 installceci 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.
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 installdans 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 .
npm est comme un bâtiment de bibliothèque avec des étages de collections de livres organisés, ce qui facilite la recherche et la gestion. (Photo : Johannes Mändle sur Unsplash )
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.
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.
Par défaut, une fenêtre de terminal ressemble probablement à ceci, bien que son apparence puisse varier.
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 ne considérez probablement pas votre machine comme un serveur, et vous ne devriez pas non plus. Mais il peut exécuter des langages de programmation côté serveur.
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.
CodeKit peut exécuter une commande pour vérifier le formatage du code avec des outils comme ESLint sans utiliser directement la ligne de commande.
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.
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 windowpris documentpour -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 fetchest en fait une API de navigateur, et non du JavaScript « pur ».
N’ayez crainte cependant. console.logest 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’ processobjet, 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.jsfichier 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 :
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.jspour obtenir la sortie suivante :
Look, ma, Node hands!
1
2
3
4
5
Vous pouvez également entrer nodepar 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.
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 :
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 :
Encore une fois, tout cela est bon. Cette chaîne d’outils signifie que ce qui est envoyé au navigateur est hautement optimisé, mais c’est aussi une surcharge et une complexité supplémentaires.
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 yarnet npmensemble. 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.
Les différences de syntaxe entre les différents gestionnaires de packages sont généralement minimes. (Source : Vite )
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 npxdes commandes flotter là-bas. npx fait en fait partie de npm, mais en utilisant npxin 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.
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.
Ouvrez le terminal et exécutez la nvm list availablecommande pour voir une liste des versions de Node disponibles au téléchargement et à l’installation.
Exécutez la nvm usecommande, suivie du numéro de version du nœud que vous souhaitez utiliser (par exemple nvm use 16.9.1) pour utiliser une version spécifique. Vous pouvez également utiliser use latest, ltsou newestau lieu d’un numéro de version spécifique, où newestest 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 :
0.39.0est 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 -vet 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 .
Nous pouvons installer notre tout premier package avec la npm installcommande (ou npm ien 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é sassdans le registre de paquets npm. S’il trouve ce package (ce qu’il fait), npm l’installe dans le projet dans un node_modulesdossier 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 installcommande, 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.jsonet 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.jsonfichier dans votre projet, si nécessaire ;
met à jour le package-lock.jsonfichier (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_modulesdossier); et
exécute un audit des packages installés.
Passons en revue ceux-ci un par un.
package.jsonetpackage-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.jsonun 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.jsonc’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.jsonfichier.
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 installcommande, 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 sassJSON . dependenciesLe numéro lui-même ( 1.43.4dans 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.xversion 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_modulesensuite du dossier.
node_modules
node_modulesest 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 sassdossier, 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_modulesdes centaines de sous-dossiers ou plus, qui s’accumulent rapidement en termes d’espace disque. node_modulespeut souvent devenir assez lourd.
Si vous vous demandez comment valider un dossier très volumineux comme node_modulesdans le référentiel d’un projet, voici une remarque importante : contrairement aux fichiers JSON, le node_modulesdossier n’est pas destiné à être validé dans Git , ni même partagé. En fait, à peu près tous les exemples de .gitignorefichiers (le fichier qui indique quels fichiers Git doit ignorer lors du suivi des fichiers) incluent node_modulespour 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 npminstall(ou npm ipour 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 sasspré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é :
YIKES !
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 fixsert 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’ --forceindicateur à 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 fixne 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_moduleset 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 ?
npm est, comme vous le savez maintenant, un gestionnaire de packages . Mais comme des outils similaires antérieurs qui exécutent des tâches en ligne de commande, tels que Grunt et Gulp , npm peut également exécuter des tâches, ce qui est parfait pour nous car maintenant que nous avons installé le package Sass dans le chapitre précédent , nous pouvons commencer à l’utiliser !
Ouvrez le package.jsonfichier dans votre dossier de test et vous ne verrez pas grand-chose pour le moment ; juste une dependenciespropriété, avec une seule dépendance à ce jour :
{"dependencies":{"sass":"^1.43.4"}}
Cependant, le package.jsonfichier contient bien plus que de simples dépendances. Il contient également de nombreuses méta-informations sur votre projet. L’un des éléments les plus intéressants est une propriété facultative, mais extrêmement utile, appelée scripts.
N’oubliez pas que toutes les sous-dépendances de Sass sont suivies dans package-lock.json, qui est généré automatiquement et ne doit pas être modifié à la main. package.jsonne contient généralement que les dépendances de niveau supérieur, et nous pouvons le personnaliser librement.
L’ scriptsobjet de votre package.jsonfichier vous permet de créer des commandes que vous pouvez exécuter dans ce projet pour gérer diverses tâches à votre place, soit en tant que processus ponctuel, soit en cours d’exécution en continu. Généralement, ces « tâches » sont utilisées pour des choses comme le démarrage d’un serveur de développement pour le développement local, la compilation d’actifs et/ou l’exécution de tests. En fait, il existe souvent une seule commande startou devintégrée aux projets pour gérer toutes les tâches que vous pourriez avoir besoin d’exécuter simultanément, comme compiler Sass et JavaScript dans le même ordre.
Nous n’avons pas encore de scripts à exécuter, mais réglons cela !
Exemple : compiler Sass en CSS
À l’intérieur de la scriptssection du package.jsonfichier, nous avons accès à tous nos packages installés. Même si nous ne sommes pas en mesure de saisir simplement sassdes commandes dans le terminal pour le moment, nous pouvons exécuter sassdes commandes dans le cadre d’un script npm.
Nous pourrions exécuter sassdes commandes dans le terminal si Sass était installé globalement, ce qui signifie à l’échelle du système, plutôt qu’installé dans un dossier de projet spécifique. Jusqu’à présent, nous n’avons installé Sass que dans ce dossier (c’est ce qui se passe par défaut lorsque vous installez un package). Mais une installation globale rendrait sassles commandes disponibles n’importe où sur le système.
Commencez par coller ce bloc de code dans votre package.jsonfichier, juste après l’ {accolade d’ouverture :
La syntaxe JSON est très stricte. Essayez d’exécuter le contenu du fichier via un validateur JSON si vous êtes bloqué.
Cela nous donne accès à un npm run sass:buildscript, qui compilera Sass en CSS pour nous !
Le nom de la commande n’a pas d’importance, tant qu’il s’agit d’une chaîne continue. Il convient également de noter que les deux-points ( :) ne font rien de spécial ici ; c’est juste une convention, car l’un ou l’autre buildou sassseul serait probablement trop générique.
Si vous avez déjà travaillé avec des commandes Sass – ou si vous jetiez un coup d’œil – vous savez probablement que cela signifie que nous devons également créer un style.scssfichier à la racine de notre dossier de projet. Faisons cela et insérons-y du code Sass arbitraire.
Le style.scssfichier se trouve à côté des fichiers et du dossier JSON node_modulesau niveau supérieur du dossier du projet.
Voici le code Sass que j’ai utilisé, si vous souhaitez le copier et le coller :
Super! Enregistrez ce fichier à style.scssla racine de votre projet et essayons d’exécuter notre nouvelle commande :
npm run sass:build
Une fois cette tâche terminée, vous devriez voir apparaître presque instantanément deux nouveaux fichiers dans votre dossier de projet : style.csset style.css.map.
Après avoir exécuté npm run sass:build, vous devriez voir les fichiers style.css et style.css.map apparaître au niveau supérieur du dossier du projet.
Si vous le souhaitez, vous pouvez ouvrir le style.cssfichier — qui contient le code CSS compilé — pour vérifier que c’est bien ce que nous attendons :
Regardez ça, du pur CSS !
Le sasspackage va même jusqu’à compiler une carte source pour nous, ce qui nous permet de voir quels styles proviennent de quels .scssfichiers lorsque nous les inspectons dans les DevTools d’un navigateur. Comme c’est gentil!
Si vous rencontrez une erreur : vérifiez la syntaxe à l’intérieur de package.jsonpour vous assurer qu’il s’agit d’un JSON valide (voici un validateur JSON en ligne que vous pouvez utiliser) et que votre .scssfichier contient du Sass valide (voici un convertisseur Sass en ligne ). Une autre chose à vérifier est que le nom du fichier correspond au nom dans la commande.
Création d’une commande de développement uniquement
C’est plutôt sympa, mais nous en aurons probablement marre d’exécuter cette commande encore et encore au fur et à mesure de notre développement. Alors, configurons une deuxième commande qui dit à Sass de surveiller le fichier pour nous et de le recompiler automatiquement chaque fois que nous enregistrons des modifications !
Ajoutez ceci à l’intérieur de l’ scriptsobjet dans package.json:
"sass:watch":"sass style.scss style.css --watch"
Remarque importante : assurez-vous qu’il y a une virgule ( ,) entre les deux scripts. L’ordre n’a pas d’importance, mais la virgule entre eux fait. Encore une fois, JSON est strict, alors appuyez-vous sur le validateur JSON si nécessaire.
Maintenant, si nous exécutons sass:watch(à ne pas confondre avec sasquatch), vous verrez un message dans votre terminal disant : « Sass surveille les changements. Appuyez sur Ctrl-C pour arrêter.
Si vous ouvrez votre style.scssfichier maintenant, apportez une modification et enregistrez-le, vous devriez voir un message apparaître automatiquement dans le terminal confirmant que le Sass a été recompilé en CSS :
Maintenant c’est utile ! Non seulement cela, mais une fois que nous aurons validé ces fichiers dans notre référentiel, nous aurons les instructions exactes pour installer Sass et le faire fonctionner, avec une simple commande, et tous ceux qui travaillent sur ce projet le feront aussi !
Nous allons laisser les choses ici sur ce projet de test. Il était utile de voir comment démarrer, mais le plus souvent, vous atteindrez un projet préconfiguré, plutôt que de créer des commandes npm à partir de zéro, ce qui est exactement ce que nous ferons ensuite, dans la finale chapitre de ce guide npm.
Notes finales sur l’installation des packages npm
Vous devez savoir qu’il existe en fait deux façons d’installer les packages npm, et celle que vous souhaitez dépend si le package est destiné à faire partie de la version de production ou s’il est uniquement à des fins de développement.
npm install(ou npm i) est le moyen standard (et par défaut) d’ajouter un package à un projet.
npm install--save-dev(ou npm i -D) ajoute uniquement le package à vos « dépendances de développement », ce qui signifie qu’elles ne seront installées que lors du développement du projet, et non lors de la construction de la version de production finalisée du projet.
Les packages installés en tant que dépendances de développement peuvent inclure des bibliothèques de test, des linters, des serveurs de prévisualisation et d’autres outils qui vous aident uniquement pendant le processus de développement. Ils ne sont généralement pas utilisés pour compiler ou exécuter le site Web lui-même.
Il y a un dernier drapeau à connaître : npm install --global(ou npm i -g). Voici comment installer un paquet globalement, comme nous en avons discuté un peu plus tôt lors de l’installation de Sass. Vous pouvez l’utiliser si, par exemple, vous souhaitez pouvoir exécuter sassn’importe où sur votre machine. D’autres cas d’utilisation courants pour l’installation globale peuvent inclure des outils CLI que vous voudriez utiliser partout, ou même un autre gestionnaire de packages, comme Yarn .
Et après
Nous approchons de la fin de notre voyage ! Il y a une dernière chose que vous devez savoir, et comment utiliser npm pour faire tourner rapidement tout ce dont vous avez besoin sur un projet existant. Alors, disons que vous héritez d’un projet qui utilise npm. Par où commencer ? Comment vous assurez-vous que vous collaborez avec les autres de manière cohérente ? C’est l’objet de la dernière section de ce guide npm.
Nous avons eu un bon aperçu du fonctionnement de npm et de son utilisation pour installer des packages et exécuter des commandes à ce stade. Allons maintenant un peu plus loin et voyons à quoi ressemble le téléchargement et l’installation d’un projet npm existant , plutôt que d’en démarrer un à partir de zéro. Plus probablement qu’autrement, c’est probablement ce que vous ferez la plupart du temps. C’est beaucoup, beaucoup plus facile que d’installer et de configurer toutes les pièces individuelles une par une.
C’est ce que nous couvrons dans ce dernier chapitre du guide de npm, et je m’inspirerai de mon expérience personnelle sur un de mes projets réels.
Le projet que j’ai choisi pour cela est mon propre démarreur de blog statique SvelteKit . Je pense que c’est un bon exemple car il contient de nombreux packages préinstallés qui sont parfaits à des fins de démonstration.
C’est un de mes vrais projets qui est conçu pour vous donner – comme vous l’avez peut-être deviné par son nom – une longueur d’avance pour la construction d’un site de blog généré statiquement. (« Généré statiquement » signifie que notre code sera compilé dans .htmldes fichiers, prêts à être déployés n’importe où sur le Web. C’est l’une des quelques approches englobées dans la manière « Jamstack » de créer des sites .)
Et pas de soucis si vous ne savez rien sur SvelteKit – c’est juste pour démontrer, et nous n’écrirons rien que vous ne sachiez déjà. Cela dit, il convient de noter que SvelteKit utilise Vite sous le capot, qui est en fait un package npm qui nous donne accès à des outils de construction modernes et à un serveur de développement ultra rapide.
Cloner le projet
Tout d’abord, nous devons « cloner » le projet, qui est un mot fantaisiste pour copier le projet sur notre système afin que nous puissions travailler dessus localement. Il existe deux manières de cloner un projet existant.
Si vous préférez la manière visuelle dans le navigateur, dirigez-vous vers le référentiel de démarrage sur GitHub, cliquez sur le menu déroulant « Code » situé directement dans l’interface utilisateur de GitHub, puis sélectionnez l’option « Télécharger ZIP ».
Alternativement, si vous préférez utiliser la ligne de commande à la place, exécutez cette commande (assurez-vous simplement que vous êtes dans un endroit où cela ne vous dérange pas qu’un nouveau dossier de projet soit ajouté à votre ordinateur, par exemple ) cd /path/to/folder:
Vous vous souvenez peut-être que cela npxnous permet d’exécuter des packages npm sans les installer de manière permanente. degitclone le projet comme git clonele ferait, mais sans son historique Git (littéralement, « de-git »).
Quelle que soit la méthode que vous utilisez, vous obtenez un nouveau sveltekit-blog-starterdossier frais. Ouvrons-le dans un éditeur de code, ouvrons le terminal et exécutons la commande npm install(ou ).npm i
npm exécute automatiquement un audit lors de l’installation des packages.
À ce stade, vous verrez une note sur les vulnérabilités, comme nous l’avons couvert dans la dernière section de ce guide. Il peut dire quelque chose comme « trouvé 0 vulnérabilités » (comme dans la capture d’écran ci-dessus), mais il est tout à fait possible que ce nombre soit supérieur à zéro. Si vous voyez des vulnérabilités, ne vous inquiétez pas. Vous êtes libre de l’ignorer pour l’instant car ce n’est pas un projet que nous avons l’intention de lancer en production pour que d’autres puissent le voir ou l’utiliser. (Voir la section sur npm auditdans un chapitre précédent pour plus d’informations.)
Démarrer le serveur et apporter des modifications
Si vous deviez jeter un coup d’œil à l’intérieur du package.jsonfichier dans le projet cloné, vous verriez la commande pour démarrer le serveur de développement :
npm run dev
Exécutez cette commande dans le terminal et vous devriez voir presque immédiatement quelque chose comme ce qui suit :
Dans VS Code, vous pouvez appuyer sur CMDtout en cliquant sur l’ http://localhost:3000URL, ou vous pouvez la saisir manuellement dans votre navigateur. Dans tous les cas, le site doit s’afficher dans le navigateur !
Prenons juste un instant ici pour apprécier à quel point c’était relativement rapide et simple ! Oui, nous aurions peut-être dû installer d’abord un tas d’échafaudages, mais c’est un coût initial et unique. Nous avons un projet entier en cours d’exécution sur notre machine avec seulement quelques commandes – et nous pouvons faire la même chose chaque fois que nous voulons installer un autre projet existant !
Je n’entrerai pas dans les détails de ce projet particulier car il n’est pas important d’apprendre npm, mais c’est un bel exemple car il contient de nombreuses choses intéressantes préconfigurées, et nous pouvons facilement apporter des modifications et les voir se mettre à jour immédiatement dans le navigateur. Regardons quelques-unes de ces commandes ensuite.
SvelteKit nécessite Node 14 ou supérieur. Si vous avez installé npm dans le cadre de ce guide, cela ne vous posera aucun problème. Mais si vous l’aviez déjà installé avant de commencer, et si vous rencontrez des erreurs en essayant de faire fonctionner ce projet, cela vaut la peine d’ node -vêtre sûr. nvm est votre ami si vous avez besoin d’une mise à niveau.
Compiler automatiquement Sass lors de la sauvegarde
Vous pouvez trouver les fichiers Sass du projet dans le src/lib/assets/scss/dossier. Essayez d’ouvrir le global.scssfichier directement. Effectuez une modification, enregistrez-la et vous devriez voir la mise à jour automatiquement (et presque instantanément ) dans votre navigateur.
Faire des changements de contenu
Le site de démarrage utilise en fait le README.mdfichier du référentiel comme page d’accueil. Si vous ouvrez README.mdet commencez à apporter des modifications (ce n’est pas grave si vous ne connaissez pas Markdown , n’importe quelle modification fera l’affaire), vous devriez également voir ces modifications apparaître dès que vous enregistrez, tout comme Sass l’a fait à la dernière étape :
Si vous le souhaitez, vous pouvez ouvrir une autre page, dire le src/routes/contact.sveltefichier et mettre à jour le code HTML pour le voir s’actualiser en direct dans votre navigateur dès qu’il est enregistré.
Vous pouvez même dupliquer l’un des fichiers Markdown à l’intérieur de src/lib/posts/et apporter des modifications pour qu’il apparaisse automatiquement dans la liste des publications sur la /blogpage, si vous voulez aller aussi loin. (Assurez-vous simplement de lui donner un titre unique.)
Comprendre les importations
Il y a une chose importante à propos des projets npm que nous avons brièvement mentionnée dans le quatrième chapitre, mais que nous n’avons pas encore couverte : les importations. Ce guide ne serait pas vraiment complet si nous n’abordions pas cela. L’idée de base est que nous pouvons, comme son nom l’indique, importer un package dans notre code et l’utiliser sur place.
Comment? Ouvrez le svelte.config.jsdossier à la racine du projet et vous verrez un bloc de importlignes en haut, quelque chose comme ceci :
Chacun de ces imports est un package installé utilisé dans ce fichier. Ce que fait réellement chaque package n’est pas important pour le moment ; Je veux juste attirer l’attention sur la importsyntaxe. C’est ainsi que nous utilisons les packages dans nos fichiers de code réels ; nous disons à JavaScript ce qu’il faut importer et d’où . Ensuite, nous pouvons l’appeler dans notre code.
Cette syntaxe est appelée » importations ES6″, ce qui n’est important qu’à connaître car c’est la norme que JavaScript basée sur le navigateur et Node JavaScript ont convenu d’utiliser à l’avenir.
Auparavant, Node JavaScript utilisait (et utilise souvent encore) une syntaxe légèrement différente appelée CommonJS. Si vous voyez une importation qui ressemble à ceci, c’est l’ancien style CommonJS :
const myPackage =require('package-name')
L’autre chose cruciale à comprendre à propos du style ES6 importest la suivante : la syntaxe est spécifique à npm, pas à un standard de langage.
Pour être clair : vous pouvez utiliser importen JavaScript normal . C’est une caractéristique très ordinaire du langage à exportune variable, une fonction, un objet, etc. d’un fichier, et importde l’utiliser dans un autre. Mais pour ce faire, vous devez fournir un chemin relatif ou (dans les navigateurs plus modernes) une URL vers tout ce que vous importez. Le simple fait d’utiliser une chaîne avec le slug d’un package, comme nous le voyons ici, n’est pas valide.
Alors pourquoi est-il utilisé s’il ne s’agit pas d’un code techniquement valide ? Parce que la gestion de ce style d’importation est l’une des belles choses que npm fait pour nous. Lorsque nous disons à npm to import somePackage from 'name'en tant que chaîne sans chemin, npm sait automatiquement qu’il faut rechercher dans les packages installés sur le projet pour trouver l’importation que nous avons demandée. Cela nous évite à la fois de taper des chemins relatifs fastidieux et d’avoir réellement besoin de savoir où nos packages se trouvent au plus profond du labyrinthe de node_modules.
Cela peut aller sans dire, mais : puisque la syntaxe n’est pas valide, vous ne pourrez pas l’utiliser avec succès à moins que votre projet npm n’inclue un bundler ou un compilateur quelconque, pour traiter les importations et les modules en code de navigateur valide.
Construire le site final
La plupart des projets npm comme celui-ci ont deux objectifs principaux :
Vous aider à développer votre site ou votre application
Créer une version de production finalisée
SvelteKit ne fait pas exception. Lorsque nous avons terminé la configuration de notre (génial) serveur de développement et que nous sommes satisfaits de nos modifications, nous pouvons exécuter cette commande :
npm run build
Si votre serveur de développement est toujours en cours d’exécution, vous pouvez soit l’arrêter avec Ctrl+ C, soit ouvrir un nouvel onglet de terminal. Vous ne pourrez pas taper de commandes dans la même fenêtre de terminal où le processus de développement est en cours d’exécution, car il s’agit d’une tâche active et continue.
Lorsque nous exécutons la buildcommande, SvelteKit parcourt tous les fichiers du projet et crache une collection complète et prête à être déployée de fichiers HTML, CSS et JavaScript statiques, et le fait assez rapidement. Vous pouvez télécharger cette collection de fichiers partout où vous pouvez héberger un site Web. Outillage moderne ; bonne sortie à l’ancienne.
Lorsque la commande de construction se termine, vous devriez voir un nouveau builddossier à la racine (c’est-à-dire au niveau supérieur) de votre dossier de projet. Si vous le parcourez, vous remarquerez qu’il n’y a plus de fichiers .md, .svelte, ou tout autre fichier qui ne peut pas être lu par un navigateur. Tout a été compilé en pur HTML, CSS et JavaScript, sans oublier, comme vous le verrez si vous ouvrez un fichier JavaScript ou CSS, qu’ils sont minutieusement minifiés pour être aussi petits que possible à charger dans le navigateur aussi vite que possible .
Si vous le souhaitez, vous pouvez exécuter npm run previewune fois la construction terminée pour voir comment le site compilé se charge dans le navigateur. La différence ici est que le contenu sera chargé à partir du builddossier final, plutôt que construit avec des fichiers pré-compilés à la volée comme il le ferait lors de l’utilisation de la devcommande. Vous ne verrez aucune différence à moins d’ouvrir l’onglet Réseau dans DevTools (ou d’essayer de mettre à jour quelque chose), mais vous regarderez le produit final.
Il s’agit d’une étape facultative, mais je pense que c’est plutôt cool d’avoir une idée du peu de fichiers compilés avec lesquels nous nous retrouvons, compte tenu de tous les différents fichiers que nous mettons dans le projet, et de la taille réelle du bundle final, grâce au des outils de construction incroyables intégrés à ce projet. (Pour mémoire, tout est SvelteKit et Vite .)
Pratiques de déploiement modernes
C’est un sujet pour une autre fois, mais le déploiement moderne ne vous oblige souvent pas à exécuter une buildcommande et à télécharger les fichiers vous-même (bien que ce soit toujours une option). Au lieu de cela, un hôte (comme Netlify ou Vercel ) se connecte directement au référentiel GitHub de votre projet et, chaque fois que vous apportez des modifications à la branche principale du référentiel, l’hôte exécute votre commande de construction pour vous et déploie automatiquement les fichiers compilés !
C’est l’une des nombreuses fonctionnalités extrêmement intéressantes de cette nouvelle ère de développement frontal. Pas de problème avec FTP ou de glisser manuellement des fichiers n’importe où ; nous sommes convaincus que tout est construit et déployé automatiquement lorsque nous poussons notre code, sans que nous ayons besoin de faire quoi que ce soit !
Conclusion de ce guide npm
Si vous êtes arrivé jusqu’ici, félicitations ! Et merci. Félicitations, car ce fut une longue, longue lecture. Et merci, parce que… eh bien, ce fut une longue, longue lecture.
Mais vous avez réussi et, espérons-le, vous avez également appris des choses importantes. J’ai mentionné au début que mon objectif n’était pas la brièveté, mais l’efficacité. Cela signifie que nous avons couvert beaucoup . Nous avons commencé par un bref aperçu de npm et de sa place dans le paysage moderne du développement frontal avant de nous familiariser avec la ligne de commande . À partir de là, nous avons décomposé les termes «nœud» et «gestionnaire de paquets» pour avoir une compréhension précise de ce qu’est et fait npm. Une fois que nous nous sommes familiarisés avec le rôle que jouent les gestionnaires de packages dans le développement, nous nous sommes plongés directement dans npm, y compris comment l’installer , ajouter des packages à un projet , configurer des commandes, et enfin, comment sauter dans un projet existant qui utilise npm.
J’espère que tout ce que nous avons couvert dans ce guide npm ouvre au moins suffisamment la porte pour que vous puissiez explorer davantage npm et monter de niveau lorsque vous êtes prêt. Cela me prend souvent de répéter quelque chose plusieurs fois et d’essayer plusieurs approches pour que quelque chose s’imprègne vraiment. Donc, si vous êtes assis là à vous sentir presque aussi confus qu’avant, prenez plus de temps pour cela. Réfléchissez à ce que vous savez et à ce que vous avez appris, et revenez ou essayez une nouvelle approche lorsque vous serez prêt !
