We’d like to migrate Discourse’s asset pipeline over to use EmberCLI. EmberCLI is the standard way to develop Ember applications and Discourse’s approach has long been a source of confusion for people approaching our project with an Ember.js background.
Background
Discourse has been around long enough that it pre-dates EmberCLI’s existence, and in fact using something like the Rails asset pipeline was considered a best practice at the time. Over the years we’ve tacked on more and more to our Ember application, including javascript modules, Babel.js and source maps, but we feel like we’ve pushed the Rails asset pipeline as far as we can go. Some new features like async/await are very hard to integrate into our current system.
In the next major version of Discourse (2.5) we plan on migrating over to EmberCLI. This is going to take quite a while to do, so we will do our best to keep two versions of our front end application working. Adventurous people should be able to opt-in to EmberCLI and others can continue to use the application “as is,” until we reach a point where we feel things are stable.
Roadmap
-
Migrate existing patterns over to EmberCLI patterns: We’ve already done a little bit of this in 2.4. Basically the goal is to slowly migrate our Javascript code to a format that closely matches what Ember-CLI expects. This involves:
- importing everything from the same paths
- using different extensions for raw handlebars / ember handlebars
- getting rid of computed property deprecations
- changing to ember’s
Locationmodule from our custom module
-
Boot Discourse via EmberCLI: This will likely involve finding new issues as things in (1) are fixed and repeating the same approach.
-
Integrating Theme Components and Plugins: We’ll need to do some investigation here to integrate existing extensions to Discourse as seamlessly as possible.
-
Identify any performance (or other) bottlenecks: it should be as fast as our current system, or faster.
-
Come up with a timeline to switch over: it’ll need to be generous so people have a long time to beta the feature and provide feedback.
Advantages
When we’re fully migrated over, a lot of stuff that is currently broken or hard to do like source maps and async/await should just work.
Additionally, for some developers who only want to work on the front end parts of Discourse, we might be able to set things up so that they can only run EmberCLI pointed at a server like try.discourse.org to hack on the front end application without having to run an entire Ruby/Rails server with Redis/Postgres.
This is going to be a big project but in the end our application will be much better for it!
There are so many generators that rails provides out of the box for plugins. Also discourse is the biggest open source rails app, so maybe it would be good to combine the efforts.
