Nos últimos meses, temos trabalhado em um novo sistema de build para código JavaScript de plugins. Isso trará os plugins em conformidade com as mudanças que fizemos no sistema de build de temas em julho de 2025, que dependem de tecnologias de navegador mais modernas e de ferramentas de construção de JS.
Essa mudança é amplamente compatível com versões anteriores. A maioria dos desenvolvedores de plugins não precisará fazer nada. 
Benefícios
Além da modernização nos bastidores, essa mudança trará diversos benefícios funcionais para desenvolvedores e administradores do Discourse:
-
Os ativos dos plugins são fortemente armazenados em cache e são indexados por plugin. Isso significa que reiniciar seu servidor em desenvolvimento não exigirá a reconstrução de todos os plugins do zero.
-
Podemos começar a incluir código pré-compilado para plugins populares em nossos pacotes de ativos existentes. Durante uma reconstrução, apenas plugins alterados/novos precisarão ser compilados. Isso deve ser especialmente útil para máquinas com recursos limitados.
-
O código do plugin será transpilado para um módulo ES nativo. Isso traz uma sintaxe muito mais simples, execução mais rápida no navegador e desbloqueia o uso futuro de recursos como
import()para divisão de pacotes no futuro.
Testes / Cronograma
Temos testado esse sistema internamente há algum tempo e verificamos sua funcionalidade em centenas de plugins oficiais. O Meta vem operando com o novo sistema há semanas.
Se você quiser testá-lo, pode definir a variável de ambiente ROLLUP_PLUGIN_COMPILER=1.
Planejamos alterar o padrão muito em breve. Haverá um breve período em que o novo sistema poderá ser desativado usando ROLLUP_PLUGIN_COMPILER=0, caso surjam surpresas, mas pretendemos manter o período de transição ao mínimo.
Possíveis problemas com plugins complexos
Para plugins mais complexos, há algumas coisas sobre as quais o novo sistema é mais rigoroso:
-
Importar módulos de administração a partir de código não-administrativo agora gerará uma exceção. Isso sempre foi desencorajado e causaria erros surpreendentes. Agora, isso é detectado e bloqueado de forma mais deliberada.
Se você encontrar esse problema, deve considerar se o código do seu plugin estaria melhor localizado no diretório admin-js (
admin/assets/javascripts/...). Se você realmente precisar importar condicionalmente módulos de administração, deve usar o helperoptionalRequiredo núcleo para realizar isso. -
Importações entre plugins ainda são suportadas. No entanto, de forma semelhante aos módulos de administração, importar módulos de um plugin que não está instalado/ativado agora gerará um erro muito mais óbvio. Se a dependência entre plugins for intencionalmente opcional, você deve usar o helper
optionalRequiredo núcleo. -
Mudanças sutis de tempo podem causar problemas em casos raros. Agora que o código do plugin está sendo compilado para módulos ES nativos, tudo no escopo do módulo está sendo executado imediatamente. Se você tiver alguma lógica incomum no escopo do módulo, ela pode precisar ser movida para o código de execução (por exemplo, dentro de um construtor de classe ou similar).
Se você encontrar algum desses problemas e precisar de ajuda para resolvê-los, não hesite em postar abaixo.
Erros de CORS / Access-Control-Allow-Origin
Se você encontrar erros de CORS após a atualização e usar uma CDN, deve executar uma reconstrução completa via CLI (./launcher rebuild app) para incluir essa alteração na configuração do NGINX.
Se você usar armazenamento S3 (ou compatível com S3) para ativos, precisará configurar sua CDN para adicionar o cabeçalho de resposta Access-Control-Allow-Origin: * a todos os ativos.
