Is this possible to turn off SOME deprecations warnings?


I want to upgrade my app to version 1.11 and the biggest problem is the removal of ObjectController. It would be very helpfull for me to have warnings on “You attempted to access […] but object proxying is deprecated”, but not “Ember.ObjectController is deprecated, please use Ember.Controller…”.

Is this possible?

The reason for that is that I want to have ObjectController, so nothing breaks and just repair the proxying.

p.s. Is it also possible to hook to some deprecations? So when certain one is occurring, i can for example trigger some tracker and log it on server?


I would like to know how to disable warnings, aside from managing a fork of Ember, cause I’ve tried that.

  • The best way is to fix what they are warning you about. :smiley:
  • @pangratz has submitted an RFC (that I believe @mixonic has also reviewed and helped with) to make a public log level API, please check that out: emberjs/rfcs#65.
  • If you need to be able to silence warnings and deprecations immediately, you can conditionally override the Ember.deprecate and Ember.warn methods. For example, while running your tests (or just running the app but without tests) you might add something like the following to tests/test-helper.js:
import Ember from 'ember';

Ember.deprecate = function() { };
Ember.warn = function() { };


I’ve asked the question because I want to fix the deprecations. :slight_smile: Problem is that (if I see correctly) this RFC you are talking about is for the master branch so I don’t know if it’s possible to use in Ember 1.11…

I think this way would be good for many teams, when upgrading from 1.10 to 1.11:

  • fixing all references to model without ‘model’ keyword
  • at the same time leaving ObjectController, so nothing breaks (this causes unwanted obvious deprecation logs)
  • eventually hook some api calls to all other deprecation logs
  • after two weeks of work and testing, we are sure that there are no bad references to the model (no more logs from step above), we just replace all ObjectController with Controller everywhere in the app

p.s. so yeah, maybe replacing Ember.deprecate method, filtering the message text and, if passed, forwarding to the original method, is the best option…


@rwjblue I recall there used to be hooks for dev only code I forget what happened to those, I used to have helpers for inspecting views and things like that. Seems like it would be cool to revive that dev plugin hook to easily redefine what deprecations you ignore during upgrade work. It’s been so noisy sometimes the deprecation just get in the way of development work.


Yeah, I definitely understand your point. I intend to use the RFC that I linked above to make it trivial for an Ember CLI app to use RAISE_ON_DEPRECATE for any/all new deprecations but allow (or silence) ones that are still being worked on by a dev team. This both makes your console easier to look at, and gives you a concrete list of the “chores” that the team needs to cleanup over time.

Please review and chime in on that RFC…


I really like the RFC for configuring log level and silencing deprecations. hope it gets traction.


The RFC mentioned above is now live and you can do something like this (in an initializer):

let list = ['id-for-deprecation']; // change this list

Ember.Debug.registerDeprecationHandler((message, options, next) => {
  if (!list.includes( {
    next(message, options);

(noted here since this thread often comes up in Google queries)