La parte importante della mia frase era:
Una volta aggiornato, le deprecazioni si trasformano in errori, come hai detto 
Sì, questi sono accessibili tramite le proprietà iniettate dei componenti, o importando i moduli Site e User da discourse/models/user e discourse/models/site
Ah sì, utile alternativa al passarli tramite helper come parametri.
Per il mio plugin che sto sviluppando ed eseguendo ./bin/ember-cli non ho nulla di cui preoccuparmi, dato che sto usando ember-cli.
Ma la mia preoccupazione sono le dozzine o centinaia di persone che non lo scopriranno finché non sarà troppo tardi, qualcuno che non conosce javascript da CSS o un plugin da un componente del tema, non ha bisogno di preoccuparsi a meno che non abbia javascript in un componente del tema.
Quello che vorrei è un semplice test in modo che sappiano se devono preoccuparsi di qualcosa. Per quelle persone, raccomanderò loro di avviare un nuovo server, ripristinare il loro database e vedere se qualcosa va storto. Giusto?
Oppure dovrebbero semplicemente attivare EMBER_CLI_PROD_ASSETS: 1, fare una ricostruzione e se va storto, disattivarla di nuovo, e poi avviare un nuovo server per risolverlo.
Suppongo che potresti interrogare per vedere se ci sono theme_fields con il tipo html o js:
Funzionerebbe, ma configurare un server completamente nuovo sembra uno sforzo eccessivo. Invece, consiglierei:
. . . A meno che tu non abbia passato l’ultimo anno a sviluppare uno strumento per rendere “facile” l’avvio di nuovi server? 
Quindi, ciò che accadrà a coloro che non prestano attenzione a queste cose è che si romperà quando arriverà la finestra di ember-by-default e quindi potranno disattivare quella variabile ENV per un altro mese o due (e presumibilmente risolverla) prima che ciò non funzioni più.
Ho ripristinato un backup su un nuovo sito che ha abilitato il tema Kanban e sta generando errori (l’ho segnalato nell’argomento Kanban), ho provato a impostare
EMBER_CLI_PROD_ASSETS: 0
e le ricompilazioni dicono ancora:
Perché dovresti farlo regolarmente:
https://github.com/browserslist/browserslist#browsers-data-updating
che (penso di) riconoscere provenire da ember-cli. C’è un modo per disabilitarlo sui nuovi siti?
Se ricompilo un vecchio sito, otterrà la nuova immagine di base e non sarà in grado di disabilitare ember-cli?
C’è un errore di battitura nel tuo messaggio qui o nel tuo yml? Dovrebbe essere EMBER_CLI_PROD_ASSETS: 0
Grazie! Ma sì, quello è un errore di battitura, ma l’ho corretto nel file yml. L’ho semplicemente copiato e incollato correttamente nell’OP.
Il controllo nel codice sembra invariato, ma non ho molta familiarità con Ruby. Un condizionale booleano con ENV['EMBER_CLI_PROD_ASSETS'] utilizzerà il valore di quella chiave o sarà vero se quella chiave esiste?
Se è quest’ultima, la risposta potrebbe essere rimuovere EMBER_CLI_PROD_ASSETS dallo yml piuttosto che impostarlo a 0.
Non funzionerà, devi rimuovere la riga.
. . . aspetta . . .
Nessuno dei miei problemi aveva a che fare con ember-cli, ma con la mia errata configurazione, dato che si trattava di un’installazione a 2 container e web_only.yml non è stato aggiornato quando standalone.yml lo è stato. Ecco una PR:
Ember CLI è ora l’impostazione predefinita per tutte le installazioni di Discourse. Quando aggiornerai la prossima volta (tramite l’interfaccia utente /admin/upgrade o tramite ./launcher rebuild app), verrai automaticamente passato a Ember CLI.
Ora stiamo eseguendo Ember CLI nella maggior parte del nostro hosting gestito, quindi non ci aspettiamo problemi significativi. Ma se noti qualcosa, per favore crea un topic qui su Meta e indagheremo.
Ho ricostruito un sito ieri che è fallito a causa di ember CLI e l’ho risolto rimuovendo EMBER_CLI_PROD_ASSETS=1.
A un certo punto all’inizio ho provato a disabilitare ember cli impostando EMBER_CLI_PROD_ASSETS=0 e sono abbastanza sicuro che includesse ancora ember_cli e qualcuno mi ha detto che non potevi disabilitarlo impostandolo a 0 (il che non aveva senso, ma sembrava essere vero).
Questo è un po’ difficile per gli auto-ospitanti che hanno temi vecchi e non guardano mai la console javascript.
Questo era vero, ma ho corretto la logica con quest’ultimo commit in modo che =0 funzioni come previsto. Detto questo, intendiamo rimuovere completamente l’ambiente ‘legacy’ tra poche settimane, quindi per favore non usare =0 a meno che non sia per un periodo di tempo estremamente breve.
Abbiamo aggiunto la retrocompatibilità per gli errori più comuni che abbiamo riscontrato nei nostri hosting. Ad esempio questo commit un paio di settimane fa ha aggiunto la retrocompatibilità per Discourse.User e Discourse.SiteSettings. Questo commit ha corretto alcuni problemi per temi con processi di inizializzazione non standard.
Vogliamo rendere questo rilascio il più agevole possibile, quindi se hai riscontrato errori nell’ultima settimana circa, ti preghiamo di comunicarci l’errore preciso e il codice che l’ha causato.
Oh. Evvai. Ha senso. (Funziona come pensavo dovesse funzionare fin dall’inizio. E non sono pazzo a ricordare che mi è stato detto che non funzionava come pensavo dovesse funzionare. Queste sono grandi cose!).
Trovo molto difficile capirlo (probabilmente a causa dell’ignoranza). Quando clicco sulla cosa che penso dovrebbe mostrarmi cosa sta causando l’errore, quello che ottengo è il codice che sembra essere il codice che testa la deprecazione, non il codice che la mostra. Mi impegnerò a inviare presto alcuni esempi.
Se hai bisogno di una mano per capirlo, un argomento di Support con uno screenshot dell’errore sarebbe un buon punto di partenza, poi potremo aiutarti con il debug da lì. È probabile che qualcun altro abbia riscontrato un errore simile e possa riconoscerne i sintomi. 
E ora l’ultimo passo di questa saga: il sistema di build legacy è ora disabilitato. Tutte le installazioni di Discourse compileranno gli asset utilizzando Ember CLI.
Questa modifica influenzerà solo le persone che avevano impostato deliberatamente EMBER_CLI_PROD_ASSETS=0 nella loro configurazione. In tal caso, verrà visualizzato un avviso durante la build e verrà utilizzato Ember CLI.