Allow variable substitution in logger

[andrewplummer]

ie. logger.debug('some string %s', var)

[kaareal]

does this also work in production? with pino logger

[andrewplummer]

Updated to allow errors to preserve their stack trace.

idk about pino logger this is just for the console logger

[kaareal]

I think we should align the setup so it match pino (production usecase) ... which should be possible.
The logger.info([mergingObject], [message], [...interpolationValues]) is what pino suggests.

Which we kind of dont like as we like to write (perhaps we are wrong)
logger.info("message", object) ... but that will be seen as [message], [...interpolationValues] ... so that leads to problems.

i think we should define how this works before support interpolationValues or at the same time.

[andrewplummer]

I'm not really sure what mergingObject or whatever that is, but if it doesn't work like console then I think they're already misaligned... The question is does pino logger support printf style interpolation? If it does then it makes sense to support it no? If not and we really want to be that strict about alignment then conversely we should check for interpolation and throw an error to halt execution

[kaareal]

yeah you are right console and pino (structure logging is not really one 2 one).
The key issue is that in structure logging, there is one object that everything gets merged into. (The mergingObject)
while thats not true for console.

pino supports it. (printf style interpolation)

Pino default syntax

logger.info("hello")
// {"msg":"hello"}
logger.info('%o hello %s', {worldly: 1}, 'world')
// {"msg":"{"worldly":1} hello world"}
logger.info({ foo: "bar" }, "message")
//{"msg": "message", "foo": "bar"}

now for the problem

turns out that we like write it like this
logger.info("foobar", { other: "value" })
the output will be { msg: "foobar" } is dropped because its trying todo a printf interpolation ... so we got some magic to move args around ... but it does not currently include printf styled support.

i am all for modify the api to fit our need ... but yeah it needs to be complete for the different use cases.