Scaricare e installare npm e Node.js su Windows 11 e 10

Su Windows 11 e Windows 10 la strada più pulita per avere Node.js e npm è installare il runtime ufficiale e verificare subito che il PATH sia corretto. Il punto non è solo “far partire il setup”: il punto è evitare conflitti con vecchie installazioni, versioni residue in App Execution Alias, e problemi tipici come npm non riconosciuto, permessi sulla cartella globale o tool di build che falliscono per mancanza di componenti C++.

Se devi sviluppare, fare deploy locali o usare strumenti come Vite, React, Angular, Electron o pacchetti CLI, conviene partire con una base stabile e verificata. In Windows la differenza la fanno i dettagli: dove installi, come gestisci gli aggiornamenti, e se tieni una sola versione o più versioni in parallelo.

Verifica prima di installare: pulizia del contesto

Prima di scaricare altro, controlla se il sistema ha già Node.js installato e da dove lo sta prendendo. È il modo più rapido per evitare di sovrascrivere una situazione confusa con un’altra altrettanto confusa.

1. Apri PowerShell o Prompt dei comandi.
2. Esegui questi comandi:

node -v
npm -v
where node
where npm

Se node -v e npm -v rispondono con una versione, hai già un’installazione attiva. where node e where npm ti dicono il percorso effettivo usato da Windows. Se vedi più percorsi, o uno punta a cartelle vecchie come C:\Program Files\nodejs\ e un altro a un tool di versioning, c’è già un possibile conflitto.

Se i comandi non sono riconosciuti, il problema è più semplice: Node.js non è installato oppure il PATH non è aggiornato.

Scaricare Node.js su Windows 11 e 10

Per un’installazione standard, usa il sito ufficiale di Node.js e scegli la release LTS. Per quasi tutti i casi d’uso è la scelta giusta: meno sorprese, più compatibilità con moduli e tool di sviluppo, aggiornamenti più lineari.

1. Vai alla pagina ufficiale di download di Node.js.
2. Scarica il pacchetto Windows Installer 64-bit se il tuo sistema è moderno; su Windows 10/11 a 64 bit è il caso comune.
3. Evita archivi “portabili” o repack non ufficiali se non hai un motivo preciso.

Se lavori in ambiente aziendale, è normale voler fissare una versione invece di inseguire l’ultima disponibile. In quel caso conviene documentare la release usata nel progetto e allineare tutto il team sulla stessa major.

Installazione guidata: cosa selezionare davvero

Avvia l’installer scaricato. Il wizard di Node.js su Windows è semplice, ma alcune opzioni meritano attenzione perché influenzano il comportamento successivo.

1. Accetta la licenza.
2. Lascia la cartella di default se non hai una policy interna diversa.
3. Assicurati che sia selezionata l’opzione per aggiungere Node.js al PATH.
4. Se proposta, accetta l’installazione degli strumenti di compilazione richiesti per i moduli nativi, soprattutto se prevedi pacchetti che compilano estensioni.
5. Completa l’installazione e chiudi il wizard.

La voce sul PATH è quella che evita metà delle richieste di supporto. Senza PATH corretto, node e npm esistono sul disco ma non sono invocabili da terminale. Se stai preparando una macchina per sviluppo o test, conviene non risparmiare qui: installa la parte standard e verifica dopo.

Prima verifica dopo il setup

Subito dopo l’installazione apri una nuova finestra di terminale. Questo passaggio conta: una sessione già aperta spesso non vede le variabili d’ambiente aggiornate.

node -v
npm -v
npm config get prefix

Il risultato atteso è una versione valida per entrambi i comandi. npm config get prefix ti restituisce il prefisso globale usato da npm; su Windows di solito non è il primo elemento che guardi, ma è utile per capire dove andranno pacchetti globali e binari collegati.

Se node -v risponde ma npm -v no, di solito non è un problema del runtime: è più spesso una PATH incompleta, un’installazione danneggiata o un conflitto con un’installazione precedente.

Gestire più versioni con nvm-windows

Se devi lavorare su progetti diversi con requisiti diversi, la soluzione più pratica su Windows è nvm-windows, non il classico nvm per Linux/macOS. È un gestore pensato per Windows e serve proprio a mantenere più versioni di Node.js senza disinstallare ogni volta.

