La partie importante de ma phrase était :
Une fois que vous mettez à jour, les dépréciations se transforment en erreurs, comme vous l’avez dit 
Oui, ceux-ci sont accessibles via les propriétés injectées des composants, ou en important les modules Site et User de discourse/models/user et discourse/models/site.
Ah oui, alternative utile pour éviter de les passer en paramètres via les helpers.
Pour mon plugin que je développe et que j’exécute avec ./bin/ember-cli, je n’ai rien à craindre, car j’utilise ember-cli.
Mais ma préoccupation concerne les dizaines ou les centaines de personnes qui ne seront pas au courant de cela avant qu’il ne soit trop tard, quelqu’un qui ne connaît pas le javascript du CSS ou un plugin d’un composant de thème, ils n’ont pas à s’inquiéter à moins qu’ils n’aient du javascript dans un composant de thème.
Ce que j’aimerais, c’est un simple test pour qu’ils sachent s’ils doivent s’inquiéter de quoi que ce soit. Pour ces personnes, je leur recommanderai de démarrer un nouveau serveur, de restaurer leur base de données et de voir si quelque chose explose. N’est-ce pas ?
Ou devraient-ils simplement activer EMBER_CLI_PROD_ASSETS: 1, faire une reconstruction et si cela explose, le désactiver, puis démarrer un nouveau serveur pour le réparer.
Je suppose que vous pourriez interroger pour voir s’il existe des theme_fields de type html ou js :
Cela fonctionnerait, mais la mise en place d’un tout nouveau serveur semble être beaucoup d’efforts. Au lieu de cela, je recommanderais :
. . . À moins que vous n’ayez passé l’année dernière à développer un outil pour qu’il soit « facile » de créer de nouveaux serveurs ? 
Donc, ce qui arrivera à ceux qui ne prêtent aucune attention à ces choses, c’est que cela échouera lorsque la fenêtre « ember-by-default » arrivera, puis ils pourront désactiver cette variable d’environnement pendant encore un ou deux mois (et la corrigeront probablement) avant que cela ne fonctionne plus.
J’ai restauré une sauvegarde sur un nouveau site qui a le thème Kanban activé et il génère des erreurs (je l’ai signalé dans le sujet Kanban), j’ai essayé de définir
EMBER_CLI_PROD_ASSETS: 0
et les reconstructions disent toujours :
Pourquoi vous devriez le faire régulièrement :
https://github.com/browserslist/browserslist#browsers-data-updating
ce que je reconnais (je pense) venir de ember-cli. Y a-t-il un moyen de le désactiver sur les nouveaux sites ?
Si je reconstruis un ancien site, va-t-il obtenir la nouvelle image de base et ne pas pouvoir désactiver ember-cli ?
Est-ce une faute de frappe dans votre message ici ou une faute de frappe dans votre yml ? Il devrait être EMBER_CLI_PROD_ASSETS: 0
Merci ! Mais oui, c’est une faute de frappe, mais je l’ai bien mise dans le fichier yml. Je l’ai juste copié/collé correctement dans le message initial.
La vérification dans le code semble inchangée, mais je ne suis pas très familier avec Ruby. Une condition booléenne avec ENV['EMBER_CLI_PROD_ASSETS'] utilisera-t-elle la valeur de cette clé ou sera-t-elle vraie si cette clé existe ?
Si c’est le cas, la réponse pourrait être de supprimer EMBER_CLI_PROD_ASSETS du fichier yml plutôt que de le définir sur 0.
Cela ne fonctionnera pas, vous devez supprimer la ligne.
. . . attendez . . .
Aucun de mes problèmes n’avait à voir avec ember-cli, mais avec ma propre mauvaise configuration, car il s’agissait d’une installation à 2 conteneurs et web_only.yml n’a pas été mis à jour lorsque standalone.yml l’a été. Voici une PR :
Ember CLI est maintenant le choix par défaut pour toutes les installations de Discourse. Lorsque vous effectuerez votre prochaine mise à jour (via l’interface /admin/upgrade ou via ./launcher rebuild app), vous serez automatiquement basculé vers Ember CLI.
Nous utilisons maintenant Ember CLI pour la majorité de notre hébergement géré, nous n’attendons donc pas de problèmes majeurs. Mais si vous remarquez quoi que ce soit, n’hésitez pas à créer un sujet ici sur Meta et nous enquêterons.
J’ai reconstruit un site hier qui avait échoué à cause d’Ember CLI et je l’ai corrigé en supprimant EMBER_CLI_PROD_ASSETS=1.
À un moment donné, j’ai essayé de désactiver Ember CLI en définissant EMBER_CLI_PROD_ASSETS=0 et je suis à peu près sûr que cela incluait toujours ember_cli et quelqu’un m’a dit que l’on ne pouvait pas le désactiver en le réglant sur 0 (ce qui n’avait pas de sens, mais semblait être vrai).
C’est un peu difficile pour les auto-hébergeurs qui ont de vieux thèmes et ne regardent jamais la console JavaScript.
C’était vrai, mais j’ai corrigé la logique avec ce dernier commit afin que =0 fonctionne comme prévu. Cela dit, nous avons l’intention de supprimer totalement l’environnement ‘legacy’ dans quelques semaines, alors n’utilisez pas =0 sauf sur une base extrêmement à court terme.
Nous avons ajouté la rétrocompatibilité pour les erreurs les plus courantes que nous avons rencontrées sur notre hébergement. Par exemple, ce commit il y a quelques semaines a ajouté la rétrocompatibilité pour Discourse.User et Discourse.SiteSettings. Ce commit a corrigé certains problèmes pour les thèmes avec des processus d’initialisation non standard.
Nous voulons que ce déploiement soit aussi fluide que possible, donc si vous avez rencontré des erreurs la semaine dernière environ, veuillez nous faire part de l’erreur précise et du code qui l’a causée.
Oh. Hourra. C’est logique. (Cela fonctionne comme je le pensais depuis le début. Et je ne suis pas fou de me souvenir qu’on m’a dit que cela ne fonctionnait pas comme je le pensais. Ce sont de bonnes choses !).
Je trouve cela vraiment difficile à comprendre (probablement par ignorance). Lorsque je clique sur ce qui, je pense, devrait me montrer ce qui cause l’erreur, ce que j’obtiens est le code qui semble être le code qui teste la dépréciation, pas le code qui l’exhibe. Je m’efforcerai d’envoyer quelques exemples bientôt.
Si vous avez besoin d’aide pour comprendre, un sujet de Support avec une capture d’écran de l’erreur serait un bon point de départ - nous pourrons alors vous aider à déboguer à partir de là. Il y a de fortes chances que quelqu’un d’autre ait rencontré une erreur similaire et puisse reconnaître les symptômes. 
Et maintenant, la dernière étape de cette saga : le système de build hérité est maintenant désactivé. Toutes les installations de Discourse compileront les assets en utilisant Ember CLI.
Ce changement n’affectera que les personnes qui avaient délibérément défini EMBER_CLI_PROD_ASSETS=0 dans leur configuration. Dans ce cas, un avertissement sera imprimé pendant la compilation, et Ember CLI sera utilisé.