Dove installa npm i pacchetti su Windows 10 e 11

Dove finisce davvero un npm i su Windows 10 e 11

La risposta corta è semplice: npm i installa i pacchetti dentro la cartella del progetto, quasi sempre in node_modules accanto al file package.json. Su Windows 10 e 11 non esiste un “posto unico” valido per tutti i casi, perché npm separa chiaramente installazione locale, installazione globale, cache e file di configurazione. Se questa distinzione non è chiara, il risultato tipico è confusione su dove cercare i moduli, perché una CLI funziona in un terminale e non in un altro, o perché un pacchetto sembra “sparito” dopo un cambio di cartella.

Il punto pratico è questo: il progetto si porta dietro le sue dipendenze. L’installazione locale serve a rendere riproducibile l’ambiente; quella globale serve solo per strumenti da riga di comando che vuoi richiamare da qualsiasi directory. In mezzo ci sono la cache di npm e i wrapper eseguibili creati in node_modules\.bin o nella directory globale dei binari. Su Windows, inoltre, la presenza di spazi nei percorsi, permessi diversi e più versioni di Node installate con metodi diversi può cambiare il comportamento percepito, anche se il meccanismo di base resta lo stesso.

Installazione locale: la regola normale

Quando lanci npm install dentro una cartella che contiene un package.json, npm legge il file e risolve le dipendenze dichiarate. I pacchetti vengono scritti in node_modules nella directory corrente. Se il progetto è in C:\Users\Marco\Desktop\sito, i moduli finiranno in C:\Users\Marco\Desktop\sito\node_modules. È qui che va cercato il risultato di un’installazione standard, non in Program Files e non in una cartella “di sistema”.

Un esempio concreto: se esegui npm i express in un progetto, npm aggiunge express come dipendenza e deposita il suo codice sotto node_modules\express. Se il pacchetto fornisce un eseguibile, npm crea anche un collegamento locale in node_modules\.bin, che viene usato dagli script definiti nel progetto. Questo è il motivo per cui spesso puoi far partire strumenti come vite, eslint o webpack senza installarli globalmente: li richiami dal contesto del progetto.

La cartella node_modules può diventare grande in fretta, ma è voluto. Su Windows non è un’anomalia: è la conseguenza della struttura a dipendenze annidate di npm. In alcuni casi vedrai più copie dello stesso pacchetto in punti diversi dell’albero, perché npm risolve versioni differenti richieste da moduli diversi. Non è necessariamente un errore; è il modo in cui si mantiene la compatibilità tra dipendenze.

Installazione globale: dove vanno i pacchetti con -g

Se usi npm i -g nomepacchetto, il pacchetto non finisce nel progetto ma nel profilo dell’utente o nella directory globale configurata da npm. Su Windows il percorso preciso dipende dalla configurazione, dalla versione di Node e da come è stato installato il runtime. Il controllo corretto non è “indovinare” il path, ma chiederlo a npm.

Il comando utile è questo:

npm root -g
npm prefix -g

npm root -g mostra la cartella dove npm deposita i pacchetti globali. npm prefix -g mostra il prefisso globale, cioè la base da cui vengono derivati anche i binari eseguibili. Su molte installazioni Windows moderne il prefisso globale finisce sotto il profilo utente, spesso in un percorso simile a C:\Users\<utente>\AppData\Roaming\npm per i binari e a una directory collegata per i moduli. Ma la regola operativa resta: verifica sempre con npm, non con supposizioni.

Un caso classico è l’installazione di un tool globale che poi non viene trovato nel terminale. In quel caso non basta sapere dove npm lo ha messo: bisogna anche verificare che il percorso dei binari globali sia presente in PATH. Su Windows, se il terminale non vede il comando, il problema può essere il path dell’utente, una sessione non riaperta dopo la modifica delle variabili d’ambiente, oppure l’uso di un terminale avviato con un profilo diverso.

Cache di npm: non confonderla con la destinazione dell’installazione

Molti cercano i pacchetti nella cache di npm pensando che sia il luogo di installazione. Non è così. La cache serve a velocizzare download e reinstallazioni, non a ospitare il progetto in esecuzione. Il contenuto della cache può essere utile per diagnosi, ma non è il posto dove un’applicazione carica i moduli a runtime.

Per vedere dove si trova la cache, usa:

npm config get cache

Su Windows il valore punta spesso a un percorso sotto il profilo utente. Se hai problemi strani con installazioni corrotte, dipendenze che si riscaricano continuamente o errori dopo un cambio di rete, la cache può essere un elemento da controllare. Ma prima di toccarla, conviene distinguere bene tra cache e installazione reale: sono due cose diverse, con funzioni diverse.

Come capire in cinque secondi dove è stato installato un pacchetto

Se vuoi una risposta operativa, senza teoria, fai così: entra nella cartella del progetto e controlla node_modules. Se il pacchetto è globale, chiedi a npm il prefisso e il root globale. Se vuoi sapere dove finisce il binario eseguibile, guarda sia il pacchetto locale in node_modules\.bin sia il path globale dei comandi.

cd C:\percorso\del\progetto
npm ls nomepacchetto
npm root
npm root -g
npm prefix -g

npm ls nomepacchetto ti dice se il pacchetto è presente nell’albero locale e in quale versione. Se il comando restituisce un errore o non trova nulla, non significa per forza che npm abbia fallito: può significare semplicemente che il pacchetto non è installato in quella directory ma altrove, magari in globale o in un altro progetto. Su Windows questo errore è comune quando si aprono più cartelle in Visual Studio Code o si passa da una shell a un’altra senza verificare la directory corrente.