Questo approccio è utile in almeno tre casi: devi mantenere un progetto legacy, stai testando compatibilità tra major diverse, oppure vuoi isolare ambienti di build. In pratica, invece di “aggiornare tutto”, cambi versione quando entri nel progetto giusto.

1. Disinstalla eventuali versioni di Node.js installate in modo manuale, se stanno creando conflitti.
2. Installa nvm-windows dal repository ufficiale del progetto.
3. Apri un nuovo terminale e verifica che nvm sia disponibile.
4. Installa una versione LTS, poi impostala come attiva.

nvm install lts
nvm use lts
node -v
npm -v

Se vuoi una versione specifica:

nvm install 20.11.1
nvm use 20.11.1

Con nvm-windows il concetto importante è che la versione attiva cambia per la sessione o per il contesto configurato. È una strada più robusta quando i progetti non sono omogenei. Il compromesso è che devi essere disciplinato: verificare sempre la versione prima di avviare build o script importanti.

Installa npm da solo? No: arriva con Node.js

Un dettaglio che evita confusione: su Windows, npm viene installato insieme a Node.js. Se stai cercando un installer separato per npm, stai probabilmente inseguendo un problema di percezione, non un requisito tecnico.

La coppia corretta è questa: installi Node.js, ottieni anche npm, poi eventualmente aggiorni npm con il suo comando dedicato se serve una release più recente rispetto a quella inclusa nel runtime.

npm install -g npm@latest

Questo aggiornamento ha senso solo se sai perché lo stai facendo. In ambienti di sviluppo standard, la versione inclusa con la LTS è spesso sufficiente. Se aggiorni npm, fallo consapevolmente e verifica che i progetti non abbiano vincoli di compatibilità con una versione specifica.

Configurare il repository npm e i permessi locali

Su Windows i problemi non arrivano solo dall’installazione: spesso esplodono quando npm deve scrivere in cartelle globali o scaricare dipendenze con script di post-installazione. Per questo è utile controllare il prefisso globale e, se necessario, lavorare in modo più ordinato con directory utente dedicate.

Per vedere la configurazione attuale:

npm config list

Per capire dove finiscono i pacchetti globali:

npm root -g
npm prefix -g

Se una policy locale ti impone di non usare installazioni globali diffuse, puoi limitare l’uso di -g e preferire dipendenze di progetto. È un approccio più pulito e riduce conflitti tra team o tra ambienti diversi.

Quando il terminale dice “node non è riconosciuto”

È il problema più comune dopo l’installazione. Le cause tipiche sono tre: il terminale era già aperto, il PATH non include la cartella giusta, oppure c’è un conflitto tra più installazioni.

1. Chiudi tutte le finestre di terminale e riaprile.
2. Controlla il PATH con:

echo %PATH%

In PowerShell puoi usare:

$env:Path

Il percorso di Node.js dovrebbe comparire tra le variabili d’ambiente. Se non compare, apri Impostazioni di sistema avanzate → Variabili d’ambiente e verifica la voce Path dell’utente o del sistema. In genere la cartella di Node.js è qualcosa come C:\Program Files\nodejs\.

Se il percorso c’è ma il comando non funziona, cerca duplicati con:

where node
where npm

Se emergono più posizioni, disinstalla quelle non necessarie oppure riallinea il PATH. Non lasciare più installazioni “a metà”: è il modo più rapido per ottenere comportamenti incoerenti tra terminali diversi.

Windows 11 e 10: Microsoft Store, App Execution Alias e installazioni duplicate

Su Windows 10 e 11 può capitare di avere alias o app stub che interferiscono con il comportamento atteso. In particolare, se hai installato applicazioni tramite Microsoft Store o hai abilitazioni residue di alias, il sistema può intercettare alcuni comandi in modo non previsto.

Se Node.js sembra installato ma il terminale continua a non trovare il comando, controlla anche le impostazioni degli alias nelle app di Windows. È un controllo banale ma spesso risolutivo, soprattutto su macchine usate da più persone o configurate nel tempo con tool diversi.

