Closed adamhamlin closed 1 year ago
There are not any plans to do so. In my opinion, I think the readme is rather clear that this module is not meant for production use cases and adding such support would make it easier to use in unsupported contexts. The rc file support that is currently included is provided for CLI usage where providing options on each invocation is quite cumbersome otherwise. This is a common feature in CLI applications (pino-pretty's primary purpose).
I would say that if loading rc files is desired in programmatic usage, then it is the responsibility of the app.
@jsumners yep, I agree RC files are really generally meant for CLI stuff, and the readme is very clear about being non-production (and that's how we're using it). Tho if it is development-only, that basically means only developers will see it and they tend to be opinionated about formatting/aesthetics; a gitignored rc file is a good way to give them that frictionless, per-user customization.
Because it's development-only, we didn't want to pipe all our app scripts to pino-pretty
--because some are used in production. We could duplicate and have development-only invocations, or make each developer wrap these scripts themselves, but that can be cumbersome, too.
All of this to say, I get it. Tho if the library had error'd when attempting to pass the option --config
for programmatic use (instead of doing nothing), would've at least made things more clear
I do not know why config
is available in https://github.com/pinojs/pino-pretty#options. A PR to remove it from that section would be welcome.
Better late than never. Opened https://github.com/pinojs/pino-pretty/pull/475
Best I can tell, the rc files are only loaded for CLI usage (i.e., going through
bin.js
). Any plans to extend that to programmatic usage?https://github.com/pinojs/pino-pretty/blob/849f0fc907adc3df30e7290b7fc091a055a30e51/bin.js#L23-L32