Configuring pino

[karl-run]

The log ingestion service I am using have certain requirements that require me to configure pino in a specific way. Is there any way to achieve this?

Great library by the way.

[atkinchris]

Unfortunately, this isn't possible at the moment - but it's the next thing I'd like to work on when I get time.

What format would be most useful to you? I was thinking a .loggerrc.js file, and a logger construction function () => (level) => (...log) => void.

[kurideja]

Hi, thanks for a great library. Not OP, but in my case, I wanted to use custom log level labels and a custom message key. IMHO .loggerrc.js or next-logger.config.js could export optional properties options and destination that are needed for pino factory function pino([options], [destination]) => logger.

[karl-run]

Yeah a .loggerrc.js would solve my problems as well. I need to disable timestamp and map the labels from numbers to strings.

[atkinchris]

Would a custom Pino transport work for you here? https://github.com/pinojs/pino/blob/v7.0.0/docs/transports.md

[rohit-gohri]

I think best would be to provide a way to pass a pino instance, that would already be configured with transports/serializers/redaction settings/etc. Something like next-logger.config.js where we can export a custom logger instance:

// next-logger.config.js
const pino = require('pino');

const logger = pino({
  messageKey: 'message',
  level: process.NODE_ENV === 'production' ? 'info' : 'trace',
  enabled: !(process.env.NO_LOG === 'true'),
});

module.exports = {
    logger,
};

[atkinchris]

I've got a beta version of this, with config loading - if you wouldn't mind trying it out. I'm especially interested to see how the config loading copes with your Yarn workspaces, @rohit-gohri!

npm install "https://github.com/atkinchris/next-logger.git#v3.0.0-beta.1"

Create a file at the root of your project called next-logger.config.js (or feasibly anything else that cosmiconfig can read from). Make this a CommonJS module, and export a field called logger. If this is a Pino instance, it will be used instead of the default instance.

For an example, here's the config I've been using this evening on one of my projects that consumes this library.

// next-logger.config.js
const pino = require('pino')

const logger = pino({
  messageKey: 'message',
  timestamp() {
    return `,"@timestamp":"${new Date(Date.now()).toISOString()}"`
  },
  formatters: {
    level(label) {
      return { level: String(label).toUpperCase() }
    },
  },
})

module.exports = {
  logger,
}

[atkinchris]

I'm going to change logger into a function. It would be passed the library's default Pino configuration, and would be expected to return a Pino instance.

This should make it easier to extend the default behaviour - which is designed to match console.log usages in Next.js, such as logging with multiple arguments.

---

This is now in beta 2.

npm install "https://github.com/atkinchris/next-logger.git#v3.0.0-beta.2"

// next-logger.config.js
const pino = require('pino')

const logger = (defaultConfig) => pino({
  ...defaultConfig,
  messageKey: 'message',
  timestamp() {
    return `,"@timestamp":"${new Date(Date.now()).toISOString()}"`
  },
  formatters: {
    level(label) {
      return { level: String(label).toUpperCase() }
    },
  },
})

module.exports = {
  logger,
}

---

This is now published to npm on the beta dist tag.

npm install next-logger@beta

[karl-run]

Nice! That's works perfectly. :) That way I can require that config for my application logger as well.

[rohit-gohri]

I somehow missed the original beta release, tested this now. Working great in yarn workspace based monorepo too! 🥳

[atkinchris]

Thanks for confirming @karl-run & @rohit-gohri. We've also been using the beta in a couple of production applications since October.

I've formally released this now as a new major version. The existing behaviour is captured in the provided default logger, so there shouldn't be breaking changes.