Aller au contenu
Accueil / NVM, pour bien commencer la journée

NVM, pour bien commencer la journée

nvm

NVM sert à faire coexister plusieurs version de NodeJS sur un même poste informatique. Ça peut être utile quand on a des projets qui ne fonctionnent pas tous sur la même version, ou pour faire des tests.

Node.js® permet en effet d’utiliser du JavaScript hors du navigateur. Il est indispensable pour développer avec des frameworks JS, que ce soit en front-end (React, Vue, Angular, Svelte…) ou en back-end (Express, Nest…).

Récemment, j’ai eu le cas quand j’ai voulu tester Vite, qui ne marchait pas avec l’unique version de Node alors installée sur mon poste. J’ai donc du faire évoluer ma version de Node. Sauf qu’avec Node, il n’est pas question d’un simple upgrade comme avec la plupart des logiciels.

Au sommaire :

Faire coexister plusieurs version de NodeJS sur un même poste

1- Installer NVM

Avec Linux, l’installation de logiciels se fait le plus souvent dans le terminal en ligne de commande (bash dans mon cas) :

franck@franck-tux $ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh
franck@franck-tux $ source ~/.bashrc

Il est recommandé auparavant de supprimer toutes les versions de Node que notre ordinateur peut comporter. Pour ma part, j’ai laissé ma v14.17.6 historique, et elle a très bien été prise en compte par le manager.

↑ — Revenir au sommaire

2- Installer une nouvelle version de Node

Lister les versions qu’on a déjà en local

nvm list

Lister les versions qui existent pour en choisir une

nvm list-remote

Installer une nouvelle version

nvm install v18.12.1

Vérifier la version en cours

nvm list
# ou
node –version

Exemples illustrés :

↑ — Revenir au sommaire

3- Switch ponctuel d’une version à l’autre

3.1- Une nouvelle version de Node

Exemple : J’avais la v14.17.6 et j’ai installé la v18.12.1 pour faire fonctionner Vite + React

Vite avec Node 14.17.6 :

L’agaçant localhost n’autorise pas la connexion est le signe que la version de Node n’est pas adaptée, ce que confirme le message dans la console

Vite avec Node 18 :

Avec Node 18, Vite + React fonctionne parfaitement

↑ — Revenir au sommaire

3.2- L’impact d’un changement de version de Node

Mon projet sur le cinéma des origines, sur lequel je travaille actuellement, fonctionne avec les deux versions de Node, 14 et 18 : pas d’impact.

Un projet indifférent à la version de Node

En revanche, les cours de Mike Codeur que je suis également en ce moment sont optimisés pour les versions 12, 14, 15 et 16 mais pas au delà (React Mastery). Donc ils ne marchaient plus sous Node 18. Allais-je devoir choisir entre Mike et Vite?

Sous Node 18, plus possible d’accéder au cours

↑ — Revenir au sommaire

3.3- Bascule entre versions de Node

En plus des deux autres versions déjà installées, j’ai donc ajouté la v16.14.0, qui semblait un bon compromis pour tout faire fonctionner. Malheureusement, après son installation, elle n’a pas pris l’ascendant. C’est la v18.12.1 qui restait prioritaire. En effet, quand on installe une version, elle ne devient pas nécessairement celle en cours. Par défaut, la version la plus récente a le dessus.

Trois versions de Node, mais la 18 reste la version par défaut au lieu de la dernière installé, la 16

Pour forcer le système à passer ponctuellement à la v16.14.0 on fait

nvm use 16.14.0

(et généralement nvm list avant car je ne mémorise toujours pas “16.14.0”):

On a switché sur la v16 !

↑ — Revenir au sommaire

4- Automatisation

4.1- Choix d’une version de Node par défaut

Sauf que le système retourne à la v18 (la version stable la plus récente) dès le démarrage suivant.

Pour rester de manière pérenne sur la v16, il faudrait en effet utiliser nvm alias :

nvm alias default 16.14.0

Mais il est quand même dommage de faire tourner tous mes projets sur la v16, alors qu’un seul le nécessite vraiment.

En savoir plus :

↑ — Revenir au sommaire

4.2- Les fichiers .nvmrc

