log.debug should map to console debug in Chrome

[dorhugiEvinced]

Although the documentation for Chrome console specifies that console.debug has a log level of "info", it actually has log level of "verbose".

With the current loglevel implementation, debug messages are mapped to console.info. This behavior doesn't allow filtering messages in the dev console which are actually "verbose", and hence causing console.debug and log.debug to have different behaviors.

I suggest that log.debug would map to console debug.

[CaitlinWeb]

I second this. Chrome currently displays debug logs in blue text under the "verbose" category. loglevel is mapping console.debug to console.log in all cases. Instead, if console.debug is present it should use that.

[pimterry]

Yeah, this has been divisive, I'm still not 100% sure either way. The original discussion is here: https://github.com/pimterry/loglevel/issues/64.

The main problem is that this log level doesn't appear in the console by default, which confuses users, as they expect loglevel alone to control which levels of output are visible. Most users don't even realise that chrome's level filtering exists at all.

I'll keep thinking about it - if you or anybody else has strong feelings, do reply here!

In the meantime, you can work around this yourself. If you'd prefer the direct mapping behaviour, you can bring it back using the code snippet from https://github.com/pimterry/loglevel/issues/126#issuecomment-433131539

[verzac]

Hi @pimterry,

Thanks for the lovely plugin!

I personally think that people shouldn't be confused by a direct mapping to console.debug. I thought the aim of this library was just to control whether or not console.debug actually prints to the console, instead of compensating for users not knowing that their browser's log levels are set to INFO by default? Everyone's gone through the shenanigan of using console.debug and being confused as to why there are no messages in the console, right?

That being said, I can understand why people would want this library to compensate for that, I just don't think it should. I don't know, I think it's a bit weird that log.debug proxies to console.log when there's a direct equivalent called console.debug.

JFYI my use-case for this library is that I'm using it for Node.js on Lambda, which means that when I use log.debug, instead of seeing DEBUG, I see INFO on CloudWatch's logs.

Nonetheless, would it be possible to add #126 to the docs while this is still up in the air, or perhaps add a toggle switch? I fairly think it's useful for people who ONLY wants to have a lightweight mechanism to control whether or not their console.debug and console.log calls are actually called without overriding console. Or at least let us know in the docs that log.debug actually proxies to console.log instead of console.debug.

[jocafi]

I suggest to create a new method called "useConsoleDebug(value: boolean)" or "useChromeSpecification(value: boolean)" or another name in order to reorder (remap) the internal calls to the console methods using the Chrome specification.

[Moinax]

This is still open and I still don't see why you do such an exception for log.debug: If the user set his chrome console level to error he won't be able to see the log.info anyway.

[silasabbott]

With console.debug being officially supported in all browsers, I feel it really does need to be accounted for somehow in this library. It has its own purpose, despite being so closely related to console.log In Firefox, debug is an entirely separate level on its own.

I think it makes a lot more sense to teach users with an important note in the docs about log level filters, rather than completely omitting a standard console method.