EmberCLI: Coming to a Discourse near you!

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

  1. 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 Location module from our custom module
  2. Boot Discourse via EmberCLI: This will likely involve finding new issues as things in (1) are fixed and repeating the same approach.

  3. Integrating Theme Components and Plugins: We’ll need to do some investigation here to integrate existing extensions to Discourse as seamlessly as possible.

  4. Identify any performance (or other) bottlenecks: it should be as fast as our current system, or faster.

  5. 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!

26 Likes

Thanks Robin! This focus is very important to us, of course.

Please let us know if you’d like us to test out any branches

PS I can only imagine how much work this migration will be, so very much appreciated.

10 Likes

Do you also plan to eventually make discourse plugins be rails plugins? that would be great! :smiley: 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.

That is a different and much more complicated request that should not be associated with this work.

5 Likes

We are going to start merging some big template linting changes. They should mostly “just work”, but some regressions are to be expected. We’ll do our best to fix them quickly so please report anything unusual like user interface elements not updating when they should.

5 Likes

Today I merged a large commit that renames all .js.es6 files in the app/assets/javascripts/discourse folder to be .js. This is a step towards matching the Ember CLI standard way of naming files.

Next up is plugin support for .js transpilation, and to deprecate .es6.

10 Likes