In den letzten Monaten haben wir an einem neuen Build-System für JavaScript-Code von Plugins gearbeitet. Dies bringt Plugins auf den Stand der Änderungen, die wir im Juli 2025 am Theme-Build-System vorgenommen haben, und setzt dabei auf modernere Browser-Technologien und JS-Build-Tools.
Diese Änderung ist größtenteils abwärtskompatibel. Die meisten Plugin-Autoren müssen nichts unternehmen. 
Vorteile
Neben der Modernisierung im Hintergrund bringt diese Änderung eine Reihe funktionaler Vorteile für Discourse-Entwickler und Hosts:
-
Plugin-Assets werden stark gecacht und sind pro Plugin getrennt indiziert. Das bedeutet, dass beim Neustart Ihres Servers in der Entwicklung nicht alle Plugins von Grund auf neu erstellt werden müssen.
-
Wir können beginnen, vorab kompilierten Code für beliebte Plugins in unsere bestehenden Asset-Bundles aufzunehmen. Während eines Neubuilds müssen nur geänderte/neue Plugins erstellt werden. Dies sollte besonders für ressourcenbeschränkte Maschinen nützlich sein.
-
Plugin-Code wird in ein natives ES-Modul transpiliert. Dies ermöglicht eine deutlich einfachere Syntax, schnellere Ausführung im Browser und ebnet den Weg für zukünftige Funktionen wie
import()zum Aufteilen von Bundles.
Testing / Zeitplan
Wir testen dieses System seit einiger Zeit intern und haben seine Funktionalität an hunderten offiziellen Plugins verifiziert. Meta läuft seit Wochen mit dem neuen System.
Wenn Sie es selbst ausprobieren möchten, können Sie die Umgebungsvariable ROLLUP_PLUGIN_COMPILER=1 setzen.
Wir planen, den Standard sehr bald zu ändern. Es wird eine kurze Phase geben, in der das neue System mit ROLLUP_PLUGIN_COMPILER=0 deaktiviert werden kann, falls es zu unerwarteten Problemen kommt. Wir beabsichtigen jedoch, die Übergangszeit so kurz wie möglich zu halten.
Mögliche Probleme bei komplexen Plugins
Bei komplexeren Plugins gibt es einige Punkte, bei denen das neue System strenger ist:
-
Das Importieren von Admin-Modulen aus nicht-Admin-Code löst nun eine Ausnahme aus. Dies wurde bereits immer abgeraten und würde zu überraschenden Fehlern führen. Jetzt wird dies gezielter erkannt und blockiert.
Wenn Sie auf dieses Problem stoßen, sollten Sie überlegen, ob Ihr Plugin-Code besser im
admin-js-Verzeichnis (admin/assets/javascripts/...) platziert werden sollte. Falls Sie wirklich bedingte Importe von Admin-Modulen benötigen, sollten Sie denoptionalRequire-Helper des Kerns verwenden. -
Querverweise zwischen Plugins werden weiterhin unterstützt. Ähnlich wie bei Admin-Modulen löst das Importieren von Modulen aus einem nicht installierten/deaktivierten Plugin jedoch nun einen deutlich offensichtlicheren Fehler aus. Wenn die Abhängigkeit zwischen Plugins optional sein soll, verwenden Sie den
optionalRequire-Helper des Kerns. -
Subtile Timing-Änderungen können in seltenen Fällen Probleme verursachen. Da Plugin-Code nun zu nativen ES-Modulen kompiliert wird, wird alles im Modulbereich sofort ausgeführt. Falls Sie ungewöhnliche Logik im Modulbereich hatten, muss diese möglicherweise in den Laufzeitcode verschoben werden (z. B. in einen Klassenkonstruktor oder ähnliches).
Wenn Sie auf eines dieser Probleme stoßen und Hilfe bei der Lösung benötigen, zögern Sie nicht, unten zu posten.
CORS / Access-Control-Allow-Origin-Fehler
Wenn Sie nach dem Update CORS-Fehler erleben und einen CDN nutzen, sollten Sie einen vollständigen CLI-Neubuild durchführen (./launcher rebuild app), um diese Änderung in der NGINX-Konfiguration zu übernehmen.
Wenn Sie S3 (oder S3-kompatiblen) Speicher für Assets verwenden, müssen Sie Ihren CDN so konfigurieren, dass er den Antwort-Header Access-Control-Allow-Origin: * für alle Assets hinzufügt.
