Deprecating Ember.Logger

[lupestro]

This is the RFC for the work to deprecate Ember.Logger.

Rendered.

[mmun]

I support this change. Happy to help implement as well.

[ef4]

This is good, and it looks like a nicely separable piece of work that doesn't require any deep experience with ember internals.

[locks]

A suggestion: Try making the question a sub-header and not use bullet points for all of the answer.

[locks]

You might want to slightly rephrase this section to specifically indicate that it is Ember.warn and friends that are noops in production.

[paulyoder]

What happens in the situation where the Ember.Logger methods are wrapped in another function to provide additional functionality?

For example, my app has an initializer that sends all log messages to Rollbar. Here is what it looks like for the Ember.Logger.info method:

let infoLogger = Ember.Logger.info;
Ember.Logger.info = function() {
  Rollbar.info.apply(Rollbar, arguments);
  infoLogger.apply(this, arguments);
};

How would I change this code in light of this RFC? Would I just override console.info directly then?

[bendemboski]

@paulyoder I would think you'd just override console.info directly -- that's what many libraries that don't depend on a framework like Ember do, e.g. TrackJS.

[bendemboski]

I think this makes sense. As far as the eslint question, I personally wouldn't want to turn off no-console because I frequently scatter console.log()s and console.count()s and whatnot in my code while I'm debugging something, and want eslint to remind me to remove them before checking in the code. So I would opt for something like this:

no-console: ["error", { allow: ["info", "warn", "error"] }]

This gives me a good set of options for logging to the console, but also allows me to use console.log() or console.debug() (and various other console methods) with the eslint safety net.

Personally, I'd advocate for something like ☝️ over just disabling no-console in ember-cli's blueprints, although I'm uncertain of the merits of doing ☝️ over just leaving it on and letting the user decide.

[webark]

I think that separate from this RFC, it would be nice to have another RFC that deals with the "debugging and logging story" of ember. I think this is where a lot of these kinds of issues could come out, and you could tap into some parts of ember and other extensible tools to get a richer logging and debugging experience.

[locks]

@webark send that RFC over ;)

[rwjblue]

@lupestro - Great job putting this together!!

I only have a few responses to the unanswered questions section:

How do we deal with Logger.debug in the codemod?

I think replacing it with (console.debug || console.log)(<whatever arguments>) would be perfectly fine (and be an accurate codemod). I think Logger.debug is fairly rare, and having the codemod roughly guarantee existing functionality is a good default...

What do we do about the eslint no-console flag?

I think we do nothing. Leaving Logger.log's strewn about a codebase just as a way to work around the no-console rule is much worse than simply adding // eslint-disable-line no-console (the codemod could do this for the user automatically also).

[rwjblue]

We discussed this at the core team meeting today, and we are general happy to move forward on this RFC. Since it seems like conversation has largely settled here, we are moving it into the final comment period.

[akatz]

Rendered?: https://github.com/lupestro/rfcs/blob/cbef6c30cc6915c57ba116597c98a7c2ab864c69/text/0297-deprecate-ember-logger.md

[machty]

I'm the proud maintainer of the addon with the most uses of Ember.Logger (ember-concurrency), and technically e-c supports Embers all the way back to 1.13. If I want to continue that long-term support I'll have to have some kind of code that fulfills a similar purpose as Ember.Logger; what's the proper strategy for me going forward?

[lupestro]

Currently, the best recommendation I can think of is to build a small wrapper of your own, preferably as a service suitable for dependency injection, possibly even available to your clients for interception. (Ember.Logger itself has something like a single functional line for each kind of console call it performs, so your wrapper shouldn't need to be any bigger.)

I'm hoping other reviewers will have a better suggestion. I'll make sure the best suggestion makes it into the deprecation guide, since this is a question that is likely to be asked a lot. Should I say anything in the RFC text at this late date?

[MelSumner]

Was the option 2 considered as a bridge, or will that just prolong the pain?

Extract Ember.Logger into its own (tiny) @ember/console package as a shim for users.

[rwjblue]

@MelSumner - I think that is likely fine but under a different name (e.g. @ember/legacy-logger or somesuch).

@machty - I believe that the answer here is more situational (e.g. it depends how an addon uses Ember.Logger). In the ember-concurrency cases, I have specific suggestions below.

• Warning for not using maxConcurrency - This should be swapped for deprecate (the message explicitly states that it is a deprecation). This change is backwards compatible and avoids any deprecations proposed by this RFC.
• Logging the cancellation reason when manually debugging - I would change this usage to directly invoke console.log. This would mean that someone could not debug manually on IE < 11, but that seems like an extremely unlikely scenario...

[rwjblue]

Thanks to everyone for participating in this RFC! After discussion with the core team, we are 👍 on moving forward here.