New installs will default to Ember CLI builds in Production

announcements
21

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

5 Likes
22

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

4 Likes
23

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.

5 Likes
24

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)
2 Likes
25

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

4 Likes
26

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?

1 Like
27

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

2 Likes
28

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
29

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.

1 Like
30

That won’t work, you need to remove the line.

1 Like
31

. . . wait . . .

None of my issues had to do with ember-cli, but with my own misconfiguration, since this was a 2-container installation and web_only.yml didn’t get updated when standalone.yml was. Here’s a PR:

4 Likes
32

Ember CLI is now the default for all installations of Discourse. When you next update (either via the /admin/upgrade UI, or via ./launcher rebuild app), you will be automatically switched to Ember CLI.

We’re now running Ember CLI in the majority of our managed hosting, so we don’t expect any major issues. But if you notice anything, please do make a topic here on Meta and we’ll investigate.

7 Likes
33

I rebuilt a site yesterday that failed due to ember CLI and fixed it by removing EMBER_CLI_PROD_ASSETS=1.

At one point early on I tried to disable the ember cli by setting EMBER_CLI_PROD_ASSETS=0 and I’m pretty sure that it still included ember_cli and someone told me that you couldn’t disable it by setting it to 0 (which didn’t make sense, but seemed to be true).

This is a bit challenging for self-hosters who have old themes and never look at the javascript console.

2 Likes
34

That was true, but I fixed the logic with this latest commit so that =0 works as expected. That said, we intend to totally rip out the ‘legacy’ environment in a matter of weeks, so please don’t use =0 unless it’s on an extremely short-term basis.

We’ve added backwards compatibility for the most common errors we saw across our hosting. For example this commit a couple of weeks ago added backwards-compatibility for Discourse.User and Discourse.SiteSettings. This commit fixed up some issues for themes with non-standard initialization processes.

We want to make this rollout as smooth as possible, so if you’ve run into errors in the last week-or-so, please do let us know the precise error, and the code which caused it.

6 Likes
35

Oh. Hooray. That makes sense. (It works like I thought it should all along. And I’m not crazy for remembering that I was told it didn’t work how I thought it should. These are great things!).

I find it really hard to figure that out (likely due to ignorance). When I click the thing that I think should show me what’s causing the error, what I get is the code that appears to be the code that tests for the deprecation, not the code that exibits it. I’ll endeavor to send some example(s) soon.

3 Likes
36

If you need a hand figuring it out, a #support topic with a screenshot of the error would be a good starting point - then we can help with debugging from there. Chances are, someone else has seen a similar error, and may recognise the symptoms. :crossed_fingers:

7 Likes
37

And now for the final step of this saga: the legacy build system is now disabled. All Discourse installs will compile assets using Ember CLI.

This change will only affect people who had deliberately set EMBER_CLI_PROD_ASSETS=0 in their config. In that case, a warning will be printed during the build, and Ember CLI will be used.

12 Likes