プラグインの新しいビルドシステムを紹介します

開発
1

この数ヶ月間、プラグインのJavaScriptコード用の新しいビルドシステムに取り組んできました。これは、2025年7月にテーマのビルドシステムに行った変更、つまりよりモダンなブラウザ技術とJSビルドツールに依存する変更にプラグインを準拠させるものです。

この変更は、ほとんど後方互換性があります。ほとんどのプラグイン作成者は何もする必要がありません。 :tada:

利点

舞台裏のモダナイゼーションに加え、この変更はDiscourseの開発者とホスターに多くの機能的な利点をもたらします。

  1. プラグインのアセットは厳密にキャッシュされ、プラグインごとにキーが設定されます。これにより、開発中にサーバーを再起動しても、すべてのプラグインを最初から再構築する必要がなくなります。

  2. 既存のアセットバンドルに人気のあるプラグインのプリコンパイルされたコードを含めることができるようになります。再ビルド中、変更された/新しいプラグインのみをビルドする必要があります。これは特にリソースが限られているマシンで役立つはずです。

  3. プラグインコードは、ネイティブESモジュールにトランスパイルされます。これにより、構文が大幅に単純化され、ブラウザでの実行が高速化され、将来的にはバンドル分割のためのimport()などの機能の使用が可能になります。

テスト / タイムライン

私たちはこのシステムを社内で長期間テストしており、何百もの公式プラグインでその機能を確認しています。Metaでは数週間にわたって新しいシステムで運用されています。

ご自身で試してみたい場合は、環境変数ROLLUP_PLUGIN_COMPILER=1を設定できます。

私たちはまもなくデフォルトを変更する予定です。予期せぬ事態に備えて、新しいシステムを無効にできる短い期間、ROLLUP_PLUGIN_COMPILER=0を使用できますが、移行期間を最小限に抑えるつもりです。

複雑なプラグインに関する潜在的な問題

より複雑なプラグインについては、新しいシステムがより厳密になる点がいくつかあります。

  1. 管理モジュールを非管理コードからインポートすると、例外が発生するようになります。これは常に非推奨であり、予期しないエラーを引き起こす可能性がありました。今後は、より意図的に検出およびブロックされます。

    この問題が発生した場合は、プラグインコードをadmin/assets/javascripts/...の管理jsディレクトリに配置するのが最適かどうかを検討する必要があります。管理モジュールを条件付きでインポートする必要がある場合は、コアのoptionalRequireヘルパーを使用してそれを実現する必要があります。

  2. クロスプラグインインポートは引き続きサポートされています。ただし、管理モジュールと同様に、インストール/有効化されていないプラグインからのモジュールをインポートすると、はるかに明白なエラーが発生するようになります。クロスプラグインの依存関係がオプションであることが意図されている場合は、コアのoptionalRequireヘルパーを使用する必要があります。

  3. 微妙なタイミングの変更により、まれに問題が発生する可能性があります。プラグインコードがネイティブESモジュールにコンパイルされるようになったため、モジュールスコープ内のすべてがすぐに実行されます。モジュールスコープ内に予期しないロジックがあった場合、それを実行時コード内（例：クラスコンストラクタ内など）に移動する必要があるかもしれません。

これらの問題のいずれかに遭遇し、解決に助けが必要な場合は、遠慮なく以下に投稿してください。

「いいね！」 5