Les cours de Mike ne sont pas optimisés pour les versions au delà de la v16. Il est donc assez gênant de devoir retaper nvm use 16.14.0 à chaque fois qu’on veut les relancer (d’autant que le lancement est très lent avec ce projet créé en CRA). Attendre de longues minutes pour finalement voir notre navigateur nous dire “localhost n’autorise pas la connexion”, parce qu’on a oublié le nvm use 16.14.0, est des plus énervants pour commencer la journée.

Mais il y a une solution : les fichier .nvmrc

Ajoutez un fichier .nvmrc à la racine de votre projet. Dans ce fichier, ajoutez la version du nœud que ce projet utilise. Dans mon cas, 16.14.0

Un fichier .nvmrc contient une seule ligne

Maintenant, lorsque vous ouvrez le projet dans votre éditeur préféré, vous pouvez exécuter la commande nvm use, et il utilisera la version définie dans le fichier .nvmrc.

franck@franck-tux $ nvm use
Found ‘…ClonesCoursMastery/05react-hooks/.nvmrc’ with version <16.14.0>
Now using node v16.14.0 (npm v8.3.1)

Bon. Ça évite de devoir rechercher le numéro de version précis via un nvm list.

Mais il faut toujours taper nvm use avant npm start si on ne veut pas encore tomber sur l’énervant “localhost n’autorise pas la connexion”

Je pourrais aussi ajouter une ligne dans package.json. Mais c’est délicat dans la mesure où je partage de nombreux projets sur Github, et que je ne peux pas prévoir de quelle(s) version(s) sont équipés les éventuels utilisateurs.

En savoir plus :

↑ — Revenir au sommaire

4.3- L’extension VSCode nvm integration

Heureusement est arrivé… un excellent plugin de VS Code qui lance pour moi nvm use puis la version de Node indiquée dans le .nvmrc, à chaque fois que j’ouvre un projet ! Voila la solution pour bien démarrer la journée !

La solution pour bien démarrer la journée !

Maintenant, quand je lance les cours de Mike, tout est automatisé. Plus de risque d’utiliser une mauvaise version de Node :

et plus de risque d’avoir le désagréable localhost n’autorise pas la connexion dès le début de la journée

↑ — Revenir au sommaire

5- Désinstaller une version

J’ai donc à ce jour 3 versions de Node sur mon poste Ubuntu. La 18 est celle qui tourne par défaut, tandis que j’ai automatisé le switch vers la 16 pour les cours de Mike. Et je peux changer tout ça quand bon me semblera :

Ubuntu 22.04.1 LTS
git --version   --> 2.34.1
node --version  --> 18.12.1 (16.14.0 pour React Mastery)
npm --version   --> 8.19.2 (8.3.1 pour React Mastery)
npm view react version   --> 18.2.0
On peut travailler en même temps sur deux projets ayant une version de Node différente !

Cependant, avec le temps et le glissement des versions, il arrivera un moment où certaines versions de Node n’auront plus aucune pertinence dans mon cocktail. Il sera alors temps de faire un peu de ménage :

nvm uninstall 14.17.6

Actuellement, la v19 arrive en fin de vie et la v14 passe en maintenance. Il est donc grand temps d’upgrader les projets codés en v14 vers la v18 ou la v20, les current du moment !

↑ — Revenir au sommaire

6- Mises à jour intermédiaires

6.1- Pour npm

Récemment, j’ai eu un message m’enjoignant de changer de version de NPM :

npm notice New patch version of npm available! 9.6.1 -> 9.6.6
npm notice Changelog: https://github.com/npm/cli/releases/tag/v9.6.6
npm notice Run npm install -g npm@9.6.6 to update!

J’ai donc installé cette nouvelle version de npm indépendamment de ma version de Node (18.2.1) :

npm --version   --> 9.6.6

6.2- Pour Node

L’équipe de Node livre des versions corrigeant les failles de sécurité aussitôt qu’elle le peut. Que faire si une faille de sécurité affecte la version de Node installée sur :

  • votre ordinateur de développement : c’est peu risqué, sauf si un module tiers l’exploite ;
  • votre site web : redéployez aussitôt le site en question avec une version corrigeant la faille (VPS).

