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

Su Windows 10 e 11 il modo più pulito per installare Node.js e NPM da riga di comando è usare winget, il gestore pacchetti integrato nelle versioni recenti di Windows. Così eviti il classico giro del browser, riduci gli errori di installazione manuale e ti porti a casa un setup ripetibile, utile sia su macchine singole sia su ambienti di lavoro che vuoi standardizzare.

La scelta pratica è semplice: installi Node.js LTS, verifichi che node e npm siano nel PATH, controlli che la versione sia quella attesa e poi, se serve, aggiorni con lo stesso strumento. Niente magia: se qualcosa non torna, quasi sempre il problema è nel PATH, in una vecchia installazione residua o in una policy aziendale che blocca winget.

Perché usare winget invece dell'installer grafico

Il pacchetto ufficiale di Node.js per Windows funziona anche con il setup tradizionale, ma da riga di comando hai alcuni vantaggi concreti: installazione più veloce, meno click, possibilità di automatizzare e soprattutto coerenza tra una macchina e l'altra. In un contesto tecnico questo conta più della comodità dell'installer classico.

Con winget puoi anche fissare la versione LTS, aggiornare in modo controllato e verificare subito che il sistema stia usando l'eseguibile giusto. Se su una macchina esiste già una vecchia versione di Node installata in un percorso diverso, lo scopri immediatamente invece di accorgertene dopo giorni perché un progetto npm compila con comportamenti incoerenti.

Prerequisiti minimi

Prima di partire, controlla questi punti essenziali:

• Windows 10 1809+ o Windows 11 con App Installer installato.
• winget disponibile da terminale.
• Permessi amministrativi locali, se la policy della macchina lo richiede.
• Connessione Internet verso i repository Microsoft e il feed dei pacchetti.

Se winget non è presente, il problema non è Node.js: è il livello di gestione pacchetti di Windows. In quel caso devi prima installare o aggiornare App Installer dal Microsoft Store o tramite canale aziendale, poi riprovare.

Verifica iniziale: winget, PATH e conflitti

Apri PowerShell o Windows Terminal e verifica subito che lo strumento sia disponibile:

winget --version

Se il comando risponde con una versione, sei a posto. Se ricevi un errore tipo comando non riconosciuto, devi sistemare App Installer o la variabile d'ambiente PATH del sistema. Questo è il primo punto da chiudere, altrimenti l'installazione non parte.

Conviene anche controllare se esistono installazioni precedenti di Node:

where node

where npm

Se ottieni più percorsi, hai un conflitto potenziale. Tipicamente succede quando una vecchia installazione MSI è rimasta in C: vm, C: odejs o in C: pm, oppure quando un altro package manager ha lasciato binari nel PATH. Non è ancora un guasto, ma va tenuto d'occhio perché può farti eseguire un binario diverso da quello appena installato.

Installazione di Node.js LTS da riga di comando

Per la maggior parte dei casi, installa la versione LTS. È la scelta giusta per sviluppo, build e ambienti dove vuoi stabilità più che sperimentazione.

winget install OpenJS.NodeJS.LTS

Se vuoi installare la versione corrente, non LTS, usa il pacchetto standard:

winget install OpenJS.NodeJS

Durante l'installazione winget può chiedere conferma dei termini o l'accettazione di una sorgente. È normale. Se sei in ambiente aziendale e il terminale non ha privilegi elevati, il setup potrebbe fallire con un errore di accesso: in quel caso rilancia il comando in una sessione amministrativa.

Se preferisci essere esplicito sulla sorgente, puoi prima cercare il pacchetto:

winget search OpenJS.NodeJS

Questo ti permette di verificare il nome esatto del pacchetto prima dell'installazione, utile quando vuoi evitare ambiguità o quando la macchina è soggetta a repository filtrati.

Verifica post-installazione: versioni e NPM

Dopo l'installazione, chiudi e riapri il terminale. È un passaggio banale ma necessario: il PATH viene ricaricato solo nelle nuove sessioni. Poi verifica Node e NPM:

node -v

npm -v

Il risultato atteso è una versione valida, per esempio v20.x.x o una release LTS recente, e una versione npm coerente con quel ramo di Node. Se node -v funziona ma npm -v no, quasi sempre hai una installazione parziale o un PATH sporco.

Controlla anche il percorso effettivo dei binari:

where node

where npm

Il percorso deve puntare all'installazione appena eseguita, in genere sotto C: vm solo se usi un gestore di versioni diverso, oppure nella cartella standard di Node.js su Windows. Se il primo risultato non è quello atteso, stai eseguendo un binario diverso da quello installato adesso.

Se Node non compare nel PATH

Il problema più comune dopo l'installazione è questo: il setup è andato a buon fine, ma il comando non è riconosciuto nella shell corrente o in una shell diversa. La causa è quasi sempre il PATH non aggiornato o una priorità sbagliata tra percorsi.

Controlla il PATH della sessione corrente:

echo %PATH%

In PowerShell puoi usare:

$env:Path

Se non vedi la directory di Node.js, apri Impostazioni di sistema avanzate > Variabili d'ambiente e verifica che il percorso corretto sia presente nelle variabili di sistema o utente. In alternativa, se vuoi una verifica più rapida senza toccare nulla, basta aprire una nuova finestra di terminale: spesso il problema sparisce solo perché la sessione precedente non aveva riletto il PATH.

