‫Instructeur :
‫dans cette conférence, nous
‫allons parler d'un tas d'autres choses
‫que vous devez savoir sur l'utilisation des
‫packages npm, telles que la gestion des versions, la mise à jour ou la
‫suppression de packages, ainsi que d'autres choses, alors commençons.
‫La première chose dont je
‫veux parler dans cette vidéo, ce sont les numéros de version de nos packages.
‫La plupart des packages
‫sur npm suivent la notation dite de version sémantique,
‫ce qui signifie que leurs numéros de
‫version sont toujours exprimés avec ces trois numéros.
‫La première ici est appelée la version majeure.
‫La seconde est appelée la version mineure.
‫La troisième est appelée la version patch.
‫Il y a en fait une signification dans ces trois nombres.
‫La version patch, qui n'est que cette dernière ici,
‫n'est destinée qu'à corriger les bugs.
‫Disons que dans la version 1. Le 18, les développeurs ont trouvé un
‫bogue et ont donc corrigé ce bogue, puis
‫ont publié le 1. 18. 1.
‫Ensuite, ils ont trouvé un autre bogue, puis
‫ils en ont publié 1. 18. 2 et ainsi de
‫suite jusqu'à ce qu'ils atteignent 1. 18. 11, qui est
‫le numéro de version actuel.
‫Encore une fois, ce dernier ici est juste pour les corrections de bugs.
‫Ensuite, nous avons la version mineure.
‫La version mineure
‫introduit de nouvelles fonctionnalités dans le package,
‫mais elle n'inclut pas les modifications de rupture.
‫Toutes les modifications apportées dans un nouveau numéro
‫de version seront toujours rétrocompatibles.
‫Si un jour l'équipe nodemon, par exemple, décide
‫de sortir la version 1. 19, eh bien,
‫cela inclura alors quelques nouvelles fonctionnalités mais
‫cela ne cassera pas notre code.
‫Et la même chose se passe bien sûr avec celui-ci ici.
‫Donc si un jour, il y a Slugify 1. 4, eh bien, notre
‫code fonctionnera toujours de la même manière.
‫Il n'y aura pas de changements de rupture.
‫Il y aura simplement quelque chose de
‫nouveau, donc de nouvelles fonctionnalités, qui ne sont pas que des corrections de bugs.
‫Les corrections de bugs concernent à nouveau la
‫troisième, donc pour la version
‫de correctif, puis les nouvelles fonctionnalités mineures sont pour la version mineure.
‫Ensuite, bien sûr, nous avons la version majeure,
‫qui n'est augmentée que lorsqu'il
‫s'agit d'une énorme nouvelle version qui peut avoir des changements de rupture.
‫Par exemple, si Slugify 2 arrive.
‫Eh bien, notre code pourrait ne plus
‫fonctionner parce que la fonction slugify que nous avons
‫ici, par exemple, a peut-être changé de nom
‫ou peut-être que le paramètre qu'il attend ici est différent ou que
‫les options ont changé, ou quelque
‫chose a peut-être changé qui cassera
‫la version précédente .
‫Sachez que lorsqu'il y a une nouvelle version,
‫cela peut généralement affecter le code
‫que vous avez déjà.
‫Pour cette raison, il est également important
‫de parler de mise à jour des packages.
‫Dans notre colis. json,
‫ce petit symbole qui précède le
‫numéro de version est ce qui spécifie les
‫mises à jour que nous acceptons pour chacun des packages.
‫Ce symbole ici, que npm spécifie ici par défaut,
‫signifie que nous acceptons les correctifs et les versions mineures.
‫Maintenant, comment mettons-nous à jour les packages ?
‫Eh bien, arrêtons ce processus ici.
‫La première chose que
‫nous pouvons faire est de vérifier s'il existe des packages obsolètes.
‫Nous écrivons npm obsolète, et cela devrait alors nous donner en fait
‫un tableau avec tous
‫les packages obsolètes.
‫Eh bien en ce moment, ils sont tous à jour, donc
‫cela ne s'est pas vraiment produit.
‫Ce que je
‫veux vous montrer maintenant, c'est que nous pouvons
‫en fait installer un certain paquet avec un certain numéro de version.
‫Faisons cela avec le Slugify et installons-le
‫à la version 1. 0. 0.
‫Npm install slugify puis à 1. 0. 0.
‫Essayons ça.
‫Maintenant en effet, nous avons un zéro zéro.
‫Lorsque nous le survolons, il indique en fait
‫la dernière version 1. 3. 4, c'est ce que nous avions.
‫Mais si nous exécutons maintenant npm obsolète, cela
‫devrait alors nous donner cela.
‫On voit que le courant est 1. 0. 0.
‫Recherché est 1. 3. 4, parce que c'est
‫celui que nous acceptons car rappelez-vous qu'avec
‫cela ici, nous acceptons tous les correctifs et toutes les versions
‫mineures, mais bien sûr, nous pouvons également changer cela.
‫Par exemple, nous pouvons le définir sur ce symbole ici.
‫Cela n'acceptera alors que les versions de correctifs.
‫Celui-ci est un peu plus sûr.
‫Si nous exécutons à nouveau npm obsolète, voyons ce
‫que nous obtenons.
‫Maintenant, le recherché n'est que de 1. 0. 2, car
‫encore une fois, nous n'acceptons que les versions mineures.
‫Số 1. 3. 4 n'est
‫pas accepté par nous parce que nous
‫n'acceptons aucune des versions mineures, donc
‫encore une fois, juste des versions de correctifs.
‫Si vous deviez faire npm update slugify maintenant, voyons ce que nous avons obtenu
‫à ce moment-là.
‫Nous sommes maintenant à 1. 0. 2.
‫Vous voyez
‫qu'il a changé pour ma configuration de mise à
‫jour ici pour accepter les versions mineures et les correctifs.
‫Pas seulement les versions de correctifs comme nous l'avions auparavant.
‫Si nous devons réexécuter cela maintenant,
‫cela devrait nous faire
‫passer jusqu'à 1. 3. 4, comme avant.
‫En effet, nous y voilà.
‫Très bien, c'est ainsi que nous mettons à jour les packages.
‫Il existe d'autres configurations que
‫nous pouvons choisir ici.
‫Nous pouvons dire, par exemple, que nous voulons toutes les
‫versions, donc si à un moment donné, il y
‫a une version deux et si nous n'avons pas
‫mis à jour nos packages, cela
‫passera automatiquement notre version à la version deux.
‫Celui-ci comprend toutes les versions,
‫même celles avec des changements de rupture.
‫Mais ce n'est généralement pas une bonne idée,
‫et donc je vais généralement avec celui-ci qui est
‫par défaut, ou parfois même celui-ci ici parce qu'à un moment
‫donné, même si une version mineure devrait simplement introduire de nouvelles
‫fonctionnalités mais pas de changements de rupture,
‫nous savons que Parfois, il peut y avoir des
‫bogues que les développeurs ne trouvent pas, et puis
‫ces bogues, ils se
‫retrouvent dans notre code et peuvent casser notre code.
‫Nous ne voulons pas de cela, bien sûr.
‫La version la plus sûre consiste
‫simplement à utiliser celle-ci pour les corrections de bogues.
‫En fait, gardons-le comme ça ici, juste à
‫des fins de démonstration.
‫C'est ce que vous devez savoir sur
‫les numéros de version et la mise à jour.
‫Mais on peut bien sûr aussi supprimer des packages.
‫Allons maintenant de l'avant et installons Express, afin
‫que nous puissions ensuite continuer et le supprimer après cela.
‫Je suis sûr que vous pouvez deviner comment nous pouvons faire cela.
‫C'est très facile.
‫Npm uninstall, il ne s'appelle donc pas supprimer.
‫C'est vraiment désinstaller.
‫Nous installons et nous désinstallons Express.
‫Cela le supprimera ensuite de notre dossier
‫de modules de nœuds, ainsi que de nos
‫dépendances dans un package. fichier json.
‫Chaque fois que nous décidons de ne plus utiliser un
‫module, eh bien, nous devons toujours le
‫supprimer ou le désinstaller.
‫Maintenant, pour terminer, je veux parler
‫un peu du dossier des modules de nœud.
‫Ce dossier, qui contient
‫toutes les dépendances de notre projet.
‫Supposons que vous souhaitiez partager votre code avec
‫quelqu'un ou que vous souhaitiez, par
‫exemple, commencer à travailler sur
‫un ordinateur, puis passer au suivant.
‫Vous ne partagerez jamais ce dossier de modules de nœuds car
‫ce code, vous pouvez facilement l'obtenir à partir de npm.
‫Il n'est pas nécessaire d'aller de l'avant
‫et de copier tout ce code
‫ici, par exemple, dans un référentiel GitHub ou dans un dossier Dropbox,
‫ou vraiment quelque part où vous souhaitez partager votre code,
‫car ce dossier ici, comme
‫vous le voyez, contient des tonnes de dossiers
‫et chacun d'eux peut avoir des tonnes de fichiers.
‫Tout d'un coup, vous pourriez vous retrouver
‫avec des dizaines ou des centaines de milliers de fichiers.
‫Vous ne devez jamais partager
‫ce dossier et ne jamais l'extraire dans votre référentiel GitHub.
‫Disons que vous avez téléchargé ce code sur
‫votre compte GitHub sans ces modules de nœud, ou que
‫vous l'avez mis dans une Dropbox
‫sur un ordinateur et téléchargé sur l'autre.
‫Disons que nous avons maintenant téléchargé ce code
‫ici, donc sans modules de nœuds.
‫Nous supprimons donc celui-ci maintenant et
‫nous nous retrouvons avec juste un dossier de projet normal.
‫Comment pouvons-nous maintenant récupérer nos dépendances ou notre
‫dossier de modules de nœuds ?
‫Eh bien, c'est très facile.
‫Tout ce que nous avons à faire est d'installer npm.
‫Ce qu'il a fait, c'est lire notre paquet. json, lisez
‫nos dépendances, puis téléchargez
‫le tout dans ce dossier, d'accord.
‫Maintenant, une pièce importante de ce puzzle est
‫le verrou du paquet. fichier json.
‫Si nous ouvrons cela, nous obtenons une liste de
‫toutes les versions de tous les packages que
‫nous utilisons réellement.
‫Cela inclut les dépendances de nos dépendances.
‫Allons à Slugify, par exemple.
‫Slugify, et donc ici nous voyons que nous utilisons la
‫version 1. 3. 4.
‫C'est très important car si vous partagez
‫votre code, vous voulez que l'autre développeur ou
‫même vous-même utilise exactement les
‫mêmes versions de package, afin que votre
‫code fonctionne exactement de la même manière pour vous et
‫pour l'autre développeur.
‫Pour cela, les numéros de version exacts sont
‫fondamentalement gravés dans la pierre dans
‫ce package-lock. fichier json.
‫Si vous partagez votre code, que vous
‫utilisiez GitHub ou Dropbox ou quelque chose comme ça, partagez
‫toujours votre package. json
‫et le package-lock. json car
‫ces deux fichiers sont nécessaires
‫à l'autre développeur pour ensuite reconstruire essentiellement
‫le dossier des modules de nœud.
‫Oui, je pense que c'est tout ce
‫que vous devez savoir sur les versions de
‫package, la mise à jour, la désinstallation et également le partage de code
‫avec npm, package. json et package-lock. json.
‫S'il y a quelque chose de plus que
‫vous voulez savoir, vous pouvez toujours demander dans le cours Q et A
‫et vous obtiendrez de l'aide là-bas.