Closed Wirone closed 2 years ago
Ah, interesting. This doesn't work because it's not really how it's meant to be used I'm afraid.
methodFactory
exists purely as a swappable part to let you change how the 5 built-in log methods work, not as something you can call yourself to add new logging methods. You're right that it doesn't know anything about which level is enabled, but that's intentional, the level enabling/disabling is handled totally separately.
I'm curious about what you're trying to do though, since there might be new things we should add to loglevel, or easier approaches you could use. What's your goal here? Why do you want to add a .log()
method, rather than just using the existing level-based methods?
As someone already said in other issue, log()
method is different than debug()
because the latter is rendered with blue color. I want to simply log black messages and add colors if something noteworthy happened.
Maybe I misunderstood purpose of factory. I thought it can be used as factory for creating new, custom methods binded to specified level. For me, if it does not do it, it should be private and something like setMethodFactory()
should be exposed instead of it, for setting custom factory.
It would be nice if this supported custom log methods like winston
I want to create log.silly('some tmp debug log')
to make it more compatible with winston.
In this case:
Calling
logger.log('Something')
will output data even ifapp.config.debug === true
because insetLevel()
you're callingreplaceLoggingMethods()
which iterates onlylogMethods
and that array is not updated when callingmethodFactory()
. In other words: every method created with factory will always output data to console.For now I use:
But it's not proper solution.