За последние несколько месяцев мы работали над новой системой сборки для JavaScript-кода плагинов. Это приведёт плагины в соответствие с изменениями, внесёнными нами в систему сборки тем в июле 2025 года, которые опираются на более современные технологии браузеров и инструменты сборки JS.
Это изменение в значительной степени обратно совместимо. Большинству авторов плагинов ничего делать не потребуется. 
Преимущества
Помимо модернизации «под капотом», это изменение принесёт ряд функциональных преимуществ разработчикам и хостерам Discourse:
-
Активы плагинов сильно кэшируются и индексируются по каждому плагину отдельно. Это означает, что перезапуск вашего сервера в режиме разработки не потребует полной пересборки всех плагинов.
-
Мы сможем начать включать предварительно скомпилированный код для популярных плагинов в наши существующие пакеты активов. При пересборке потребуется собирать только изменённые или новые плагины. Это должно быть особенно полезно для машин с ограниченными ресурсами.
-
Код плагинов будет транспилироваться в нативный ES-модуль. Это обеспечит более простой синтаксис, ускорит выполнение в браузере и откроет возможность использования таких функций, как
import(), для разделения пакетов в будущем.
Тестирование / График
Мы тестировали эту систему внутренне в течение некоторого времени и проверили её работоспособность на сотнях официальных плагинов. Meta работает с новой системой уже несколько недель.
Если вы хотите попробовать её самостоятельно, установите переменную окружения ROLLUP_PLUGIN_COMPILER=1.
Мы планируем очень скоро изменить значение по умолчанию. В течение короткого периода новую систему можно будет отключить, установив ROLLUP_PLUGIN_COMPILER=0, на случай любых неожиданностей, но мы намерены свести период перехода к минимуму.
Возможные проблемы со сложными плагинами
Для более сложных плагинов новая система более строга в нескольких аспектах:
-
Импорт административных модулей из кода, не относящегося к админке, теперь будет вызывать исключение. Это всегда не рекомендовалось и могло приводить к неожиданным ошибкам. Теперь это обнаруживается и блокируется более явно.
Если вы столкнулись с этой проблемой, подумайте, не лучше ли переместить код вашего плагина в директорию
admin-js(admin/assets/javascripts/...). Если вам действительно необходимо условно импортировать административные модули, используйте вспомогательную функциюoptionalRequireядра для этого. -
Межплагиновые импорты по-прежнему поддерживаются. Однако, аналогично административным модулям, импорт модулей из плагина, который не установлен или не включён, теперь будет вызывать гораздо более очевидную ошибку. Если межплагиновая зависимость должна быть необязательной, используйте вспомогательную функцию
optionalRequireядра. -
Скрытые изменения времени выполнения могут в редких случаях вызывать проблемы. Теперь, когда код плагинов компилируется в нативные ES-модули, всё, что находится в области видимости модуля, выполняется немедленно. Если у вас была необычная логика в области видимости модуля, её, возможно, потребуется переместить в код времени выполнения (например, внутрь конструктора класса или аналогичного места).
Если вы столкнётесь с любой из этих проблем и вам понадобится помощь в её решении, не стесняйтесь написать об этом ниже.
Ошибки CORS / Access-Control-Allow-Origin
Если после обновления вы столкнулись с ошибками CORS и используете CDN, выполните полную пересборку через CLI (./launcher rebuild app), чтобы применить это изменение в конфигурации NGINX.
Если вы используете хранилище S3 (или совместимое с S3) для активов, вам необходимо настроить ваш CDN так, чтобы он добавлял заголовок ответа Access-Control-Allow-Origin: * ко всем активам.
