Come installare Node.js e NPM su Rocky Linux 8 e AlmaLinux

Installare Node.js e NPM su Rocky Linux 8 e AlmaLinux senza dipendere dai pacchetti vecchi

Su Rocky Linux 8 e AlmaLinux la scelta giusta, nella maggior parte dei casi, non è prendere il Node.js del repository base e sperare che basti. Per ambienti di sviluppo, deploy applicativi e server che ospitano framework moderni, conviene usare il repository ufficiale di NodeSource oppure, quando serve allinearsi a una versione precisa per progetto, gestire il runtime in modo esplicito. Qui parto dal caso più comune: installazione pulita di Node.js e NPM su una macchina RHEL-like recente, con procedura ripetibile e controlli finali per evitare sorprese.

Il punto non è solo “farlo partire”. Il punto è avere una versione prevedibile, aggiornabile e verificabile, senza mischiare troppi canali di distribuzione. Se installi Node da sorgenti diverse, in poco tempo ti ritrovi con binari duplicati, PATH confusi e dipendenze native che compilano contro librerie non coerenti. Su un server vero, questa è la strada più veloce per perdere tempo in troubleshooting.

Scelta del metodo: repository ufficiale o gestore versioni

Per Rocky Linux 8 e AlmaLinux ci sono tre strade pratiche:

• Repository ufficiale NodeSource: ideale se vuoi una versione stabile di Node.js di sistema, con aggiornamenti via dnf.
• Gestore versioni come nvm: utile su workstation o ambienti multi-progetto, meno adatto come runtime di sistema per servizi gestiti da systemd.
• Pacchetti del repository distro: comodi, ma spesso vecchi; li userei solo se il progetto è vincolato a quella release o per test rapidi.

Se devi installare Node.js su una macchina che eroga un servizio, la scelta più lineare è NodeSource. Se invece lavori su più progetti con requisiti diversi, nvm ha senso, ma devi accettare che l’ambiente sia per utente e non per sistema. In questa guida mi concentro sulla via più robusta per server Linux: repository ufficiale e installazione con dnf.

Prerequisiti minimi e verifica della base OS

Prima di toccare i pacchetti, conviene verificare che il sistema sia effettivamente Rocky Linux 8 o AlmaLinux e che dnf funzioni correttamente. Non è un dettaglio: su sistemi clonati o convertiti da altre distribuzioni, i repo possono essere sporchi o disallineati.

Controlla versione e release con questi comandi:

cat /etc/os-release
rpm -q rocky-release almalinux-release
uname -r

Ti aspetti un output coerente con la distro in uso. Se rocky-release o almalinux-release non risultano installati, fermati e chiarisci la base del sistema prima di aggiungere repository esterni. È un controllo banale, ma evita di inseguire problemi che nascono da una macchina già fuori standard.

Installazione di Node.js e NPM con NodeSource

Il flusso tipico è questo: importi lo script del repository, aggiorni la cache dei pacchetti e installi Node.js. Lo script di NodeSource configura il repository corretto per la major version che scegli. Per esempio, se vuoi una LTS recente, puoi usare la serie 20 o 22 a seconda della compatibilità del progetto.

Procedura consigliata:

sudo dnf -y install curl ca-certificates
curl -fsSL https://rpm.nodesource.com/setup_20.x | sudo bash -
sudo dnf -y install nodejs

Dopo l’installazione, verifica versione e presenza di NPM:

node -v
npm -v
which node
which npm

In condizioni normali, node -v e npm -v devono restituire versioni coerenti con la release scelta, mentre which deve puntare a un percorso in /usr/bin o equivalente gestito dal pacchetto installato. Se trovi binari in /usr/local/bin o in percorsi strani, probabilmente esiste già un’installazione manuale che va chiarita prima di proseguire.

Cosa installa davvero il pacchetto nodejs

Su molte distribuzioni, il pacchetto nodejs include già anche NPM. Questo significa che non devi inseguire un pacchetto separato a meno che il repository scelto non lo spezzi in componenti distinti. Il punto operativo è semplice: una volta installato nodejs, controlla sempre che la coppia Node/NPM sia allineata e che l’ambiente non stia pescando versioni residue da installazioni precedenti.

Per una verifica più completa, esegui:

rpm -qi nodejs
rpm -ql nodejs | head
node -p "process.versions"
npm config get prefix

npm config get prefix è utile per capire dove verranno installati i pacchetti globali. Su un server, questa informazione serve più di quanto sembri: se il prefix non è quello atteso, i moduli globali possono finire in un percorso non incluso nel PATH del servizio o dell’utente operativo.

Quando usare nvm invece del repository di sistema

nvm è comodo quando devi passare da una versione all’altra senza toccare il sistema. È una scelta sensata per sviluppatori, ambienti di test e macchine dove più progetti convivono con requisiti diversi. Però ha un limite strutturale: vive dentro la shell dell’utente. Se poi il codice gira come servizio, devi assicurarti che il servizio erediti lo stesso ambiente, cosa che spesso non è vera e porta a errori del tipo “node: command not found” in produzione, anche se in login shell tutto sembra a posto.

