À partir d’aujourd’hui, toutes les nouvelles installations auto-hébergées de Discourse utiliseront par défaut nos builds Ember CLI en production.
Nous utilisons nous-mêmes ces builds en production depuis un certain temps ; ils devraient être stables et compatibles avec tous les principaux plugins. Si vous rencontrez des problèmes et souhaitez les désactiver, modifiez votre fichier app.yml et supprimez la ligne EMBER_CLI_PROD_ASSETS: 1.
Sinon, veuillez nous signaler tout bogue et nous nous efforcerons de le corriger rapidement.
Dans un avenir proche, toutes les installations de Discourse utiliseront les builds Ember CLI.
Mon interprétation est que pour les installations existantes, vous pouvez passer à l’utilisation d’Ember CLI en faisant l’une des deux choses suivantes :
Modifier app.yml pour ajouter la ligne EMBER_CLI_PROD_ASSETS: 1, puis reconstruire, ou
Attendre « un avenir proche » où cela deviendra la norme, puis reconstruire
Oui, @Simon_Manning a raison : vous pouvez l’activer manuellement si vous le souhaitez, ou attendre qu’il devienne la valeur par défaut. Nous le déployons progressivement afin de détecter tous les bugs à l’avance.
Pourriez-vous également expliquer ce que cela implique et pourquoi c’est important, en particulier pour ceux qui ne sont pas familiers avec l’écosystème Ember ?
Je suis super enthousiaste à l’idée de ce changement, qui est une excellente chose pour l’avenir de Discourse.
Je recommanderais simplement ceci : si vous utilisez des composants de thème ou des plugins tiers, veuillez lancer une instance de test séparée avec le même ensemble et tout vérifier là-bas avant de passer à Ember CLI sur votre site principal.
Je viens de publier des modifications importantes sur l’un de mes composants de thème, sans lesquelles le site hôte aurait été cassé.
En bref : c’est la méthode officiellement prise en charge pour développer des applications Ember, ce qui devrait faciliter la contribution des personnes et nos futures mises à niveau d’Ember.
Est-il vrai que les seuls composants de thème susceptibles d’être cassés par ce changement sont ceux contenant du JavaScript Wyeth ?
Existe-t-il un moyen simple d’interroger les composants de thème qui incluent du JavaScript ? Soit via un explorateur de données ou une requête Rails ? J’aimerais pouvoir identifier quels sites risquent d’être affectés par ce changement et leur proposer d’utiliser mon nouveau produit (gratuitement, afin que je puisse enfin obtenir des testeurs) pour installer un environnement de staging et effectuer un test avant de mettre à niveau leur site de production.
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)
