Hi, any ETA? Thank you.
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
You should post on Dracula a Dark Theme for Discourse so that they can fix it.
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.
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.
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
Yep these can be accessed via the injected properties of components, or by importing the
User modules from
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.
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
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)
. . . 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.
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: 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?
Is that a typo in your message here or a typo in your yml? It should read
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.