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.
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.
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
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.
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.
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.
C’est vrai - ce changement de l’Ember CLI n’affecte pas les parties HTML ou CSS des thèmes/composants.
En général, vous pouvez identifier les composants de thème problématiques en recherchant les avertissements de dépréciation jaunes dans la console JavaScript du navigateur dans l’ancien environnement non-Ember CLI. (Le passage à l’Ember CLI est la raison pour laquelle nous introduisons ces dépréciations)
Meta utilise l’Ember CLI depuis plusieurs semaines maintenant, et nous avons travaillé pour nous assurer que tous nos thèmes/plugins officiels fonctionnent dans le nouvel environnement.
Ok. Donc, si je télécharge /admin/customize/themes.json (ou quel que soit le chemin réel), il y aura des avertissements. Pensons-nous qu’il y aura de faux négatifs (c’est-à-dire pas d’avertissements mais cela échouera lors de la mise à niveau).
Oh, et si cela échoue, il suffit de désactiver la variable d’environnement.
Pour les plugins, si je vois des avertissements de dépréciation dans la console javascript, devrai-je enfin comprendre ce qu’ils signifient ? Il semblait qu’ils provenaient de composants que j’utilisais et non de mon code, mais Ember et javascript me sont encore assez mystérieux. (malgré le fait d’avoir beaucoup de code que j’ai au moins en grande partie écrit).
Non, les avertissements de dépréciation apparaissent à l’exécution dans la console de votre navigateur. Ils n’apparaîtront pas dans l’API REST des thèmes.
Pour l’instant, vous pourriez le faire. Mais nous avons l’intention d’en faire le défaut non optionnel très bientôt, donc la meilleure solution est de corriger la cause première.
Oui, j’en ai bien peur. Si vous pensez qu’ils proviennent de composants de base, ou si vous avez du mal à en trouver la raison, veuillez ouvrir un sujet Dev avec les détails.
Ha. Si vous avez de la chance. Sinon, vous obtiendrez une erreur complète et un arrêt complet de l’exécution JavaScript. Ce qui peut entraîner des pages vierges ou corrompues.
Jusqu’à présent, j’ai trouvé divers problèmes, mais surtout la perte de certains attributs de l’objet Discourse et vous devez donc trouver un moyen différent d’accéder aux attributs du site et de l’utilisateur. (Indice : ceux-ci sont accessibles dans les composants. Vous pouvez voir le travail que j’ai fait récemment sur le TLP TC)
