loglevel: Missing 'log' method to serve as a drop-in replacement for 'console'

I’ll throw my two cents into the mix:

Problems

console.trace sucks for trace level logging

I avoid using console.trace unless I want to actually see a stack trace. This is because Chrome shows the stack trace expanded, which clutters up the console. I don’t feel it is a good method to use for the trace level of a logging tool.

However, by not using log.trace with loglevel, I’ve limited myself to only 4 levels (error, warn, info, and debug). This is annoying because I often would like to add trace level logs for things that are deeper than debug. But I do not want to see stack traces for them.

Note that console.warn and console.error in Chrome also include stack traces, but they are much more usable since the traces are collapsed. I only have an issue with console.trace.

Not taking full advantage of browser log styling

It is important to consider that Chrome styles console.log, console.debug, console.info, console.warn, and console.error differently. However, loglevel doesn’t take full advantage of this by not supporting console.log. IMO, this is a major downside of loglevel at this time.

Making log.log an alias for some other loglevel will not solve this. We really need a new loglevel for console.log.

App environment is affected by loglevel

I agree with @sompylasar that many app developers don’t want their logging tool to impact the app environment without permission. However, the local storage feature is useful and think it makes sense to continue to support it.

Proposed Solution

I propose the following enhancements be made to loglevel:

• add a verbose log level between debug andtrace
• add a log.verbose method that maps to console.log
• add a log.log method that maps to console.log
• add a configuration option that disables/enables local storage features

I disagree with @mroderick regarding solving this by decorating log methods or creating a plugin. As soon as any wrapper is used around loglevel, the browser will report logs as coming from the wrapping code’s file and line number instead of the actual file and line of the log call within your application.

I am willing to make these improvements and create a PR, but I’d like to hear from @pimterry and others that this proposal would be acceptable.

I use the latest Google Chrome, the devtools console renders debug in blue color, log in black color, info in black color with a blue info icon on the left.

I needed a tiny library that copes with console inconsistencies and is browserifiable/webpackable. For my case I forked and patched loglevel to remove persistence and add log as a second method on the INFO level (see my fork: https://github.com/sompylasar/loglevel/blob/master/lib/loglevel.js#L77 ). I am not suggesting to use the same level for all logging, I am suggesting to wrap every logging method the browser provides.

I understand your thoughts on persistence: you want to visit your app in production, tamper with your own storage and read the logs. It’s a good idea. But if the persistence is hardcoded into the logging library, it touches the environment without express permission from the app author. I see this as putting the persistence part into a separate optional module which lets configure the cookie and the storage or opt out of persistence, and using loglevel.setLevel(loglevelPersistence.getLogLevel()) once in the app’s entry point. No further code changes are needed.

I’d rather not have a log.log method. As in my first posts way above, it’s not a common log level in most other libraries, it’s not obvious where it fits in the semantic order of levels, and it would be a breaking change anyway, which I’d really like to avoid.

I do totally agree we need to find a solution now that console.debug seems to have been quietly killed though. I need to think about it further, but in principle I think I’d be happy to make log.debug start using console.log under the hood, instead of console.debug. How would people feel about that?

No, it does not. The browser console outputs the log and debug messages differently.

I think I’d be happy to make log.debug start using console.log under the hood, instead of console.debug. How would people feel about that?

This seems like a good solution to me as well. Because console.trace has a different behavior than the other log methods, I personally don’t use it as “standard” loglevel in my apps. And with console.debug being a noop, the log methods available for my apps has shrunk to just log.info, log.warn, and log.error. Making log.debug work again by mapping to console.log would certainly help!

I’d rather not have a log.log method. As in my first posts way above, it’s not a common log level in most other libraries, it’s not obvious where it fits in the semantic order of levels, and it would be a breaking change anyway, which I’d really like to avoid.

Why not just have log.log be an alias for log.debug? It wouldn’t add another loglevel, but it would be available for consistency for those who wish their logging tool to have the same API as browser logging. I personally would use log.debug over log.log, but I wouldn’t mind the alias existing. And doing this would squash many of the complaints people have.

Revised Proposal

Now that console.debug is no longer a thing, I would revise my proposal (see post above) to the following:

• change the log.debug method to map to console.log
• add a log.log method that maps to console.log (as an alias, no additional loglevel)
• add a configuration option that disables/enables local storage features

I’ve removed log.verbose because there isn’t anything for it to map to.

I’d like to +1 adding a “log” method. I just ran into this same issue while integrating loglevel. It’s such a common method that it needs to be in the lib; I’d dare say that it’s more often used the “info”.