Preparate i caffè rinforzati e i manuali di troubleshooting, perché il mondo Node.js sta per diventare molto più burocratico.
Se pensavate che la vostra vita da sviluppatore fosse già abbastanza complicata tra bug di regressione e dipendenze che si romponi da sole, la notizia che arriva dal team di npm vi farà venire voglia di tornare ai bei vecchi tempi del C++ compilato a mano. Con l’arrivo della versione 12 di npm (prevista per luglio 2026), la filosofia del «scarica e spera che non succeda nulla di male» sta ufficialmente tramontando.
In parole povere: npm sta decidendo di smettere di fidarsi di chiunque. Il grosso della novità riguarda la sicurezza, ma per noi che amiamo smanettare con pacchetti di terze parti, le implicazioni sono pesanti. Il cambiamento principale è che l’opzione ‘allowScripts’ passerà di default su ‘off’. Cosa significa? Che i classici script di preinstall, install e postinstall — quelli che spesso servono a compilare moduli nativi con node-gyp o a configurare l’ambiente — non verranno più eseguiti automaticamente. Se un pacchetto ha bisogno di far girare del codice per installarsi correttamente, npm lo bloccherà finché non sarai tu a dirgli esplicitamente: «Ok, mi fido di questo tizio’.
E non finisce qui. Anche le dipendenze che arrivano direttamente da Git o da URL remoti (i famosi tarball) non verranno più risolte senza il tuo consenso esplicito tramite flag come ‘–allow-git’ o ‘–allow-remote’. In pratica, npm sta costruendo un vero e proprio checkpoint doganale per ogni singola dipendenza che entra nel tuo progetto.
Dal punto di vista della sicurezza, devo ammettere che è una mossa geniale. Chi non vorrebbe eliminare alla radice quella pratica sporca di far girare codice arbitrario al primo ‘npm install’? È una manovra che chiude falle enormi legate all’iniezione di codice malevolo tramite script nascosti. Se la guardiamo con l’occhio dell’hacker, è una difesa basata sul principio del ‘least privilege’ che fa la sua figura.
Però, parliamoci chiaro: per noi che amiamo costruire prototipi veloci, che scarichiamo librerie sperimentali per vedere se funzionano in un progetto Godot o che integriamo pezzi di codice presi dal web per una macchina CNC, questa è una seccatura monumentale. Il workflow diventerà più lento. Dovremo passare del tempo a revisionare i warning, usare ‘npm approve-scripts’ e aggiornare il nostro package.json con liste di permessi sempre più lunghe. È l’incubo di ogni maker: la fine della libertà creativa in favore di un ecosistema iper-controllato.
Il consiglio pratico? Non aspettate il 2026 per trovarvi in crisi. Se usate già npm 11.16.0 o versioni successive, iniziate a guardare i warning che appaiono durante l’installazione. Create la vostra whitelist ora, così quando arriverà il grande upgrade, l’unica cosa che dovrete fare sarà un commit e non una notte intera a cercare perché il modulo ‘sass’ non riesce più a compilare.
In definitiva: meno magia, più controllo. Un po’ come quando smonti un vecchio arcade e ti rendi conto che ogni singolo contatto deve essere pulito e testato, invece di sperare che la polvere non faccia corto circuito. Un po’ meno divertente, ma decisamente più sicuro.