Negli ultimi mesi, abbiamo lavorato a un nuovo sistema di build per il codice JavaScript dei plugin. Questo porterà i plugin in linea con le modifiche apportate al sistema di build dei temi a luglio 2025, che si basano su tecnologie browser più moderne e su strumenti di build JS.
Questo cambiamento è in gran parte retrocompatibile. La maggior parte degli autori di plugin non dovrà fare nulla. 
Vantaggi
Oltre alla modernizzazione “dietro le quinte”, questo cambiamento porterà numerosi vantaggi funzionali agli sviluppatori e agli host di Discourse:
-
Le risorse dei plugin sono fortemente memorizzate nella cache e sono indicizzate per singolo plugin. Ciò significa che il riavvio del server in ambiente di sviluppo non richiederà la ricompilazione completa di tutti i plugin da zero.
-
Possiamo iniziare a includere codice precompilato per i plugin più popolari nei nostri pacchetti di risorse esistenti. Durante una ricompilazione, saranno necessari build solo per i plugin modificati o nuovi. Questo dovrebbe essere particolarmente utile per macchine con risorse limitate.
-
Il codice dei plugin verrà trasformato in un modulo ES nativo. Ciò garantisce una sintassi molto più semplice, un’esecuzione più rapida nel browser e apre la strada a futuri utilizzi di funzionalità come
import()per la suddivisione dei bundle.
Test / Cronoprogramma
Abbiamo testato questo sistema internamente per un certo periodo e ne abbiamo verificato il funzionamento su centinaia di plugin ufficiali. Meta utilizza il nuovo sistema da settimane.
Se desideri provarlo, puoi impostare la variabile d’ambiente ROLLUP_PLUGIN_COMPILER=1.
Pianifichiamo di cambiare l’impostazione predefinita molto presto. Ci sarà un breve periodo in cui il nuovo sistema potrà essere disabilitato impostando ROLLUP_PLUGIN_COMPILER=0, nel caso di imprevisti, ma intendiamo mantenere al minimo il periodo di transizione.
Possibili problemi con plugin complessi
Per i plugin più complessi, ci sono alcune aree in cui il nuovo sistema è più rigoroso:
-
Importazione di moduli amministrativi da codice non amministrativo genererà ora un’eccezione. Questo è stato sempre sconsigliato e avrebbe causato errori imprevisti. Ora tale situazione viene rilevata e bloccata in modo più deliberato.
Se incontri questo problema, valuta se il codice del tuo plugin sarebbe meglio collocato nella directory admin-js (
admin/assets/javascripts/...). Se hai davvero bisogno di importare condizionalmente moduli amministrativi, dovresti utilizzare l’helperoptionalRequiredel core per farlo. -
Importazioni tra plugin sono ancora supportate. Tuttavia, analogamente ai moduli amministrativi, importare moduli da un plugin non installato o abilitato genererà ora un errore molto più evidente. Se la dipendenza tra plugin è intesa come opzionale, dovresti utilizzare l’helper
optionalRequiredel core. -
Sottili cambiamenti temporali possono causare problemi in rari casi. Ora che il codice dei plugin viene compilato in moduli ES nativi, tutto ciò che è nell’ambito del modulo viene eseguito immediatamente. Se avevi una logica insolita nell’ambito del modulo, potrebbe essere necessario spostarla nel codice di runtime (ad esempio, all’interno di un costruttore di classe o simili).
Se incontri uno di questi problemi e hai bisogno di aiuto per risolverli, non esitare a scrivere qui sotto.
Errori CORS / Access-Control-Allow-Origin
Se dopo l’aggiornamento riscontri errori CORS e utilizzi una CDN, dovresti eseguire una ricompilazione completa tramite CLI (./launcher rebuild app) per applicare questa modifica alla configurazione NGINX.
Se utilizzi archiviazione S3 (o compatibile con S3) per le risorse, devi configurare la tua CDN per aggiungere l’intestazione di risposta Access-Control-Allow-Origin: * a tutte le risorse.
