지난 몇 달 동안 플러그인 JavaScript 코드를 위한 새로운 빌드 시스템을 구축해 왔습니다. 이 시스템은 2025년 7월에 테마 빌드 시스템에 적용한 변경 사항과 플러그인을 동기화하며, 보다 최신의 브라우저 기술과 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을 사용 중이라면, NGINX 구성에 이 변경 사항을 반영하기 위해 전체 CLI 재빌드(./launcher rebuild app)를 실행해야 합니다.
자산을 위해 S3(또는 S3 호환) 스토리지를 사용하는 경우, 모든 자산에 Access-Control-Allow-Origin: * 응답 헤더를 추가하도록 CDN을 구성해야 합니다.
