Come il tuo sito indica la versione di Node che gli serve
Nel package.json, engines avvisa chi installa il pacchetto, salvo engine-strict. devEngines controlla chi lavora sul codice, prima di install, ci e run. Nessuno dei due installa Node.
In questa guida (3)
Chi pubblica un sito con Node ha bisogno di dire quale versione gli serve. Nel package.json ci sono due campi che sembrano la stessa frase e non fanno lo stesso lavoro. Il 5 novembre 2026 ho letto la documentazione del CLI npm in versione 11, le pagine package.json e config. Non ho lanciato npm su un server.
Le pagine sono package.json e la configurazione del CLI. Quale linea di Node convenga a un progetto è un altro pezzo, Node.js LTS: quale versione scegliere per un progetto. Il comando che reinstalla le versioni già fissate, e che devEngines dichiara di precedere, sta in npm ci o npm install.
Il campo che avvisa chi installa il pacchetto
La pagina package.json dice che engines indica la versione di Node su cui il programma funziona. L'esempio stampato è un oggetto con node impostato a un intervallo che parte da 0.10.3 e si ferma prima di 15. È l'esempio del manuale, non un intervallo da copiare. Se la versione manca, o se il valore è un asterisco, va bene qualunque Node. Lo stesso campo può indicare quale versione di npm è in grado di installare il programma. L'esempio del manuale, anche questo da non copiare, usa una tilde su 1.0.20.
Senza il flag engine-strict, il campo è solo un avviso. La stessa pagina precisa che produce warning quando il pacchetto viene installato come dipendenza. Non ho allargato questa frase alle installazioni fatte dentro il repository: il testo parla della dipendenza.
engine-strict, sulla pagina config, ha default false. Se è true, npm rifiuta di installare, e anche di prendere in considerazione, un pacchetto che dichiara di non essere compatibile con la versione di Node in uso. Il flag force scavalca quel rifiuto.
Il campo che ferma chi lavora sul codice
devEngines è un altro oggetto. La pagina dice che parte prima dei comandi install, ci e run. La forma non è quella di engines. engines, scrive la nota, avvisa quando una dipendenza usa un Node o un npm diversi da quelli del progetto in cui viene usata. devEngines avvisa chi lavora sul codice sorgente del progetto.
Le chiavi ammesse sono cpu, os, libc, runtime e packageManager. Ogni voce è un oggetto, oppure un array di oggetti. L'oggetto deve avere name e può avere version e onFail. onFail vale warn, error o ignore. Se manca, vale error. npm assume che il runtime sia node. Se runtime.name o packageManager.name sono una stringa diversa, il CLI fallisce. L'esempio del manuale mette un runtime di nome node con onFail error, e un packageManager di nome npm con onFail error.
Che cosa scrivere, e che cosa il file non fa
Se il sito è una libreria che altri installano, il campo che il manuale lega all'avviso verso chi la installa è engines. Se devono fermarsi le persone che lavorano in quel repository, il manuale assegna il controllo a devEngines, e onFail di default è un errore. I due campi non installano Node sulla macchina e non cambiano la versione scelta nel pannello di hosting. Quella scelta resta fuori da package.json. Il numero da scrivere, quando serve una linea ancora aggiornata, si decide nel pezzo sulla LTS.
La fotografia è lo schedario a cassetti della Indiana State Library, di TBurmeister (Wikimedia Foundation), 4 ottobre 2024 alle 19:14, licenza CC BY-SA 4.0. È un catalogo cartaceo. Non è il package.json del sito.
