1 22/10/2026 9 min

PNPM su Ubuntu 22.04 e 20.04: scelta corretta tra Corepack, npm e installazione globale

Se devi usare PNPM su Ubuntu 22.04 o 20.04, la strada più pulita oggi è passare da Corepack, non da un'installazione globale “a mano” fatta con npm i -g pnpm. Il motivo è semplice: Corepack ti aggancia alla versione dichiarata dal progetto, riduce gli scarti tra macchine diverse e ti evita di inseguire binari sparsi nel sistema.

La differenza pratica è questa: su una workstation o su un server di build vuoi sapere quale PNPM stai usando, da dove arriva e come lo aggiorni senza rompere il resto. Su Ubuntu questo conta ancora di più perché spesso trovi Node installato dai repository di sistema, da NodeSource, da NVM o da un container. Mischiare tutto senza criterio porta quasi sempre a problemi di path, permessi o versioni incompatibili.

Prerequisito vero: una versione di Node.js adatta

PNPM non vive da solo: ha bisogno di Node.js. Prima di installarlo, verifica quale Node hai già sul sistema e da dove arriva. Questo è il punto in cui si evitano i classici casi da “funziona nel mio terminale ma non nel servizio systemd”.

Controlla così:

node -v
npm -v
which node
which npm

Se node -v restituisce una versione troppo vecchia, aggiorna prima Node. Per Ubuntu 20.04 e 22.04, in genere conviene usare un repository supportato o un gestore come nvm se lavori in ambienti utente; su server e ambienti condivisi, però, una installazione di sistema ben controllata è spesso più prevedibile.

Per PNPM, la soglia minima utile dipende dalla versione che vuoi usare. In pratica, se sei su una LTS recente di Node, sei in una zona sicura. Se sei su una versione vecchia, prima sistemi Node e poi attivi PNPM.

Metodo consigliato: Corepack con Node.js recente

Corepack è il meccanismo integrato in Node per gestire package manager come PNPM e Yarn. Su sistemi moderni è la scelta migliore perché ti consente di attivare la versione richiesta dal progetto senza installare PNPM globalmente in modo permanente.

Procedura tipica:

  1. Verifica Node e Corepack.
  2. Abilita Corepack.
  3. Attiva PNPM.
  4. Controlla la versione effettiva usata dalla shell.
node -v
corepack -v
sudo corepack enable
pnpm -v

Se corepack non è presente, significa che la tua installazione di Node è troppo vecchia o non include il binario. In quel caso hai due strade: aggiornare Node oppure usare un’installazione alternativa di PNPM. In ambiente server, la prima è quasi sempre la scelta giusta.

Dopo corepack enable, il comando pnpm diventa disponibile e Corepack può scaricare la versione corretta quando serve. Se il progetto contiene un campo packageManager nel file package.json, la versione viene ancorata lì. È la soluzione più pulita per team e CI/CD.

Installazione tramite npm globale: quando ha senso e quando no

L’alternativa classica è installare PNPM con npm in modo globale. È semplice, ma ha un costo: stai legando il package manager a una versione specifica del tuo ambiente e non al progetto. In una macchina di sviluppo personale può andare bene; su server condivisi o pipeline, meno.

Se decidi comunque di farlo, il comando è questo:

npm install -g pnpm
pnpm -v
which pnpm

Occhio ai permessi. Se npm install -g fallisce con errori di scrittura in directory di sistema, non forzare con sudo a occhi chiusi. Prima capisci come è stato installato Node e dove punta il prefisso globale:

npm config get prefix
npm root -g

Se il prefisso globale punta a una directory protetta, il problema non è PNPM: è la gestione di Node sul sistema. In quel caso conviene correggere l’installazione di Node o usare Corepack, non aggiungere eccezioni di permessi che poi si trascinano nel tempo.

Installazione su Ubuntu 22.04 e 20.04 con NodeSource e Corepack

Su Ubuntu 22.04 e 20.04, se vuoi un impianto stabile, puoi installare Node da un repository affidabile e poi usare Corepack. Questo è un buon compromesso tra semplicità operativa e controllo delle versioni.

Flusso tipico:

  1. Aggiorna l’indice pacchetti.
  2. Installa Node.js.
  3. Abilita Corepack.
  4. Attiva PNPM.
sudo apt update
sudo apt install -y nodejs
node -v
corepack enable
pnpm -v

Se il pacchetto nodejs dai repository Ubuntu è troppo vecchio per il tuo caso d’uso, valuta un repository più aggiornato o un metodo di gestione versione diverso. La scelta dipende dal ruolo della macchina: su un server applicativo vuoi stabilità, su una macchina di build vuoi spesso una versione più recente per allinearti al progetto.

Nota pratica: su alcune installazioni, il comando node è presente ma npm o corepack no. Questo è un segnale che stai usando un pacchetto incompleto o una build non standard. Prima di continuare, verifica il pacchetto installato e il path effettivo dei binari.

Verifica che PNPM sia davvero quello atteso

Installare non basta: va verificato che la shell stia usando il binario giusto. Su sistemi con più installazioni di Node, è facile ritrovarsi con un pnpm diverso da quello previsto. Il controllo minimo è questo:

