New installs will default to Ember CLI builds in Production

IAmGav · November 5, 2021, 7:15am

you can already implement it.

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

Falco · November 5, 2021, 12:48pm

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

merefield · November 5, 2021, 4:17pm

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.

eviltrout · November 5, 2021, 7:56pm

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.

valsha · November 5, 2021, 9:45pm

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

pfaffman · November 5, 2021, 11:05pm

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

pfaffman · November 6, 2021, 5:50pm

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.

david · November 6, 2021, 8:21pm

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.

pfaffman · November 6, 2021, 9:51pm

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

david · November 6, 2021, 10:48pm

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.

merefield · November 7, 2021, 8:48am

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)

david · November 7, 2021, 11:21am

The important part of my sentence was:

Once you update, the deprecations turn into errors, as you said

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

merefield · November 7, 2021, 11:48am

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

pfaffman · November 8, 2021, 4:42pm

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.

david · November 8, 2021, 4:49pm

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

github.com

discourse/discourse/blob/4272eb7ffc7b89fe9d293962a0433a91e3dea58f/app/models/theme_field.rb#L40-L46

    
      
          @types ||= Enum.new(html: 0,
                              scss: 1,
                              theme_upload_var: 2,
                              theme_color_var: 3, # No longer used
                              theme_var: 4, # No longer used
                              yaml: 5,
                              js: 6)

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

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

pfaffman · November 8, 2021, 5:03pm

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

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.

pfaffman · November 12, 2021, 2:25pm

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

EMBER_CLI_PROD_ASSETS: 0

and rebuilds are still saying:


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

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?

Simon_Manning · November 12, 2021, 2:29pm

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

pfaffman · November 12, 2021, 2:31pm

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.

Simon_Manning · November 12, 2021, 2:39pm

The check in the code seems to be unchanged but I’m not very familiar with Ruby. Will a boolean conditional with ENV['EMBER_CLI_PROD_ASSETS'] use the value of that key or will it be true if that key exists?

If it’s the latter, the answer might be to remove EMBER_CLI_PROD_ASSETS from the yml rather than set it to 0.