過去数ヶ月、プラグインの JavaScript コード用の新しいビルドシステムを開発してきました。これにより、プラグインは 2025 年 7 月にテーマのビルドシステムに対して行った変更と同期されます。その変更は、より現代的なブラウザ技術と JS ビルドツールに依存するものです。
この変更は主に後方互換性を保っています。ほとんどのプラグイン作者は特に何も行う必要はありません。 
メリット
裏側の近代化に加えて、この変更は Discourse の開発者やホスティング管理者に以下の機能的なメリットをもたらします：
-
プラグインアセットは厳重にキャッシュされ、プラグインごとにキーが設定されます。つまり、開発環境でサーバーを再起動しても、すべてのプラグインをゼロから再ビルドする必要がなくなります。
-
人気のあるプラグインに対して、既存のアセットバンドル にプリコンパイルされたコードを含められるようになります。再ビルド時には、変更されたまたは新しいプラグインのみをビルドすれば済みます。これはリソースが限られたマシンで特に役立ちます。
-
プラグインコードはネイティブな ES モジュールにトランスパイルされます。これにより、構文がより簡素化され、ブラウザ内での実行速度が向上し、将来的なバンドルスプリッティングのための
import()などの機能の利用が可能になります。
テスト / タイムライン
このシステムは内部で長期間テストしており、数百の公式プラグインで機能を検証済みです。Meta 自体も数週間、この新しいシステムで稼働しています。
ご自身で試してみたい場合は、ROLLUP_PLUGIN_COMPILER=1 という環境変数を設定してください。
間もなくデフォルトを変更する予定です。何か予期せぬ事態に備え、新しいシステムを一時的に ROLLUP_PLUGIN_COMPILER=0 で無効化できる短い期間を設けますが、移行期間は最小限に抑える予定です。
複雑なプラグインにおける可能性のある問題
より複雑なプラグインの場合、新しいシステムでは以下の点についてより厳格になります：
-
非管理コードからの管理モジュールのインポート は、例外を発生させるようになります。これは以前から推奨されていなかった行為であり、予期せぬエラーを引き起こす可能性があります。現在はより意図的に検出・ブロックされます。
この問題に遭遇した場合は、プラグインコードを
admin/assets/javascripts/...などのadmin-jsディレクトリに配置した方がよいかもしれません。本当に条件付きで管理モジュールをインポートする必要がある場合は、コアのoptionalRequireヘルパーを使用してください。 -
プラグイン間でのインポート は引き続きサポートされています。ただし、管理モジュールと同様に、インストールされていないまたは有効化されていないプラグインからのモジュールインポートは、より明確なエラーを発生させるようになります。プラグイン間の依存関係がオプションであることが意図されている場合は、コアの
optionalRequireヘルパーを使用してください。 -
微妙なタイミングの変化 が稀なケースで問題を引き起こす可能性があります。プラグインコードがネイティブな ES モジュールとしてコンパイルされるようになったため、モジュールスコープ内の処理はすべて即座に実行されます。もしモジュールスコープ内に特殊なロジックがあった場合は、それをランタイムコード（例えばクラスコンストラクタ内など）に移動させる必要があるかもしれません。
これらの問題に遭遇し、解決のサポートが必要な場合は、遠慮なく下記に投稿してください。
CORS / Access-Control-Allow-Origin エラー
更新後に CORS エラーが発生し、CDN を使用している場合は、NGINX 設定へのこの変更を取り込むために、フル CLI ビルド（./launcher rebuild app）を実行してください。
アセットに S3（または S3 互換）ストレージを使用している場合は、CDN 側ですべてのアセットに Access-Control-Allow-Origin: * というレスポンスヘッダーを追加するように設定する必要があります。
