pino
pino copied to clipboard
Create Child Logger with Options
Is there any appetite to allow creating child loggers with options?
For example, to allow a child logger to redact specific fields which its parent may not.
I think options would have to be merged with the parent options (child options taking precedence over the parent), otherwise creating a child logger wouldn't make much sense. In cases where option values are sets/arrays (e.g. redact), I think the merge would result in the sum of the two sets/arrays.
Thoughts?
Yeah I think it’s cool but the problem comes with merging. That’s expensive, and child loggers are often created in hot paths. So the api becomes a bit of a footgun, that’s why we didn’t do it in the first place. On top of that there’s probably other options that would require additional initialisation which would cause more drag. Redaction is a good use case I suppose, are there any other specific options that we would want in a child logger? If so we could have child logger options specific to child loggers, and options may only replace. If it’s only redaction we want, then instead of child logger options we simply have child logger redact as a second param
When you say replace, do you mean replace all the options of the parent? Or just the ones that are specified when creating the child logger? I don't think the former makes much sense. The latter would actually work great for my use case, but I have no clue if that's the exception to the rule or not.
The API is pretty clean right now. I'm worried that adding a one-off nth additional param for any of the options is a slippery slope to a mess.
Just a thought, but how would you feel about giving the user some way to opt-in to the expense of merging? Like a mergeOptions property? Fast/dumb replace by default, slower/ergonomic merge if mergeOptions = true. So maybe a function signature like:
logger.child(bindings[,options][,mergeOptions]) => logger
?
the option keys of the parent - but we need a strict subset of options for the child logger that will replace the parent. These need to be only that which makes sense to override and which don’t require additional initialisation (unless the init can be amortised)
No merging options, it’s too expensive
Got it. Subset options replace is probably the best that could be done then (with redact being a member of that subset). Not sure if I'll get a chance in the immediate future to get a PR going, but I'll think about it. Feel free to close this if you don't wanna keep it open for further discussion. Thanks!
Closed by #1059 ?
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.