Créer des systèmes de menu accessibles

## Introduction

Les éléments HTML peuvent être dotés d'attributs qui servent à tout, depuis l'ajout d'informations sur l'accessibilité jusqu'au contrôle stylistique.

```html


<div class="names" role="region" aria-label="Names"></div>
```

Ce qui est _déconseillé_, c'est d'_inventer_ vos propres attributs, ou de réaffecter des attributs existants pour une fonctionnalité sans rapport.

```html

<div highlight="true"></div>


<div width="large"></div>
```

C'est pas bien, et pour des tas de raisons. Votre HTML devient invalide, ce qui peut ne pas avoir de conséquences négatives réelles, mais vous prive de ce sentiment rassurant et flou d'avoir un HTML valide. La raison la plus convaincante est que le **HTML est un langage vivant** et ce n'est pas parce que des attributs et des valeurs ne font rien aujourd'hui qu'ils ne feront rien demain.

Bonne nouvelle cependant : vous pouvez créer vos propres attributs. Il vous suffit de les préfixer avec `data-*` et ensuite vous êtes libre de faire ce qui vous plaît&nbsp;!

## Syntaxe

Il est très pratique de pouvoir créer nos propres attributs HTML et d'y placer nos propres informations. Et c'est possible&nbsp;! c'est même exactement ce que sont les **data attributes** ([attributs de données](https://developer.mozilla.org/fr/docs/Learn/HTML/Howto/Use_data_attributes)). Ils sont comme ceci&nbsp;:

```html

<div data-foo></div>


<div data-size="large"></div>


<li data-prefix="Attention au HTML ici."></li>
<li>
  
  <aside data-some-long-attribute-name><aside></aside></aside>
</li>
```

Les data attributes sont souvent appelés attributs `data-*`, car ils sont toujours formatés de cette façon. Le mot `data`, puis un tiret `-`, puis un autre texte que vous pouvez inventer.

### Pouvez-vous utiliser l'attribut data seul ?

```html
<div data=""></div>
```

Cela ne va probablement pas faire de mal, mais vous n'obtiendrez pas l'API JavaScript que nous verrons plus tard dans ce guide. Vous vous créez essentiellement un attribut pour vous-même, ce qui, comme je l'ai mentionné dans l'introduction, est _déconseillé_.

#### Ce qu'il ne faut pas faire avec les data attributes

Stockez du contenu qui doit être accessible. Si le contenu doit être vu ou lu sur une page, ne le mettez pas seulement dans des data attributes, mais assurez-vous que ce contenu se trouve quelque part dans le contenu HTML.

```html

<div data-name="Chris Coyier"></div>


<div>
  <span class="visually-hidden">Chris Coyier</span>
</div>
```

Voici plus d'informations sur le [masquage des choses](/articles/cacher-des-elements-avec-css).

## Stylisation avec des data attributes

