Installare Node.js e NPM su Windows 10 e 11 da riga di comando

Installare Node.js e NPM su Windows 10 e 11 dalla riga di comando

Su Windows 10 e 11 la strada più pulita per installare Node.js e NPM da terminale è usare winget, perché evita installer manuali, riduce gli errori di percorso e rende più semplice l’aggiornamento successivo. In pratica, il punto non è solo “mettere Node sul PC”, ma farlo in modo ripetibile, verificabile e reversibile.

Se lavori su più macchine, o devi preparare un ambiente di sviluppo senza aprire il browser, la riga di comando è la scelta giusta. Se invece ti serve una versione specifica per un progetto legacy, conviene fermarsi un attimo e decidere prima quale ramo installare, perché il numero di versione influenza anche la compatibilità con moduli nativi e toolchain di build.

Prima di installare: cosa devi aspettarti

Il risultato atteso è questo: dopo l’installazione, i comandi node, npm e, se presente, npx devono rispondere nel prompt senza errori di “command not found” o “is not recognized”. Inoltre, node -v e npm -v devono restituire una versione coerente con quella scelta.

Se il comando non viene trovato subito dopo l’installazione, il problema di solito non è Node in sé ma il PATH della sessione corrente, oppure un conflitto con installazioni precedenti. Su Windows questo succede spesso quando si mischiano installer grafici, versioni vecchie, Chocolatey, nvm-windows e winget senza una regola chiara.

Verifica preliminare del sistema

Prima di installare, controlla che winget sia disponibile. Su Windows 10 e 11 recenti fa parte di App Installer. Apri PowerShell o Windows Terminal e lancia:

winget --version

Se ottieni una versione, puoi procedere. Se il comando non esiste, significa che App Installer non è presente o non è aggiornato. In quel caso la chiusura del gap è semplice: installa o aggiorna App Installer dal Microsoft Store, poi riprova il comando. Non è il caso di improvvisare con pacchetti casuali scaricati da fonti non ufficiali.

Per capire se hai già Node installato, controlla anche:

node -v
npm -v
where node
where npm

Se where restituisce più percorsi, hai probabilmente più installazioni in conflitto. In quel caso conviene decidere quale tenere e rimuovere le altre, altrimenti rischi di eseguire una versione diversa da quella attesa a seconda della shell o dell’ordine nel PATH.

Installazione consigliata con winget

Per la maggior parte dei casi, il pacchetto ufficiale è la scelta più semplice. Il comando base è questo:

winget install OpenJS.NodeJS.LTS

Questo installa il ramo LTS, che è quello più sensato per sviluppo ordinario, corsi, ambienti condivisi e workstation aziendali. Se invece ti serve l’ultima versione corrente, puoi usare il pacchetto non LTS:

winget install OpenJS.NodeJS

Dopo l’installazione, apri una nuova finestra di terminale e verifica:

node -v
npm -v
npx -v

Se i comandi rispondono, l’installazione è andata a buon fine. Se node funziona ma npm no, di solito il problema è raro perché NPM viene distribuito insieme a Node. Più spesso il sintomo è un PATH non aggiornato o una shell rimasta aperta prima dell’installazione.

Perché LTS è quasi sempre la scelta giusta

Node.js evolve rapidamente e non tutte le versioni sono uguali per stabilità operativa. Per un ambiente Windows da lavoro, il ramo LTS riduce il rischio di incompatibilità improvvise con tool come webpack, vite, eslint, TypeScript e pacchetti con dipendenze native. Questo non significa che l’ultima release sia “sbagliata”, ma che va scelta con un motivo preciso.

Un dettaglio pratico: se lavori su progetti diversi, la versione di Node dovrebbe essere una decisione per progetto, non una scelta casuale della macchina. Se ti serve cambiare spesso versione, valuta nvm-windows invece di installare e disinstallare manualmente ogni volta. Su una workstation singola con un solo stack, winget resta comunque il percorso più lineare.

Installare una versione specifica

Se devi allinearti a una release precisa, prima elenca i pacchetti disponibili o cerca il nome esatto del package. In molte installazioni basta questo approccio:

winget search nodejs

Da lì puoi installare il pacchetto corretto in base al nome trovato. Il vantaggio è che non dipendi da un installer scaricato a mano e puoi ripetere la procedura in modo coerente su altre macchine.

Se usi versioni specifiche per compatibilità applicativa, annota il vincolo nel progetto: ad esempio in package.json tramite il campo engines o in una documentazione interna. Non è una protezione assoluta, ma aiuta a ridurre l’errore umano quando qualcuno aggiorna la workstation senza verificare prima i requisiti.

Gestire il PATH e i conflitti

Il problema più comune dopo l’installazione è il classico: Node è installato, ma il terminale dice che il comando non esiste. In quel caso devi distinguere tra installazione riuscita e sessione che non vede ancora il PATH aggiornato.

Controlla il percorso risolto dai comandi:

where node
where npm

Su una installazione standard dovresti vedere qualcosa di simile a un percorso sotto C:\\Program Files\nodejs\. Se compare prima un’altra cartella, magari lasciata da una vecchia installazione, quella copia può avere priorità. In quel caso la soluzione migliore è rimuovere il duplicato o ripulire il PATH, non forzare il sistema a convivere con copie diverse dello stesso runtime.

Se vuoi verificare il PATH dell’utente corrente, usa:

echo %PATH%

Oppure in PowerShell:

$env:Path

Quando modifichi il PATH da interfaccia grafica, la chiusura e riapertura del terminale è obbligatoria. Questo dettaglio sembra banale, ma è una delle cause più frequenti di falsi negativi nei test post-installazione.

