Nous souhaitons migrer le pipeline d’actifs de Discourse vers EmberCLI. EmberCLI est la méthode standard pour développer des applications Ember, et l’approche de Discourse a longtemps été une source de confusion pour les personnes abordant notre projet avec une expérience en Ember.js.
Contexte
Discourse existe depuis suffisamment longtemps pour avoir précédé l’existence d’EmberCLI. À l’époque, l’utilisation d’un pipeline d’actifs similaire à celui de Rails était considérée comme une bonne pratique. Au fil des ans, nous avons ajouté de plus en plus de fonctionnalités à notre application Ember, notamment des modules JavaScript, Babel.js et des cartes de source. Cependant, nous estimons avoir poussé le pipeline d’actifs de Rails à ses limites. Certaines nouvelles fonctionnalités, comme async/await, sont très difficiles à intégrer dans notre système actuel.
Dans la prochaine version majeure de Discourse (2.5), nous prévoyons de migrer vers EmberCLI. Cette migration prendra un certain temps, nous ferons donc de notre mieux pour maintenir deux versions de notre application frontend fonctionnelles. Les personnes aventureuses pourront opter pour EmberCLI, tandis que les autres pourront continuer à utiliser l’application « telle quelle » jusqu’à ce que nous jugions la situation stable.
Feuille de route
-
Migrer les modèles existants vers les modèles EmberCLI : Nous avons déjà commencé cette démarche dans la version 2.4. L’objectif est de migrer progressivement notre code JavaScript vers un format correspondant étroitement aux attentes d’Ember-CLI. Cela implique :
- importer tout depuis les mêmes chemins ;
- utiliser des extensions différentes pour les templates Handlebars bruts et les templates Handlebars Ember ;
- éliminer les dépréciations liées aux propriétés calculées ;
- passer du module
Locationpersonnalisé d’Ember à celui d’Ember.
-
Démarrer Discourse via EmberCLI : Cela impliquera probablement de découvrir de nouveaux problèmes au fur et à mesure que les éléments du point (1) seront corrigés, et de répéter la même approche.
-
Intégrer les composants de thème et les plugins : Nous devrons mener des investigations pour intégrer les extensions existantes de Discourse de la manière la plus transparente possible.
-
Identifier tout goulot d’étranglement (de performance ou autre) : Le système doit être aussi rapide que notre système actuel, voire plus.
-
Établir un calendrier pour la migration : Il devra être généreux afin de laisser aux utilisateurs suffisamment de temps pour tester la fonctionnalité en version bêta et fournir des retours.
Avantages
Une fois la migration entièrement achevée, de nombreuses fonctionnalités actuellement dysfonctionnelles ou difficiles à mettre en œuvre, comme les cartes de source et async/await, devraient fonctionner sans problème.
De plus, pour certains développeurs souhaitant uniquement travailler sur les parties frontend de Discourse, nous pourrions configurer l’environnement de manière à ce qu’ils puissent lancer EmberCLI pointé vers un serveur comme try.discourse.org pour modifier l’application frontend, sans avoir à exécuter un serveur Ruby/Rails complet avec Redis/Postgres.
Il s’agit d’un projet important, mais au final, notre application en sera bien meilleure !
Rails propose de nombreux générateurs intégrés pour les plugins. De plus, Discourse est la plus grande application open source basée sur Rails, il serait donc peut-être judicieux de combiner nos efforts.
