seanmonstar

Feb 11 2014

intel v0.5

intel is turning into an even more awesome logging framework than before, as if that was possible! Today, I released version 0.5.0, and am now here to hawk it’s newness. You can check out the full changelog yourself, but I want to highlight a couple bits.

JSON function strings

intel.config is really powerful when coupled with some JSON config files, but Formatters and Filters were never 100% in config, because you could pass a custom function to either to customize to your little kidney’s content. It’s not possible to include typical functions in JSON. Much sad face. So, the formatFn and filterFn options allow you to write a function in a string, and intel will try to parse it into a function. Such JSON.

Logger.trace

A new lowest level was introduced, lower than even VERBOSE, and that’s TRACE. Likewise, Logger.trace behaves like console.trace, providing a stack trace with your message. If you don’t enable loggers with TRACE level logging, then no stacks will be traced, and everything will choo-choo along snappy-like.

Full dbug integration

This is the goods. intel is an awesome application logging library, since it lets you powerfully and easily be a logging switchboard: everything you want to know goes everywhere you want. However, stand-alone libraries have no business deciding where logs go. Libraries should simply provide logging when asked to, and shut up otherwise. That’s why libraries should use something like dbug. Since v0.4, intel has been able to integrate somewhat with dbug, but with 0.5, it can hook directly into it, meaning less bugs, and better performance. Examples!

// hood/lib/csp.js
var dbug = require('dbug')('hood:csp');

exports.csp = function csp(options) {
    dbug('csp options:', options);
    if (!options.policy) {
        dbug.warn('no policy provided. are you sure?');
    }
    // ...
};

// myapp/server.js
var intel = require('intel');
intel.console({ debug: 'hood' });
// will see: 'myapp.node_modules.hood.csp:DEBUG csp options: {}'

Dare I say, using intel and dbug together gives the best logging solution for libraries and apps.

Oct 25 2013

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.warn to only get warn or greater message from the foo logger.
  • 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.