Discourse의 에셋 파이프라인을 EmberCLI 기반으로 전환하기를 원합니다. EmberCLI는 Ember 애플리케이션을 개발하는 표준 방식이며, Discourse의 기존 접근법은 Ember.js 배경을 가진 사람들이 프로젝트를 접할 때 오랫동안 혼란의 원인이 되어 왔습니다.
배경
Discourse는 EmberCLI이 등장하기 이전부터 존재해 왔으며, 당시에는 Rails 에셋 파이프라인과 같은 도구를 사용하는 것이 모범 사례로 여겨졌습니다. 수년에 걸쳐 우리는 JavaScript 모듈, Babel.js, 소스 맵 등 Ember 애플리케이션에 점점 더 많은 기능을 추가해 왔지만, Rails 에셋 파이프라인을 더 이상 확장하기는 어렵다고 느낍니다. async/await와 같은 일부 새로운 기능은 현재 시스템에 통합하기가 매우 어렵습니다.
Discourse의 다음 주요 버전(2.5)에서는 EmberCLI로의 전환을 계획하고 있습니다. 이 작업에는 상당한 시간이 소요될 것으로 예상되므로, 프론트엔드 애플리케이션의 두 버전을 동시에 유지하는 데 최선을 다할 것입니다. 모험적인 사용자는 EmberCLI로의 전환을 선택적으로 사용할 수 있으며, 다른 사용자는 시스템이 안정화될 때까지 기존 애플리케이션을 그대로 사용할 수 있습니다.
로드맵
-
기존 패턴을 EmberCLI 패턴으로 전환: 2.4 버전에서 이미 일부 작업을 수행했습니다. 기본적으로 목표는 JavaScript 코드를 Ember-CLI이 기대하는 형식에 가깝도록 서서히 이식하는 것입니다. 여기에는 다음이 포함됩니다:
- 모든 것을 동일한 경로에서 가져오기
- 원시 handlebars / ember handlebars에 서로 다른 확장자 사용
- 계산된 속성(computed property) 비권장 사항 제거
- 자체 모듈 대신 ember의
Location모듈로 변경
-
EmberCLI를 통해 Discourse 부팅: (1)의 문제가 수정되는 과정에서 새로운 문제가 발견될 가능성이 높으며, 동일한 접근 방식을 반복하게 될 것입니다.
-
테마 컴포넌트 및 플러그인 통합: 기존 Discourse 확장 기능을 최대한 매끄럽게 통합하기 위해 조사가 필요합니다.
-
성능(또는 기타) 병목 현상 식별: 현재 시스템과 동일한 속도이거나 더 빨라야 합니다.
-
전환 시간표 수립: 사용자가 기능을 베타 테스트하고 피드백을 제공할 수 있도록 충분한 시간을 확보해야 합니다.
장점
전환이 완료되면 현재 깨져 있거나 구현하기 어려운 소스 맵이나 async/await와 같은 많은 부분이 정상적으로 작동하게 될 것입니다.
또한, Discourse의 프론트엔드 부분만 작업하려는 일부 개발자를 위해, Redis/Postgres가 포함된 전체 Ruby/Rails 서버를 실행하지 않고 try.discourse.org와 같은 서버를 가리키는 EmberCLI만 실행하여 프론트엔드 애플리케이션을 개발할 수 있도록 설정할 수 있을 것입니다.
이는 대규모 프로젝트이지만, 궁극적으로 우리의 애플리케이션은 훨씬 더 좋아질 것입니다!
rails가 플러그인을 위해 기본적으로 제공하는 생성기가 정말 많거든요. 또한 discourse는 가장 큰 오픈소스 rails 앱이므로, 노력을 합치는 것이 좋은 방법이 될 수 있을 것 같습니다.
