Logger creation

[gagle]

Instead of having a unique logger instance which can use any module in the npm registry, have you thought about letting the user to create instances? I feel very insecure having only one instance. I'd prefer to have a wrapper around the bole module, something like this:

//logger.js
module.exports = require('bole').createLogger();
module.exports.output([...]);

And then use that instance as usual:

var log = require('../../very/long/path/to/logger')('my-module');
log.info(...);

You could maintain the singleton instance, but third-party modules shouldn't use a logger module, bole shouldn't be a dependency of any other module.

You may think that this approach generates the very-hard-to-maintain relative paths, and it's true, but this can be resolved in other ways. Furthermore, if you're using a web framework with a very basic evented logging mechanism like hapi, you don't need to care about this. Hapi emits events which can be listened in a single place. With the below code you just need to require the module once in your app. This is just a sample, but other frameworks could work in a similar way:

//Anywhere
hapiServer.log(['my-module', 'error'], new Error ('foo')); //This can be wrapped in a function: log(new Error('foo'))
hapiRequest.log(...);

//Listening
var logger = require('../../very/long/path/to/logger'); //The path is hardcoded only once
server.on('log', function(event) {
  bole(event.tags[0])[event.tags[1]](event.data);
  //This will be resolved to: bole('my-module').error(err)
})

[rvagg]

@gagle yes, I'm fine with this approach and would welcome a pull request that is additive and doesn't take away from the singleton pattern.

My original goals with the singleton was to make a simple logger, in my opinion bunyan is too complex for most use-cases and the lack of a singleton is to blame for most of that. With bole, you can log anywhere in your application and not have to pass the logger around between modules.

But that doesn't preclude adding functionality to support more sophisticated use-cases if people want them, as long as it doesn't detract from the simple use-case.