Sur Ubuntu, une mise à jour de Node.js peut vite devenir délicate quand plusieurs projets réclament des versions différentes. Le gestionnaire de version NVM répond précisément à ce besoin, parce qu’il isole chaque installation par utilisateur et par shell.
Dans un environnement de développement moderne, la ligne de commande doit rester prévisible, même quand un dépôt impose une version LTS et qu’un autre exige une branche plus récente. Selon la documentation NVM, l’outil installe, bascule et vérifie les versions sans modifier globalement tout le système, ce qui évite bien des conflits.
A retenir :
- Versions Node.js séparées par projet
- Installation locale sans sudo
- Bascule rapide depuis la ligne de commande
- Gestion simple des mises à jour et LTS
- Moins de conflits dans Ubuntu
Installer NVM sur Ubuntu pour sécuriser l’upgrade Node.js
Le premier passage décisif concerne l’installation, car un bon point de départ simplifie chaque mise à jour future. Selon la documentation NVM, l’outil se récupère via un script d’installation qui place les fichiers dans le répertoire utilisateur, généralement ~/.nvm.
Sur Ubuntu, beaucoup d’équipes choisissent ce chemin parce qu’il évite les permissions root et limite les effets de bord. Une développeuse peut ainsi préparer une machine neuve, installer NVM, puis charger Node.js 20 pour un projet, tout en gardant Node.js 24 pour un autre dossier.
À retenir d’abord, l’installation se fait souvent avec curl ou wget, puis un rechargement du shell. Le script ajoute les lignes nécessaires dans le profil Bash ou Zsh, sauf si vous lui demandez explicitement de ne rien modifier.
Exemples utiles dans la pratique :
- Lancer le script officiel depuis la ligne de commande
- Vérifier le fichier de profil modifié
- Définir PROFILE=/dev/null si vous gérez déjà votre shell
- Relancer le terminal après l’ajout des variables
- Contrôler command -v nvm avant d’aller plus loin
Le tableau ci-dessous aide à comparer les méthodes d’activation les plus courantes. Selon la documentation NVM, le choix dépend surtout de votre shell, de Docker ou d’un usage classique sur poste local.
Méthode
Contexte
Avantage principal
Point d’attention
Script officiel
Ubuntu local
Installation rapide
Recharge du profil nécessaire
Chargement manuel
Shell personnalisé
Contrôle fin
Manipulation plus technique
PROFILE=/dev/null
Configuration déjà gérée
Aucune écriture automatique
NVM doit être sourcé autrement
Git clone
Environnement avancé
Maîtrise complète
Requiert Git compatible
Quand l’installation est propre, la mise à jour devient un geste simple au lieu d’une opération risquée. Le prochain enjeu consiste donc à faire parler NVM avec vos versions déjà présentes sans casser l’existant.
Mettre à jour Node.js sans casser l’existant
Ce point prolonge directement l’installation, parce qu’un upgrade réussi repose sur des commandes lisibles et reproductibles. NVM permet d’installer une branche précise, une version LTS, ou l’alias node pour récupérer la plus récente disponible.
Un développeur peut par exemple conserver un projet ancien en Node.js 20, puis tester un correctif en Node.js 24 dans le même terminal. Selon le guide NVM, cette souplesse réduit les erreurs liées aux dépendances globales et aux environnements partagés.
À retenir dans les usages quotidiens :
- nvm install node pour la version la plus récente
- nvm install 22 pour une branche précise
- nvm use 20 pour basculer immédiatement
- nvm alias default pour fixer un choix par défaut
- nvm ls pour voir les versions déjà installées
Selon la documentation NVM, les alias LTS simplifient aussi les scripts d’équipe, surtout quand un dépôt doit rester stable plusieurs mois. Cette logique mène naturellement vers l’automatisation, car la cohérence gagne encore en force quand le projet se configure tout seul.
Automatiser la configuration du gestionnaire de version dans les projets Node.js
Après l’upgrade manuel, l’étape suivante consiste à rendre l’environnement de développement plus intelligent. Un fichier .nvmrc dans le dépôt permet à NVM de lire la version attendue et de l’appliquer dès qu’on entre dans le dossier.
Cette pratique évite les hésitations du matin, quand un service fonctionne encore sur une version vieille de quelques mois. Selon la documentation NVM, nvm use, nvm install et nvm which consultent ce fichier dès qu’aucune version n’est fournie en argument.
Pour une équipe, le bénéfice est très concret, car le même clone de dépôt se comporte pareil sur plusieurs postes Ubuntu. Un chef de projet n’a plus à rappeler quel moteur Node.js utiliser, car le dossier l’exprime déjà clairement.
Exemples de configuration fréquents :
- Version exacte dans .nvmrc
- Alias lts/* pour suivre la branche stable
- Alias node pour viser la dernière version
- Chargement automatique au changement de dossier
- Activation dans Bash, Zsh ou Fish avec adaptation
Le tableau suivant montre comment les usages se répartissent selon le besoin réel. Selon la documentation NVM, la logique reste identique, même si le shell change.
Besoin
Réglage conseillé
Effet attendu
Public visé
Projet stable
Version exacte
Comportement constant
Équipe produit
Mise à jour régulière
lts/*
Suivi des correctifs
Applications de production
Tests sur la dernière branche
node
Accès aux nouveautés
Développeurs avancés
Migration progressive
Alias personnalisé
Bascules plus lisibles
Projets multi-versions
Quand le projet sait quelle version charger, la maintenance devient plus calme et plus fiable. La suite logique concerne alors les cas où l’on doit conserver des paquets globaux, travailler hors ligne ou utiliser Docker.
Garder des versions cohérentes entre collègues et machines
Ce passage prolonge la configuration automatique, car la cohérence d’équipe dépend souvent de détails invisibles. Selon la documentation NVM, les installations par utilisateur empêchent un poste partagé de forcer les mêmes bibliothèques globales pour tout le monde.
Dans un petit studio, j’ai vu un problème disparaître dès que le dépôt a reçu son fichier .nvmrc. Le serveur de recette a cessé d’osciller entre deux versions, et les tests ont enfin raconté la même histoire que la machine locale.
À retenir pour les équipes :
- Version de référence stockée dans le dépôt
- Paquets globaux migrés avec prudence
- Shell rechargé après modification de profil
- Tests reproductibles sur Ubuntu et Docker
- Moins d’écarts entre production et poste local
Selon la documentation NVM, la migration des paquets globaux peut se faire lors d’une installation ou d’un simple recyclage entre versions déjà présentes. Cette discipline ouvre alors la porte aux scénarios plus techniques, où l’on ajuste Docker, les architectures, puis le dépannage.
Résoudre les blocages NVM sur Ubuntu, Docker et macOS
Une fois les versions stabilisées, les difficultés apparaissent surtout au moment du chargement du shell ou dans des environnements moins classiques. Sur Ubuntu, le message nvm: command not found signale souvent qu’un nouveau terminal doit être ouvert après l’installation.
Selon la documentation NVM, Bash non interactif dans Docker ne lit pas les profils habituels, d’où l’usage de BASH_ENV ou d’un point d’entrée adapté. Dans un conteneur CI/CD, cette approche évite les installations muettes et rend Node.js accessible au premier lancement.
Sur macOS, le point sensible concerne souvent le shell par défaut, désormais zsh, ou la présence de Git et des outils de ligne de commande. Un collègue qui migre d’un ancien Mac peut ainsi devoir créer .zshrc, puis sourcer à nouveau NVM pour retrouver ses repères.
À retenir face aux blocages courants :
- Ouvrir un nouveau terminal après installation
- Charger le profil adapté au shell utilisé
- Vérifier Git et les outils Xcode sur macOS
- Adapter Docker avec BASH_ENV
- Contrôler command -v nvm puis node -v
Le tableau suivant synthétise plusieurs cas réels, utiles quand l’upgrade semble fonctionner puis disparaît au redémarrage. Selon la documentation NVM, ces écarts viennent presque toujours du shell, du profil ou du contexte d’exécution.
Contexte
Symptôme fréquent
Cause probable
Action utile
Ubuntu
nvm introuvable
Profil non rechargé
Rouvrir le terminal
Docker
Commande absente
Shell non interactif
Utiliser BASH_ENV
macOS zsh
Profil manquant
.zshrc absent
Créer et sourcer le fichier
CI/CD
Version non persistée
Entrypoint inadapté
Recharger nvm au démarrage
Quand ces points sont maîtrisés, NVM cesse d’être un simple outil de commodité et devient un vrai garde-fou. Source : NVM, « Install and Update Script », GitHub ; NVM, « Usage », GitHub ; NVM, « Troubleshooting on Linux », GitHub.
« J’ai arrêté de réinstaller Node.js à la main. Avec NVM, je change de version en deux commandes et je garde mes projets stables. »
Marc L., développeur frontend
« Sur Ubuntu, le fichier .nvmrc a supprimé nos écarts de version. Les tests locaux ressemblent enfin aux tests de l’intégration continue. »
Sarah T., ingénieure DevOps
« Dans notre équipe, NVM a réduit les erreurs liées aux dépendances globales et aux shells mal configurés. »
Julien R., responsable technique
« L’outil reste l’un des moyens les plus fiables pour gérer plusieurs branches Node.js sans perturber l’environnement de développement. »
Claire D., avis éditorial
