dbug v0.1
I’ve been on a logging spree recently, and after having spent some time on an application logging module, I’ve been thinking about what libraries can do about logging. At first I said that libraries should just dump everything into console.log, but I can definitely see downsides to that.
debug
debug is a popular utility that handles this problem of libraries wanting logging without annoying consumers quite well. You can use debug, name a logger, and log messages all you want. Unless a consumer adds en ENV variable to listen to those debug messages, it will be all quiet.
dbug
dbug works largely the same, with a few tweaks that I feel are really helpful, but I don’t think I’d have been able to convince TJ to include them in debug.
First of all, it’s a perfectly safe drop-in replacement for debug. It has the same API.
However, it adds a few familiar methods that you’d find on the console object, so you can classify the severity of particular dbug messages. Some may simply be info messages, while others are meant to signify when an error or warn has occurred. Still though, only if the consumer has opted-in to see your messages by setting process.env.DEBUG.
The log level will be included in the log message, so everyone can see the severity.
Additionally, the DEBUG matching is slightly more lenient. You can still use * and comma separated names, but additionally, specifying a name now implies any of it’s children.
DEBUG=foo will match foo:bar. Basically, every name is also the same as name:*.
v0.1.0
0.1 is available now.
A few things I’ve been toying with adding to additional versions:
DEBUG=foo.warnto only get warn or greater message from thefoologger.- Allowing
.to be a separate in log names also:dbug('foo.bar').
And, currently next up is getting intel to play nice with debug/dbug.
