Three.js r185 toglie il codice deprecato: i rischi per il 3D

In sintesi

• Three.js r185 ha eliminato il codice segnato come deprecato nelle release precedenti, come indicato nella pull request #33407 del progetto.
• Il rischio concreto non è “se” ma “quando”: un lock file rigenerato, cancellato o mai salvato nel sistema di controllo versione fa scattare l’aggiornamento in automatico.
• Anche senza toccare il lock file, un aggiornamento di routine può portare dentro r185 se la versione non è fissata a un numero preciso. A quel punto il codice deprecato non c’è più, punto.
• Chi gestisce configuratori 3D, showroom virtuali o esperienze immersive in produzione deve sapere chi, in azienda o tra i fornitori, è responsabile di questa verifica.
• Un blocco in produzione ha un costo misurabile: vendite ferme, richieste di assistenza, un cliente che prova ad aprire il tour virtuale e trova una pagina bianca.

Cosa è cambiato davvero in Three.js r185

Three.js è la libreria più usata per costruire scene tridimensionali nel browser. Configuratori di prodotto, tour virtuali, visualizzatori per ecommerce: se un oggetto ruota in 3D su un sito, probabilmente dietro c’è questa libreria. Come ogni progetto che vive da anni, accumula codice deprecato, funzioni superate ma lasciate attive solo per non rompere i progetti più vecchi.

Con r185, documentata nella pull request #33407, il team guidato dal maintainer Mugen87 ha rimosso quel codice in blocco. La pull request è intitolata semplicemente “Remove deprecated code” e riguarda l’intero repository, non un singolo modulo. Le funzioni che fino a ieri generavano solo un avviso in console oggi sono sparite.

Non è la prima rimozione nella storia di Three.js. È la prima volta che succede tutto insieme, invece che un metodo alla volta nel tempo. Questa scelta, concentrare anni di debito tecnico in una sola release, rende il rischio più acuto del solito: chi ha ignorato gli avvisi per mesi si ritrova oggi senza margine di manovra.

Perché questo riguarda chi gestisce un’esperienza 3D in produzione

Hai commissionato un configuratore 3D negli ultimi anni? È probabile che usi almeno una delle funzioni ora rimosse. Finché il progetto resta ancorato a una versione precedente, non cambia nulla. Continua a funzionare.

Il problema si attiva in due situazioni. La prima riguarda il lock file: il documento che fissa quale versione esatta della libreria viene usata, proprio per evitare che un aggiornamento automatico cambi le cose senza preavviso. Se quel file viene rigenerato per errore, cancellato, o non è mai stato salvato correttamente nel sistema di controllo versione, il prossimo aggiornamento può portare dentro r185 senza che nessuno se ne accorga. Fino a quando il sito smette di funzionare.

La seconda situazione è più subdola. Anche con il lock file al suo posto, se la versione indicata non è bloccata a un numero preciso ma lasciata aperta ad aggiornamenti minori futuri, un aggiornamento di routine può comunque introdurre r185. Il lock file gestisce quando arriva l’aggiornamento. Non impedisce che il codice deprecato, una volta arrivata quella versione, semplicemente non ci sia più.

Un configuratore sviluppato due o tre anni fa, con dipendenze mai più toccate da allora, può smettere di funzionare per un aggiornamento innescato da un fornitore esterno o da una manutenzione di routine. Il cliente che prova ad aprire il link trova una pagina bianca. Nessuno ha rotto niente. È scaduto il margine di compatibilità, e nessuno se n’era accorto prima.

Cosa fare se non gestisci direttamente il codice

Non devi aprire il codice sorgente. Questo compito spetta a chi ha scritto o mantiene il progetto, in azienda o tra i fornitori esterni. Quello che puoi fare è porre la domanda giusta: la versione di Three.js è fissata con un lock file committato, ed è precedente a r185 o già aggiornata? Se chi risponde non sa cosa sia un lock file, è già un segnale che vale la pena approfondire.

Se l’esperienza 3D genera direttamente ordini o preventivi, la domanda successiva riguarda i soldi: quante richieste passano ogni settimana da quello strumento, e quanto costerebbe restare fuori uso qualche giorno mentre si cerca una soluzione? Anche una stima approssimativa trasforma una questione tecnica in una priorità aziendale con un budget reale.

Ed è qui il punto più scomodo. Il mondo dello sviluppo web tratta da anni gli avvisi di deprecazione come rumore di fondo, qualcosa da ignorare finché non diventa un’emergenza. Le librerie open source comunicano con largo anticipo cosa sta per essere rimosso. Quella comunicazione, però, resta quasi sempre dentro la console dello sviluppatore: non arriva mai a chi decide i budget. Il risultato è prevedibile. La responsabilità si scarica su chi gestisce il business proprio nel momento peggiore, quando la pagina è già bianca e il cliente è già al telefono. Ed è un meccanismo che nessuno nella filiera ha interesse reale a correggere, perché finché il sito funziona nessuno chiede chi stia pagando il debito tecnico accumulato.

Le librerie open source continuano a evolvere, e r185 non sarà l’ultima pulizia di questo tipo. Un monitoraggio periodico delle dipendenze, anche solo trimestrale, costa una frazione di un blocco non previsto in produzione nel giorno sbagliato. Decidere come e quando migrare resta un compito tecnico. Decidere se stanziare tempo e budget per prevenire il rischio prima che diventi un’emergenza, invece, è una scelta di chi gestisce il business, e che troppo spesso viene rimandata fino a quando è troppo tardi per rimandarla ancora.

Domande correlate

Cosa succede se non aggiorno subito a Three.js r185?

Nulla, finché il progetto resta fissato su una versione precedente tramite il lock file. Il rischio si attiva solo quando un aggiornamento automatico o manuale introduce r185 senza che il codice sia stato prima verificato e adattato.

Come faccio a sapere se il mio progetto usa Three.js?

Chiedi al team tecnico o al fornitore che ha sviluppato l’esperienza 3D quale libreria è stata usata per il rendering tridimensionale. Se la risposta è Three.js, chiedi anche quale versione è installata e se è fissata con un lock file.

Quanto costa un audit per verificare questo rischio?

Dipende dalla complessità del progetto, ma è una verifica mirata e circoscritta. Costa molto meno di un intervento d’emergenza su un sistema già bloccato in produzione. Chiedi un preventivo specifico per la valutazione di compatibilità con r185.

Chi è responsabile se l’esperienza 3D smette di funzionare?

Dipende dal contratto con il fornitore che ha sviluppato il progetto. Se la manutenzione non è esplicitamente inclusa, verifica subito chi ha in carico il monitoraggio delle dipendenze tecniche, prima che il problema si presenti davvero.

Fonti:

• Global Remove deprecated code. #33407 (@Mugen87), three.js releases: https://github.com/mrdoob/three.js/releases (accesso ottobre 2026)