Se la macchina ha subito più installazioni e disinstallazioni, il consiglio operativo è semplice: elimina il superfluo, tieni una sola fonte di verità e verifica il risultato con where node e where npm. Meno ambiguità = meno rogne.

Verificare che npm funzioni davvero con un progetto reale

Un controllo serio non si ferma alla versione. Crea un progetto di prova e fai installare una dipendenza minima. È il modo migliore per capire se il runtime è sano, se il download funziona e se la cartella di lavoro è scrivibile.

mkdir test-node
cd test-node
npm init -y
npm install lodash

Se tutto va bene, vedrai una cartella node_modules, un package-lock.json e una voce in package.json. Il comando npm install deve completarsi senza errori di permessi, proxy o TLS.

Per controllare rapidamente che Node esegua codice:

node -e "console.log('Node OK')"

Questo test vale più di mille “sembra funzionare”: ti dice che il runtime parte, interpreta JavaScript e scrive output sul terminale.

Se usi proxy, firewall o rete aziendale

In ambienti aziendali la parte più fragile non è l’installazione, ma l’accesso al registry npm. Se la rete passa da proxy o filtro TLS, il download dei pacchetti può fallire anche con Node.js installato correttamente.

Controlla la configurazione attuale con:

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

Se il registry non è quello predefinito o se esiste un proxy obbligatorio, la configurazione va documentata. Non salvare credenziali in chiaro in file condivisi. Se devi impostare un proxy con autenticazione, usa i meccanismi previsti dall’organizzazione e ruota le credenziali se sono già state esposte.

Se il problema è TLS ispezionato da appliance aziendali, prima di toccare npm verifica che il certificato della CA interna sia installato dove serve. Spesso l’errore non è “npm rotto”, ma catena di fiducia incompleta.

Aggiornare Node.js senza rompere i progetti

Gli aggiornamenti sono il punto in cui molti ambienti si degradano. Con Node.js conviene distinguere tra aggiornamento del runtime e aggiornamento del progetto. Il runtime lo cambi per sicurezza, supporto o compatibilità; il progetto lo testi nel suo contesto.

Se usi l’installer tradizionale, l’aggiornamento consiste nel scaricare la nuova LTS e sostituire la versione precedente. Se usi nvm-windows, il flusso è più pulito: installi la nuova versione e la attivi quando serve.

nvm install lts
nvm use lts
node -v
npm -v

Dopo un cambio versione, rilancia i test del progetto, soprattutto se hai dipendenze native, script di build o tool che invocano API di Node specifiche. Il rischio non è teorico: una major nuova può cambiare comportamenti, warning o compatibilità di alcune librerie.

Quando conviene scegliere LTS e quando Current

Per un ambiente di sviluppo quotidiano, la risposta è quasi sempre LTS. La branch Current ha senso se devi testare una funzionalità nuova, validare compatibilità futura o preparare un progetto per una major non ancora diventata stabile nel tuo stack.

Se il tuo obiettivo è lavorare senza interruzioni, LTS è la scelta naturale. Se invece devi verificare framework, plugin o pipeline CI/CD su una release recente, allora Current può essere utile, ma solo in un ambiente separato o ben documentato.

La regola pratica è semplice: production-like e sviluppo condiviso su LTS; sperimentazione controllata su Current.

Controlli finali e disciplina operativa

Dopo l’installazione, conserva una checklist minima. Ti serve la prossima volta che una macchina “misteriosamente” smette di vedere Node o npm.

1. node -v restituisce una versione coerente con quella attesa.
2. npm -v funziona nella stessa sessione di terminale.
3. where node e where npm puntano a una sola installazione o a un solo gestore versioni.
4. npm install in un progetto di test completa senza errori.
5. Se usi nvm-windows, la versione attiva è quella prevista dal progetto.

Se qualcosa non torna, non partire subito con reinstallazioni casuali. Prima verifica il layer giusto: PATH, alias, versione attiva, rete, permessi. Su Windows, quasi sempre il problema è nel contesto, non nel runtime in sé.

Assunzione operativa: qui si parte da una macchina Windows 10/11 a 64 bit, con accesso amministrativo almeno per l’installazione iniziale e con terminale aggiornato dopo ogni modifica al PATH.