Se invece esiste un conflitto con vecchi binari, la soluzione pulita è rimuovere le installazioni obsolete e lasciare un solo punto di ingresso. Non conviene tenere più versioni casuali nello stesso PATH, soprattutto su macchine usate per build o training: prima o poi il comando giusto verrà risolto nel posto sbagliato.

Aggiornare Node.js e NPM senza reinstallare tutto a mano

Quando esce una nuova LTS, puoi aggiornare con winget invece di rifare l'intero setup manualmente. Prima verifica se il pacchetto è aggiornabile:

winget upgrade

Se Node.js compare nell'elenco, esegui l'upgrade:

winget upgrade OpenJS.NodeJS.LTS

Questo approccio è più pulito del “disinstalla e reinstalla” perché mantiene il flusso di gestione coerente. Dopo l'aggiornamento, rifai sempre i controlli node -v e npm -v. Non dare per scontato che il terminale stia usando il nuovo binario finché non lo hai verificato.

Se il pacchetto non compare tra gli upgrade, ma vuoi comunque forzare un refresh della sorgente, puoi aggiornare il catalogo:

winget source update

Questa operazione non tocca i binari installati e quindi è reversibile e a basso rischio. Serve soprattutto quando il client winget ha dati di repository non aggiornati.

Installazione controllata in ambiente aziendale

In un contesto aziendale il punto non è solo installare Node.js, ma farlo in modo ripetibile e auditabile. Se la macchina è gestita da policy, potresti dover usare canali approvati, proxy, certificati aziendali o repository interni. In quel caso winget resta utile, ma devi verificare che la sorgente sia consentita.

Se l'organizzazione blocca l'accesso ai repository pubblici, la soluzione non è forzare l'installazione con workaround opachi. Il percorso corretto è allinearsi al sistema di distribuzione interno: pacchetto firmato, repository privato o immagine già predisposta. Questo riduce rischi e semplifica gli aggiornamenti successivi.

Per un controllo minimo di sicurezza, fai almeno queste verifiche:

• conferma del pacchetto installato con winget list;
• verifica della versione con node -v;
• controllo del percorso con where node;
• eventuale tracciamento nel sistema di inventario software aziendale.

Quando serve una versione specifica di Node

Non sempre LTS è la scelta giusta. Se stai testando funzionalità recenti, librerie che richiedono un major specifico o progetti legacy, potresti aver bisogno di una versione diversa. Su Windows, però, tenere più versioni di Node installate in modo disordinato è una cattiva idea.

Se devi gestire più release, valuta un gestore di versioni dedicato come nvm-windows. Non è lo stesso flusso di winget: qui il focus è il cambio rapido tra versioni. Winget è perfetto per installare e aggiornare in modo pulito, mentre un version manager è più adatto quando devi switchare tra progetti con requisiti diversi.

La regola pratica è questa: se ti serve una sola versione stabile, winget basta. Se devi mantenere più rami, usa uno strumento pensato per quello scenario e non improvvisare con installazioni multiple nello stesso sistema.

Test rapido con un file JavaScript

Una volta verificato che Node e NPM rispondono, fai un test concreto. Crea un file di prova, per esempio test.js, con questo contenuto:

console.log('Node.js funziona correttamente');

Poi eseguilo:

node test.js

Se vedi l'output atteso, hai validato non solo il binario ma anche l'esecuzione di uno script reale. È un controllo banale, ma utile quando vuoi escludere problemi di shell, encoding o PATH.

Per testare NPM, puoi inizializzare una cartella di prova:

mkdir npm-test

cd npm-test

npm init -y

La creazione di package.json conferma che il gestore pacchetti funziona e che la rete, se necessaria, non è bloccata da policy o proxy.

Disinstallazione e pulizia se qualcosa va storto

Se l'installazione è andata male, prima di rifare tutto conviene capire cosa è stato lasciato indietro. Disinstallare e reinstallare a caso spesso peggiora il problema, soprattutto quando restano binari nel PATH o cartelle vecchie con priorità superiore.

Per rimuovere Node.js installato via winget:

winget uninstall OpenJS.NodeJS.LTS

Dopo la rimozione, controlla ancora where node e where npm. Se restituiscono ancora percorsi, vuol dire che c'è un'altra installazione da ripulire manualmente o una directory residua nel PATH. Solo a quel punto ha senso intervenire sulle variabili d'ambiente.

Se vuoi fare una pulizia completa, annota prima i percorsi esistenti e poi rimuovi solo ciò che appartiene a Node.js. Non toccare directory condivise o cartelle usate da altri strumenti. Il rollback, in questo caso, è semplice: reinstalli con lo stesso comando winget dopo aver corretto il conflitto.

Scelta pratica finale

Per Windows 10 e 11, il flusso più lineare è questo: verifica winget, installa OpenJS.NodeJS.LTS, riapri il terminale, controlla node -v e npm -v, poi fai un test con uno script minimo. Se devi mantenere più versioni, separa il problema e passa a un version manager dedicato.

In pratica, il tempo speso a controllare PATH e conflitti iniziali te lo riprendi subito dopo, quando eviti di inseguire errori strani in build, deploy locali o script npm che “funzionano sulla macchina di qualcuno”. Su Windows, la differenza tra un setup pulito e uno sporco quasi sempre sta lì.