Un dettaglio che crea molta confusione: il comando where può aiutarti a capire quale eseguibile viene risolto per primo nel PATH. Se un tool sembra “installato” ma il terminale ne apre un’altra versione, il problema non è npm che ha sbagliato posto; è il sistema che sta preferendo un’altra copia.

where node
where npm
where npx

Perché su Windows il percorso sembra cambiare più spesso

Windows mette in gioco alcune variabili che su altri sistemi si notano meno. La prima è il profilo utente: molti percorsi di npm passano da AppData, quindi cambiano da un account all’altro. La seconda è la gestione delle variabili d’ambiente: se modifichi il PATH, spesso devi aprire una nuova shell perché la sessione corrente non rilegga tutto in automatico. La terza è la convivenza di installazioni multiple di Node, per esempio una fatta con l’installer ufficiale, una con nvm per Windows, una con Chocolatey o una portata dentro una macchina di sviluppo già predisposta.

In pratica, due terminali diversi possono vedere due mondi diversi. Uno può usare il Node installato globalmente, l’altro quello gestito da un version manager. Se in uno npm i -g mette i binari in una directory e nell’altro no, non è un comportamento casuale: è una differenza di prefisso e di contesto. Per questo, quando fai troubleshooting, conviene sempre partire da node -v, npm -v e where node prima di cambiare configurazioni.

Un’altra fonte di sorprese è l’avvio di PowerShell o Prompt dei comandi con privilegi diversi. In alcuni casi il pacchetto globale è installato correttamente nel profilo utente ma il terminale elevato non eredita lo stesso ambiente. Il risultato è che un comando funziona in una shell e non nell’altra. Anche qui la diagnosi non si fa a intuito: si confrontano i path, si controlla il prefisso globale e si verifica quale utente sta eseguendo la sessione.

Se il pacchetto non si vede: diagnosi pratica

Quando un pacchetto “non si trova”, il problema più frequente non è l’installazione in sé ma la directory sbagliata, il progetto sbagliato o il binario non presente nel PATH. La sequenza corretta è semplice: controlla la cartella corrente, verifica il file package.json, poi ispeziona l’albero dei moduli e infine il prefisso globale. Saltare questi passi porta quasi sempre a conclusioni sbagliate.

cd
npm root
npm root -g
npm prefix
npm prefix -g

npm prefix ti dice la base del progetto corrente; npm root ti dice dove stanno i moduli locali. Se i due percorsi non corrispondono alla cartella che pensavi di usare, hai già trovato il problema. È una verifica banale, ma in assistenza tecnica è una delle più utili perché taglia fuori il 50% degli errori di contesto.

Se invece stai lavorando con un pacchetto globale e il comando non parte, controlla il file eseguibile effettivo. Su Windows i wrapper possono essere .cmd o script associati, e il nome richiamato dal terminale non sempre corrisponde al file che immagini. La domanda giusta non è “dove ha installato npm?”, ma “qual è il comando risolto dal sistema, e da quale directory viene preso?”.

Installazione locale o globale: la scelta corretta non è estetica

Se devi distribuire un progetto, quasi sempre la scelta corretta è locale. Così blocchi le versioni nel progetto e riduci le sorprese tra un PC e l’altro. L’installazione globale ha senso solo per strumenti usati come utility, non per librerie applicative. Questo vale ancora di più su Windows, dove il profilo dell’utente, i permessi e il PATH possono introdurre differenze non immediatamente visibili.

Per esempio, installare globalmente eslint può sembrare comodo, ma rischi di avere una versione diversa da quella prevista dal progetto. Installarlo localmente e richiamarlo con gli script del package manager riduce la variabilità. Lo stesso vale per build tool, bundler e framework CLI: meglio agganciarli al progetto, non al computer.

In un contesto aziendale o su postazioni condivise, questo approccio è ancora più importante. Se un collega apre lo stesso repository ma usa una macchina diversa, l’unica cosa che deve cambiare è il runtime installato, non il comportamento delle dipendenze. La directory node_modules del progetto, il lockfile e gli script diventano la fonte di verità. Il resto è contorno.

Verifica finale: cosa controllare quando tutto sembra a posto

Alla fine, il controllo serio non è “vedo la cartella”, ma “il comando giusto risolve il percorso giusto”. Se il progetto parte, i moduli sono presenti in node_modules, i binari locali funzionano da npx o dagli script npm e il globale compare nel PATH quando serve, allora l’installazione è coerente. Se uno di questi elementi manca, non è un dettaglio da ignorare: è il punto da cui ripartire.

npm list --depth=0
npm bin -g
npm config get prefix
npx --no-install nomecomando

npm list --depth=0 mostra le dipendenze principali del progetto; npm bin -g indica la directory dei binari globali; npm config get prefix conferma il prefisso attivo; npx --no-install ti dice se un comando locale è davvero risolvibile senza cercarlo altrove. Sono controlli rapidi, ma sufficienti per capire dove npm ha installato davvero i pacchetti su Windows 10 e 11 e, soprattutto, se il sistema li vede nel modo corretto.

La regola da tenere a mente è questa: locale nel progetto, globale solo per gli strumenti, cache separata. Se parti da qui, il resto diventa molto più leggibile anche quando Windows, terminale e versioni di Node sembrano raccontare tre storie diverse.

Assunzione operativa: i percorsi esatti possono variare in base al metodo di installazione di Node.js e alla configurazione del profilo utente; in caso di dubbio, i comandi npm root, npm root -g e npm prefix -g sono la fonte più affidabile.