[BUGFIX beta] Refactor deprecations to have a private log level API#11419
Conversation
There was a problem hiding this comment.
nitpick: few small typos in test name
|
LGTM. My only thought is maybe introduce only one new underscored prop on the |
mixonic
force-pushed
the
raise-on-deprecation-no-dont-actually-raise
branch
from
ab24816 to
9699cf7
Compare
|
These methods should move to |
mixonic
force-pushed
the
raise-on-deprecation-no-dont-actually-raise
branch
from
9699cf7 to
7f38ad4
Compare
mixonic
force-pushed
the
raise-on-deprecation-no-dont-actually-raise
branch
from
7f38ad4 to
f56a8c5
Compare
…ctually-raise [BUGFIX beta] Refactor deprecations to have a private log level API
Fixes an issue introduced by emberjs#11419 where the evaluation of `ENV.RAISE_ON_DEPRECATION` was moved to boot-time rather than run-time. Previously, it was possible to set `RAISE_ON_DEPRECATION` to true midway through running an app, and all deprecations after that would throw because `Ember.deprecate` would check the value of the env variable every time it was called. The code in emberjs#11419 changed to a [one-time evaulation at boot-time](https://github.com/emberjs/ember.js/blob/master/packages/ember-debug/lib/main.js#L279-L281), breaking that original behavior. This commit restores the old behavior while still allowing changing deprecation behavior for specific deprecations by id.
Fixes an issue introduced by #11419 where the evaluation of `ENV.RAISE_ON_DEPRECATION` was moved to boot-time rather than run-time. Previously, it was possible to set `RAISE_ON_DEPRECATION` to true midway through running an app, and all deprecations after that would throw because `Ember.deprecate` would check the value of the env variable every time it was called. The code in #11419 changed to a [one-time evaulation at boot-time](https://github.com/emberjs/ember.js/blob/master/packages/ember-debug/lib/main.js#L279-L281), breaking that original behavior. This commit restores the old behavior while still allowing changing deprecation behavior for specific deprecations by id. (cherry picked from commit 7290c71)
|
Hmm, somehow it would be nice if this would be available in |
|
Sure, it should be available to ember-data. |
|
Yeah, I just figured this is as fresh as it gets and available since |
|
@pangratz in 1.13 as well 👏 something like this should probably go through the RFC process and become a public API- It seems bad to opt into a new private-but-already-used-by-ember-data use. |
|
Okidok, maybe I can come up with such in the next days... |
|
Agreed. I believe that @teddyzeenney will also be excited about using this from the inspector (to get raise on deprecation for specific deprecations for easier tracking down of deprecations). We also need to begin adding ids for all usages of Ember.deprecate though... |
|
Okay, I gave it a shot: emberjs/rfcs#65 |
@rwjblue can you elaborate? The default behavior still exists, only a finer grained control over specific deprecation warning is added, right? |
4 participants
On the path to 1.13, we're adding a few deprecations that will take more than several days to completely remove from Ember's own tests. Therefor we've added a private API for changing the level of these deprecation messages to "silence". This both keeps the dev process smooth, and allows Travis to process our builds without blowing the log buffer.