As of today, all new self hosted installs of Discourse will default to using our Ember CLI builds in production.
We’ve been running these builds ourselves in production for quite some time now and they should be stable and work with all major plugins. If you encounter any issues and need to turn it off, edit your app.yml and remove EMBER_CLI_PROD_ASSETS: 1
Otherwise, please report any bugs to us and we’ll be quick to fix them.
In the near future all installs of Discourse will be using the Ember CLI builds.
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.
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.
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)