New installs will default to Ember CLI builds in Production

Hi, any ETA? Thank you.

1 Like

you can already implement it.

All you need to do it add a line to your app.yml and rebuild.


We plan to enable it for older sites in around a month from now.


I’m super excited about this change and it’s a great thing for the future of Discourse.

I would simply recommend this: if you are running any third party theme components or plugins, please spin up a separate test instance with the same set and check it all out there before moving to ember cli on your main site.

I have just released some significant changes to one of my Theme Components without which it would have broken the host site.


There’s more information here:

The short version is: this is the officially supported way to develop Ember applications and should make it easier for people to contribute and for us to ugprade Ember in the future.


Yes, I set up EMBER_CLI_PROD_ASSETS: 1 but Dracula Theme is not working well.
so I remove this feature :frowning:


You should post on Dracula a Dark Theme for Discourse so that they can fix it.


Is it true that the only theme components likely to be broken by this change are those Wyeth javascript in them?

Is there an easy way to do a query to find the theme components that include javascript? Either a data explorer or rails query? I would like to have a way to tell which sites are likely to be bitten by this and offer to let them use my new product (for free, so I can finally get some testers) to install a staging site to do a test before they upgrade their production site.

1 Like

That’s true - this ember CLI change doesn’t impact the HTML or CSS parts of themes/components.

In general, you can identify problem theme components by looking for yellow deprecation notices in the browser JS console under the old non-ember-cli environment. (Moving to Ember CLI is the reason we’ve been introducing these deprecations)

Meta has been running Ember CLI for a number of weeks now, and we’ve been working to make sure all our official themes/plugins are working in the new environment.


Ok. So if I pull down /admin/customize/themes.json (or whatever the actual path is) it’ll have warnings in it. Do we think that’s likely to have false negatives (i.e. No warnings but it’ll fail when you upgrade).

Oh, and if it does fail, you just need to switch back off the env variable.

For plugins, if I’m seeing depreciation warnings on the javascript console then I’m finally going to have to figure out what they mean? It’s seemed that they were coming from components that I was using and not my code, but Ember and javascript are still fairly mysterious to me. (in spite of having a bunch of code that I at least mostly wrote).


No, the deprecation warnings appear at runtime in your browser console. They will not appear in the theme REST API.

For now, you could do this. But we intend to make this the non-optional default very soon, so the best solution is to fix the root cause.

Yes, I’m afraid so. If you think they’re coming from core components, or you’re struggling to find the reason, then please do open a #dev topic with the details.


Ha. If you are lucky. If not so lucky you will get a full error and a complete halt to javascript execution. which can result in blank or corrupt pages.

So far I’ve found various issues but mostly the loss some attributes of the Discourse object and therefore you have to find a different way to get at site and user attributes. (Hint: these are accessible within the components. You can see the work I’ve done recently on the TLP TC)


The important part of my sentence was:

Once you update, the deprecations turn into errors, as you said :+1:

Yep these can be accessed via the injected properties of components, or by importing the Site and User modules from discourse/models/user and discourse/models/site


Ah yes, useful alternative to passing them through helpers as parameters.


For my plugin that I’m developing and running ./bin/ember-cli I have nothing to worry about, since, I’m using ember-cli.

But my concern is the dozens or hundreds of people who aren’t going to find out about this until it’s too late, someone who doesn’t know javascript from CSS or a plugin from a theme component, they don’t need to worry unless they have javascript in a theme component.

What I would like is a simple test so that they know whether they should have anything to worry about. For those people, I’ll recommend that they spin up a new server, restore their database and see if anything explodes. Right?

Or should they just turn on EMBER_CLI_PROD_ASSETS: 1, do a rebuild and if it explodes, turn it back off, and then spin up a new server to fix it.


I guess you could query to see if there are any theme_fields with the html or js type:

That would work, but setting up a whole new server seems like a lot of effort. Instead, I would recommend:

  1. Open your dev tools console, and look for yellow deprecation notices
  2. Fix them
  3. Upgrade to Ember CLI (or just wait until we roll it out by default)

. . . Unless you’ve spent the past year developing a tool to make it “easy” to spin up new servers? :wink:

So what will happen for those who don’t pay any attention to this stuff is that it’ll break when the ember-by-default window hits and then they can turn off that ENV variable for another month or two (and presumably fix it) before that doesn’t work anymore.


I restored a backup to a new site that has Kanban theme enabled and it’s getting errors (I reported it on the kanban topic), I tried setting


and rebuilds are still saying:

Why you should do it regularly:

which I (think I) recognize as coming from ember-cli. Is there some way to disable it on new sites?

If I rebuild an old site is it going to get the new base image and not be able to disable ember-cli?

1 Like

Is that a typo in your message here or a typo in your yml? It should read EMBER_CLI_PROD_ASSETS: 0


Thanks! But yes, that’s a typo, but I got it right in the yml file. I just copy/pasted it correctly in the OP.

1 Like