1.0.1 • Public • Published


    Make bunyan's log level methods much mo' betta'!


    • Have bunyan's log level methods return values, usually the first argument given so that you can inline your logging statements.
    • No worries about having your logged objects conflict with bunyan's core fields.
    • Allow log level methods to support functions in order to defer expensive log statements if the log method's level is below the currently configured log level.


    Install bunyan & @northscaler/bunyaner:

    $ npm i --save bunyan
    $ npm i --save @northscaler/bunyaner

    Create a file that your module will use to get a logger:

    // log.js
    const bunyan = require('bunyan')
    const bunyaner = require('@northscaler/bunyaner')
    module.exports = bunyaner({ bunyanLogger: bunyan.createLogger({ name: 'my-logger' }) })

    Now use it:

    const log = require('./log')
    let gameState = log.info({
      game: 'zork',
      player: 'querky123'
    }) // logs { ..., "payload": { "game": "zork", "player": "querky123" }, ... } & returns object
    // ...querky123 plays game to level 5...
    gameState = log.info({
      game: 'zork',
      player: 'querky123',
      level: 5 // <- conflicts with bunyan core logging field, but no matter!
    }) // logs { ..., "payload": { "game": "zork", ..., "level": 5 }, ... } & returns object
    if (gameState.badness) {
      // log method logs given error, then returns it so it can be thrown
      throw log.error(new Error('boom'), 'we blew up')
    } // logs { ..., "isError": true, "payload": { "message": "boom", "stack": ... }, "msg": "we blew up", ... } & returns the error object
    // avoid calculations if your logging level is higher than
    // your method's level by putting whatever's logged inside a function:
    log.debug(() => `foo: ${somethingExpensive()}`) // if log.level() is > debug, somethingExpensive() is never called!


    This library monkey patches a bunyan logger to give it log level methods that

    • return a value,
    • allow the caller to defer expensive evaluation when the current log level is below the level of the log method invoked.
    • prevent conflicts with bunyan's core fields, and
    • indicate that the logged object was an Error.

    Returning values

    With this monkey patch, the log methods return values so that you can inline your logging code. The returned value is usually the first argument that you give the log function, but there are some exceptions noted below. Generally, inline logging looks like this:

    const foo = log.debug({bar: true}, 'I just set my foo')

    and it will log something like this (without indentation):

      "name": "test",
      "hostname": "...",
      "pid": 32708,
      "level": 30,
      "payload": {
        "bar": true
      "msg": "I just set my foo",
      "time": "2020-08-18T17:13:42.766Z",
      "v": 0

    The value is returned whether or not the log level method would generate log output. Otherwise, inline logging wouldn't be very valuable!

    The only times the value returned from the log method is not the first value are the following.

    • If the first argument is a function, you are performing deferred execution and shouldn't be using inline logging, so undefined is returned.
    • If the first argument is a util.format string, then the second argument to the log level method is returned and there is no payload property in the logged record.

    Lazy log calculations

    Passing a function to the log method will cause evaluation of the function to be executed only if the current log method would produce output. After all, if you're not going to log anything, then don't calculate anything to log!

    When the first argument is a function, the function will be invoked with the remainder of the arguments given and the function's return value will be passed along to bunyan's log method. If the function returns an array, then the elements become the multiple arguments to the log method.

    No conflicts with core logging properties

    For any object that you want to log, this monkey patch puts it in a property called payload (by default), so that you don't ever conflict with bunyan's core fields.

    Logging Errors

    If the payload is an Error, the isError property is included in the log record with the value true. You can also force the isError property to always be present, too, and its value will be true or false based on whether the payload is an Error.

    throw log.error(new Error('boom'), 'Done blowed up')

    logs (without indentation):

      "name": "test",
      "hostname": "...",
      "pid": 32908,
      "level": 50,
      "payload": {
        "message": "boom",
        "name": "Error"
      "isError": true,
      "msg": "Done blowed up",
      "time": "2020-08-18T17:49:30.797Z",
      "v": 0

    Notice the payload & isError properties in the log record.

    If the first argument is an Error, bunyan's configured err serializer is used to log it, otherwise it is converted into a plain, old JavaScript object and that value is logged. In either case, there is a log record field added called isError (by default) and its value will be truthy. If you don't want to include the Error stack, use your own err serializer with bunyan.


    The function returned by require('@northscaler/bunyaner') takes a configuration object as follows.

      bunyanLogger: logger,             // required: your configured bunyan logger instance
      bunyanerOpts: {                   // optional
        payloadKey: 'payload',          // or whatever you want, just don't conflict with bunyan
        errorIndicatorKey: 'isError',   // or whatever you want, just don't conflict with bunyan
        alwaysShowErrorIndicator: false // or true

    Create a file in your app that configures the log, then have your app just require:

    const bunyan = require('bunyan')
    const bunyaner = require('@northscaler/bunyaner')
    // ...configure bunyan however you want to here...
    const logger = bunyan.createLogger({ name: 'my-logger' })
    module.exports = bunyaner({ bunyanLogger: logger })


    Don't use return value feature with deferred logging

    If you use deferred logging, like log.debug(() => somethingExpensive()), remember that you will not get a return value from the log method, because you are intentionally skipping logging based on the current log level.

    Use aspects for tracing

    Combine AOP from @northscaler/aspectify with this library's deferred logging to do automated, efficient and unobtrusive tracing. Here's an example that logs inputs as well as happy & saddy path outputs:

    // in file trace.js
    const { AsyncAround } = require('@northscaler/aspectify')
    const log = require('./.../log.js') // as above
    const trace = async ({ thisJoinPoint }) => {
      const start = Date.now()
      try {
        const returned = await thisJoinPoint.proceed()
        log.trace(() => ({
          clazz: thisJoinPoint.clazz.name,
          method: thisJoinPoint.fullName,
          args: thisJoinPoint.args,
          elapsed: Date.now() - start
        return returned
      } catch (e) {
        log.error(() => ({
          clazz: thisJoinPoint.clazz.name,
          method: thisJoinPoint.fullName,
          args: thisJoinPoint.args,
          threw: e,
          elapsed: Date.now() - start
        throw e
    module.exports = AsyncAround(trace)

    Now use it:

    const trace = require('./trace')
    class CustomerRepository {
      constructor(mongoose) {
        // ...  
      @trace // will log happy & saddy paths -- no need for log statements everywhere
      async findByLastName(lastName) {
        // use mongoose to query...

    Use @northscaler/error-support

    NB: shameless plug.

    If you use @northscaler/error-support, the Errors you log will be converted very nicely to a loggable object, include entire cause chains.


    npm i @northscaler/bunyaner

    DownloadsWeekly Downloads






    Unpacked Size

    1.07 MB

    Total Files


    Last publish


    • avatar
    • avatar
    • avatar
    • avatar
    • avatar