transports behavior for @accelint/logger

[brandonjpierce]

The current setup of @accelint/logger was designed around the idea that almost all of our use cases include a PLG stack or similar where stdout is consumed and stored from the k8s pods.

As such, we baked in a default transport into the logger to accommodate for this fact. At present it swaps between a human readable and structured logger via the pretty option for getLogger().

// pretty=false
{ level: 'info', time: '2025-01-01T00:00:00.000Z', msg: 'User logged in' }

// pretty=true (see below)

---

At present if you supply any additional transports they are additive to the default stdout logger. You cannot disable that default stdout logger. Meaning if you add in pino transport, for whatever reason, you would technically double up on the structured logging to stdout. E.g.

const p = pino({
  level: 'trace'  // Enable all log levels
})

const logger = getLogger({
  ... // other props
  transports: [
    logger: p
  ]
});

[devindavies]

Could we make it additive, but expose a Boolean flag to explicitly disable the default transport?

[brandonjpierce]

I'll add that as an option 👍

[Peechiz]

the danger is probably super low, but should there be some sort of error thrown if the user were to throw that flag but also not populate transports? I would personally want to know if I accidentally turned off all logging

[brandonjpierce]

Yep that seems reasonable!

[ArrayKnight]

In the case of the Replace option, would you export the default transports array and allow them to spread it (to recreate Additive) or to filter it and then spread it, and/or pick and choose individual transports as exports?

[brandonjpierce]

I think that is a very sensible thing we can do, yeah

[ArrayKnight]

Yea, I think we should go the declarative route. It also handles the scenario if there are multiple default transports but the user only wants to disable one of them