Vorremmo migrare il pipeline degli asset di Discourse per utilizzare EmberCLI. EmberCLI è il metodo standard per sviluppare applicazioni Ember e l’approccio di Discourse è stato a lungo fonte di confusione per chi si avvicina al nostro progetto con una conoscenza di Ember.js.
Contesto
Discourse esiste da abbastanza tempo da aver preceduto la nascita di EmberCLI; infatti, all’epoca, l’uso di qualcosa come il pipeline degli asset di Rails era considerato una best practice. Nel corso degli anni abbiamo aggiunto sempre più funzionalità alla nostra applicazione Ember, inclusi moduli JavaScript, Babel.js e source map, ma riteniamo di aver spinto il pipeline degli asset di Rails fino ai suoi limiti. Alcune nuove funzionalità come async/await sono molto difficili da integrare nel nostro sistema attuale.
Nella prossima versione maggiore di Discourse (2.5) intendiamo migrare verso EmberCLI. Questo richiederà un tempo considerevole, quindi faremo del nostro meglio per mantenere funzionanti due versioni della nostra applicazione frontend. Gli utenti più avventurosi potranno attivare EmberCLI, mentre gli altri potranno continuare a utilizzare l’applicazione “così com’è”, fino a quando non raggiungeremo un punto in cui riterrà tutto stabile.
Roadmap
-
Migrare gli schemi esistenti verso gli schemi di EmberCLI: Ne abbiamo già fatto un po’ nella versione 2.4. L’obiettivo è migrare gradualmente il nostro codice JavaScript verso un formato che corrisponda il più possibile a quanto previsto da Ember-CLI. Questo comporta:
- importare tutto dagli stessi percorsi
- utilizzare estensioni diverse per i template Handlebars grezzi / Handlebars di Ember
- eliminare le deprecazioni delle computed property
- passare al modulo
Locationdi Ember dal nostro modulo personalizzato
-
Avviare Discourse tramite EmberCLI: Questo probabilmente comporterà la scoperta di nuovi problemi man mano che gli elementi di (1) vengono risolti, ripetendo lo stesso approccio.
-
Integrazione dei componenti dei temi e dei plugin: Dovremo effettuare alcune indagini per integrare le estensioni esistenti di Discourse nel modo più fluido possibile.
-
Identificare eventuali colli di bottiglia (o altri): il sistema dovrebbe essere veloce quanto quello attuale, o più veloce.
-
Definire una tabella di marcia per il passaggio: dovrà essere generosa, in modo che le persone abbiano molto tempo per testare la funzionalità in versione beta e fornire feedback.
Vantaggi
Una volta completata la migrazione, molte funzionalità attualmente rotte o difficili da gestire, come i source map e async/await, dovrebbero funzionare senza problemi.
Inoltre, per alcuni sviluppatori che desiderano lavorare solo sulle parti frontend di Discourse, potremmo configurare il sistema in modo che possano eseguire EmberCLI puntando a un server come try.discourse.org per modificare l’applicazione frontend senza dover avviare un intero server Ruby/Rails con Redis/Postgres.
Si tratta di un progetto importante, ma alla fine la nostra applicazione ne uscirà molto migliorata!
Ci sono così tanti generatori che Rails offre nativamente per i plugin. Inoltre, Discourse è la più grande applicazione open source basata su Rails, quindi potrebbe essere utile unire gli sforzi.
