Ember 2.2.0 Deprecation Checklist

[rwjblue]

• Function as second argument in debug functions

[workmanw]

So I was looking into trying to write a rule for this. But I'm not completely sure how to do it. It would be easy to write a rule for the following:

Ember.assert(message, () => true, options);
Ember.assert(message, function() { /* ... */ }, options);

The challenge I think would be:

const myConstructor = {}.constructor;
Ember.warn(message, myConstructor, options);

It's possible there is some way to do this that I don't know about. But it definitely seems like a runtime concern. You couldn't always determine what typeof the second argument is.

---

I'd be happy to attempt the former. It seems like it may cover most usage. Also I could attempt the later with some direction.

[minichate]

@workmanw The approach I've been taking in these cases is to try and optimize for the common real-world cases.

The integration suite will run the changes against some large-ish open source Ember projects (Discourse, etc.) which I've taken as a proxy for "scenarios that people actually run into".

[workmanw]

+1 That seems practical to me. I also ran it against our app too.

I'll take a swing at the "happy path" use case tomorrow. Cheers!
On Jan 26, 2016 10:12 PM, "Christopher Troup" [email protected]
wrote:

@workmanw https://github.com/workmanw The approach I've been taking in
these cases is to try and optimize for the common real-world cases.

The integration suite will run the changes against some large-ish open
source Ember projects (Discourse, etc.) which I've taken as a proxy for
"scenarios that people actually run into".

—
Reply to this email directly or view it on GitHub
#3 (comment)
.