Se vuoi comunque usare nvm, la logica è questa:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install --lts
node -v
npm -v

Nota operativa: con nvm, il binario non sta nel percorso di sistema classico. Se devi esporre un’app con systemd, conviene evitare il “funziona nel mio terminale” e definire esplicitamente il percorso del binario o usare il pacchetto di sistema. In altri termini, nvm è ottimo per il laptop; sul server va usato con disciplina.

Verifica del funzionamento con un test minimo

Dopo l’installazione non basta vedere la versione. Serve anche un test minimo che confermi che Node esegue JavaScript e che NPM riesce a inizializzare un piccolo progetto. Questo intercetta problemi di permessi, PATH e dipendenze di runtime prima di arrivare al deploy dell’app vera.

Esegui una prova locale in una directory temporanea:

mkdir -p /tmp/node-test && cd /tmp/node-test
node -e "console.log('node ok')"
npm init -y
npm install lodash

Se npm init -y crea correttamente il file package.json e npm install lodash completa senza errori, hai una base affidabile. Se invece compaiono errori di rete, TLS o permessi, il problema non è l’installazione di Node in sé, ma l’ambiente del server: proxy, CA certificate, DNS o policy di filesystem.

Aggiornare Node.js senza rompere i servizi

Il vero valore di usare un repository gestito è poter aggiornare in modo controllato. Su server applicativi conviene separare aggiornamento del runtime e restart del servizio. Prima verifichi la nuova versione in staging o su una macchina identica, poi pianifichi il cambio in finestra controllata.

Per aggiornare una installazione da repository:

sudo dnf -y update nodejs
node -v
npm -v

Se l’app è gestita da systemd, dopo l’aggiornamento controlla lo stato del servizio e i log recenti:

systemctl status nome-servizio --no-pager
journalctl -u nome-servizio -n 100 --no-pager

Il criterio pratico è questo: se il servizio continua a partire e l’app risponde, l’aggiornamento è andato bene. Se fallisce, non inseguire subito il runtime: confronta prima la versione di Node richiesta dall’app, gli eventuali moduli nativi e il contenuto di package-lock.json. Spesso il problema è un modulo compilato contro ABI diversa, non il binario di Node in sé.

Problemi frequenti e come riconoscerli in pochi minuti

Ci sono alcuni errori ricorrenti che vale la pena riconoscere al volo. Il primo è la presenza di più installazioni contemporanee. Se node -v restituisce una versione, ma il servizio ne usa un’altra, hai quasi certamente un conflitto di PATH o un ambiente shell diverso da quello del demone.

Il secondo è l’assenza di NPM nel percorso atteso. In questo caso controlla il pacchetto effettivamente installato e il contenuto di rpm -ql nodejs. Il terzo è il fallimento di installazione di moduli con binding nativi, tipico di node-gyp e simili. Su Rocky e Alma spesso serve il gruppo di sviluppo base e qualche tool di compilazione:

sudo dnf -y groupinstall "Development Tools"
sudo dnf -y install python3 make gcc-c++

Questi pacchetti non servono a Node.js in sé, ma servono ai moduli che compilano componenti nativi. Se il tuo stack usa solo JavaScript puro, puoi anche non averne bisogno. Se invece installi librerie come driver, parser o componenti che dipendono da C/C++, devi considerare questa parte come prerequisito operativo.

Disinstallazione pulita e ripristino

Se devi rimuovere Node.js, fallo in modo pulito e verifica che non restino repository o configurazioni inutili. La rimozione del pacchetto è semplice, ma il vero rischio è lasciare in giro script, symlink o cache di NPM che confondono i successivi tentativi di installazione.

Per un’installazione da repository di sistema:

sudo dnf -y remove nodejs
sudo dnf clean all
hash -r

Se hai usato NodeSource e vuoi togliere anche il repository, controlla i file in /etc/yum.repos.d/ e rimuovi solo quello relativo a NodeSource, dopo aver verificato che non serva ad altri host. In caso di rollback, reinstalla il pacchetto dalla stessa major version precedentemente in uso, così riduci il rischio di incompatibilità con lockfile e moduli compilati.

Scelta pratica per ambienti server

Se stai preparando una macchina per ospitare un’app Node.js, la regola pratica è questa: repository ufficiale per il runtime di sistema, nvm solo dove il vantaggio operativo supera il costo della gestione dell’ambiente. Su Rocky Linux 8 e AlmaLinux, la via più pulita resta una versione LTS installata da repository, verificata con node -v e npm -v, e poi agganciata a un servizio con percorsi espliciti e log leggibili.

Il vantaggio non è solo tecnico ma anche manutentivo: quando tra tre mesi andrai a fare troubleshooting, troverai un’installazione prevedibile, un’origine chiara dei pacchetti e meno variabili nascoste. In ambienti Linux questo vale più di una guida veloce che funziona solo al primo colpo.