In den letzten Monaten haben wir an einem neuen Build-System für Plugin-JavaScript-Code gearbeitet. Dies wird Plugins auf den Stand der Änderungen bringen, die wir im Juli 2025 am Theme-Build-System vorgenommen haben, welches sich auf modernere Browsertechnologien und JS-Build-Tools stützt.
Diese Änderung ist größtenteils abwärtskompatibel. Die meisten Plugin-Autoren müssen nichts unternehmen. 
Vorteile
Abgesehen von der Modernisierung hinter den Kulissen wird diese Änderung Discourse-Entwicklern und -Hostern eine Reihe von funktionalen Vorteilen bringen:
-
Plugin-Assets werden stark gecacht und pro Plugin 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, vorcompilierte Codes für beliebte Plugins in unsere bestehenden Asset-Bundles aufzunehmen. Während eines Rebuilds müssen nur geänderte/neue Plugins gebaut werden. Dies sollte besonders nützlich für ressourcenbeschränkte Maschinen sein.
-
Plugin-Code wird in ein natives ES-Modul transpiliert. Dies bringt eine viel einfachere Syntax, eine schnellere Ausführung im Browser und ermöglicht zukünftig die Nutzung von Dingen wie
import()für das Bundle-Splitting.
Testen / Zeitplan
Wir testen dieses System intern seit einiger Zeit und haben seine Funktionalität bei Hunderten von offiziellen Plugins überprüft. Meta läuft bereits 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 Zeit geben, in der das neue System deaktiviert werden kann, indem ROLLUP_PLUGIN_COMPILER=0 gesetzt wird, falls unerwartete Dinge auftreten, aber wir beabsichtigen, die Übergangszeit so kurz wie möglich zu halten.
Mögliche Probleme mit komplexen Plugins
Bei komplexeren Plugins gibt es einige Dinge, bei denen das neue System strenger ist:
-
Das Importieren von Admin-Modulen aus Nicht-Admin-Code löst nun eine Ausnahme aus. Dies wurde schon immer abgeraten und würde zu überraschenden Fehlern führen. Jetzt wird es bewusster 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/...) untergebracht wäre. Wenn Sie wirklich bedingt Admin-Module importieren müssen, sollten Sie denoptionalRequire-Helfer des Kerns verwenden, um dies zu erreichen. -
Cross-Plugin-Importe werden weiterhin unterstützt. Ähnlich wie bei Admin-Modulen löst der Import von Modulen aus einem Plugin, das nicht installiert/aktiviert ist, nun einen viel offensichtlicheren Fehler aus. Wenn die Cross-Plugin-Abhängigkeit optional sein soll, sollten Sie den
optionalRequire-Helfer des Kerns verwenden. -
Subtile Timing-Änderungen können in seltenen Fällen Probleme verursachen. Da Plugin-Code jetzt in native ES-Module kompiliert wird, wird alles im Modul-Scope sofort ausgeführt. Wenn Sie unübliche Logik im Modul-Scope hatten, muss diese möglicherweise in den Laufzeitcode verschoben werden (z. B. in einen Konstruktor einer Klasse oder Ähnliches).
Wenn Sie auf eines dieser Probleme stoßen und Hilfe bei der Behebung benötigen, zögern Sie nicht, unten zu posten.