Vuoi cambiare rapidamente versione di Node? nvm è lo strumento che fa per te.
Primi passi
Perché nvm? Node è un eseguibile. Ad esempio, sotto Linux, se hai installato il pacchetto della tua distribuzione, sarà presente in una directory del tipo /usr/local/bin.
Il problema è che questo eseguibile corrisponde a una versione data e fissa, e può essere aggiornato solo a una versione più recente dal tuo gestore di pacchetti.
nvm ti permette invece di far coesistere più versioni sulla stessa macchina.
1. Installazione
nvm dispone di diversi metodi di installazione, incluso uno script per installarlo automaticamente. Alla data di pubblicazione di questo articolo, puoi avviare (vedi
il README) :
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
Questo script installerà nvm in ~/.nvm e aggiungerà delle righe al file di configurazione della tua shell che devono essere eseguite affinché nvm possa funzionare. Per usare nvm, apri una nuova shell o esegui il comando source [file] dove [file] è lo script di configurazione della tua shell (~/.bashrc, ~/.zshrc o altro a seconda del tuo caso)
Puoi vedere l'elenco delle versioni di node disponibili per il download lanciando
nvm ls-remote
2. Utilizzo
Installeremo due versioni di node diverse :
nvm install 12.16.3
Un node -v ti indica che l'eseguibile è alla versione 12.16.3.
nvm install 14.3.0
Un node -v ti indica che l'eseguibile è alla versione 14.3.0, e se questa versione è quella di cui hai bisogno per il tuo progetto, puoi lanciarlo direttamente !
Puoi poi cambiare liberamente versione utilizzando nvm use [numero di versione].
Per capire meglio la magia dietro nvm, esploriamo la struttura della cartella di installazione.
Lo script di installazione ha clonato la directory git in ~/.nvm.
ls ~/.nvm
La cartella più importante in pratica è quella chiamata versions/node, che memorizza in cartelle diverse le versioni installate e le fa coesistere.
cd ~/.nvm/versions/node
Dovresti vedere apparire la seguente struttura :
La struttura della sottocartella `~/.nvm/versions/node`
In ogni sottocartella, c'è una directory bin che raggruppa gli eseguibili corrispondenti alla versione in questione (npm e npx sono collegamenti simbolici).
Puoi ora verificare che ./v12.16.3/bin/node -v e ./v14.3.0/bin/node -v ti diano i numeri di versione attesi.
Puoi trovare questi percorsi di installazione lanciando :
nvm which current
nvm which 12.16.3
Cambia versione ancora più velocemente
Se lavori su molti progetti e che ti perdi nei numeri di versione, i seguenti alias dovrebbero facilitarti la vita :
nvm alias project1 12.16.3
nvm alias project2 14.3.0
Puoi ora cambiare direttamente versione con nvm use project1 e nvm use project2.
Esistono degli alias utili già configurati, che puoi vedere digitando nvm alias poi tabulazione nel terminale :
Se desideri non scrivere nulla, è anche possibile ! Posiziona un file .nvmrc alla radice del tuo progetto e utilizza nvm use, nvm install senza specificare la versione al suo interno.
Le versioni nell'universo Node.js
Potresti aver notato che le versioni di node e npm sono della seguente forma :
X.Y.Z
E non è un caso che questo formato sia anche quello dei tuoi pacchetti nel tuo package.json e package-lock.json.
Con il dolce nome di semver, la gestione semantica delle versioni è al centro dell'ecosistema e ogni sviluppatore JavaScript ne trarrebbe vantaggio a padroneggiarla.
Il primo numero “X” corrisponde alla versione maggiore : quando questo numero viene incrementato, ciò indica che la nuova versione non è retrocompatibile con la versione precedente.
Il secondo, “Y”, corrisponde alla versione minore. Un cambiamento indica che più funzioni sono disponibili o che alcune sono obsolete, ma che l'API rimane retrocompatibile. La versione “Z” indica una correzione di bug.
Si deve tornare a zero per “Z” quando si incrementa “Y”, e si devono mettere a zero “Y” e “Z” quando si incrementa “X”.
Attenzione però, nulla impedisce a uno sviluppatore di incrementare “X” o “Y” mettendo online il suo pacchetto npm, e purtroppo,
L'errore è umano.
Una breve deviazione nel package.json
Nel tuo package.json, avrai sicuramente già visto questi numeri di versione arricchiti da decorazioni: “^4.12.2”, “<=12.0.1”, “~0.4.77” o meno, come in “1.0.3”. A volte, ci vedi anche arrangiamenti complicati: “<1.0.0 || >=2.5.1” o ancora “>4.0.1 <=5.3.0”.
Ecco la traduzione:
1.0.3: npm deve installare la versione 1.0.3, e nessuna libertà gli è lasciata;
^4.12.2: npm deve installare la versione più aggiornata dopo la 4.12.2 inclusa, ma non quella dopo la 5.0.0. In pratica, nessuna versione che non sia retrocompatibile con la 4.12.2;
~0.4.77: npm deve installare l'ultima versione 0.4.x;
<=12.0.1: o la versione 12.0.1 se esiste, o una versione precedente. Questo può essere utile per lasciare la scelta a npm, per esempio se un altro pacchetto richiede questo package alla versione 11.0.6.
“<1.0.0 || >=2.5.1”: tutte le versioni tranne quelle tra la 1.0.0 e la 2.5.0 (la cui API potrebbe non essere adatta a noi).
“>4.0.1 <=5.3.0”: tutte le versioni tra la 4.0.2 e la 5.3.0 incluse.
Se questi esempi non hanno soddisfatto la tua intensa curiosità, puoi esaminare
il parser di npm.
Le versioni di node
node è un eseguibile le cui versioni seguono il “Semantic versioning”.
Il suo ciclo di release è molto regolare poiché una nuova versione maggiore viene creata ogni 6 mesi.
Le versioni maggiori dispari (13.*.*, 15.*.*, ecc.) vengono abbandonate dopo 6 mesi. Le versioni maggiori pari (14.*.*, 16.*.*, ecc.) hanno un destino diverso dopo questi 6 mesi:
vengono messe in supporto a lungo termine (LTS), un supporto che dura 12 mesi. Possono avvenire aggiornamenti e risoluzioni di bug;
alla fine di questo periodo, vengono mantenute per altri 18 mesi, durante i quali i bug vengono risolti.
Morale della storia, se avvii un progetto o se ne aggiorni la versione, preferisci la versione maggiore pari attuale di node.
Gli errori dovuti alle versioni di node
Supponiamo che se esegui npm install, npm si lamenti scrivendo:
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE package: '@angular-devkit/core@x.y.z',
npm WARN EBADENGINE required: { node: '>= 12.4.0 <12.9.1', npm: '^6.10.0 || ^7.5.6',},
npm WARN EBADENGINE current: { node: 'v18.18.0', npm: '9.8.1' }
npm WARN EBADENGINE }
Dovremmo quindi avere:
una versione di node superiore o uguale a 12.4.0 e inferiore o uguale a 12.9.0 (attualmente, non è il caso, poiché npm è alla versione 18.18.0)
una versione di npm tra 6.10.0 incluso e 7.0.0 escluso o tra 7.5.6 incluso e 8.0.0 escluso (attualmente, non è il caso, poiché npm è alla versione 9.8.1).
Una breve deviazione tramite nvm ls-remote mi indica le versioni possibili dopo la 12.4.0.
nvm use 12.4.0 mi indica che questa versione arriva con npm versione 6.9.0, il che non è adatto secondo il mio messaggio di errore.
Dopo alcune installazioni, mi accorgo che la versione 12.7.0 di node è adatta e risolve il mio messaggio di errore.
Posso disinstallare le versioni inutili usando nvm uninstall [version].
Conclusione
nvm è un'utility che può rivelarsi molto utile se non controlli la versione di node sul server, se lavori su un progetto in cui un suo aggiornamento improvviso sarebbe sgradito rispetto agli altri collaboratori, o ancora se quest'ultimo rompesse alcuni vecchi pacchetti. Esistono altri gestori di versioni di
node come
n (
disponibile qui), ma il numero di versioni è più limitato.