Installazione tramite PowerShell e automazione

Se devi automatizzare la preparazione di un ambiente, puoi eseguire winget direttamente da PowerShell in uno script di provisioning. Il vantaggio è che il setup resta leggibile e ripetibile. Un esempio minimo:

winget install --id OpenJS.NodeJS.LTS --accept-package-agreements --accept-source-agreements

Gli switch di accettazione riducono i prompt interattivi, utili in installazioni batch o in ambienti di laboratorio. Non usarli alla cieca in produzione su postazioni condivise: prima verifica che la policy interna consenta installazioni automatiche e che il pacchetto sia davvero quello desiderato.

Se vuoi rendere più robusto il flusso, puoi aggiungere un controllo preliminare:

if (Get-Command winget -ErrorAction SilentlyContinue) {
  winget install --id OpenJS.NodeJS.LTS --accept-package-agreements --accept-source-agreements
} else {
  Write-Host "winget non disponibile: verificare App Installer"
}

Questa logica è utile in script di onboarding, dove il vero problema non è installare Node una volta, ma farlo senza interventi manuali su decine di macchine.

Verifica funzionale dopo l’installazione

La verifica non deve fermarsi alla versione. Conviene testare anche il comportamento di NPM con un progetto vuoto, così intercetti subito problemi di permessi, proxy o cache corrotta.

mkdir C:	emp
ode-test
cd C:	emp
ode-test
npm init -y

Se npm init -y crea correttamente il file package.json, hai già una conferma pratica che il runtime e il package manager funzionano. A questo punto puoi fare un test ancora più concreto:

npm install lodash

Se il download fallisce, il problema potrebbe essere rete, proxy aziendale, certificati TLS ispezionati o policy di sicurezza. In quel caso non serve toccare Node: devi prima verificare l’accesso a registry.npmjs.org e l’eventuale configurazione proxy in npm config.

Cache, proxy e ambienti aziendali

In reti aziendali o ambienti con proxy, NPM può fallire anche se Node è installato bene. Qui il punto non è la versione del runtime ma la capacità di raggiungere il registry o di fidarsi del certificato usato dal proxy. Prima di cambiare configurazioni, verifica l’errore reale.

npm config get proxy
npm config get https-proxy
npm config get registry

Se il registry è stato riscritto o il proxy non è impostato, NPM può restituire timeout, errori TLS o impossibilità di risolvere i pacchetti. La correzione va fatta con criterio: imposta solo ciò che serve, documenta la modifica e, se possibile, preferisci configurazioni di ambiente o profilo utente rispetto a cambi globali non tracciati.

Per pulire la cache, se davvero necessario e dopo aver escluso altri problemi:

npm cache verify

Questo è un controllo meno aggressivo di una pulizia forzata e spesso basta per capire se la cache è coerente. Evita di cancellare tutto senza motivo: prima osserva, poi intervieni.

Disinstallare o sostituire una versione senza lasciare residui

Se devi cambiare ramo o rimuovere una versione problematica, fallo in modo ordinato. Con winget puoi verificare i pacchetti installati e poi rimuovere quello corretto:

winget list node

Una volta identificato il pacchetto, la rimozione può essere eseguita con il nome o l’ID appropriato. Dopo la disinstallazione, ricontrolla where node e where npm per assicurarti che non restino binari in vecchie cartelle del PATH.

Se hai installazioni miste, il vero lavoro è ripulire i residui: cartelle in C:\\Program Files\nodejs\, voci PATH obsolete e eventuali helper di version manager. Senza questa pulizia, il sistema può continuare a puntare a un eseguibile non più desiderato.

Quando usare nvm-windows invece di winget

Se sviluppi su più progetti con requisiti diversi, o devi cambiare spesso versione di Node senza toccare l’installazione globale, nvm-windows è più adatto. Il vantaggio è il controllo per-sessione o per-shell della versione attiva, che evita di trasformare la macchina in un campo di battaglia tra installer diversi.

Il limite è che introduce un livello in più da gestire. Per una postazione standard, dove serve una sola versione stabile, winget resta più semplice e più facile da supportare. Per un ambiente di sviluppo con più stack, invece, il version manager riduce i tempi morti e i conflitti.

Checklist operativa rapida

1. Verifica winget --version e, se manca, aggiorna App Installer.
2. Installa il ramo desiderato con winget install OpenJS.NodeJS.LTS oppure il pacchetto corrente.
3. Apri una nuova shell e controlla node -v, npm -v e where node.
4. Fai un test reale con npm init -y in una cartella vuota.
5. Se ci sono errori, isola prima PATH, proxy e conflitti di installazione.

Questa sequenza è più affidabile di una verifica “a vista” dell’installer, perché ti dice subito se il sistema è davvero operativo o solo apparentemente installato.

Dettaglio che evita ore di debug

Una buona abitudine è trattare Node e NPM come parte del profilo di lavoro, non come un software qualunque. Annotare la versione installata, il metodo di installazione e l’eventuale presenza di proxy o version manager ti evita debug inutili quando un collega o un futuro te stesso trova un comportamento diverso da quello atteso.

Su Windows, la maggior parte dei problemi non nasce dall’installazione in sé, ma da ciò che le ruota attorno: PATH sporco, shell vecchia, proxy aziendale, più versioni in parallelo, oppure aspettative vaghe sulla release da usare. Se tieni questi punti sotto controllo, installare Node.js e NPM da riga di comando diventa una procedura rapida e ripetibile, non un piccolo rito ogni volta diverso.