would you take a pr basically doing this:
@@ -56,7 +56,7 @@ function pino (opts, stream) {
var stringify = safe ? stringifySafe : JSON.stringify
var formatOpts = safe ? null : {lowres: true}
var name = opts.name
- var level = opts.level || 'info'
+ var level = opts.level || process.env.LOG_LEVEL || 'info'
var serializers = opts.serializers || {}
var end = ',"v":' + LOG_VERSION + '}\n'
var cache = !opts.extreme ? null : {
so i don't have to pass its value into the logger? =)
I'm against it, but seems something a lot of people want.
@davidmarkclements I'm thinking of letting this in. What's your opinion?
Please don't, I don't like debugging magic switches in my code - it adds implicit behavior to functions for arbitrary reasons which make them harder to reason about. To prevent abstraction leakage, env var parsing is best done at the fringes of an application - CLIs or application roots only
I agree with you @yoshuawuyts.
Ok, closing this for now, we might re-evaluate if more people asks for this feature.
Ideally this could easily be implemented with a simple wrapper, something like require('pino/env').
what if we add a piece to the readme "Log level environment variable" which shows
var pino = require('pino')({level: process.env.LOG_LEVEL})
@stephenmathieson do you think that would help at all?
To prevent abstraction leakage, env var parsing is best done at the fringes of an application - CLIs or application roots only
yeah, i agree here for the most part
thanks anyway fellas!
Most helpful comment
Please don't, I don't like debugging magic switches in my code - it adds implicit behavior to functions for arbitrary reasons which make them harder to reason about. To prevent abstraction leakage, env var parsing is best done at the fringes of an application - CLIs or application roots only