CSS peut [sélectionner des éléments HTML sur la base d'attributs](https://css-tricks.com/almanac/selectors/a/attribute/) et de leurs valeurs.

```css
/* Sélectionner tout élément ayant cet attribut de données et cette valeur */
[data-size='large'] {
  padding: 2rem;
  font-size: 125%;
}

/* Vous pouvez l'étendre à un élément, une classe ou n'importe quoi d'autre */
button[data-type='download'] {
}
.card[data-pad='extra'] {
}
```

Cela peut être convaincant. Les principaux _hooks_ de style en HTML/CSS, ce sont les **classes**, et bien que les classes soient excellentes (elles ont une spécificité moyenne et de belles méthodes JavaScript via `classList`), un élément en est doté ou non, c'est l'un ou l'autre, (essentiellement _activé_ ou _désactivé_). Avec les attributs `data-*`, vous obtenez cette capacité d'activation/désactivation, **_et_** la possibilité de sélectionner en fonction de la valeur qu'il possède au même niveau de spécificité.

```css
/* Sélectionne si l'attribut est présent du tout */
[data-size] {
}

/* Sélectionne si l'attribut a une valeur particulière */
[data-state='open'],
[aria-expanded='true'] {
}

/* Sélecteur "Commence par", ce qui signifie que cela correspond à "3" ou à tout ce qui commence par 3, comme "3.14" */
[data-version^='3'] {
}

/* "Contient" signifie que la valeur contient la chaîne de caractères n'importe où à l'intérieur */
[data-company*='google'] {
}
```

### La spécificité des sélecteurs d'attributs

C'est exactement la même chose qu'une classe. Nous pensons souvent à la spécificité comme à une valeur en quatre parties&nbsp;:

style en ligne, IDs, classes/attributs, balises.

Ainsi, un sélecteur d'attribut seul est **0, 0, 1, 0**. Un sélecteur comme celui-ci&nbsp;:

```css
div.card[data-foo='bar'] {
}
```

... serait **0, 0, 2, 1** — le 2 est dû au fait qu'il y a une classe (`.card`) et un attribut (`[data-foo="bar"]`), et le 1 est dû au fait qu'il y a une balise (`div`).



<figure role="group"><img src="/images/specificity-selector.webp" alt="schéma montrant la spécificité : une div (spécificité = 1) avec une classe (specificité = 1) et un attribut de données avec une valeur (spécificité = 1)"/><figcaption>Illustration d'un sélecteur CSS incluant un attribut data.</figcaption></figure>

Les sélecteurs d'attributs ont moins de spécificité qu'un ID, plus qu'un élément/balise, et la même chose qu'une classe.

### Valeurs d'attributs insensibles à la casse

Au cas où vous auriez besoin de corriger d'éventuelles incohérences de capitalisation dans vos data attributes, le sélecteur d'attribut dispose d'une variante insensible à la casse pour cela.

```html

[data-state="open" i] { }
```

C'est le petit `i` à l'intérieur du sélecteur entre crochets.

### Utilisation visuelle des data attributes

CSS vous permet d'extraire la valeur de l'attribut de données et de l'afficher si nécessaire.

```css
/* <div data-emoji="✅"> */

[data-emoji]::before {
  content: attr(data-emoji); /* Retourne '✅' */
  margin-right: 5px;
}
```

### Exemple de cas d'utilisation du style

Vous pourriez utiliser des data attributes pour spécifier le nombre de colonnes que vous souhaitez pour un conteneur de grille.

```html
<div data-columns="2"></div>
<div data-columns="3"></div>
<div data-columns="4"></div>
```

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_rNaEvgp" src="//codepen.io/chriscoyier/embed/rNaEvgp?height=500&amp;theme-id=light&amp;slug-hash=rNaEvgp&amp;user=chriscoyier&amp;default-tab=result" scrolling="no" frameborder="0" height="500" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="https://codepen.io/chriscoyier/pen/rNaEvgp">
  Data Attribute Based Columns</a> de chriscoyier dans <a href="https://codepen.io">CodePen</a></span>
</div>

## Accéder aux data attributes en JavaScript

Comme tout autre attribut, vous pouvez accéder à la valeur avec la méthode générique `getAttribute`.

```js
let value = el.getAttribute('data-state')

// Vous pouvez également définir la valeur.
// Returns data-state="collapsed"
el.setAttribute('data-state', 'collapsed')
```

Mais les data attributes ont également leur propre API spéciale. Admettons que vous ayez un élément avec plusieurs data attributes (ce qui est tout à fait ok) :

```html
<span
  data-info="123"
  data-index="2"
  data-prefix="Dr. "
  data-emoji-icon="🏌️♀️"
></span>
```

Si vous avez une référence à cet élément, vous pouvez définir (_set_) et obtenir (_get_) les attributs comme suit :

```js
// GET
span.dataset.info // 123
span.dataset.index // 2

// SET
span.dataset.prefix = 'M. '
span.dataset.emojiIcon = '🎪'
```

Notez l'utilisation du camelCase dans la dernière ligne. Elle convertit automatiquement les attributs de style kebab en HTML, comme `data-this-little-piggy`, en style camelCase en JavaScript, comme `dataThisLittlePiggy`.

Cette API n'est sans doute pas aussi agréable que [`classList`](https://developer.mozilla.org/fr/docs/Web/API/Element/classList) avec ses méthodes claires d'ajout, de suppression, de basculement (_toggle_) et de remplacement, mais c'est mieux que rien.

Vous avez également accès aux ensembles de données en ligne :

```html
<img src="spaceship.png"
  data-ship-id="324" data-shields="72%"
  onclick="pewpew(this.dataset.shipId)">
</img>
```

### Données JSON à l'intérieur des data attributes

```html
<ul>
  <li
    data-person='
    {
      "nom" : "Chris Coyier",
      "job" : "Personne Web"
    }
  '
  ></li>
</ul>
```

Hé, pourquoi pas ? Ce n'est qu'une chaîne de caractères et il est possible de la formater en [JSON](/articles/json-pour-les-debutants) valide (attention aux guillemets et autres). Vous pouvez extraire ces données et les parser selon vos besoins.

```js
const el = document.querySelector('li')

let json = el.dataset.person
let data = JSON.parse(json)

console.log(data.name) // Chris Coyier
console.log(data.job) // Personne Web
```

### Cas d'utilisation de JavaScript

Le concept est que vous pouvez utiliser les data attributes pour mettre dans le HTML des informations auxquelles JavaScript peut avoir besoin d'accéder pour faire certaines choses.

Un cas courant serait lié à la fonctionnalité de la base de données. Disons que vous avez un bouton "J'aime" :

```html
<button data-id="435432343">♡</button>
```

Ce bouton pourrait être doté d'un _click handler_ qui exécute une requête Ajax vers le serveur pour incrémenter le nombre de _j'aime_ dans une base de données à chaque clic. Il sait quel enregistrement mettre à jour car il l'obtient du data attribute.

### Spécifications

- [Sélecteurs niveau 4](https://drafts.csswg.org/selectors-4/#attribute-selectors) (projet)
- [Sélecteurs niveau 3](https://drafts.csswg.org/selectors-3/#attribute-selectors) (recommandé)
- [Sélecteurs de niveau 2](https://www.w3.org/TR/CSS2/selector.html#attribute-selectors), révision 1 (définition initiale)

Data attributes, guide complet

Guide de l'accessibilité du clavier: JavaScript (2e partie)


<h2>Comment une page web est-elle construite ?</h2>

Le cheminement d'un navigateur partant d'un document source HTML pour finalement afficher une page stylée et interactive s'appelle le chemin critique du rendu (<i>critical rendering path</i>). Ce processus peut comporter de nombreuses étapes, comme je le montre dans [mon article sur le sujet](https://bitsofco.de/understanding-the-critical-rendering-path/), mais celles-ci peuvent être regroupées en deux grandes étapes. La première consiste en **l'analyse du document** par le navigateur pour déterminer ce qui sera finalement rendu sur la page, et la seconde est **le rendu** par le navigateur.

<figure><img src="/images/HTML-to-Render-Tree-to-Final-compressor.png" alt="la décomposition du processus en deux étapes"/></figure>

La première étape permet de construire l'arbre de rendu (<i>render tree</i>), une représentation sous forme d'arbre des **éléments HTML** qui seront rendus sur la page ainsi que leurs styles associés. Pour cela, le navigateur a besoin de deux choses&nbsp;:

1. le CSSOM, une représentation des styles associés aux éléments
2. le DOM, la représentation des éléments

<h2>Comment le DOM est créé, et à quoi il ressemble</h2>

Le DOM est une représentation du document HTML source. Comme nous le verrons plus loin, il comporte quelques différences, mais il s’agit pour l'essentiel d’une conversion de la structure et du contenu du document HTML en un modèle objet utilisable par divers programmes.

La structure d'objet du DOM est représentée par ce qu'on appelle une "arborescence de noeuds" (<i>node tree</i>). On l'appelle ainsi parce qu'il peut être considéré comme un arbre qui se ramifie en plusieurs branches enfants, chacune pouvant avoir des feuilles. Le premier parent est l'élément racine `<html>`, les "branches" enfants sont les **éléments** imbriqués et les "feuilles" sont le **contenu** des éléments.

Prenons par exemple ce document HTML&nbsp;:

```
<!doctype html>
<html lang="en">
 <head>
   <title>My first web page</title>
  </head>
 <body>
    <h1>Hello, world!</h1>
    <p>How are you?</p>
  </body>
</html>
```

Ce document peut être représenté comme une arborescence de noeuds&nbsp;:

<figure><img src="/images/node-tree-example-compressor.png" alt=""/></figure>
 
<h2>Ce que n'est pas le DOM</h2>

De l'exemple ci-dessus on pourrait conclure que le DOM est un mapping exact du document source HTML ou de ce que vous voyez dans votre DevTools. Cependant, il y a des différences. Pour bien comprendre ce qu'est le DOM, nous devons d'abord comprendre ce qu'il n'est **pas**.

<h3>Le DOM n'est pas votre HTML source</h3>

Bien que créé à partir du document source HTML, le DOM n'en est pas toujours l'exact reflet. Il peut en différer dans deux cas&nbsp;:

<h4>1. Lorsque le HTML n'est pas valide</h4>
    
Le DOM est une interface pour les documents HTML valides. Pendant le processus de création du DOM, le navigateur peut être amené à corriger des informations invalides.
    
Prenons ce document HTML par exemple :
    
```
<!doctype html>
<html>
Hello, world!
</html>
```

Il manque les éléments `<head>` et `<body>` à ce document, alors qu'ils sont requis dans un HTML valide. Si nous inspectons l'arborescence créée, nous pouvons constater que l'erreur a été corrigée&nbsp;:

<figure><img src="/images/corrected-html-compressor.png" alt=""/></figure>
    
<h4>2. Lorsque le DOM est modifié par JavaScript</h4>

En plus d'être une interface permettant de visualiser le contenu d'un document HTML, le DOM peut être modifié, ce qui en fait une ressource vivante.

Nous pouvons par exemple créer des noeuds supplémentaires via JavaScript.

```
var newParagraph = document.createElement("p");
var paragraphContent = document.createTextNode("I'm new!");
newParagraph.appendChild(paragraphContent);
document.body.appendChild(newParagraph);
```

Le DOM sera mis à jour, mais bien entendu notre document source HTML restera inchangé.

<h3>Le DOM n'est pas ce que vous voyez dans le navigateur</h3>

Ce que vous voyez dans le viewport de votre navigateur c'est l'arbre de rendu qui, nous l'avons vu, est un mélange de DOM et de CSSOM. Ce qui distingue le DOM de l'arbre de rendu c'est que ce dernier ne comprend que ce qui sera "peint" à l'écran. De ce fait, il exclut les éléments visuellement cachés, par exemple ceux stylés `display: none`.

```
<!doctype html>
<html lang="en">
  <head></head>
  <body>
    <h1>Hello, world!</h1>
    <p style="display: none;">How are you?</p>
  </body>
</html>
```

Le DOM comprendra l'élément`<p>`:

<figure><img src="/images/dom-with-p-compressor.png" alt=""/></figure>

Cependant l'arbre de rendu —&nbsp;et donc ce qui est visible dans le viewport&nbsp;— ne comprendra pas cet élément.

<figure><img src="/images/rendertree-without-p-compressor.png" alt=""/></figure>

<h3>Le DOM n'est pas ce que vous voyez dans DevTools</h3>

Cette différence ne tient pas à grand chose car l'inspecteur d'éléments DevTools offre la meilleure approximation du DOM disponible dans le navigateur. Toutefois DevTools inclut des informations qui ne sont pas dans le DOM.

Le meilleur exemple en est [les pseudo-éléments CSS](/articles/les-pseudo-elements-css-before-et-after/) créées via les sélecteurs `::before` et `::after`. Ils font partie du CSSOM et de l'arbre de rendu mais techniquement ils n'appartiennent pas au DOM puisque celui-ci est construit à partir du seul document source HTML, qui ne comprend pas les styles appliqués aux éléments.

Bien que ne faisant pas partie du DOM, les pseudo-éléments apparaissent dans notre inspecteur DevTools&nbsp;:

<figure><img src="/images/Pseudo-element-in-devtools-inspector.png" alt=""/></figure>
    
C'est la raison pour laquelle les pseudo-éléments ne peuvent pas être ciblés par JavaScript, parce qu'ils ne font pas partie du DOM&nbsp;!
    
<h2>On récapitule</h2>

Le DOM est une interface vers un document HTML. Il est utilisé par les navigateurs dans une première étape pour déterminer ce qui peut être rendu à l'écran, et par JavaScript pour modifier le contenu, la structure ou le style de la page.

Bien que similaire à d'autres formes de documents source HTML, il en diffère en plusieurs points&nbsp;:

- son HTML est toujours valide
- c'est un modèle vivant qui peut être modifié par JavaScript
- il ne comprend pas de pseudo-éléments (p.ex. `::after`)
- il ne comprend pas d'élémens cachés (p.ex. via `display: none`)


Le DOM, c'est quoi exactement ?


L’[animation d’un SVG au moyen de CSS](/articles/animer-un-svg-avec-css/) est facile, cependant CSS ne peut pas animer toutes les propriétés SVG animables. Par exemple, les propriétés qui définissent la forme présente d’un élément ne peuvent être modifiées ou animées en CSS. Il est toutefois possible de le faire grâce à SMIL. Sara Soueidan en parle dans son remarquable [Guide des animations SVG (SMIL)](/articles/guide-des-animations-svg/) ici-même, mais je voudrais éclairer ce point plus précisément ici.

**Le plus important à retenir&nbsp;: les formes doivent avoir le même nombre de points**  
Autrement, l’animation ne marchera pas. La forme ne disparaîtra pas, rien de grave ne se produira, mais rien ne s’animera.

Il n’est pas toujours évident de savoir combien de points constituent une forme en regardant l’attribut `d` (dans le cas d’un `path`) ou `point` (dans le cas d’un polygone), le mieux est parfois de commencer avec une forme simple dans un programme d’édition vectorielle.

### 1. Commencer avec la forme la plus complexe

Dans cette démo, je vais partir d’une étoile, qui sera ma forme la plus compliquée, pour la morpher en _check_ de case à cocher (une “hirondelle”).

<figure><img src="/images/star.png" alt=""/></figure>

Gardez une copie de ce SVG, puis utilisez une autre version pour construire la forme suivante.

### 2. Construire la forme suivante avec les mêmes points

Déplacez les points pour obtenir la forme désirée.

<figure><img src="/images/star-illustrator-gif-compressor.gif" alt="dans illustrator, on déplace les points pour former une hirondelle"/></figure>

<figure><img src="/images/check-illustrator-gif.png" alt=""/></figure>

### 3. Utiliser la forme de départ dans le SVG lui-même

    //SVG
    <svg viewBox="0 0 194.6 185.1">

      <polygon fill="#FFD41D" points=" ... les points de la forme 1 ... ">

      </polygon>

    </svg>

### 4. Ajouter un élément d’animation vers la forme suivante

    //SVG
    <svg viewBox="0 0 194.6 185.1">

      <polygon fill="#FFD41D" points=" ... les points de la forme 1 ... ">

        <animate attributeName="points" dur="500ms" to=" ... les points de la forme 2 ... " />

      </polygon>

    </svg>

Cette animation sera lancée immédiatement, il nous faut corriger cela.

### 5. Déclencher l’animation quand on le veut

SMIL permet de traiter les interactions telles que clics et hovers, tant que tout se passe à l’intérieur de SVG. Par exemple, vous pourriez lancer l’animation lorsqu’elle est cliquée&nbsp;:

    //SVG
    <polygon id="shape" points=" ... les points de la forme 1 ... ">

      <animate begin="shape.click" attributeName="points" dur="500ms" to=" ... les points de la forme 2 ... />

    </polygon>

Pas mal, mais un peu limité car il ne permet de traiter que les clics sur ce SVG précisément. Mais quid si cet élément fait partie d’un bouton et qu’on veut lancer l’animation lorsque c’est le bouton qui est cliqué&nbsp;?

Tout d’abord, donnons un ID à notre animation, afin de permettre à JavaScript de la retrouver, puis empêchons tout déclenchement intempestif&nbsp;:

    //SVG
    <animate id="animation-to-check" begin="indefinite" ... />

Nous avons maintenant référencé cette animation et nous pouvons la déclencher comme nous l’entendons&nbsp;:

    //JavaScript
    animationToCheck = document.getElementById("animation-to-check");

    // Lancez ceci sur un clic, ou de la façon que vous voulez
    // (voir démo ci-dessous)
    animationToCheck.beginElement();

### Démo

Cette démo contient en fait quatre animations&nbsp;: une pour morpher l’étoile en hirondelle, une pour modifier la couleur de la forme, et les mêmes dans l’animation inverse. Lorsqu’on clique sur le bouton, on vérifie d’abord l’état présent du bouton, puis on déclenche les animations appropriées.

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_DpFfE" src="//codepen.io/chriscoyier/embed/DpFfE?height=200&amp;theme-id=light&amp;slug-hash=DpFfE&amp;user=chriscoyier&amp;default-tab=result" scrolling="no" frameborder="0" height="200" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="http://codepen.io/chriscoyier/pen/DpFfE/">
  Shape Morph Button</a> de Chris Coyier dans <a href="https://codepen.io">CodePen</a></span>
</div>


Le morphing en SVG


Il existe bien des façons de sélectionner des éléments en CSS. La plus basique est la sélection par nom de balise, comme `p { }`. Presque tout ce qui est plus spécifique qu'un sélecteur de balise utilise des [attributs](https://developer.mozilla.org/fr/docs/Web/HTML/Attributes) —&nbsp;`class` et `id` permettent tous deux de sélectionner ces attributs sur les éléments HTML. Mais la classe et l'ID ne sont pas les seuls attributs que les développeurs peuvent choisir. Nous pouvons utiliser n'importe quel **attribut** d'un élément comme sélecteur.

La sélection d'attributs a une syntaxe spéciale. En voici un exemple :

```css
a[href="https://css-tricks.com"]
{
  color: #e18728;
}
```

Il s'agit d'un **sélecteur à correspondance exacte** qui ne sélectionnera que les liens dont la valeur exacte de l'attribut `href` est "https://css-tricks.com".

## Les sept différents types

Les sélecteurs d'attributs sont sensibles à la casse par défaut (voir [correspondance insensible à la casse ci-dessous](#caseinsensitive)), et sont écrits entre crochets `[]`.

Il existe sept types différents de correspondances avec un sélecteur d'attribut, et la syntaxe est différente pour chacun. Les sélecteurs d'attributs les plus complexes reposent sur la syntaxe du sélecteur de correspondance exacte&nbsp;: ils commencent tous par le nom de l'attribut et se terminent par un signe égal suivi de la ou des valeurs de l'attribut, généralement entre guillemets. Ce qui se trouve entre le nom de l'attribut et le signe égal est ce qui fait la différence entre les sélecteurs.

```css
[data-value] {
  /* L'attribut existe */
}

[data-value='foo'] {
  /* L'attribut a cette valeur exacte */
}

[data-value*='foo'] {
  /* La valeur de l'attribut contient cette valeur quelque part */
}

[data-value~='foo'] {
  /* L'attribut contient cette valeur quelque part dans une liste séparée par un espace */
}

[data-value^='foo'] {
  /* La valeur de l'attribut commence par ceci */
}

[data-value|='foo'] {
  /* La valeur de l'attribut commence par ceci dans une liste séparée par un tiret */
}

[data-value$='foo'] {
  /* La valeur de l'attribut se termine par ceci */
}
```

**La valeur contient** : la valeur de l'attribut contient un terme comme seule valeur, une valeur dans une liste de valeurs ou comme partie d'une autre valeur. Pour utiliser ce sélecteur, ajoutez un astérisque (_) avant le signe égal. Par exemple, `img[alt_="art"]` sélectionnera les images dont le texte alt est "art abstrait" et "Le départ de Nimrod", car la valeur "art" se trouve dans le mot "départ".

**La valeur est dans une liste séparée par un espace**&nbsp;: la valeur est soit la seule valeur de l'attribut, soit une valeur entière dans un ensemble de valeurs séparées par un espace. Contrairement au sélecteur "contains", ce sélecteur ne recherchera pas la valeur sous forme de fragment de mot. Pour utiliser ce sélecteur, ajoutez un tilde (`~`) avant le signe égal. Par exemple, `img[alt~="art"]` sélectionnera les images avec le texte alt "art abstrait" et "exposition d'art", mais pas "Le départ de Nimrod" (que le sélecteur "contains" sélectionnerait).

**Valeur commence par** : la valeur de l'attribut commence par le terme sélectionné. Pour utiliser ce sélecteur, ajoutez un caret (`^`) avant le signe égal. N'oubliez pas que la sensibilité à la casse compte. Par exemple, `img[alt^="art"]` sélectionnera les images avec le texte alt "exposition d'art" et "motif artistique", mais pas une image avec le texte alt "Arthur Miller" car "Arthur" commence par une majuscule.

**La valeur est la première dans une liste séparée par des tirets** : Ce sélecteur est très similaire au sélecteur "commence par". Ici, le sélecteur correspond à une valeur qui est soit la seule valeur, soit la première d'une liste de valeurs séparées par un tiret. Pour utiliser ce sélecteur, ajoutez un caractère pipe (`|`) (_tuyau_)avant le signe égal. Par exemple, `li[data-years|="1900"]` sélectionnera les éléments de liste dont la valeur de data-years est "1900-2000", mais pas l'élément de liste dont la valeur de data-years est "1800-1900".

**Valeur se terminant par** : la valeur de l'attribut se termine par le terme sélectionné. Pour utiliser ce sélecteur, ajoutez un signe dollar (`$`) avant le signe égal. Par exemple, `a[href$="pdf"]` sélectionne tous les liens qui se terminent par .pdf.

<p class="is-style-explanation">Une remarque sur les guillemets : Dans certaines circonstances, vous pouvez ne pas utiliser de guillemets autour de la valeur, mais les règles de sélection sans guillemets sont incohérentes d'un navigateur à l'autre. Les guillemets fonctionnent toujours, donc si vous vous en tenez à leur utilisation, vous pouvez être sûr que votre sélecteur fonctionnera.</p><br/>

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_OPobRY" src="//codepen.io/css-tricks/embed/OPobRY?height=600&amp;theme-id=light&amp;slug-hash=OPobRY&amp;user=css-tricks&amp;default-tab=result" scrolling="no" frameborder="0" height="600" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="https://codepen.io/team/css-tricks/pen/OPobRY">
  Attribute Selectors</a> de css-tricks dans <a href="https://codepen.io">CodePen</a></span>
</div>

Fait amusant : les valeurs sont traitées comme des chaînes de caractères, vous n'avez donc pas besoin d'effectuer un échappement fantaisiste des caractères pour les faire correspondre, comme vous le feriez si vous utilisiez des caractères inhabituels dans un sélecteur de classe ou d'ID.

```css
[class='(╯°□°）╯︵ ┻━┻'] {
  couleur: rouge;
  font-weight: bold;
}
```

<h2 id="caseinsensitive">Correspondance insensible à la casse</h2>

Les sélecteurs d'attributs insensibles à la casse font partie de la spécification <a href="https://www.w3.org/TR/selectors-4/#attribute-case">Selectors Level 4</a> du groupe de travail CSS. Comme mentionné ci-dessus, les chaînes de valeur d'attribut sont par défaut sensibles à la casse, mais peuvent être modifiées en insensibles à la casse en ajoutant `i` juste avant le crochet fermant&nbsp;:

```css
[attribute='value' i] {
  /* Les styles ici s'appliqueront aux éléments avec :
    attribut="valeur"
    attribut="VaLuE"
    attribut="VALUE"
    ...etc
  */
}
```

La correspondance insensible à la casse pourrait être vraiment pratique pour cibler les attributs contenant du texte imprévisible, écrit par les humains. Par exemple, supposons que vous conceviez une bulle de dialogue sur une application de chat et que vous souhaitiez ajouter une "main agitée" à tous les messages contenant le texte "hello" sous une forme ou une autre. Vous pourriez le faire rien qu'avec CSS, en utilisant une correspondance insensible à la casse pour attraper toutes les variations possibles&nbsp;:

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_ydpvGQ" src="//codepen.io/css-tricks/embed/ydpvGQ?height=300&amp;theme-id=light&amp;slug-hash=ydpvGQ&amp;user=css-tricks&amp;default-tab=result" scrolling="no" frameborder="0" height="300" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="https://codepen.io/andyadams/pen/ydpvGQ">
  Case-insensitive CSS attribute matching</a> de css-tricks dans <a href="https://codepen.io">CodePen</a></span>
</div>

## Combiner tout cela

Vous pouvez combiner un sélecteur d'attribut avec d'autres sélecteurs, tels que tag, class ou ID.

```css
div[attribute='value'] {
  /* règles de style ici */
}

.module[attribute='value'] {
  /* règles de style ici */
}

#header[attribute='value'] {
  /* règles de style ici */
}
```

Vous pouvez même combiner plusieurs sélecteurs d'attributs. Cet exemple sélectionne les images dont le texte alternatif comprend le mot "personne" comme seule valeur ou une valeur dans une liste séparée par un espace, et une valeur src qui comprend la valeur "lorem"&nbsp;:

```css
img[alt~='person'][src*='lorem'] {
  /* règles de style ici */
}
```

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_jEvVVb" src="//codepen.io/css-tricks/embed/jEvVVb?height=750&amp;theme-id=light&amp;slug-hash=jEvVVb&amp;user=css-tricks&amp;default-tab=result" scrolling="no" frameborder="0" height="750" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="https://codepen.io/team/css-tricks/pen/jEvVVb">
  Combined Attributes and Attribute-Only Selection</a> de css-tricks dans <a href="https://codepen.io">CodePen</a></span>
</div>

## Sélecteurs d'attributs en JavaScript et jQuery

Les sélecteurs d'attributs peuvent être utilisés dans jQuery comme tout autre sélecteur CSS. En JavaScript, vous pouvez utiliser les sélecteurs d'attributs avec `document.querySelector()` et `document.querySelectorAll()`.

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_XJPNNg" src="//codepen.io/css-tricks/embed/XJPNNg?height=750&amp;theme-id=light&amp;slug-hash=XJPNNg&amp;user=css-tricks&amp;default-tab=result" scrolling="no" frameborder="0" height="750" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="https://codepen.io/team/css-tricks/pen/XJPNNg">Attribute Selectors in JS and jQuery</a> de css-tricks dans <a href="https://codepen.io">CodePen</a></span>
</div>


Attributs


L'une des raisons pour lesquelles cette nouvelle ère de développement front-end, riche en outils, est si difficile à comprendre au début, c'est que nous _appelons_ souvent les choses par un nom unique, alors qu'elles sont composées de plusieurs éléments interconnectés. Il en va ainsi pour npm et l'écosystème qui l'entoure.

Pensons par exemple à la façon dont nous nous référons avec désinvolture à "l'Internet", même si le Web lui-même n'est pas une chose unique et unifiée, mais une collection de protocoles, de DNS, de serveurs, de navigateurs, de réseaux, de demandes et de réponses... et bien d'autres choses assemblées au cours d'années d'itérations. Le navigateur lui-même est une machine composée de nombreuses pièces.

## Table des matières <small>(rappel)</small>

<div class="toc">

- [À qui s'adresse ce guide ?](/articles/npm-guide-complet-pour-le-debutant)
- [Que signifie le mot "npm" ?](/articles/npm-guide-1-npm) ← **_vous êtes ici_**
- [Qu'est-ce que la ligne de commande ?](/articles/npm-guide-2-cli)
- [Qu'est-ce que Node ?](/articles/npm-guide-3-node)
- [Qu'est-ce qu'un gestionnaire de paquets ?](/articles/npm-guide-4-gestionnaire-de-paquets)
- [Comment installer npm ?](/articles/npm-guide-5-installer-npm)
- [Comment installer les paquets npm ?](/articles/npm-guide-6-package-installer-paquets)
- [Que sont les commandes npm ?](/articles/npm-guide-7-commandes)
- [Comment installer un projet npm existant ?](/articles/npm-guide-8-installer-projet)

</div>

### npm est un ensemble de technologies

De même, ce que nous appelons généralement "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&nbsp;! une sorte de [machine de Rube Goldberg](https://en.wikipedia.org/wiki/Rube_Goldberg_machine) pour générer du code convivial pour le navigateur.

J'ai déjà mentionné la ligne de commande&nbsp;! c'est une partie importante de l'écosystème car c'est la façon dont nous interagissons avec lui. Mais nous en reparlerons dans le prochain chapitre.

Et puis il y a npm, qui fait partie d'une catégorie connue sous le nom de logiciel de "gestion de paquets". Nous en parlerons également. 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](https://nodejs.org/en/) lui-même, qui est si difficile à expliquer succinctement que je le décris souvent en paraphrasant Douglas Adams&nbsp;: c'est un langage de programmation qui ressemble presque —&nbsp;mais pas tout à fait&nbsp;— à JavaScript.

### npm gère les outils de projet

Pour brouiller encore un peu les pistes, de nombreux projets pour lesquels vous tapez `npm install` dans la ligne de commande peuvent être livrés avec des outils préinstallés pour vous aider à faire une grande variété de choses dans votre projet, comme retraiter votre code (par exemple, transformer le code Sass en CSS). Il existe de nombreux projets tout-en-un, préconfigurés, qui n'attendent que votre installation et votre démarrage ([Create React App](https://create-react-app.dev/), [Next](https://nextjs.org/), [Nuxt](https://nuxtjs.org/fr/) et [SvelteKit](https://kit.svelte.dev/), pour n'en citer que quelques-uns). C'est pratique quand c'est bien fait, bien sûr, mais cela a aussi ajouté de la complexité —&nbsp;ce qui signifie ajouter encore d'autres noms à notre liste de choses de l'_arrière du front_.

Cette liste comprend souvent des outils tels que [Babel](https://babeljs.io/) (pour la compilation de JavaScript), [Sass](https://sass-lang.com/) (pour la compilation de CSS), [webpack](https://webpack.js.org/) (pour le regroupement des ressources), [Vite](https://vitejs.dev/) (pour les serveurs de développement et autres outils), [PostCSS](https://postcss.org/) (pour transformer une syntaxe en une autre)&nbsp;! [Autoprefixer](https://autoprefixer.github.io/) (qui peut être un plugin PostCSS pour les préfixes des fournisseurs de CSS)&nbsp;! [TypeScript](https://www.typescriptlang.org/) (pour une syntaxe JavaScript supplémentaire)&nbsp;! [ESlint](https://eslint.org/) (pour vérifier la qualité du code)&nbsp;! [Prettier](https://prettier.io/) (pour le formatage du code), et des bibliothèques de test comme [Jest](https://jestjs.io/) ou [Cypress](https://www.cypress.io/).

<figure role="group"><img src="/images/library-building.webp" alt=""/><figcaption>npm ressemble à une bibliothèque, avec des étages de livres bien organisés pour les retrouver et les gérer. (Photo: <a href="https://unsplash.com/@leonardo_64?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Johannes Mändle</a> on <a href="https://unsplash.com/">Unsplash)</a></figcaption></figure>

Toutes ces choses (et bien d'autres) entrent dans cette vaste catégorie générale d'outils qui sont souvent fournis _avec_ les projets installés par npm —&nbsp;ou qui peuvent être installés et utilisés via npm&nbsp;— mais qui 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 que cela vaut la peine de noter la distinction, pour avoir une idée de l'endroit où se trouvent les limites dans ce vaste et nouveau monde.

Et d'ailleurs, si vous ne savez pas ce que sont la plupart (ou _aucun_) des outils mentionnés ci-dessus, ce n'est pas grave. Peut-être ne les avez-vous pas encore rencontrés, ou peut-être avez-vous travaillé, sans en connaître le nom, sur un projet où ils étaient installés. Quoi qu'il en soit, tout ceci n'est qu'un contexte supplémentaire.

### Faisons une pause ici

Si vous vous sentez déjà un peu dépassé à ce stade, ne vous inquiétez pas. Ce que je veux que vous reteniez de la lecture de ce chapitre d'intro, c'est que ce que nous appelons "npm" (ou peut-être plus simplement "tous ces trucs en ligne de commande et en arrière-plan") n'est pas vraiment une chose, mais _un ensemble de choses qui fonctionnent ensemble pour nous faciliter le développement_.

Ah, et oui : toute cette complexité peut sembler intimidante au départ, mais elle améliore _réellement_ les choses. Je vous le promets.

Alors que le front-end _semble_ évoluer très rapidement, non, **vous n'avez pas été laissé derrière**. Vous avez peut-être juste un peu de formation continue à rattraper.

<div class="button-container button-block">
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-complet-pour-le-debutant">← Chapitre 1</a></div>
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-2-cli">Chapitre 3 →</a></div>
</div>


Qu'est-ce que npm ?


Maintenant que nous savons [ce que signifie npm](/articles/npm-guide-1-npm) et que nous avons une idée très générale de ce qu'il fait et de sa place dans le développement Web, nous devons passer un peu de temps à examiner la ligne de commande, car c'est ainsi que nous interagissons avec npm.

## Table des matières <small>(rappel)</small>

<div class="toc">

- [À qui s'adresse ce guide ?](/articles/npm-guide-complet-pour-le-debutant)
- [Que signifie le mot "npm" ?](/articles/npm-guide-1-npm)
- [Qu'est-ce que la ligne de commande ?](/articles/npm-guide-2-cli) ← **_vous êtes ici_**
- [Qu'est-ce que Node ?](/articles/npm-guide-3-node)
- [Qu'est-ce qu'un gestionnaire de paquets ?](/articles/npm-guide-4-gestionnaire-de-paquets)
- [Comment installer npm ?](/articles/npm-guide-5-installer-npm)
- [Comment installer les paquets npm ?](/articles/npm-guide-6-package-installer-paquets)
- [Que sont les commandes npm ?](/articles/npm-guide-7-commandes)
- [Comment installer un projet npm existant ?](/articles/npm-guide-8-installer-projet)

</div>

### Un aperçu de l'interface en ligne de commande

L'[interface en ligne de commande](https://fr.wikipedia.org/wiki/Interface_en_ligne_de_commande) (CLI) est un endroit où nous pouvons taper des _commandes_, qui seront exécutées directement par notre ordinateur. Elle 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. Vous avez besoin d'installer quelque chose sur votre système, ou de le mettre à jour&nbsp;? elle peut le faire, sans oublier de les désinstaller également. Même les langages côté serveur peuvent s'exécuter sur la ligne de commande, ce qui ouvre un large éventail d'outils et de techniques de développement.

C'est pour ces raisons que l'interface en ligne de commande est considérée comme un outil indispensable pour de nombreux développeurs. Même si vous n'êtes pas un développeur, il y a de fortes chances que vous ayez rencontré la ligne de commande à un moment ou à un autre. Vous y avez peut-être accédé en ouvrant l'application Terminal sous MacOS. Vous en avez peut-être utilisé une directement intégrée à votre éditeur de code —&nbsp;[VS Code](https://code.visualstudio.com/) et de nombreux autres éditeurs de code sont dotés d'un terminal intégré. Vous avez peut-être même rencontré des applications de terminal tierces comme [iTerm](https://iterm2.com/) ou [Hyper](https://hyper.is/).

<figure><img src="/images/terminal.webp" alt="images de divers terminaux"/></figure>

Si vous avez utilisé le terminal, il est possible qu'une grande partie de votre utilisation de la ligne de commande ait consisté à taper (ou coller) des commandes que quelqu'un d'autre vous a données. C'est très bien&nbsp;; c'est souvent de cette façon que nous parvenons à faire les choses.

Mais prenons un moment pour comprendre ce qu'_est_ exactement la ligne de commande, et pourquoi elle est si largement utilisée.

### Ligne de commande et 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", abréviation de "command line interface".

Distinctions pédantes mises à part, ces termes sont souvent utilisés pour signifier à peu près la même chose. Aussi, pour simplifier au maximum les choses, je les utiliserai indifféremment à partir de maintenant.

### Ouverture de la ligne de commande

Quel que soit le nom que vous lui donnez, vous connaissez probablement la ligne de commande comme cette fenêtre à l'aspect intimidant, où vous tapez des commandes que votre ordinateur semble comprendre, même si vous ne le faites pas.

<figure role="group"><img src="/images/open-cli.webp" alt=""/><figcaption>Par défaut, une fenêtre de terminal devrait ressemble à ceci, mais les apparences peuvent varier.</figcaption></figure>

Selon l'endroit et la manière dont vous travaillez sur la ligne de commande, l'une des premières choses que vous pouvez remarquer 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.

<figure><img src="/images/command.webp" alt="n'entrez pas le caractère $"/></figure>

C'est une convention courante que de préfixer les commandes par le caractère $ —&nbsp;mais c'est une convention qui prête à confusion, parce qu'en fait il n'y a pas besoin de taper ce caractère. Il ne fait littéralement _pas_ partie de la commande. Le caractère `$` signifie simplement que la commande doit être exécutée dans un terminal.

Voici donc la première règle à connaître pour travailler avec la ligne de commande&nbsp;: 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&nbsp;; le terminal s'en charge.

```bash
Pas besoin de copier le caractère $
$ npm run build
```

Vous verrez peut-être quelque chose d'autre commencer une ligne à la place de $, comme >, \_ , ou même une flèche. Encore une fois, quoi que ce soit, il est presque certain que ce n'est pas destiné à être tapé ou collé directement dans la ligne de commande. La question de savoir si la documentation ou d'autres didacticiels doivent ou non inclure le caractère de début de ligne est une toute autre conversation ([dont Chris a longuement discuté](https://css-tricks.com/to-or-not-to-displaying-terminal-code-snippets/)). Quoi qu'il en soit, cela peut prêter à confusion, c'est pourquoi je veux m'assurer que cela est mentionné.

### Que fait la ligne de commande ?

La ligne de commande n'est pas exactement faite pour écrire du code. Comme le nom "ligne de commande" l'indique, elle sert à écrire des commandes. Je suppose que l'on pourrait dire que _tout_ le codage est constitué de commandes dans une certaine mesure, donc il est vrai que la séparation est un peu floue. Mais de manière générale, le code dans un terminal est écrit différemment de ce qu'il est dans un éditeur de code. On utilise le terminal pour diriger notre ordinateur avec des commandes que nous voulons qu'il exécute _immédiatement_.

### Les avantages de la ligne de commande

Pour commencer, vous vous demandez peut-être pourquoi les développeurs aiment travailler avec la ligne de commande. Vous préférez peut-être une belle application, ou une interface utilisateur graphique (GUI en abrégé, parfois prononcé "gooey") où vous pouvez voir toutes vos options et trouver la meilleure visuellement. C'est tout à fait normal, et nous parlerons un peu des GUI dans ce chapitre et en fournirons des exemples.

De nombreux développeurs pensent ainsi, mais travailler en ligne de commande apporte certains avantages qui ne sont pas toujours faciles à reproduire dans une application visuelle.

#### Elle vous accorde des privilèges système dignes d'un dieu

La ligne de commande est ce que les informaticiens appellent un "environnement privilégié". Cela peut sembler faire référence à une maison de fraternité de Yale, mais cela signifie simplement qu'il s'agit d'un endroit où il y a très peu de restrictions sur ce que vous êtes autorisé à faire&nbsp;; un endroit sans garde-fous.

C'est de là que vient la réputation déconcertante de la ligne de commande&nbsp;: quelle que soit la commande que vous tapez, pour autant qu'elle soit valide, elle est exécutée immédiatement et, souvent, de manière irréversible. Elle est capable d'interagir avec les fichiers cachés que votre système d'exploitation tente de vous empêcher de modifier. Vous avez le pouvoir d'accéder à tout ce qui se trouve dans le système. Vous avez même le pouvoir d'interagir avec des fichiers centraux similaires sur un serveur distant —&nbsp;et nous connaissons tous l'adage selon lequel une grande responsabilité accompagne ce genre de pouvoir.

Il peut être utile de considérer la ligne de commande comme un gardien de sécurité paresseux. Elle suppose que vous savez _toujours_ ce que vous faites et vous laisse passer l'entrée. Cela la rend un peu risquée, oui, mais cela la rend aussi très puissante, et le choix parfait pour certaines tâches et projets.

#### Elle est super rapide

Un autre avantage de la ligne de commande par rapport aux applications classiques est qu'elle est rapide.

Ce n'est pas toujours le cas&nbsp;; la vitesse de la ligne de commande a tendance à être surestimée et dépend largement de la tâche en question. Mais lorsqu'elle est rapide, elle 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, à savoir 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 choses 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 ce que cela signifie également) comme npm —&nbsp;elle télécharge et transmet les fichiers entre les ordinateurs&nbsp;— généralement beaucoup, _beaucoup_ plus rapidement que, disons, en utilisant un navigateur pour le faire.

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 et à grande vitesse fait du terminal l'outil le plus rapide et le plus efficace pour de nombreuses tâches.

#### Elle fait ce que les autres langages ne peuvent pas faire

Une autre raison pour laquelle le travail 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 pour vous 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 même à des langages plus récents comme Rust ou Go. Vous savez peut-être déjà que Node fait partie de cette liste, mais si ce n'est pas le cas, pardonnez-moi de prendre un peu d'avance.

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 qui attend des requêtes et y répond. WordPress, par exemple, reste inactif jusqu'à ce qu'il reçoive une requête qui déclenche PHP. Lorsque vous envoyez un nouveau tweet, il s'agit d'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 merveilleux, mais ils ne peuvent pas travailler 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 tant d'autres choses qu'une application ou un site Web peut avoir à faire. Par défaut, le JavaScript du navigateur ne peut même pas s'exécuter si quelqu'un ne regarde pas activement la page Web dans son navigateur.

Il est normal de penser que les langages côté serveur sont 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 bien sûr (il _pourrait_ en être un, mais ce serait bizarre et probablement peu judicieux). Mais un serveur, néanmoins.

<figure role="group"><img src="/images/server.webp" alt="un ordinateur portable avec un message écrit à la main : ceci est un serveur, ne le fermez pas !"/><figcaption>Vous ne voyez sans doute pas votre machine comme un serveur, mais elle peut exécuter des langages côté serveur...</figcaption></figure>

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 essayé). Vous avez peut-être installé PHP pour pouvoir exécuter WordPress (bien que de nos jours, il existe [des moyens bien plus agréables de le faire](https://css-tricks.com/using-local-with-flywheel/)), ou vous avez peut-être installé Ruby pour pouvoir suivre des tutoriels sur Rails, à titre d'exemple.

Ou, peut-être pas. Vous n'avez peut-être jamais installé un langage de programmation complet. Quoi qu'il en soit, sachez simplement que ces langages s'exécutent sur un serveur plutôt que sur un navigateur Web - et à cet effet, _votre machine est un serveur_.

En outre, la plupart des outils que vous souhaitez utiliser dans votre flux de travail de développement, comme Sass pour compiler les CSS, fonctionnent en fait sur des langages côté serveur. L'utilisation de la ligne de commande vous place donc à 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 tôt dans cet article. Il est intéressant de noter que certaines tâches de la ligne de commande ont des interfaces graphiques correspondantes qui rendent le travail avec la ligne de commande plus visuel et programmatique.

Parmi les bons exemples, citons [GitHub Desktop](https://desktop.github.com/) (pour la gestion des dépôts de code), [CodeKit](https://codekitapp.com/) (pour le traitement, le regroupement et la compilation des ressources), et l'onglet Source Control de VS Code. Même si les interfaces graphiques de ce type sont généralement axées sur des tâches spécifiques, elles vous permettent d'effectuer des tâches par le biais d'une interface utilisateur visuelle agréable, dans une fenêtre d'application réelle qui se trouve en dehors de la fenêtre du terminal.

<figure role="group"><img src="/images/codekit.webp" alt=""/><figcaption>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.</figcaption></figure>

Il est agréable d'avoir une interface graphique en option, et même si je me suis habitué à travailler en ligne de commande au fil des ans, j'aimerais qu'il y ait plus d'interfaces graphiques pour faire les choses que la ligne de commande rend possibles, à la fois pour mon propre confort et pour abaisser la barrière d'entrée pour les nouveaux développeurs.

Je pense néanmoions que la raison pour laquelle il n'y a pas plus d'applications de ce type est la vitesse. Il est beaucoup plus rapide et facile de créer une interface de ligne de commande (CLI) que de mettre au point une application à part entière. Donc, si nous voulons des choses agréables _aujourd'hui_, la ligne de commande est souvent l'endroit où nous devons aller pour les obtenir.

### La suite

Nous venons de passer un peu de temps à nous familiariser avec la ligne de commande. Même si elle n'est pas _spécifique_ à npm, elle est essentielle pour travailler avec npm. Il s'agit de l'interface à partir de laquelle nous indiquons au système ce qu'il doit faire, ce qui nous confère des pouvoirs incroyables au niveau du système ou du serveur pour accomplir des tâches en grande quantité à une vitesse fulgurante. En tant que gestionnaire de paquets, npm s'occupe d'installer, de mettre à jour et de supprimer des fichiers (entre autres choses) 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 et pourquoi est-elle dans le nom ? C'est ce point que nous allons voir maintenant.

<div class="button-container button-block">
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-1-npm">← Chapitre 2</a></div>
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-3-node">Chapitre 4 →</a></div>
</div>


NPM et ligne de commande


Voici ce que vous devez savoir sur Node.js (ou simplement Node) et sur son rapport avec npm dès le départ :

- Node est du 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.
- Node et le JavaScript basé sur le navigateur peuvent être très différents, et avoir des capacités différentes, bien que tous deux soient JavaScript à leur base.
- Vous n'avez pas besoin de connaître Node pour utiliser npm.

Comme vous le savez peut-être maintenant, npm est l'abréviation de Node Package Manager (même si le [site officiel de npm](https://www.npmjs.com/) affiche des noms alternatifs amusants dans son en-tête à chaque chargement de page, comme "Ninja Pumpkin Mutants").

La chose essentielle à comprendre tout de suite est la suivante : "Node" et "Package Manager" sont les deux grandes pièces distinctes qui se combinent pour former npm.

Nous couvrirons ce qu'est un gestionnaire de paquets et pourquoi vous pourriez envisager d'en utiliser un lorsque nous aborderons le prochain chapitre 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.

## Table des matières <small>(rappel)</small>

<div class="toc">

- [À qui s'adresse ce guide ?](/articles/npm-guide-complet-pour-le-debutant)
- [Que signifie le mot "npm" ?](/articles/npm-guide-1-npm)
- [Qu'est-ce que la ligne de commande ?](/articles/npm-guide-2-cli)
- [Qu'est-ce que Node ?](/articles/npm-guide-3-node) ← **_vous êtes ici_**
- [Qu'est-ce qu'un gestionnaire de paquets ?](/articles/npm-guide-4-gestionnaire-de-paquets)
- [Comment installer npm ?](/articles/npm-guide-5-installer-npm)
- [Comment installer les paquets npm ?](/articles/npm-guide-6-package-installer-paquets)
- [Que sont les commandes npm ?](/articles/npm-guide-7-commandes)
- [Comment installer un projet npm existant ?](/articles/npm-guide-8-installer-projet)

</div>

### Node, c'est JavaScript, mais sans le navigateur

Vous connaissez probablement JavaScript principalement comme un langage qui s'exécute dans le navigateur, similaire à HTML et CSS. Oui, chacun de ces langages possède des abstractions et des supersets (comme [HAML](https://haml.info/) pour HTML, Sass pour CSS, et TypeScript pour JavaScript, par exemple), ainsi que des compilateurs et des transpilateurs 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, c'est du code vanille (c'est-à-dire pur) dans la syntaxe correcte, comme si les abstractions n'avaient jamais été 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 grand que toute l'histoire de npm. JavaScript n'a plus besoin d'un navigateur pour fonctionner. Ainsi, vous me verrez parfois faire référence à Node JavaScript lorsque je ferai la distinction entre ce dernier et le JavaScript "basé sur un navigateur".

### Langages côté serveur ou côté client

À ce stade, je pense qu'il est utile 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 suppose pas que vous ayez une quelconque expérience des langages côté serveur, comme PHP, Ruby ou Python, mais si le concept des langages côté serveur est entièrement nouveau pour vous, il peut être utile de [lire ce qu'ils sont](https://developer.mozilla.org/fr/docs/Learn/Server-side/First_steps/Introduction) (NdT: dans MDN en français). (Pour résumer : ce sont des langages de code qui s'exécutent purement sur un serveur au lieu du navigateur, et qui ont généralement des capacités beaucoup plus larges et plus puissantes).

Ceci est pertinent parce qu'il y a plusieurs années, vers 2009, il y avait des gens très intelligents qui aimaient vraiment JavaScript. En particulier, ils aimaient la _rapidité_ de JavaScript (surtout par rapport aux langages côté serveur dominants à l'époque, notamment PHP et Ruby), et ils voulaient que JavaScript soit présent _partout_, pas seulement dans un navigateur.

[Ryan Dahl](https://en.wikipedia.org/wiki/Ryan_Dahl) est la figure la plus marquante parmi eux, et on lui attribue l'invention de Node (et plus récemment, [Deno](https://deno.land/), qui est une anagramme de Node). C'est une chose amusante à savoir, mais autrement pas strictement pertinente à 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 fonctionne _en dehors_ du navigateur**.

Comment est-ce possible ? Sous le capot, chaque navigateur possède son propre moteur JavaScript individuel. Il s'agit de la partie du navigateur qui exécute réellement JavaScript. Oui, il s'agit apparemment d'une partie distincte du navigateur, qui ne fait pas partie des mêmes éléments que le HTML et le CSS, ce qui est logique si l'on considère que nous avons des API littérales entre le document et JavaScript. D'ailleurs, même [le concept de DOM](/articles/le-dom-cest-quoi-exactement) est plus logique si l'on considère que le département qui gère JavaScript est un bureau improvisé 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 (et non la "boisson végétale" faite principalement de jus de tomate). V8 est de loin le moteur JavaScript le plus populaire. Grâce aux efforts de normalisation de l'[ECMAScript](https://en.wikipedia.org/wiki/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 à celui de Firefox, qui ressemble beaucoup à Safari, et ainsi de suite. La popularité de V8 de nos jours a moins à voir avec ses distinctions, et plus à voir avec l'omniprésence auto-entretenue de Chrome.

(Note annexe : 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 cela est-il important ? Eh bien, il s'avère que vous pouvez retirer le moteur JavaScript d'un navigateur et, avec quelques modifications, le faire fonctionner seul - un peu comme si vous décidiez de retirer la stéréo d'une voiture, de la bricoler un peu et d'en faire une chaîne stéréo pour votre maison. V8 (et, vraisemblablement, la stéréo d'une voiture) peut parfaitement fonctionner en tant qu'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 le JavaScript "Node" et le JavaScript "basé sur le navigateur".

### Node est presque (mais pas exactement) JavaScript

Pour récapituler : JavaScript est maintenant un langage côté serveur ! Il 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 frontaux, et nous avons des super-pouvoirs maintenant.

Cela dit, **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 de nous perdre dans les méandres de l'histoire : bien que tous deux soient JavaScript à la base, et que le langage et la syntaxe soient les mêmes, de nombreux éléments de base de JavaScript dans le navigateur (comme la fenêtre ou le document, et même l'`alerte`) ne sont pas présents dans un environnement Node purement côté serveur. Il n'y a pas de `window`, bien sûr, lorsque le langage s'exécute tout seul, et non dans un navigateur. Les nouveaux développeurs JavaScript Node sont souvent surpris d'apprendre que même `fetch` est en fait une API de navigateur, et non du JavaScript "pur".

N'ayez crainte, cependant. console.log est toujours votre meilleur ami, et il y a beaucoup de nouvelles caractéristiques spécifiques à l'environnement de Node JavaScript qui diffèrent de la mise en œuvre de JavaScript par le navigateur, comme l'objet processus, qui contient tous les détails sur les processus en cours d'exécution.

Au fil des ans, Node et son écosystème ont souvent, par nécessité, évolué dans une direction très différente de celle du JavaScript basé sur le navigateur. (Un exemple évident : la syntaxe des importations entre les deux a été différente pendant des années, et ne commence que maintenant à fusionner à nouveau. Nous en parlerons un peu plus dans [le dernier chapitre](/articles/npm-guide-8-installer-projet)).

Node a longtemps eu le privilège de pouvoir évoluer 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 problèmes. Il a commencé à alimenter les applications côté serveur de la même manière que Ruby et PHP l'ont fait pendant des années, même si les navigateurs essayaient encore de se mettre d'accord sur les normes. Par conséquent, Node JavaScript et JavaScript basé sur le 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 basse droite 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 connaissez l'un, à bien des égards, vous connaissez en quelque sorte l'autre. Mais si vous trouverez qu'il est beaucoup plus facile d'apprendre l'un après avoir appris l'autre, jouer du nouvel instrument sera très différent de ce à quoi vous êtes habitué.

<figure role="group"><img src="/images/basses.webp" alt="un violoncelle à côté d'une basse électrique"/><figcaption>La même chose, mais différent (Photos: <a href='https://commons.wikimedia.org/wiki/Main_Page'>Wikimedia Commons</a>, <a href="https://unsplash.com/">Unplash</a>).</figcaption></figure>

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 tâches se ressemblent.

Node est JavaScript, avec les capacités des autres langages côté serveur mentionnés précédemment - des choses comme la lecture et l'écriture du système de fichiers, l'accès aux API de niveau système, la messagerie, la capacité d'écouter et de répondre aux demandes, les tâches planifiées... la liste est longue.

Je n'en dirai pas plus ici, mais sachez simplement que si les deux sont des JavaScript en fin de compte, ils fonctionnent dans des environnements différents et sont chacun capable de faire certaines choses que l'autre ne peut pas faire. Même si vous avez déjà écrit du JavaScript par navigateur, Node vous semblera probablement un peu étranger au-delà de la syntaxe de base, 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é aux côtés de npm, ensemble, puisque la partie gestionnaire de paquets a besoin de Node, et que la partie Node est plus utile avec un gestionnaire de paquets. (On pourrait dire qu'ils sont un ensemble de paquets. Non, je ne m'excuserai pas pour cette blague. Je suis un père, après tout).

Je tiens à souligner à ce stade que **vous n'avez pas besoin de connaître quoi que ce soit à propos de Node pour utiliser npm**. Donc, même si je suis sur le point de couvrir quelques exemples de Node ici, veuillez considérer toute cette section comme quelque chose d'agréable à savoir, mais non essentiel à cette fin. Je pense qu'il est toujours utile d'avoir une idée un peu plus précise de la façon dont Node fonctionne, juste dans le but de brosser un tableau plus complet.

> _Nous couvrirons l'[installation de Node et de npm](/articles/npm-guide-5-installer-npm) dans un prochain chapitre de ce guide. Donc, si vous ne les avez pas encore installés, vous pouvez soit jeter un coup d'œil sur cette partie, soit revenir ici lorsque vous les aurez prêts. Dans tous les cas, cela ne sera pas crucial pour suivre ce guide npm._

Si vous souhaitez l'essayer, vous pouvez créer un nouveau fichier test.js et y placer du JavaScript générique. Quelque chose d'artificiel comme le code suivant qui enregistre un certain contenu dans la console devrait faire l'affaire :

```js
console.log('Regarde, ma, des mains Node!')

const oneThroughFive = [1, 2, 3, 4, 5]

oneThroughFive.forEach((nombre) => {
  console.log(nombre)
})
```

Disons que vous enregistrez ce code, puis ouvrez la ligne de commande dans une fenêtre de terminal, naviguez jusqu'à l'endroit où se trouve le fichier (en utilisant `cd`, qui signifie "changer de répertoire"), et exécutez node test.js pour obtenir la sortie suivante :

```bash
Look, ma, Node hands!
1
2
3
4
5
```

Vous pouvez également entrer node tout seul (sans nom de fichier ensuite) pour ouvrir un terminal interactif où vous pouvez exécuter du JavaScript Node arbitraire. Si vous avez déjà ouvert la console dans les DevTools de votre navigateur pour taper du code, c'est _exactement_ la même chose, mais en ligne de commande avec Node à la place.

Essayez-le si vous le souhaitez, en supposant que vous avez installé Node. Mais encore une fois, tout ceci n'est qu'une illustration et n'est pas nécessaire pour utiliser npm.

<figure><img src="/images/node.webp" alt="commandes JavaScript dans la console"/></figure>

### La suite

Tout ce que nous avons couvert dans ce chapitre est ingénieux et permet, nous l'espérons, de vous montrer (aussi simplement que cela puisse paraître) la façon dont Node fonctionne. Rappelez-vous, bien que nous n'ayons pas couvert d'exemple spécifique, Node est capable de faire tout ce qu'un langage côté serveur peut faire. Il n'est, je l'espère, pas trop difficile d'imaginer comment l'exécution de JavaScript pour faire pratiquement tout ce à quoi vous pouvez penser au niveau du système ou même sur un serveur distant est très attrayant et avantageux.

Le concept de Node a commencé comme un moyen d'exécuter JavaScript en dehors du navigateur. En tant que tel, nous avons des paquets de scripts basés sur Node qui sont utilisés pour nous aider avec le développement front-end. Alors comment installer ces paquets et s'assurer qu'ils ne sont pas seulement mis à jour mais qu'ils peuvent être désinstallés&nbsp;? Cette question est contenue dans les deux dernières lettres de l'abréviation npm : _gestionnaire de paquets_ (package manager).

En d'autres termes, npm est un outil qui gère les paquets écrits en JavaScript Node. Qu'est-ce qu'un gestionnaire de paquets exactement et comment npm peut-il être considéré comme tel&nbsp;? C'est ce que nous allons voir dans notre guide npm.

<div class="button-container button-block">
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-2-cli">← Chapitre 3</a></div>
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-4-gestionnaire-de-paquets">Chapitre 5 →</a></div>
</div>


NPM, qu'est-ce que Node ?


Si vous êtes toujours avec moi, 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 s'agit de Node Package Manager. Dans le processus, nous avons discuté de l'importance de la **ligne de commande** et de la façon dont elle est utilisée avec npm.

Nous nous sommes également penchés sur le "n" de npm-Node et avons appris que Node ressemble beaucoup au code JavaScript que nous écrivons pour exécuter des sites Web dans un navigateur. En fait, Node est du JavaScript&nbsp;; il s'exécute simplement _en dehors du navigateur_ et est capable de faire des choses différentes de son homologue basé sur le navigateur.

## Table des matières <small>(rappel)</small>

<div class="toc">

- [À qui s'adresse ce guide ?](/articles/npm-guide-complet-pour-le-debutant)
- [Que signifie le mot "npm" ?](/articles/npm-guide-1-npm)
- [Qu'est-ce que la ligne de commande ?](/articles/npm-guide-2-cli)
- [Qu'est-ce que Node ?](/articles/npm-guide-3-node)
- [Qu'est-ce qu'un gestionnaire de paquets ?](/articles/npm-guide-4-gestionnaire-de-paquets) ← **_vous êtes ici_**
- [Comment installer npm ?](/articles/npm-guide-5-installer-npm)
- [Comment installer les paquets npm ?](/articles/npm-guide-6-package-installer-paquets)
- [Que sont les commandes npm ?](/articles/npm-guide-7-commandes)
- [Comment installer un projet npm existant ?](/articles/npm-guide-8-installer-projet)

</div>

### Ce que nous entendons par "paquet"

Tournons maintenant notre attention vers 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".

Un "package" est un terme fourre-tout pour tout fichier de code externe que vous intégrez dans un projet et que vous utilisez d'une manière ou d'une autre. Vous avez peut-être déjà utilisé [jQuery](https://jquery.com/), [Bootstrap](https://getbootstrap.com/) ou [Axios](https://axios-http.com/) dans un projet. Ce sont des exemples courants de packages.

Nous les appelons "paquets" car ils sont "emballés" et prêts à être utilisés. Certains langages les appellent par d'autres noms (Ruby les appelle "gems" par exemple), mais le concept est le même. Au risque de simplifier à l'extrême, **un paquet est du code que vous n'avez pas écrit mais que vous avez obtenu d'une source publique pour l'utiliser dans votre projet**. Vous savez, du code tiers.

Ou, si vous préférez les parodies musicales pour vos moyens mnémotechniques&nbsp;:

🎵 _Quand il y a du code que vous choisissez_<br>
🎵 _Qui n'est pas le vôtre, mais que vous utilisez_<br>
🎵 _C'est un paquet_<br>
🎵 _Quand c'est du matériel que vous installez_<br>
🎵 _Que vous importez et appelez_,<br>
🎵 _C'est un package_

Les paquets sont également souvent appelés "dépendances", car le code que vous écrivez _dépend_ de leur présence. Le code écrit à l'aide du $ 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 paquets sont aussi parfois appelés "gestionnaires de dépendances").

Les paquets 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 votre projet entier (comme un framework entier), ou il peut faire quelque chose de très petit et ciblé que vous saupoudrez seulement là où c'est nécessaire (comme un widget, ou une aide pour une tâche spécifique).

### Utilisation de paquets sans gestionnaire de paquets

Si vous avez déjà utilisé un paquet dans le passé, vous l'avez très probablement appliqué avec une balise `<script>` dans votre HTML, qui va le chercher via une URL externe (idéalement [d'un CDN](https://css-tricks.com/adding-a-cdn-to-your-website/)). Voici comment vous pourriez inclure jQuery dans le HTML de votre site :

```js
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
```

Une autre approche consiste à télécharger une copie du paquet, à l'ajouter aux fichiers de votre projet et à créer un lien vers celui-ci localement, comme ceci :

```js
<script src="/jquery.min.js"></script>
```

### Ce que les gestionnaires de paquets résolvent

Ces deux approches ont bien fonctionné pendant des années. C'est simple. C'est propre. Elle vous permet généralement de "définir et d'oublier" le paquet. Alors pourquoi auriez-vous besoin d'autre chose&nbsp;?

Vous pouvez probablement imaginer comment le fait de posséder une voiture peut sembler peu attrayant pour quelqu'un qui a un accès facile aux transports en commun ou qui n'a pas besoin de se déplacer sur de longues distances. (Cela va nous ramener à la discussion sur le gestionnaire de forfaits, je vous le promets. Restez avec moi).

Si vous avez un accès facile à des transports en commun pratiques et efficaces, alors 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'aura probablement pas beaucoup d'avantages de votre point de vue. Dans ce cas précis, les avantages sont négligeables&nbsp;; les coûts sont comparativement écrasants. Une personne dans cette position hypothétique pourrait même se demander pourquoi quelqu'un veut une voiture tout court&nbsp;!

J'évoque cette analogie parce que l'apprentissage d'une nouvelle technologie peut être très difficile 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 un transport que vous avez déjà. Cela peut sembler être 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 problèmes de manipulation. La simple liaison à un paquet dans une balise de script fonctionne bien, tant que :

- le nombre de projets que vous avez est gérable&nbsp;;
- le nombre de personnes travaillant sur les projets est gérable&nbsp;;
- le nombre de mises à jour qui doivent être apportées aux paquets est gérable&nbsp;; et, plus important encore
- chaque paquet utilisé dans vos projets est du côté client (navigateur) JavaScript ou CSS.

Ce dernier point est le plus important, car il existe une pléthore d'outils que vous ne pourrez jamais utiliser si vous n'exécutez les choses _que_ dans le navigateur (nous y reviendrons dans un instant).

Si vous cochez toutes ces cases, il se peut que vous ne dépassiez jamais cette approche. Votre approche du développement pourrait bien ressembler à ceci :

<figure><img src="/images/packages.webp" alt="Une illustration en noir et blanc montrant le diagrame de paquets et de gestionnaire de paquets. Un paquet labellisé 'Cloud' (nuage) est suivi de trois fichiers, HTML, CSS, et JavaScript, qui sont suivis par le navigateur."/></figure>

Mais même dans ce cas, lorsque vous avez plusieurs balises `<script>`, dont chacune renvoie à une version spécifique d'un script ou d'une bibliothèque, la _seule_ façon de savoir quels paquets vous utilisez —&nbsp;et s'ils sont à jour&nbsp;— est d'ouvrir manuellement le HTML et de regarder le code.

Ce n'est pas un problème en soi, mais il croît de façon exponentielle à mesure que la taille et la portée d'un projet augmentent. Vous pouvez peut-être assurer le suivi de quelques paquets manuellement, mais comment le faire quand il s'agit de centaines, voire de milliers de paquets&nbsp;? Et même si vous pouviez les suivre manuellement, le risque d'erreur humaine reste élevé.

**Ce n'est pas le rôle de HTML d'être la source de vérité pour tous les paquets utilisés sur un projet**. En plus de mélanger les points d'attention, cela introduit aussi potentiellement des conflits lorsqu'on essaie de fusionner des travaux sans rapport entre coéquipiers.

Tout cela est important, mais ce n'est que 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 en ce moment —&nbsp;et c'est là que les choses commencent _vraiment_ à se gâter.

De nombreuses applications de production utilisent une combinaison des outils et paquets suivants, voire tous :

- Sass (facilite l'écriture des CSS)
- PostCSS (améliore les CSS pour une efficacité et une compatibilité maximales)
- Babel (transpose les nouveaux JavaScript pour qu'ils fonctionnent dans les anciens navigateurs)
- TypeScript (ajoute la vérification de type à JavaScript)
- Rechargement des modules par un serveur de développement qui rafraîchit automatiquement le navigateur pour afficher vos modifications.
- Utilitaires supplémentaires pour le regroupement, la minification et/ou la concaténation de code
- Compression automatique des images
- Bibliothèques de test
- Linters

Mais remarquez que vous avez maintenant plusieurs dépendances qui non seulement ne sont _pas_ présentes dans vos balises de script, mais qui ne sont _pas non plus prises en compte dans votre projet_&nbsp;! Il n'y a aucun moyen pour quiconque —&nbsp;y compris pour vous-même dans le futur&nbsp;— d'avoir une idée des outils qui ont été utilisés ou qui sont nécessaires pour faire fonctionner ce projet.

Et même si vous pouviez savoir exactement ce dont le projet a besoin de cette façon, vous auriez toujours besoin d'aller localiser, télécharger et installer tous ces paquets vous-même... manuellement. En fonction du projet, cette tâche pourrait facilement prendre une journée, voire plus.

Tout cela signifie que votre flux de travail ressemble maintenant un peu plus à ceci :

<figure role="group"><img src="/images/workflow.webp" alt=""/><figcaption>Encore une fois, tout cela est bien. Cette chaîne d'outils signifie que ce qui est expédié au navigateur est hautement optimisé, mais cela représente également des frais généraux et une complexité supplémentaires.</figcaption></figure>

**Aussi pratiques que soient tous les outils ci-dessus, vous devez quand même les gérer**. Les dépendances sont aussi des projets, et elles envoient 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 paquet sur un CDN et d'appeler cela bon. Vous devez vous assurer que chaque chose est installée et fonctionne correctement non seulement sur votre machine, mais aussi sur celle de chaque collaborateur.

Les gestionnaires de paquets existent pour rendre les paquets —&nbsp;ou dépendances&nbsp;— d'un projet gérables en sachant ce qui est installé, ce qui est disponible pour la mise à jour et si un paquet 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 paquets, notamment npm, proposent également des fonctionnalités supplémentaires qui ouvrent encore plus de possibilités pour rendre le développement plus efficace. Mais la gestion de paquets est l'attraction principale.

### Il existe des gestionnaires de paquets qui ne sont pas npm

Cette partie n'est pas super pertinente pour npm lui-même, mais par souci d'exhaustivité, je devrais également mentionner que npm n'est pas le seul gestionnaire de paquets JavaScript. Par exemple, vous pouvez voir [Yarn](https://yarnpkg.com/) référencé dans les exemples de code. Yarn et npm fonctionnent à peu près de la même manière, à tel point qu'une grande partie de l'interopérabilité entre les deux est volontairement intégrée.

Certaines personnes préfèrent un gestionnaire de paquets plutôt qu'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.

Vous verrez peut-être des exemples de code (dont certains dans les articles de CSS-Tricks) qui font référence à la fois à Yarn et à npm. 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 de 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. D'un point de vue fonctionnel, il est rare (voire jamais) que vous utilisiez l'un ou l'autre, 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 paquets utilisés par les développeurs, il existe [un autre gestionnaire de paquets appelé PnPm](https://pnpm.io/) qui est npm dans les faits, mais plus performant et efficace. La contrepartie est que PnPm nécessite un peu plus de connaissances techniques dans certains cas, c'est donc une option un peu plus avancée.

<figure role="group"><img src="/images/p-managers.png" alt=""/><figcaption>Les différences de syntaxe entre les différents gestionnaires de paquets sont généralement minimes. (Source: <a href="https://vitejs.dev/">Vite</a>)</figcaption></figure>

### Qu'est-ce qui fait de npm le gestionnaire de paquets "standard"&nbsp;?

Encore une fois, je n'évoque d'autres gestionnaires de paquets que pour illustrer le fait que npm n'est pas le seul gestionnaire de paquets existant, mais qu'il est généralement la norme.

Qu'est-ce qui en fait le "standard" parmi les gestionnaires de paquets&nbsp;? D'autres langages, dont Ruby et PHP, disposent de gestionnaires de paquets depuis de nombreuses années&nbsp;; JavaScript n'en avait pas vraiment de bons avant npm.

npm a commencé comme un projet indépendant et open-source, mais a été racheté par Microsoft en 2020. Il se compose techniquement de deux parties&nbsp;: le gestionnaire de paquets proprement dit et le registre de paquets, qui est une liste toujours croissante de près de deux millions de paquets disponibles pour l'installation.

Vous pouvez considérer npm comme le magasin d'applications pour tout ce que vous pourriez vouloir utiliser sur un front-end ou un projet basé sur Node. Trouvez ce que vous voulez et installez-le sur votre système via la ligne de commande. Vous pouvez mettre à jour ce paquet 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 passer des commandes npx. [npx](https://docs.npmjs.com/cli/v7/commands/npx) est en fait une partie de npm, mais en utilisant `npx` dans une commande au lieu de `npm` , vous pouvez exécuter le code d'un paquet sans l'installer définitivement. NPX installe simplement ce dont il a besoin, l'exécute et le décharge.

C'est utile si, par exemple, vous voulez 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.

Un autre exemple cool : vous pouvez exécuter `npx sass` (avec les arguments d'entrée et de sortie nécessaires) si vous voulez compiler les fichiers Sass de votre projet juste une fois sans vous donner la peine d'installer complètement Sass. Ce n'est probablement pas pratique dans la plupart des cas, mais si vous avez juste besoin d'une compilation rapide et ponctuelle ici et là, npx serait un moyen pratique de le faire, car cela signifie moins de paquets installés qui doivent être mis à jour et maintenus.

### La suite

Très bien, c'était 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 paquets Node, des outils qui aident à ajouter des fonctionnalités à un projet, à ajouter des commodités pratiques pour les développeurs... ou tout cela à la fois&nbsp;!

Nous allons poursuivre en faisant maintenant nos premiers 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 de npm.

<div class="button-container button-block">
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-3-node">← Chapitre 4</a></div>
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-5-installer-npm">Chapitre 6 →</a></div>
</div>


NPM, qu'est-ce qu'un gestionnaire de paquets ?


Vous avez l'impression d'avoir une assez bonne idée de ce qu'est un gestionnaire de paquets&nbsp;? Nous avons certainement couvert beaucoup de terrain en nous familiarisant avec tous les termes et concepts des gestionnaires de paquets, mais je dirais qu'il est grand temps de faire quelque chose de nos nouvelles connaissances. Et d'abord, nous devons installer npm.

À cette fin, nous allons nous assurer que nous avons installé Node et npm, puis créer un petit projet d'exemple pour vous donner une véritable expérience pratique de travail avec les bases de npm et ce à quoi ressemble l'utilisation de npm dans votre flux de travail de développement front.

## Table des matières <small>(rappel)</small>

<div class="toc">

- [À qui s'adresse ce guide ?](/articles/npm-guide-complet-pour-le-debutant)
- [Que signifie le mot "npm" ?](/articles/npm-guide-1-npm)
- [Qu'est-ce que la ligne de commande ?](/articles/npm-guide-2-cli)
- [Qu'est-ce que Node ?](/articles/npm-guide-3-node)
- [Qu'est-ce qu'un gestionnaire de paquets ?](/articles/npm-guide-4-gestionnaire-de-paquets)
- [Comment installer npm ?](/articles/npm-guide-5-installer-npm) ← **_vous êtes ici_**
- [Comment installer les paquets npm ?](/articles/npm-guide-6-package-installer-paquets)
- [Que sont les commandes npm ?](/articles/npm-guide-7-commandes)
- [Comment installer un projet npm existant ?](/articles/npm-guide-8-installer-projet)

</div>

### Vérifiez si npm est déjà installé

Avant d'installer npm, nous devons vérifer s'il est déjà installé&nbsp;! Si vous n'êtes pas sûr que npm soit 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 comme VS Code, ou d'un autre terminal où vous avez accès à la ligne de commande.

Vous êtes prêt&nbsp;? Commencez par cette commande (remarquez que nous n'incluons pas le caractère `$` dans ces exemples) :

```js
node - v
```

Cette commande affiche la version actuelle de Node, si elle est installée. Si Node est installé, la ligne de commande répondra avec le numéro de version de Node qui est actuellement installé :

```js
v16.9.1
```

Votre version peut être différente, bien sûr. Quoi qu'il en soit, le fait que vous voyiez un numéro de version confirme que npm est installé sur votre système&nbsp;! Permettez-moi d'insister sur le fait que **les numéros eux-mêmes sont sans importance**, du moment que nous obtenons un numéro de version.

Si npm ou Node n'est pas actuellement installé, vous verrez un message du type "Commande non trouvée" à la place. Dans le cas improbable où npm serait installé mais pas Node (ou vice versa), il est probablement utile 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 directement à la section suivante), nous allons suivre les conseils des [instructions officielles de NPM](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) et le faire via un programme appelé [nvm](https://github.com/nvm-sh/nvm).

### Installation du gestionnaire de version de Node

Node Version Manager, ou nvm, vous permet d'installer, de mettre à jour et de désinstaller Node sur votre système, et aussi de gérer plusieurs versions de Node entre lesquelles vous pouvez passer.

<figure role="group"><img src="/images/nvm-github.webp" alt=""/><figcaption>Le dépôt du gestionnaire de version de Node (Node Version Manager) sur GitHub</figcaption></figure>

> Note : _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 des navigateurs, comme Chrome 96. Nous n'aurons besoin d'aucune autre version de Node que la dernière, donc cela ne sera pas nécessaire pour nous dans l'immédiat, bien que cela puisse être avantageux pour vous plus tard_.

Je sais, cela peut sembler beaucoup de travail supplémentaire d'installer un programme juste pour en installer un autre, mais encore une fois, c'est le chemin recommandé, et faire les choses de la bonne manière dès le début les rend beaucoup plus faciles à long terme. Je préfère vous mettre sur la voie du succès plutôt que de rendre les choses brièvement plus faciles au prix d'une plus grande complexité par la suite.

### Installation de nvm sur Windows

Si vous êtes sous Windows, vous aurez en fait plus de facilité ici. Vous aurez besoin de nvm pour Windows spécifiquement, mais heureusement, Windows a déjà un installateur qu'il suffit de télécharger et d'exécuter. [Les instructions se trouvent dans le repo NVM pour Windows](https://github.com/coreybutler/nvm-windows) sur GitHub.

- Téléchargez [la dernière version de NVM pour Windows](https://github.com/coreybutler/nvm-windows/releases). Vous pouvez [l'installer manuellement](https://github.com/coreybutler/nvm-windows/wiki#manual-installation), si vous préférez.
- Ouvrez le terminal et exécutez la commande `nvm list available` pour voir une liste des versions de Node qui sont disponibles pour le téléchargement et l'installation.
- Exécutez la commande `nvm use`, suivie du numéro de version de Node que vous souhaitez utiliser (par exemple, `nvm use 16.9.1`) pour utiliser une version spécifique. Vous pouvez également utiliser `use latest`, `lts`, ou `newest` au lieu d'un numéro de version spécifique, où `newest` est la dernière version installée.

Une fois installé, nvm fonctionnera de la même manière sur votre machine Windows que sur tout autre système.

### Installation de nvm sur MacOS

Pour installer nvm sur MacOS, la première étape consiste à le télécharger avec cette commande :

```bash
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
```

> Note : _0.39.0 est la dernière version publiée, mais il peut être utile de vérifier le 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 Entrée, vous verrez votre terminal afficher un tas de choses qui n'ont pas vraiment d'importance. En fait, je vais vous confier un petit secret&nbsp;: la plupart du temps, personne ne lit ce que contient son terminal. Tout ce qui nous intéresse, c'est que...

1. la commande se termine finalement&nbsp;; et
2. qu'elle ne se termine pas par un message d'erreur.

> Note : _Si vous êtes invité à entrer une commande au milieu de l'installation, appuyez sur la touche q pour quitter et continuer._

Vous saurez que l'exécution de la commande est terminée lorsque le curseur de saisie recommence à clignoter, indiquant que le terminal attend votre saisie. Vous pouvez même voir ceci juste après la fin de l'installation de nvm :

```bash
=> Close and reopen your terminal to start using nvm or run the following to use it now:

```

C'est à dire : _Fermez et rouvrez votre terminal pour commencer à utiliser nvm ou exécutez ce qui suit pour l'utiliser maintenant_.

En supposant que vous ne voyiez pas d'erreurs à ce stade, je recommanderais l'option plus simple consistant à quitter et à 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 ardoise propre.

### Comment installer npm via Node

Maintenant que nvm est installé, nous sommes prêts à faire ce que nous voulions _vraiment_ faire en premier lieu&nbsp;: installer npm et Node sur notre système.

Ce n'est pas une mauvaise idée de confirmer que nvm est installé correctement, en exécutant `nvm -v`. Si le terminal vous montre le numéro de la version installée, vous êtes prêt à partir&nbsp;! Si ce n'est pas le cas, rappelez-vous que vous devrez peut-être redémarrer votre application de terminal avant que l'installation ne soit complètement terminée.

Maintenant que nous avons nvm, l'installation de Node est une commande super courte&nbsp;:

```bash
nvm install node
```

Assez simple, hein&nbsp;?

Vous devriez voir un message du type `Downloading and installing node v17.1.0`, bien que le numéro de version puisse ne pas correspondre, ce qui est bien. Vous obtiendrez la dernière version stable au moment de l'exécution. Attendez jusqu'à ce que la commande ait fini de s'exécuter —&nbsp;encore une fois, vous saurez qu'elle est terminée lorsque vous serez de retour à l'invite par défaut et que vous pourrez taper d'autres commandes.

Après cela, vous avez terminé&nbsp;! Cette simple commande n'installe pas seulement Node, mais elle installe également npm. Encore une fois, vous pouvez vérifier que tout est installé et à jour avec `npm -v` et `node -v`. Si tout est bon, vous obtiendrez un numéro de version.

### Prochaine étape

Très bien, à ce stade, nous avons nvm pour installer et gérer Node, Node lui-même, et npm pour gérer les paquets Node. Dans la suite de ce guide npm, nous allons installer quelques paquets dans un projet&nbsp;!

<div class="button-container button-block">
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-4-gestionnaire-de-paquets">← Chapitre 5</a></div>
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-6-package-installer-paquets">Chapitre 7 →</a></div>
</div>


NPM : comment installer npm ?


À présent, vous commencez à bien connaître npm&nbsp;! Jusqu'à présent, nous avons décomposé les trois lettres de "npm" pour mieux comprendre Node et les gestionnaires de paquets. Dans [le chapitre précédent](/articles/npm-guide-5-installer-npm), nous avons même installé Node et npm tout en nous familiarisant avec le gestionnaire de version de Node, ou nvm. La prochaine étape de ce guide du débutant pour npm est probablement la raison pour laquelle vous êtes ici en premier lieu : l'installation des paquets npm.

## Table des matières <small>(rappel)</small>

<div class="toc">

- [À qui s'adresse ce guide ?](/articles/npm-guide-complet-pour-le-debutant)
- [Que signifie le mot "npm" ?](/articles/npm-guide-1-npm)
- [Qu'est-ce que la ligne de commande ?](/articles/npm-guide-2-cli)
- [Qu'est-ce que Node ?](/articles/npm-guide-3-node)
- [Qu'est-ce qu'un gestionnaire de paquets ?](/articles/npm-guide-4-gestionnaire-de-paquets)
- [Comment installer npm ?](/articles/npm-guide-5-installer-npm)
- [Comment installer les paquets npm ?](/articles/npm-guide-6-package-installer-paquets) ← **_vous êtes ici_**
- [Que sont les commandes npm ?](/articles/npm-guide-7-commandes)
- [Comment installer un projet npm existant ?](/articles/npm-guide-8-installer-projet)

</div>

### Un exemple rapide

Nous pouvons installer notre tout premier paquet avec la commande `npm install` (ou `npm i` pour faire court), suivie du nom des paquets que nous voulons ajouter à notre projet. Par exemple, [le paquet Node pour Sass](https://www.npmjs.com/package/sass) est simplement appelé "sass", ce qui signifie que nous pouvons l'ajouter à un projet comme ceci (assurez-vous simplement d'être d'abord dans un nouveau dossier que vous avez créé pour ce petit projet) :

```bash
npm install sass
```

C'est tout ce dont vous avez besoin&nbsp;! Tapez cela et npm se met directement au travail :

<figure><img src="/images/npm-install.webp" alt="lancement de la commande 'npm install sass' pour installer Sass sur notre ordi"/></figure>

Ce qui se passe en coulisses, c'est que npm essaie de trouver un paquet nommé sass dans le registre des paquets npm. S'il trouve ce paquet (ce qui est le cas), npm l'installe dans le projet dans un dossier node_modules généré automatiquement (nous y reviendrons plus tard) situé dans le dossier racine du projet, y compris tout ce dont le paquet a besoin pour fonctionner. (C'est pourquoi vous voyez que npm a ajouté 16 paquets et vérifié un total de 17 paquets npm, au lieu du seul paquet Sass - lui aussi a des dépendances).

Une fois que nous avons exécuté la commande `install`, vous pouvez remarquer 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&nbsp;: deux fichiers JSON nommés `package.json` et `package-lock.json`, plus un dossier `node_modules` entièrement nouveau.

<figure><img src="/images/package-json.webp" alt=""/></figure>

Qu'est-ce que c'est que ça&nbsp;? Nous avons demandé à npm d'installer Sass, pas tous ces trucs. Cela ne fait pas partie de Sass... n'est-ce pas&nbsp;? Eh bien, c'est exact, mais il y a une très bonne raison pour laquelle ces nouveaux éléments ont été générés dans le dossier du projet. Voyons ce qui vient de se passer.

### Ce qui se passe lorsque vous installez un paquet

Lorsque vous installez (ou désinstallez, ou mettez à jour) un paquet, npm fait la plupart, sinon la totalité, des quatre choses suivantes :

- met à jour le fichier `package.json` dans votre projet, si nécessaire&nbsp;;
- met à jour le fichier `package-lock.json` (appelé "lockfile") qui contient toutes les spécificités techniques&nbsp;;
- installe les fichiers du paquet réel - et tout autre paquet dont le paquet original pourrait dépendre (à l'intérieur du dossier `node_modules`)&nbsp;; et
- exécute un audit des paquets installés.

Passons en revue ces éléments un par un.

#### package.json et package-lock.json

Ces deux fichiers JSON fonctionnent ensemble pour assurer 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, et ainsi de suite). La différence est un peu technique, mais expliquée en gros : le fichier lockfile est l'instantané précis et approfondi de l'arbre des dépendances du projet, et `package.json` est une vue d'ensemble de haut niveau, qui peut aussi contenir d'autres choses. **Les principaux paquets que vous installez peuvent être répertoriés dans package.json, mais package-lock.json est l'endroit où l'arbre de dépendance entier est suivi**.

Le fichier lockfile n'est également jamais censé être mis à jour à la main&nbsp;; uniquement par npm. Veillez donc à ne pas confondre le fichier lockfile avec le fichier `package.json`.

Lorsque vous partagez ou collaborez avec d'autres personnes sur un projet, npm sait d'où vient le projet et ce que vous avez exactement installé dans le projet par ces deux fichiers. Il peut répliquer cet environnement avec précision sur la machine de n'importe qui d'autre, grâce à leurs informations. Les deux fichiers sont destinés à être commis à votre repo Git, et servent de schéma directeur des dépendances de votre projet. Ainsi, lorsqu'un autre développeur de votre équipe clone le repo et exécute la commande npm install, npm sait exactement quels paquets installer, ce qui vous permet de rester synchronisé avec votre collègue.

Si vous ouvrez `package.json`, vous ne verrez pas grand-chose, mais cela vaut la peine de jeter un coup d'œil juste pour voir ce qui se passe&nbsp;:

```js
{
  "dependencies" : {
    "sass" : "^1.43.4"
  }
}
```

Vous ne verrez probablement pas ce numéro de version exact (puisque le paquet a été mis à jour depuis le moment de l'écriture), mais vous _devriez_ voir `sass` listé dans un objet JSON dependencies. Le numéro lui-même (1.43.4 dans ce cas) indique la version spécifique de Sass qui est installée.

**Note** : _Petite parenthèse importante : le caractère "accent circonflexe" (^) au début du numéro de version indique à npm qu'il est autorisé à installer des mises à jour mineures du paquet. En d'autres termes, il indique à npm que le paquet Sass installé doit être au moins la version 1.43.4, mais qu'il peut s'agir de n'importe quelle version 1.x.x supérieure, tant qu'elle est inférieure à 2.0.0. npm choisit généralement la dernière version stable lorsqu'un paquet est installé, mais ajoute ce caractère pour permettre des mises à jour non cassantes. Cette partie est appelée "versionnement sémantique" et fait l'objet d'un article de blog en soi, mais n'est pas propre à npm._

Quoi qu'il en soit, cela couvre les deux fichiers JSON. Parlons maintenant du dossier `node_modules`.

#### node_modules

node_modules est **l'endroit où se trouve tout le code de paquetage réel**&nbsp;; c'est l'endroit où vos paquets Node installés et toutes les choses qui les font fonctionner sont réellement installés. Si vous ouvrez le dossier en ce moment même, vous trouverez un dossier `sass`, mais aussi plusieurs autres dossiers.

La raison de ces dossiers supplémentaires est que lorsque vous installez un paquet, il peut avoir besoin _d'autres_ paquets pour fonctionner correctement (comme c'est clairement le cas pour Sass). Ainsi, npm fait automatiquement le travail difficile de trouver et d'installer toutes ces dépendances. Comme vous l'avez peut-être deviné, ces dépendances peuvent également avoir _d'autres_ dépendances, et le processus se répète, ainsi de suite, jusqu'à ce que nous ayons fini de parcourir l'arbre des dépendances jusqu'à ses branches les plus éloignées et qu'absolument tout ce dont nous avons besoin soit installé (ou jusqu'à ce que nous ayons rencontré une erreur quelconque, bien que nous espérions que ce ne soit pas le cas).

Pour cette raison, il est courant qu'un projet ait des sous-dossiers node_modules par centaines ou plus, qui s'additionnent rapidement en termes d'espace disque. `node_modules` peut souvent devenir assez lourd.

Si vous vous demandez comment commettre un dossier super volumineux comme node_modules dans le dépôt d'un projet, voici une remarque importante&nbsp;: contrairement aux fichiers JSON, **le dossier node_modules n'est pas destiné à être committé dans Git**, ni même partagé. En fait, presque tous les exemples de fichiers `.gitignore` (le fichier qui indique les fichiers que Git doit ignorer lorsqu'il suit des fichiers) incluent `node_modules` pour s'assurer que Git ne le touche jamais ou ne le suit pas.

Alors, comment les autres membres de votre équipe obtiennent-ils ces paquets&nbsp;? Eh bien ils exécutent `npm install` (ou `npm i` en abrégé) depuis la ligne de commande pour télécharger les dépendances directement depuis la source. De cette façon, il n'est pas nécessaire de pousser (ou de tirer) des quantités massives de données depuis et vers le dépôt d'origine.

### Faire preuve de prudence lors de l'installation des dépendances

Cette toile massive de dépendances et de leurs arrière-arrière-arrière-dépendances peut conduire à des situations où une petite bibliothèque utilitaire qui fournit un service utile peut être adoptée par de nombreux autres paquets, qui sont à leur tour utilisés par de nombreux _autres_ paquets, jusqu'à ce que le code original finisse par être installé discrètement sur un pourcentage significatif de sites et d'applications.

Il peut sembler étrange (voire effrayant) que, dans le processus d'installation de votre paquet, vous puissiez _laisser passer tout un tas d'autres choses_. Cela peut ressembler à inviter un nouvel ami à votre fête chez vous, qui se présente ensuite avec 20 étrangers non invités. Mais ce n'est pas aussi bizarre ou effrayant que cela peut paraître, pour quelques raisons&nbsp;:

1. **La plupart des paquets 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 consulter le paquet sur le registre ([npmjs.com](https://www.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.
2. **Il existe un vaste monde de fonctionnalités dont de _nombreux_ projets auront besoin**. Pensez au formatage de la date, à la gestion des demandes et des réponses HTTP, à l'étranglement, au débruitage ou aux animations, pour ne citer que quelques exemples rapides. Cela n'a aucun sens de réinventer la roue et de coder manuellement ces éléments chaque fois qu'ils sont utilisés dans un nouveau projet.
3. **L'installation d'un paquet n'est pas vraiment très 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 qu'avec les paquets, ni des autres éléments sur lesquels ces applications et plugins peuvent s'appuyer. Il y a de fortes chances qu'ils s'appuient également sur de nombreux petits paquets, 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 de mauvais acteurs n'ont jamais réussi à tirer parti de ce système. Mais sachez qu'il existe de nombreux processus en place pour éviter que les choses ne dérapent. En cas de doute, contentez-vous des paquets 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 npm audit ?

Lorsque nous avons installé sass plus tôt, nous avons vu le message suivant dans le terminal une fois l'installation terminée :

```bash
found 0 vulnerabilities
```

Cependant, vous pouvez voir quelques avertissements à la place, comme ce vieux projet à moi dans l'image suivante. J'ai décidé de le démarrer et d'exécuter `npm install` (`npm i`) après qu'il soit resté inutilisé pendant au moins deux ans. Voyons comment cela se passe :

<figure><img src="/images/npm-audit.webp" alt=""/></figure>

**Les paquets présentant des vulnérabilités connues sont signalés par `npm audit`**, qui s'exécute automatiquement chaque fois que vous installez un paquet. Si vous voyez un message comme celui-ci, ne soyez pas _trop_ alarmé&nbsp;; de nombreuses vulnérabilités, en particulier dans la catégorie "modérée", comportent un risque très faible dans le monde réel, et peuvent n'être pertinentes que dans des situations très spécifiques. (Par exemple, il se peut qu'une seule méthode d'un paquet, lorsqu'elle est utilisée d'une manière particulière, le rende vulnérable).

Néanmoins, il est préférable de traiter ce que nous pouvons, ce à quoi sert la commande `npm audit fix`. L'ajout de `fix` à la fin de la commande indique à npm de procéder à la mise à jour vers une nouvelle _version mineure_ de tout paquet présentant une vulnérabilité connue. La partie "version mineure" est importante&nbsp;; les versions mineures ne sont pas censées contenir des changements de rupture, seulement des mises à jour. Cela signifie qu'il devrait être possible d'exécuter une mise à jour de cette manière sans risquer de casser votre projet.

Si l'augmentation du paquet d'un numéro de version mineure ne suffit pas, vous pouvez ajouter le drapeau `--force` à la commande originale :

```bash
npm audit fix --force
```

Il s'agit toutefois d'une manœuvre risquée. Donner à npm la permission d'"utiliser la force" signifie qu'il peut maintenant installer des mises à jour de versions majeures pour corriger les vulnérabilités —&nbsp;ce qui signifie qu'il peut effectuer des changements cassants ou introduire des incompatibilités. Je ne recommanderais pas de faire cela à moins qu'il n'y ait des vulnérabilités critiques que le correctif d'audit de npm est incapable de traiter et que vous soyez prêt et capable de passer beaucoup de temps par la suite à dépanner, si nécessaire.

Une dernière remarque à ce sujet&nbsp;: il est utile de savoir que vous pouvez parfois résoudre certains problèmes inattendus avec les projets npm en supprimant les node_modules, et en relançant `npm install`. C'est la façon dont npm " désactive et réactive les choses ", ce que j'ai moi-même fait de nombreuses fois.

### La suite

Maintenant que nous avons exploré en profondeur le terrier du lapin qui explique comment npm fonctionne sous le capot, _revenons à la pratique_, d'accord&nbsp;?

<div class="button-container button-block">
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-5-installer-npm">← Chapitre 6</a></div>
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-7-commandes">Chapitre 8 →</a></div>
</div>


NPM : comment installer les paquets npm ?


npm est, comme vous le savez maintenant, [un gestionnaire de paquets](/articles/npm-guide-4-gestionnaire-de-paquets). Mais comme d'autres outils similaires antérieurs qui exécutent des tâches en ligne de commande, tels que [Grunt](https://gruntjs.com/) et [Gulp](https://gulpjs.com/), npm peut également exécuter des tâches - ce qui est parfait pour nous car maintenant que nous avons installé le paquet Sass dans le [chapitre précédent](/articles/npm-guide-6-package-installer-paquets), nous pouvons commencer à l'utiliser&nbsp;!

## Table des matières <small>(rappel)</small>

<div class="toc">

- [À qui s'adresse ce guide ?](/articles/npm-guide-complet-pour-le-debutant)
- [Que signifie le mot "npm" ?](/articles/npm-guide-1-npm)
- [Qu'est-ce que la ligne de commande ?](/articles/npm-guide-2-cli)
- [Qu'est-ce que Node ?](/articles/npm-guide-3-node)
- [Qu'est-ce qu'un gestionnaire de paquets ?](/articles/npm-guide-4-gestionnaire-de-paquets)
- [Comment installer npm ?](/articles/npm-guide-5-installer-npm)
- [Comment installer les paquets npm ?](/articles/npm-guide-6-package-installer-paquets)
- [Que sont les commandes npm ?](/articles/npm-guide-7-commandes) ← **_vous êtes ici_**
- [Comment installer un projet npm existant ?](/articles/npm-guide-8-installer-projet)

</div>

### Sauter dans les commandes npm

Ouvrez le fichier `package.json` dans votre dossier de test, et vous ne verrez pas grand-chose pour le moment&nbsp;; juste une propriété dependencies, avec une seule dépendance jusqu'à présent&nbsp;:

```js
{
  "dependencies" : {
    "sass" : "^1.43.4"
  }
}
```

Le fichier `package.json` abrite bien plus que des dépendances, cependant. 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.

Rappelez-vous, 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.json` ne contient généralement que les dépendances de premier niveau, et nous pouvons le personnaliser librement.

L'objet `scripts` de votre fichier `package.json` vous permet de créer des commandes que vous pouvez exécuter dans ce projet afin de gérer diverses tâches pour vous, soit en une seule fois, soit en tant que processus fonctionnant en continu. En général, 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 de ressources et/ou l'exécution de tests. En fait, il y a souvent une seule commande `start` ou `dev` intégrée aux projets pour gérer _toutes_ les tâches que vous pourriez avoir besoin d'exécuter simultanément, comme la compilation de Sass et JavaScript dans la même séquence.

Nous n'avons pas encore de scripts à exécuter, mais réparons cela&nbsp;!

### Exemple : Compilation de Sass en CSS

À l'intérieur de la section `scripts` du fichier `package.json`, nous avons accès à tous nos paquets installés. Même si nous ne pouvons pas simplement taper des commandes `sass` dans le terminal pour le moment, nous pouvons exécuter des commandes `sass` dans le cadre d'un script npm.

Note : _Nous pourrions exécuter des commandes sass dans le terminal si Sass était installé globalement, c'est-à-dire à l'échelle du système, plutôt que 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 paquet). Mais une installation globale rendrait les commandes sass disponibles partout sur le système_.

Commencez par coller ce bloc de code dans votre fichier package.json, juste après l'accolade `{` ouvrante&nbsp;:

```js
"scripts" : {
  "sass:build" : "sass style.scss style.css"
},
```

La syntaxe JSON est très stricte. Essayez de faire passer le contenu du fichier par un [validateur JSON](https://jsonlint.com/) si vous êtes bloqué.

Cela nous donne accès à un script `npm run sass:build`, qui compilera Sass en CSS pour nous&nbsp;!

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 (&nbsp;:&nbsp;) ne font rien de spécial ici&nbsp;; c'est juste une convention, puisque build ou sass seul serait probablement trop générique.

Si vous avez déjà travaillé avec des commandes Sass, vous savez probablement que cela signifie que nous devons également créer un fichier `style.scss` à la racine de notre dossier de projet. Faisons-le et insérons-y un peu de code Sass arbitraire.

<figure role="group"><img src="/images/sass-example.webp" alt=""/><figcaption>Le fichier `style.scss` file est à côté des fichiers JSON et le dossier node_modules est le premier dans le projet.</figcaption></figure>

Voici le code Sass que j'ai utilisé, si vous souhaitez le copier et le coller&nbsp;:

```scss
$myColor: #ffd100;

.a {
  .nested {
    .selector {
      color: $myColor;
    }
  }
}
```

Super&nbsp;! Enregistrez ce fichier en tant que `style.scss` à la racine de votre projet, et essayons d'exécuter notre nouvelle commande&nbsp;:

```bash
npm run sass:build
```

Une fois cette tâche accomplie, vous devriez voir deux nouveaux fichiers apparaître presque instantanément dans votre dossier de projet&nbsp;: `style.css` et `style.css.map`.

<figure role="group"><img src="/images/sass-example2.webp" alt=""/><figcaption>Après avoir lancé `npm run sass:build`, vous devriez voir les fichiers style.css and style.css.map apparaître tout en haut du dossier projet.</figcaption></figure>

Si vous le souhaitez, vous pouvez ouvrir le fichier style.css —&nbsp;qui contient le code CSS compilé&nbsp;— pour vérifier qu'il correspond bien à nos attentes&nbsp;:

<figure role="group"><img src="/images/sass-example3.webp" alt=""/><figcaption>Regardez-moi ça, du pur CSS&nbsp;!</figcaption></figure>

Le paquet sass va même jusqu'à compiler une _[source map](https://css-tricks.com/should-i-use-source-maps-in-production/)_ pour nous, ce qui nous permet de voir quels styles proviennent de quels fichiers `.scss` lorsque nous les inspectons dans les DevTools d'un navigateur. Comme c'est agréable&nbsp;!

**Si vous rencontrez une erreur** : vérifiez la syntaxe du `package.json` pour vous assurer qu'il s'agit d'un JSON valide (voici un [validateur JSON en ligne](https://jsonlint.com/) que vous pouvez utiliser), et que votre fichier .scss contient du Sass valide (voici un [convertisseur Sass en ligne](https://jsonformatter.org/sass-to-css)). Une autre chose à vérifier est que le nom du fichier correspond au nom dans la commande.

### Création d'une commande réservée au développement

C'est assez génial, mais nous en aurons probablement assez d'exécuter cette commande à plusieurs reprises pendant le développement. Alors, créons une deuxième commande qui demande à Sass de surveiller le fichier pour nous et de le recompiler automatiquement chaque fois que nous enregistrons des modifications&nbsp;!

Ajoutez ceci à l'intérieur de l'objet `scripts` dans `package.json`&nbsp;:

```js
"sass:watch" : "sass style.scss style.css --watch" : "sass: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 en a. Encore une fois, **JSON est strict**, alors appuyez-vous sur le validateur JSON si nécessaire.

Maintenant, si nous exécutons `sass:watch`, vous verrez un message dans votre terminal disant : “Sass is watching for changes. Press Ctrl-C to stop.” ("Sass surveille les changements. Appuyez sur Ctrl-C pour arrêter".)

Si vous ouvrez maintenant votre fichier style.scss, que vous y apportez une modification et que vous l'enregistrez, vous devriez voir apparaître automatiquement dans le terminal un message confirmant que Sass a été recompilé en CSS :

<figure><img src="/images/sass-message.webp" alt="Une capture d'écran du texte du terminal indiquant que Sass surveille les modifications. Appuyez sur control plus c pour arrêter. En dessous, il est indiqué que le fichier style.scss a été compilé en un fichier style.css."/></figure>

_Ah, voilà qui est utile&nbsp;!_ Non seulement cela, mais une fois que nous aurons livré ces fichiers à notre dépôt, nous aurons les instructions exactes pour installer et faire fonctionner Sass, avec une simple commande - et tous les autres qui travaillent sur ce projet aussi&nbsp;!

Nous allons laisser les choses en l'état pour ce projet de test. Il était utile de voir comment démarrer, mais le plus souvent, vous vous tournerez vers 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 le [dernier chapitre de ce guide npm](/articles/npm-guide-8-installer-projet).

### Dernières notes sur l'installation des paquets npm

Vous devez savoir qu'il existe en fait deux façons d'installer des paquets npm, à choisir selon que le paquet est censé faire partie du _build_ (la construction) de **production**, ou qu'il est purement destiné au **développement**.

- `npm install` (ou `npm i`) est la manière standard (et par défaut) d'ajouter un paquet à un projet.
- `npm install --save-dev` (ou `npm i -D`) ajoute uniquement le paquet à vos "dépendances de développement", ce qui signifie qu'il ne sera installé que lors du développement du projet, et non lors de la construction de la version de production finalisée du projet.

Les paquets installés comme 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 existe un dernier drapeau qui mérite d'être connu : `npm install --global` (ou `npm i -g`). Il s'agit de l'installation globale d'un paquet, comme nous l'avons évoqué un peu plus tôt lors de l'installation de Sass. Vous pouvez l'utiliser si, par exemple, vous voulez pouvoir exécuter sass n'importe où sur votre machine. D'autres cas d'utilisation courants pour une installation globale pourraient inclure des outils CLI que vous voudriez utiliser partout, ou même un autre gestionnaire de paquets, comme [Yarn](https://yarnpkg.com/).

### Prochaines étapes

Nous approchons de la fin de notre voyage&nbsp;! 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. Disons que vous héritez d'un projet qui utilise npm. Par où commencez-vous&nbsp;? Comment vous assurer que vous collaborez avec les autres de manière cohérente&nbsp;? C'est l'objet de la dernière section de ce guide npm.

<div class="button-container button-block">
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-6-package-installer-paquets">← Chapitre 7</a></div>
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-8-installer-projet">Chapitre 9 →</a></div>
</div>


NPM : comment fonctionnent les commandes npm ?


À ce stade, nous avons obtenu un bon aperçu du fonctionnement de npm et de la façon de l'utiliser pour installer des paquets et exécuter des commandes. 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. Le plus souvent, c'est ce que vous ferez. 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 allons couvrir dans ce dernier chapitre du guide de npm, et je m'appuierai sur mon expérience personnelle sur un de mes projets réels.

## Table des matières <small>(rappel)</small>

<div class="toc">

- [À qui s'adresse ce guide ?](/articles/npm-guide-complet-pour-le-debutant)
- [Que signifie le mot "npm" ?](/articles/npm-guide-1-npm)
- [Qu'est-ce que la ligne de commande ?](/articles/npm-guide-2-cli)
- [Qu'est-ce que Node ?](/articles/npm-guide-3-node)
- [Qu'est-ce qu'un gestionnaire de paquets ?](/articles/npm-guide-4-gestionnaire-de-paquets)
- [Comment installer npm ?](/articles/npm-guide-5-installer-npm)
- [Comment installer les paquets npm ?](/articles/npm-guide-6-package-installer-paquets)
- [Que sont les commandes npm ?](/articles/npm-guide-7-commandes)
- [Comment installer un projet npm existant ?](/articles/npm-guide-8-installer-projet) ← **_vous êtes ici_** 🎉🎉🎉

</div>

## Voici un projet npm de la vie réelle

Le projet que j'ai choisi pour cela est mon propre [starter de blog statique SvelteKit](https://github.com/josh-collinsworth/sveltekit-blog-starter). Je pense que c'est un bon exemple car il est livré avec de nombreux paquets préinstallés qui sont parfaits pour la démonstration.

Il s'agit d'un projet réel conçu pour vous donner —&nbsp;comme vous l'avez peut-être deviné d'après son nom&nbsp;— une longueur d'avance sur la construction d'un site de blog généré de manière statique. (Le terme "statiquement généré" signifie que notre code sera compilé en fichiers .html, prêts à être déployés partout sur le Web. C'est l'une des quelques approches englobées dans [la manière "Jamstack" de construire des sites](https://css-tricks.com/what-makes-a-site-jamstack/)).

Et ne vous inquiétez pas si vous ne savez rien de [SvelteKit](https://kit.svelte.dev/) —&nbsp;il s'agit juste d'une démonstration, et nous n'écrirons rien que vous ne sachiez déjà. Cela dit, il est bon de noter que SvelteKit utilise [Vite](https://vitejs.dev/) sous le capot, qui est en fait un [paquet npm](https://www.npmjs.com/package/vite) qui nous donne accès à des outils de construction modernes et à un serveur de développement super rapide.

### Cloner le projet

Tout d'abord, nous devons "cloner" le projet, ce qui est un mot fantaisiste pour copier le projet sur notre système afin que nous puissions travailler dessus localement. Il existe deux façons de cloner un projet existant.

Si vous préférez la méthode visuelle dans le navigateur, rendez-vous sur le [dépôt de démarrage](https://github.com/josh-collinsworth/sveltekit-blog-starter) 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 le ZIP".

<figure><img src="/images/download-zip.webp" alt="on peut cliquer sur 'download zip' pour télécharger un fichier du projet"/></figure>

Sinon, si vous préférez utiliser la ligne de commande à la place, exécutez cette commande (assurez-vous simplement d'être 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`) :

```bash
npx degit https://github.com/josh-collinsworth/sveltekit-blog-starter.git sveltekit-blog-starter
```

Vous vous souvenez peut-être que `npx` nous permet d'exécuter des paquets npm sans les installer de façon permanente. degit clone le projet comme le ferait `git clone`, mais sans son historique Git (littéralement, "de-git").

Quelle que soit la méthode utilisée, vous obtenez un tout nouveau dossier sveltekit-blog-starter. Ouvrons-le dans un éditeur de code, ouvrons le terminal et exécutons la commande `npm install` (ou `npm i`).

<figure role="group"><img src="/images/audit-on-install.webp" alt=""/><figcaption>npm exécute automatiquement un audit lorsqu'il installe les paquets.</figcaption></figure>

À ce stade, vous verrez une note sur les vulnérabilités, comme nous l'avons abordé dans la dernière section de ce guide. Elle peut indiquer quelque chose comme "trouvé 0 vulnérabilité" (comme dans la capture d'écran ci-dessus), mais il est fort 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 les ignorer pour l'instant puisqu'il ne s'agit pas d'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 l'audit npm dans un chapitre précédent pour plus d'informations).

### Démarrer le serveur et effectuer des modifications

Si vous jetez un coup d'œil à l'intérieur du fichier package.json du projet cloné, vous verrez la commande permettant de démarrer le serveur de développement :

```bash
npm run dev
```

Exécutez cette commande dans le terminal et vous devriez voir quelque chose comme ce qui suit presque immédiatement :

<figure><img src="/images/npm-run-dev.webp" alt="svelte envoie quelques informations (version, adresse du dev local)"/></figure>

Dans VS Code, vous pouvez appuyer sur CMD tout en cliquant sur l'URL `http://localhost:3000`, ou vous pouvez la saisir manuellement dans votre navigateur. Dans tous les cas, le site devrait s'afficher dans le navigateur&nbsp;!

<figure><img src="/images/awesome-blog.webp" alt="image d'une jolie page d'accueil de blog"/></figure>

**Prenons un instant pour apprécier à quel point cela a été relativement rapide et simple&nbsp;!** Oui, nous avons peut-être dû installer d'abord un tas d'échafaudages, mais c'est un coût initial et unique. Nous avons un projet entier fonctionnant sur notre machine avec seulement quelques commandes —&nbsp;et nous pouvons faire la même chose chaque fois que nous voulons installer un autre projet existant&nbsp;!

Je n'entrerai pas dans les détails de ce projet particulier car il n'est pas important pour l'apprentissage de npm, mais c'est un bon exemple car il a beaucoup de choses sympas préconfigurées, et nous pouvons facilement faire des changements et les voir se mettre à jour immédiatement dans le navigateur. Examinons maintenant quelques-unes de ces commandes.

SvelteKit nécessite Node 14 ou plus. Si vous avez installé npm dans le cadre de ce guide, cela ne sera pas un problème pour vous. 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 de faire un rapide `node -v` pour être sûr. nvm est votre ami si vous devez faire une mise à jour.

### Compilation automatique de Sass à la sauvegarde

Vous pouvez trouver les fichiers Sass du projet dans le dossier `src/lib/assets/scss/`. Essayez d'ouvrir directement le fichier `global.scss`. Apportez une modification, enregistrez-la, et vous devriez voir la mise à jour automatiquement (et presque _instantanément_) dans votre navigateur.

<figure><img src="/images/compile-on-save.webp" alt=""/></figure>

### Apporter des modifications au contenu

Le site de démarrage utilise en fait le fichier `README.md` du repo comme page d'accueil. Si vous ouvrez le fichier `README.md` et commencez à apporter des modifications (ce n'est pas grave si vous ne connaissez pas le format [Markdown](https://css-tricks.com/little-stuff-markdown-always-forget-google/), n'importe quelle édition fera l'affaire), vous devriez également voir ces modifications s'afficher dès que vous enregistrez, tout comme Sass l'a fait à la dernière étape&nbsp;:

<figure><img src="/images/make-content-change.webp" alt=""/></figure>

Si vous le souhaitez, vous pouvez ouvrir une autre page, disons le fichier `src/routes/contact.svelte`, et mettre à jour le HTML pour le voir s'actualiser en direct dans votre navigateur également dès qu'il est enregistré.

Vous pouvez même dupliquer l'un des fichiers Markdown à l'intérieur de `src/lib/posts/` et effectuer des modifications pour qu'il apparaisse automatiquement dans la liste des articles de la page `/blog`, si vous voulez aller aussi loin. (Veillez simplement à lui donner un titre unique).

### Comprendre les importations

Il y a une chose importante concernant les projets npm que nous avons brièvement mentionnée dans le quatrième chapitre, mais que nous n'avons pas encore couverte&nbsp;: les importations. Ce guide ne serait pas vraiment complet si nous n'en parlions pas. L'idée de base est que nous &nbsp;comme son nom l'indique&nbsp;— importer un paquet dans notre code, et l'utiliser sur place.

Comment&nbsp;? Ouvrez le dossier `svelte.config.js` à la racine du projet, et vous verrez un bloc de lignes d'importation en haut, quelque chose comme ceci&nbsp;:

```js
import adapter from '@sveltejs/adapter-static'
import { mdsvex } from 'mdsvex'
import preprocess from 'svelte-preprocess'
import rehypeAutolinkHeadings from 'rehype-autolink-headings'
import rehypeSlug from 'rehype-slug'
```

Chacun de ces imports est un paquet installé utilisé dans ce fichier. Ce que fait réellement chaque paquet n'est pas important pour le moment&nbsp;; je veux juste attirer votre attention sur la syntaxe d'importation. _C'est ainsi que nous utilisons les packages dans nos fichiers de code réels_&nbsp;; nous indiquons à JavaScript *ce qu'*il faut importer et _depuis où_. Ensuite, nous pouvons l'appeler dans notre code.

Cette syntaxe est appelée "ES6 imports", qu'il est important de connaître car il s'agit de la norme que JavaScript navigateur et Node JavaScript ont convenu d'utiliser à l'avenir.

Auparavant, Node JavaScript utilisait (et utilise encore souvent) une syntaxe légèrement différente appelée CommonJS. Si vous voyez une importation qui ressemble à ceci, c'est l'ancien style CommonJS :

```js
const myPackage = require('package-name')
```

L'autre chose cruciale à comprendre à propos du style d'importation ES6 est la suivante : **la syntaxe est spécifique à npm, ce n'est pas une norme de langage**.

Pour être clair : [vous pouvez utiliser `import` dans du JavaScript normal](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Statements/import). Il s'agit d'une fonctionnalité très ordinaire du langage permettant d'exporter une variable, une fonction, un objet, etc. d'un fichier et de l'importer pour l'utiliser dans un autre. Mais pour ce faire, vous devez fournir un chemin relatif ou (dans les navigateurs plus modernes) une URL vers ce que vous importez. La simple utilisation d'une chaîne avec le slug d'un paquet, comme nous le voyons ici, n'est pas valide.

Alors pourquoi l'utiliser si ce n'est pas un code techniquement valide&nbsp;? Eh bien parce que la gestion de ce style d'importation est l'une des choses agréables que npm fait pour nous. Lorsque nous demandons à npm `import somePackage from 'name'` sous la forme d'une chaîne de caractères sans chemin d'accès, npm sait automatiquement qu'il doit rechercher les paquets 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 de devoir savoir où se trouvent nos paquets dans le labyrinthe des node_modules.

Cela va peut-être sans dire, mais : puisque la syntaxe n'est pas valide, vous ne pourrez pas l'utiliser avec succès à moins que votre projet npm ne comprenne un bundler ou un compilateur quelconque, pour traiter les importations et les modules en code de navigateur valide.

### Construction du site final

La plupart des projets npm comme celui-ci ont deux objectifs principaux&nbsp;:

1. Vous aider à développer votre site ou votre application
2. Construire 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&nbsp;:

```bash
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 commande de construction (_build_), SvelteKit passe en revue tous les fichiers du projet et produit un ensemble de fichiers HTML, CSS et JavaScript statiques, prêts à être déployés, et ce, assez rapidement. Vous pouvez télécharger cette collection de fichiers partout où vous pouvez héberger un site Web. **Outil moderne&nbsp;; bon vieux résultat**.

Lorsque la commande de construction se termine, vous devriez voir un nouveau dossier de construction à 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 HTML, CSS et JavaScript purs, sans oublier —&nbsp;comme vous le verrez si vous ouvrez un fichier JavaScript ou CSS&nbsp;— qu'ils sont minutieusement minifiés pour être _aussi petits_ que possible et se charger dans le navigateur _aussi vite_ que possible.

Si vous le souhaitez, vous pouvez exécuter `npm run preview` une fois la compilation 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 dossier de construction final, plutôt que d'être construit à la volée avec des fichiers précompilés comme ce serait le cas en utilisant la commande dev. 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 qu'il est assez cool de se faire une idée du peu de fichiers compilés avec lesquels nous nous retrouvons, compte tenu de tous les fichiers divers que nous avons mis dans le projet, et de la petite taille du paquet final, grâce aux incroyables outils de construction intégrés dans ce projet. (Pour mémoire, il s'agit de SvelteKit et Vite).

### Pratiques de déploiement modernes

C'est un sujet pour une autre fois, mais le déploiement moderne ne nécessite souvent pas que vous exécutiez une commande de _build_ et que vous téléchargiez les fichiers vous-même (bien que ce soit toujours une option). Au lieu de cela, un hôte (comme [Netlify](https://www.netlify.com/) ou [Vercel](https://vercel.com/)) se connecte directement au dépôt GitHub de votre projet et, chaque fois que vous apportez des modifications à la branche principale du dépôt, l'hôte exécute votre commande de construction pour vous et déploie les fichiers compilés automatiquement&nbsp;!

C'est l'une des nombreuses fonctionnalités extrêmement agréables de cette nouvelle ère du développement frontal. Pas besoin de s'embêter avec le FTP ou de faire glisser manuellement des fichiers n'importe où&nbsp;; nous sommes sûrs que tout est construit et déployé automatiquement lorsque nous poussons notre code, sans que nous ayons besoin de faire quoi que ce soit&nbsp;!

### Conclusion de ce guide npm

Si vous êtes arrivé jusqu'ici, félicitations&nbsp;! Et merci à vous. Félicitations, car la lecture de ce guide a été _longue, très longue_. Et merci, parce que... eh bien, c'était une _longue, longue_ lecture.

Mais vous avez réussi, et j'espère que vous avez aussi 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 de choses_. Nous avons commencé par un [bref aperçu de npm](/articles/npm-guide-1-npm) et de sa place dans le paysage moderne du développement front-end avant de nous [familiariser avec la ligne de commande](/articles/npm-guide-2-cli). À partir de là, nous avons décomposé les termes ["Node"](/articles/npm-guide-3-node) et ["gestionnaire de paquets"](/articles/npm-guide-4-gestionnaire-de-paquets) pour obtenir 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 paquets dans le développement, nous avons plongé directement dans npm, y compris [comment l'installer](/articles/npm-guide-5-installer-npm), [ajouter des paquets](/articles/npm-guide-6-package-installer-paquets) à un projet, [configurer des commandes](/articles/npm-guide-7-commandes), et enfin, comment [sauter dans un projet existant](/articles/npm-guide-8-installer-projet) qui utilise npm.

J'espère que tout ce que nous avons abordé dans ce guide npm vous ouvre au moins suffisamment la porte pour que vous puissiez explorer npm plus avant et passer au niveau supérieur lorsque vous serez prêt. Il faut souvent que je répète quelque chose plusieurs fois et que j'essaie de multiples approches pour que quelque chose s'imprègne vraiment. Donc, si vous êtes assis là à vous sentir presque aussi confus que vous l'étiez avant, prenez un peu plus de temps sur ce sujet. Réfléchissez à ce que vous savez et à ce que vous avez appris, et revenez —&nbsp;ou essayez une nouvelle approche lorsque vous serez prêt&nbsp;!

<div class="button-container button-block">
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-7-commandes">← Chapitre 8</a></div>
</div>


NPM : comment installer un projet npm existant ?


Je me souviens parfaitement du moment, au début de ma carrière de développeur, où j'ai commencé à percevoir que les choses s'éloignaient de ce que je connaissais, pour se diriger vers un ensemble plus complexe d'outils et de pratiques, ancrés dans la ligne de commande et quelque chose appelé [npm](https://www.npmjs.com/).

Voici la première partie d'un **guide du débutant** où nous couvrons le vaste sujet de **Node Package Manager**, ou npm. Nous prenons souvent pour acquis ces trois petites lettres —&nbsp;npm&nbsp;— lorsque nous les tapons dans la ligne de commande, mais npm fait partie d'un écosystème beaucoup plus vaste qui pourrait sembler intimidant ou déroutant pour quiconque s'y lance pour la première fois. Ce guide contribuera à démystifier cet écosystème et vous aidera non seulement à comprendre ce qu'est npm et ce qu'il fait, mais aussi à vous sentir à l'aise pour travailler avec lui.

## Table des matières

<div class="toc">

- [À qui s'adresse ce guide ?](/articles/npm-guide-complet-pour-le-debutant)
- [Que signifie le mot "npm" ?](/articles/npm-guide-1-npm)
- [Qu'est-ce que la ligne de commande ?](/articles/npm-guide-2-cli)
- [Qu'est-ce que Node ?](/articles/npm-guide-3-node)
- [Qu'est-ce qu'un gestionnaire de paquets ?](/articles/npm-guide-4-gestionnaire-de-paquets)
- [Comment installer npm ?](/articles/npm-guide-5-installer-npm)
- [Comment installer les paquets npm ?](/articles/npm-guide-6-package-installer-paquets)
- [Que sont les commandes npm ?](/articles/npm-guide-7-commandes)
- [Comment installer un projet npm existant ?](/articles/npm-guide-8-installer-projet)

</div>

Le développement moderne "[back-of-the-front-end](https://css-tricks.com/front-of-the-front-back-of-the-front/)" —&nbsp;dont npm fait partie&nbsp;— semble complexe car il s'appuie sur de nombreux outils interconnectés. Si vous ajoutez à cela le fait que le monde du front-end _semble_ évoluer beaucoup plus vite qu'il ne le fait en réalité, on a l'impression qu'on sera bientôt largué si l'on ne saute pas tout de suite sur la dernière nouveauté.

C'est pourquoi nous avons créé ce guide —&nbsp;pour rendre la technologie plus accessible et vous permettre de l'utiliser dans votre propre travail.

### À qui s'adresse ce guide ?

Dans mon propre parcours d'apprentissage du dev, je lisais des guides sur des technologies qui me passionnaient, puis j'arrivais à une partie qui disait "il suffit d'installer npm" ceci ou cela, et je poussais un soupir et j'abandonnais l'idée d'utiliser cet outil qui avait l'air si cool. Ou, lors de journées plus aventureuses, je copiais la commande, mais je me retrouvais inévitablement à une autre étape que je n'avais pas comprise ("il suffit", disaient-ils toujours, "de faire [une chose dont je n'avais aucune idée]"), ou je recevais un message d'erreur que le guide n'expliquait pas et qui m'arrêtait net.

**Peu importe ce qu'était npm, ce que faisaient ces commandes et où vous étiez censé les taper, personne n'avait jamais pris le temps de me l'expliquer**. Et plus je lisais des guides écrits par des personnes qui considéraient ces connaissances comme acquises, plus je me sentais isolé.

**_Si tout cela vous semble familier : cette série est pour vous_**.

Vous faites très probablement partie du groupe que l'on a décrit ces dernières années comme le "[front du front-end](https://bradfrost.com/blog/post/front-of-the-front-end-and-back-of-the-front-end-web-development/)". Comme moi, vous connaissez probablement bien votre affaire en matière de HTML et de CSS. Vous connaissez peut-être aussi un peu de JavaScript, soit le JavaScript "classique", soit jQuery. L'un ou l'autre est parfait, à la fois pour les besoins de cet article et en général.

Vous avez peut-être même essayé un framework comme React ou Vue, mais vous vous êtes surtout contenté de copier et coller des éléments pour lancer votre projet, sans savoir exactement ce qu'ils faisaient.

**Ce billet est pour vous** si vous sentez [le grand fossé](https://css-tricks.com/the-great-divide/) entre les définitions plus traditionnelles et "modernes" du développement front —&nbsp;et si vous craignez de nuire à votre carrière si vous ne comblez pas ce gouffre.  
**Ce billet est pour vous** si vous n'êtes pas vraiment sûr de savoir à quoi rime toute cette agitation autour des terminaux et des lignes de commande, et que vous préféreriez de loin ne jamais en toucher un du tout.  
**Ce billet est pour vous** si vous vous demandez pourquoi les autres développeurs semblent aimer _rendre les choses si compliquées_, et quel est l'intérêt de toutes ces lignes de commande, alors que vous pourriez simplement écrire du HTML, du CSS et du JavaScript à la place.  
**Ce billet est pour vous** si vous vous sentez exclu. Si vous avez l'impression qu'il y a une chose, _une chose vraiment importante_, que personne n'a jamais pris la peine de vous expliquer, et que vous avez peur d'être le seul à ne pas comprendre.  
Sachez ceci, ami développeur front&nbsp;: **vous n'êtes pas seul**. Vous êtes loin de l'être. Vous êtes exactement là où j'étais il n'y a pas si longtemps, et le souvenir troublant de cet endroit est encore frais dans mon esprit.

Laissez-moi essayer de répondre aux questions que vous vous posez probablement —&nbsp;les mêmes que j'avais&nbsp;— de la manière dont j'aurais aimé que quelqu'un le fasse pour moi, avant même que je sache comment les poser.

### Ce qui est couvert dans ce guide

Ce guide est une série d'articles. Non que ce sujet soit difficile à comprendre, mais parce qu'il comporte de nombreuses parties, et que chacune mérite une explication à part entière. C'est un vaste territoire avec de nombreux trous de lapin à explorer. En nous concentrant sur une étape à la fois, nous pouvons consacrer du temps à rendre les choses claires et compréhensibles. L'objectif n'est pas de tout couvrir, mais je veux être plus complet que rapide.

Nous commencerons par parler de la situation actuelle, de ce qu'est npm, d'où il vient et comment nous en sommes arrivés là. À partir de là, nous couvrirons ce qu'est Node, puis ce que sont les gestionnaires de paquets en général, avant de travailler réellement avec npm. Nous terminerons par l'installation de Node et de npm, l'initialisation d'un projet pour avoir une idée de son fonctionnement, et enfin, l'installation d'un projet npm réel depuis GitHub avec tous ses paquets et commandes.

Une partie (ou la totalité) de tout cela peut sembler très intimidant pour le moment, mais ne vous inquiétez pas. C'est pourquoi nous consacrons ensemble la durée d'un guide entier.

### Ce qu'il faut savoir avant de commencer

Je vais faire de mon mieux pour supposer le moins possible à votre sujet, au-delà du fait que vous êtes un développeur Web qui sait généralement comment construire 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 il sera certainement utile que vous ayez au moins une compréhension de base 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, il peut être utile de jeter un coup d'œil à [ce guide sur JSON](https://www.w3schools.com/whatis/whatis_json.asp), (NdT : et/ou à [celui-ci en français](/articles/json-pour-les-debutants)) ou du moins de le préparer pour le moment où nous arriverons à cette partie.

En outre, il se peut que je fasse référence à des outils, projets et frameworks spécifiques tels que [Bootstrap](https://getbootstrap.com/), [React](https://reactjs.org/), [Vue](https://vuejs.org/) et [SvelteKit](https://kit.svelte.dev/), mais je ne supposerai pas que vous ayez une quelconque expérience pratique de ces outils, ni que vous ayez déjà utilisé npm ou la ligne de commande.

Prêt à commencer&nbsp;? Commençons par clarifier ce que nous entendons par "npm", c'est-à-dire ce qu'il représente et comment il s'intègre au développement Web moderne.

<div class="button-container button-block">
<div class="wp-block-button"><a class="button-block_link" href="/articles/npm-guide-1-npm">Chapitre 2 →</a></div>
</div>


NPM, un guide complet pour le débutant

Un guide visuel des références en JavaScript


Il est très facile de surligner les rangées d’un tableau en CSS. `tr:hover { background: yellow; }` fait ça très bien. Mais surligner les colonnes est déjà plus difficile, parce qu’il n’y a pas d’élément HTML unique qui serait le parent des cellules d’un tableau dans une colonne donnée. Une [petite touche de JavaScript](http://css-tricks.com/row-and-column-highlighting/) pourrait faire l’affaire, mais Andrew Howe mais envoyé un mail dernièrement pour partager une astuce qu’il avait trouvée sur [StackOverflow](http://stackoverflow.com/questions/848840/cols-colgroups-and-css-hover-psuedoclass/11175979#11175979), envoyée par [Matt Walton](http://thinkingstiff.com/). Elle avait déjà quelques années, alors je me suis dit que je pourrais la mettre à jour et vous la livrer.

## L’astuce : des pseudo-éléments géants sur les td, et overflow hidden

CSS ne nous permet pas vraiment de connaître les dimensions du tableau, donc on crée des [pseudo-éléments](/articles/combinateurs-et-pseudo-classes-css/#lespseudoelements) super grands avec une valeur de `top` négative de la moitié, comme ceci&nbsp;:

    //CSS
    table {
      overflow: hidden;
    }

    tr:hover {
      background-color: #ffa;
    }

    td:hover::after,
    th:hover::after {
      content: "";
      position: absolute;
      background-color: #ffa;
      left: 0;
      top: -5000px;
      height: 10000px;
      width: 100%;
      z-index: -1;
    }

Le `z-index` négatif le cache en-dessous du contenu. Un [z-index](/articles/comment-fonctionne-z-index/) négatif est une astuce sympa, mais prenez garde de ne pas imbriquer ce tableau à l’intérieur d’autres éléments comportant un background, sinon le surlignage se trouvera caché en-dessous.

Vous pouvez le voir en action (survolez le tableau)&nbsp;:

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_pvwmaR" src="//codepen.io/chriscoyier/embed/pvwmaR?height=300&amp;theme-id=light&amp;slug-hash=pvwmaR&amp;user=chriscoyier&amp;default-tab=result" scrolling="no" frameborder="0" height="380" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="http://codepen.io/chriscoyier/pen/pvwmaR/">
  Row and Column Highlighting with CSS Only</a> de Chris Coyier dans <a href="https://codepen.io">CodePen</a></span>
</div>

## Fonctionnement avec touch

Les [pseudo-classes](/articles/combinateurs-et-pseudo-classes-css/#lespseudoclasses) comme `:hover` fonctionnent plus ou moins sur les terminaux tactiles. Tout d’abord, l’élément doit être focusable, ce qui n’est pas le cas des cellules d’un tableau par défaut. On pourrait certainement ajouter un [event handler](http://en.wikipedia.org/wiki/Event_%28computing%29#Event_handler) pour les clics sur les cellules du tableau, et tout faire en JavaScript, mais voici une méthode qui permet de faire l’essentiel du travail en CSS&nbsp;:

    //jQuery

    // Whatever kind of mobile test you wanna do.
    if (screen.width < 500) {

      // :hover will trigger also once the cells are focusable
      // you can use this class to separate things
      $("body").addClass("nohover");

      // Make all the cells focusable
      $("td, th")
        .attr("tabindex", "1")
        // When they are tapped, focus them
        .on("touchstart", function() {
          $(this).focus();
        });

    }

Puis dans le CSS vous ajoutez des styles pour `:focus`.

    //CSS

    td:focus::after,
    th:focus::after {
      content: ’’;
      background-color: lightblue;
      position: absolute;
      left: 0;
      height: 10000px;
      top: -5000px;
      width: 100%;
      z-index: -1;
    }

    td:focus::before {
      background-color: lightblue;
      content: ’’;
      height: 100%;
      top: 0;
      left: -5000px;
      position: absolute;
      width: 10000px;
      z-index: -1;
    }

Dans la démo finale, je développe un peu les sélecteurs CSS pour m’assurer que les cellules vides ne déclenchent rien, que les titres de colonnes dans `<thead>` ne sélectionnent que les colonnes et que les titres de rangées dans `<tbody>` ne sélectionnent que les rangées.

Vous pouvez le voir dans la [démo finale](http://codepen.io/chriscoyier/pen/pvwmaR). Et ci-dessous un touch qui fonctionne&nbsp;:

<figure role="group"><img itemprop="url" src="/images/touch-cells-compressor.gif" width="637" height="483" alt=""/></figure>


La Cascade

javascript

Ressources complémentaires en français

Ressources complémentaires en anglais