pnpm -v
which pnpm
pnpm store path

pnpm -v ti dice la versione effettiva. which pnpm ti mostra il path risolto dalla shell. pnpm store path è utile perché ti fa vedere dove PNPM conserva il content-addressable store: sapere questo aiuta quando devi fare troubleshooting di spazio disco o di permessi utente.

Se il comando non viene trovato dopo l’abilitazione di Corepack, apri una nuova shell o ricarica il profilo utente. In alcuni casi il problema è banale: il path non è ancora stato aggiornato nella sessione corrente.

Uso corretto in un progetto: file packageManager e lockfile

Il punto forte di PNPM non è solo la velocità. È il controllo della riproducibilità. Se nel progetto imposti la versione tramite packageManager, chiunque apra il repository capisce subito quale release usare. Questo riduce le differenze tra laptop, runner CI e server di deploy.

Un esempio di package.json minimale:

{ "name": "app", "private": true, "packageManager": "pnpm@9.15.0"
}

Con questo approccio, Corepack sa quale versione usare e non dipendi da un’installazione globale arbitraria. Se il lockfile è generato con una versione diversa, il team lo vede subito nei diff e può decidere se allineare tutto o mantenere una versione precisa per compatibilità.

Per inizializzare un progetto o installare dipendenze:

pnpm init
pnpm install
pnpm add express
pnpm remove express

Su macchine di produzione, evita di installare dipendenze “al volo” senza una policy chiara. Se PNPM serve per build o deployment, definisci un percorso ripetibile e documentato; se serve solo a sviluppo, non installarlo come requisito runtime del servizio.

Problemi tipici su Ubuntu: path, permessi e versioni doppie

Il problema più frequente non è l’installazione in sé, ma il fatto che esistano più Node nello stesso sistema. Capita spesso su Ubuntu quando si passa da pacchetti di distro a NodeSource, oppure da un’installazione manuale a NVM. Risultato: pnpm funziona in una shell ma non in un servizio, o viceversa.

Per capire cosa sta succedendo, guarda questi punti:

  1. which node e which pnpm per il path reale.
  2. echo $PATH per l’ordine delle directory.
  3. npm config get prefix per il prefisso globale.
  4. systemctl show <servizio> -p Environment se il problema appare solo in un servizio.
echo $PATH
which node
which pnpm
npm config get prefix

Se il servizio systemd non vede PNPM ma la shell sì, il problema è quasi sempre l’ambiente del servizio. In quel caso non devi “inventarti” un path casuale: devi esplicitare il percorso del binario o usare un ambiente coerente con quello dell’utente che esegue il processo.

Un’altra fonte di problemi è il permesso sulla directory dello store. Se il processo gira con un utente diverso da quello che ha creato lo store, le installazioni possono fallire o diventare lente. In ambienti multiutente, meglio definire uno store per utente o una strategia di build ben separata.

Aggiornare PNPM senza rompere l’ambiente

Con Corepack, l’aggiornamento è gestibile in modo ordinato: cambi la versione nel progetto o aggiorni l’attivazione del package manager. Con un’installazione globale via npm, invece, l’aggiornamento è più diretto ma anche più facile da dimenticare.

Se usi Corepack, controlla il file di progetto e poi sincronizza la versione:

cat package.json | grep packageManager
corepack prepare pnpm@9.15.0 --activate
pnpm -v

Se invece hai PNPM installato globalmente:

npm install -g pnpm@latest
pnpm -v

In entrambi i casi, dopo l’aggiornamento verifica che i workflow di build continuino a funzionare. La metrica pratica qui non è “la versione è salita”, ma “pnpm install produce lo stesso lockfile o un diff atteso”. Se il lockfile cambia in modo anomalo, fermati e controlla la compatibilità.

Disinstallazione e rollback pulito

Se PNPM è stato installato male o vuoi tornare indietro, il rollback dipende dal metodo usato. È importante non lasciare residui che confondono la shell o il sistema di build.

Rollback con installazione globale via npm:

npm uninstall -g pnpm
hash -r
which pnpm

Rollback con Corepack: disabilita o rimuovi l’attivazione, poi verifica che il comando non sia più esposto dalla shell corrente. Se il progetto ha un packageManager dichiarato, ricordati che il repo continuerà a chiedere quella versione finché non la cambi.

Se stai correggendo un server di produzione o una macchina condivisa, fai sempre un backup del file di configurazione o annota il metodo di installazione prima di toccare i binari. Il blast radius è basso, ma un path sbagliato può bloccare pipeline, hook o job automatizzati.

Scelta pratica finale per Ubuntu 22.04 e 20.04

Se vuoi una raccomandazione netta: su Ubuntu 22.04 e 20.04 usa Node aggiornato + Corepack. È il compromesso più pulito per sviluppo, CI e ambienti controllati. Usa l’installazione globale di PNPM solo quando hai un motivo preciso e accetti il costo di manutenzione.

In sintesi operativa: prima sistemi Node, poi abiliti Corepack, poi verifichi pnpm -v e which pnpm. Se la versione non è quella attesa, non continuare a installare pacchetti a caso: risolvi il path, la shell o il metodo di provisioning. È lì che si evita il 90% dei guasti “strani”.