Gostaríamos de migrar o pipeline de ativos do Discourse para usar o EmberCLI. O EmberCLI é a maneira padrão de desenvolver aplicações Ember, e a abordagem do Discourse tem sido, há muito tempo, uma fonte de confusão para pessoas que se aproximam do nosso projeto com experiência em Ember.js.
Contexto
O Discourse existe há tempo suficiente para ter surgido antes da existência do EmberCLI. Na verdade, na época, o uso de algo como o pipeline de ativos do Rails era considerado uma prática recomendada. Ao longo dos anos, adicionamos cada vez mais recursos à nossa aplicação Ember, incluindo módulos JavaScript, Babel.js e mapas de origem, mas sentimos que já levamos o pipeline de ativos do Rails ao limite. Alguns novos recursos, como async/await, são muito difíceis de integrar ao nosso sistema atual.
Na próxima versão principal do Discourse (2.5), planejamos migrar para o EmberCLI. Isso levará bastante tempo, então faremos o possível para manter duas versões da nossa aplicação front-end funcionando. Pessoas mais ousadas poderão optar por usar o EmberCLI, enquanto outros poderão continuar usando a aplicação “como está”, até que cheguemos a um ponto em que consideremos tudo estável.
Roadmap
-
Migrar padrões existentes para padrões do EmberCLI: Já fizemos um pouco disso na versão 2.4. Basicamente, o objetivo é migrar gradualmente nosso código JavaScript para um formato que se assemelhe ao que o Ember-CLI espera. Isso envolve:
- importar tudo a partir dos mesmos caminhos
- usar extensões diferentes para handlebars bruto / handlebars do Ember
- eliminar depreciações de propriedades computadas
- mudar do nosso módulo personalizado para o módulo
Locationdo Ember
-
Iniciar o Discourse via EmberCLI: Isso provavelmente envolverá a descoberta de novos problemas à medida que itens do ponto (1) forem corrigidos, repetindo a mesma abordagem.
-
Integrar Componentes de Tema e Plugins: Precisaremos investigar como integrar as extensões existentes ao Discourse da forma mais transparente possível.
-
Identificar quaisquer gargalos de desempenho (ou outros): o sistema deve ser tão rápido quanto o atual ou mais rápido.
-
Definir um cronograma para a migração: ele precisará ser generoso para que as pessoas tenham bastante tempo para testar a funcionalidade em beta e fornecer feedback.
Vantagens
Quando a migração estiver completa, muitas coisas que atualmente estão quebradas ou difíceis de fazer, como mapas de origem e async/await, devem funcionar normalmente.
Além disso, para alguns desenvolvedores que desejam trabalhar apenas nas partes front-end do Discourse, poderemos configurar o ambiente de forma que eles possam executar o EmberCLI apontado para um servidor como try.discourse.org para desenvolver a aplicação front-end sem precisar rodar um servidor completo Ruby/Rails com Redis/Postgres.
Este será um projeto grande, mas no final nossa aplicação ficará muito melhor por isso!
Existem tantos geradores que o Rails oferece nativamente para plugins. Além disso, o Discourse é o maior aplicativo Rails de código aberto, então talvez fosse bom unir esforços.
