Support for Custom Log Hooks or Interceptors #66
Replies: 2 comments
-
|
Thanks a lot for the kind words and for sharing this idea this is a really good suggestion, and your example makes the use case very clear. I definitely agree that adding a hook/interceptor option would make the library more flexible for scenarios like dynamically adjusting log levels or filtering output. Just a heads-up: I’m currently away and won’t be able to look into this in detail until after July 19th. In the meantime, feel free to open a pull request if you’d like to start prototyping, or we can pick this back up when I’m back. Thanks again for taking the time to share your thoughts and for using the library! |
Beta Was this translation helpful? Give feedback.
-
|
This feature would be very useful. The interface could be really simple, like: LoggerAdaptToConsole({
/**
* @param obj The object to be logged, using `JSON.stringify`.
*/
intercept(obj) {
// modify obj as desired, e.g. adjust level.
return obj; // or null to ignore/filter.
}
}); |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi! Thanks for this great package — it's really useful for structured console logging, especially in environments like Docker and CloudWatch.
I’m wondering if it would be possible to support a hook or interceptor option in LoggerAdaptToConsole() so users can modify or redirect logs before they’re written. For example, I’d love to be able to do something like:
This would allow for dynamic handling of log content and levels, which is useful in situations where certain known noisy logs should be downgraded or filtered.
Is this something that could be supported in a future release? Or is there a way to do this already that I might have missed?
Thanks again for the great work!
Beta Was this translation helpful? Give feedback.
All reactions