Hot reload for plugin development?

Hi All. Apologies if this has been addressed (I didn’t find it):

Developing a discourse plugin on my local machine tends to be pretty slow. Each reload of my locally running app (to view code changes) takes over 5 seconds. So I make a change in an html/hbs or js file, hit save, then have to reload the app [edit: refresh the browser], and wait 5 seconds+ to view the change.

Is there any way to do hot reload (ie, automatic updating of the local view) for local discourse plugin development?

It seems like CSS files get updated automatically, but not html/hbs or js files.

Though I’m watching to see if there are any hints, I think that’s just the way it is. And from what I’ve seen, it’s much worse on a Mac.


Hey guys,

You should quite confidently only have to restart the server if your API has changed - ie your Ruby on Rails code.

If you’ve only changed the Javascript or HBS files, you can simply pick up the changes by refreshing the browser.

You will have noticed that CSS file changes don’t even require that! :slight_smile:


I’m talking here about refreshing the browser, and whether hot reload is available to avoid having to do that. It’s the browser refresh that takes 5+ seconds to view any change.

If I have to stop and reload the server (in the case that I change plugin.rb, for instance), that probably takes 60 seconds.

Hot reload is of course the standard for developing with many technologies today (I’m most familiar with Angular, which has this standard), and is awesome for development. I believe with Rails it’s possible through webpack (but not sure about that). My sense is hot reload is not available for discourse development, but wanted to check 'cause it would be awesome if it was available.

You need to refresh the browser to pick up updated javascript files


This will be coming with the EmberCLI: Coming to a Discourse near you!


In fact you can use Ember CLI with master Discourse right now to get this behaviour!


That sounds great, thanks. To use this for local development, is there anything I need to do other than download the latest version of discourse from github onto my computer?

1 Like

You’ll need to check out the latest discourse then do something like this:

  1. Start the api server: rails s

  2. Start the Ember server:

    1. Enter the right folder cd app/assets/javascript/discourse
    2. Install packages yarn
    3. Run ember CLI: ember serve --proxy "http://localhost:3000"

Then you can open http://localhost:4200 and you should be running in Ember CLI with hot reloading.


I was excited to upgrade my local discourse instance, and am now running 2.8 locally. But I am not yet able to get hot reload to work for html and js changes.

Here is how I run things:

cd into the discourse folder locally

$ redis-server //starts the server

$ rails s //starts the rails app

$ yarn //only run this the first time, I expect

$ bin/ember-cli //starts ember cli. The command ember serve--proxy "http://localhost:3000" gave me errors for some reason

This successfully has the app run at localhost:4200.

I have added in a plugin the local discourse instance, which is successfully displayed at localhost:4200. However, if I make changes to the html or js files, these changes are only displayed on the app running locally if I refresh the browser.

Do I have to do something else to have hot-reloading work?


Hi there. Is hot-reload available with ember-cli in Discourse? I am still having the same issue I mentioned in my previous post. Following those steps, I still do not get hot-reload (ie, I still have to refresh the browser to see changes to html and javascript, and ember-cli’s output in the terminal doesn’t seem to register when I hit save after a file change).

Hot reload continues to not work for me. Is there something else beyond these steps that I need to take?

What I do is

./bin/rails s

In one shell and


In another.

Yes. Thanks. I do that as well. Do you get hot (ie, auto) reloading for html and js files?

You mean hbs files?

Yeah, I don’t get what I believe is called "liveReload"ing in the browser, despite?:


And presence of:

<script type="text/javascript" src="http://localhost:4200/_lr/livereload.js?port=4200&amp;host=localhost&amp;path=_lr/livereload"></script>


<script src="/ember-cli-live-reload.js" type="text/javascript"></script>

Yes–I meant HBS files.

Would really appreciate being able to get live reloading (especially for javascript files). When I code in other contexts, where live reloading is standard, live reloading makes the coding process a lot faster and more fun.

1 Like

Some additional information:

ember-cli/ember-cli-inject-live-reload: Ember CLI plugin that injects live-reload script into HTML content (

" livereload.js initiates a websocket connection back to Ember CLI. This allows Ember CLI to notify the browser to trigger a refresh after JavaScript or style changes."

I’m curious why the browser ignores this - I wonder if it’s an option in the browser related to site security?

I’m not sure–but I’ve definitely been able to get live reload in the browser in other contexts / other frameworks. (Not sure about ember–I’ve only ever used it with coding discourse stuff.)

I’m interested to know if live reload is expected. It seems like yes, from the previous discussion. In that case, I wonder if the discourse team has live reload, and if they’re doing something I’m not.

1 Like

The presence of the scripts is surely a sign of intent, nothing here is by accident?

So I’m wondering if it is a local browser configuration issue, or some other configuration issue.

More on livereload.js: livereload/livereload-js: LiveReload JavaScript code that communicates with the server and implements reloading (

It would certainly be nice to get an official word on the extent to which livereloading should work here and if it goes beyond CSS on the client side.

1 Like

Automatically refreshing the page is handled by ember CLI. At the moment, theme and plugin assets are compiled and served by the Rails app, not Ember CLI. Therefore theme/plugin changes don’t automatically refresh the page.

This might be something we can improve in the future. But for now, it’s expected behaviour.