New installs will default to Ember CLI builds in Production

Announcements
1

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.

18 Likes
2

Current self hosted sites, does it require an rebuild or admin upgrade to switch over ?

3 Likes
3

My interpretation is that for existing installs, you can switch to using Ember CLI by doing one of two things:

  1. Edit app.yml to add the EMBER_CLI_PROD_ASSETS: 1 line, then rebuild, or
  2. Wait until “the near future” when it becomes the standard, then rebuild
5 Likes
4

Yes @Simon_Manning is correct - you can enable it yourself manually if you wish, or you can wait for it to become the default. We are rolling it out slowly to try and catch all the bugs in advance.

7 Likes
5

ok, i have it installed. anything i need to keep an eye on ?

1 Like
6 
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db

Why you should do it regularly:
https://github.com/browserslist/browserslist#browsers-data-updating
1 Like
7

Just let us know if anything is broken, please.

4 Likes
8

Could you also explain what it entails and why it matters — to those not familiar with the Ember ecosystem.

9 Likes
9

Hi, any ETA? Thank you.

1 Like
10

you can already implement it.

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

2 Likes
11

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

8 Likes
12

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.

14 Likes
13

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.

9 Likes
14

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

3 Likes
15

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

5 Likes
16

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
17

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.

6 Likes
18

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).

2 Likes
19

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.

5 Likes
20

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)

2 Likes