Les versions de Node qui corrigent des failles de sécurité ou des bogues connus n’ont quasiment aucun risque de casser une application existante. On les appelle les versions patch. Elles sont indiquées par le troisième numéro de version : v10.0.0, v10.0.1, …

Ainsi, en juin 2023, Devtheory a relayé le message comme quoi une mise à jour de sécurité avait été mise en place concernant les versions 20.x, 18.x, 16.x et qu’il fallait d’urgence l’implémenter. On vu qu’en local c’était peu risqué. J’ai quand même voulu voir comment faire.
En fait, avec ce qu’on a déjà vu dans cet article, c’est très simple :

Lister les versions qu’on a déjà en local

nvm list

Lister les versions qui existent pour choisir la dernière d’un numéro

nvm list-remote

Installer la nouvelle version. Exemple avec la v18.12.1, à laquelle on va adjoindre la v18.16.1

nvm install v18.16.1

Après avoir vérifié que cette nouvelle 18 fonctionne bien comme l’ancienne 18, on supprime cette dernière :

nvm uninstall 18.12.1

Dans mon cas, ayant utilisé des fichiers .nvmrc dans les projets de Mike pour les forcer à fonctionner avec la v16.x, il a aussi fallu que je les modifie en remplaçant leur contenu, passant de 16.14.0 à 16.20.1
Après avoir constaté que cette v16.20.1 fonctionnait bien, j’ai pu supprimer la v16.14.0

Ce qui me fait donc maintenant

Ubuntu 22.04.2 LTS 
git --version   --> 2.34.1
node --version  --> v18.16.1 (v16.20.1 pour React Mastery) 
npm --version   --> 9.6.6 (8.19.4 pour React Mastery) 
npm view react version   --> 18.2.0

↑ — Revenir au sommaire

7- Et pour Windows ?

Node Version Manager, également appelé nvm, est la méthode la plus couramment utilisée pour installer plusieurs versions de Node.js, mais elle est uniquement disponible sous Mac/Linux : elle n’est pas prise en charge par Windows.

Cependant, il existe NVM for Windows, similaire (pas identique) à NVM, mais pour Windows :

  • Gestion de plusieurs installations de node.js sur Windows
  • Bascule entre les différentes versions installées de Node.js
  • nvm-windows fonctionne dans un shell Admin
  • Écrit en Go car il est multiplateforme

Néanmoins, il peut-être intéressant de tirer parti d’une association Windows + WSL pour mettre sur pied un environnement de développement JavaScript dans lequel NVM-Windows trouvera sa place :

Nous vous recommandons d’utiliser Visual Studio Code avec le pack d’extension Remote Development pour les projets Node.js. Cela a pour effet de diviser VS Code en une architecture « client-serveur », avec le client (l’interface utilisateur VS Code) s’exécutant sur votre système d’exploitation Windows, et le serveur (votre code, Git, plug-in, etc.) s’exécutant « à distance » sur votre distribution Linux WSL.

Installer des frameworks JavaScript sur Windows

Quelques tutos utiles :

↑ — Revenir au sommaire

8- Et sur un VPS ?

Pour les projets utilisant un framework, il existe un panel de solutions d’hébergement selon qu’on a du front ou du back à mettre en ligne. Si on a les deux à la fois, il va falloir louer un serveur physique dédié ou bien un VPS (Virtual Private Server), qu’on va devoir installer de A à Z :

  • OS serveur (Ubuntu),
  • serveur web (Nginx),
  • base de données, Express, React,
  • mais aussi tous les outils gravitant autours : NodeJS, GIT, MySQL2, Argon…

En fait on recrée en ligne toute sa stack locale. Mais qu’en est-il de NVM?

Déploiement d’un site sur un VPS

Bonne nouvelle, NVM peut également être installé sur un Serveur Privé Virtuel (VPS), ce qui permet de ne plus se soucier des problèmes de compatibilité entre les projets qu’on y ajoutera au fil du temps. Voila qui est très appréciable !

↑ — Revenir au sommaire

Aller plus loin :

Lisez aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partagez
Tweetez
Partagez