Rebase on top of bunyan about browser-bunyan

[philmander]

These features are now in the 0.4.0 release

[philmander]

The codebase was originally forked from node-bunyan, but is now detached. The code has diverged significantly and has its own releases.

Is there a node-bunyan feature you would like to see in browser-bunyan?

[tonyxiao]

nope, just out of curiosity.
Unrelated There is something that does hinder me about browser bunyan though. When I use console.log if I log an object it will actually print the object out such that I can expand it and interact with it on the console.

If I use browser-bunyan it just prints out [Object object]. Got any workarounds?

[philmander]

This isn't something that's been inherited from node-bunyan because it's not applicable on the server. The closest behavior is if you currently do this:

console.log( { abc: 123, xyz: 789 }, 'Logging an object' );

The log record will contain the fields abc and xyz, but you will need a custom log stream to actually print these fields to the console.

However, I think this is quite a nice feature for the browser so I made some updates in this branch. I've added a standard serializer which will add the object to the log record plus the built-in log streams will print the object directly to the console. Basically, it does what you want.

To use it, make sure your logger is created with the standard serializers:

var formattedLogger = bunyan.createLogger({
     name: 'formatted',
     streams: [ ... ],
     serializers: bunyan.stdSerializers
 });

Can you verify the build in the branch is good of you. If so I'll probably release it.

[tonyxiao]

Just checked, this only works if I have object as the first param.

This works

log.info(config, 'common chunk loaded with config');

This doesn't

log.info('common chunk loaded with config', config);

[philmander]

This is by design, the same way Bunyan already logs error objects as the first argument. Doing what you want to do is tricky, because Bunyan only treats the first argument as possibly being a special value and feeds subsequent arguments into util.format and these should be strings.

However, I've decided doing this will screw around with Bunyan's serializer functionality too much anyway. Instead, I've just added some special object logging support to the built-in loggings streams. To log an object you'll be able to do this:

logger.info( { obj: config }, 'common chunk loaded with config');

This should be the workaround you're looking for.

[tonyxiao]

Got it regarding by design.

Though I'm not sure if I understood the full message. I should still use bunyan.stdSerializers right? And since log.info(config, 'common chunk loaded with config') already works when config is an object, why would I want to wrap it in yet another {obj: config}?

[philmander]

Forget the bunyan.stdSerializers I didn't go with that in the end.

I think your question is best answered in the original Bunyan readme here.

Note that this implies you cannot blindly pass any object as the first argument to log it because that object might include fields that collide with Bunyan's core record fields. In other words, log.info(mywidget) may not yield what you expect. Instead of a string representation of mywidget that other logging libraries may give you, Bunyan will try to JSON-ify your object. It is a Bunyan best practice to always give a field name to included objects, e.g.: