Bring your own logger

[MeerBiene]

Is your feature request related to a problem? Please describe.
Not related to a problem just an idea by @Huskydog9988

Describe the solution you'd like
Passing your own logger so you dont get console outputs for people that are using some special logger like bunyan or something. Would required their logger to at least have a loglevel for info, warn and errors.

Describe alternatives you've considered
I thought about overwriting the console.log method globally but that didn't feel right.

Concept

blapi.setLogger(myLogger)

EDIT:
Alternative Conept

blapi.setLogging({
extended: true,
logger: myLogger
})

[maybeanerd]

I like the idea.

We could just have a variable userLogger that might or might not be defined, and depending on that it would either use that logger, or default to the console.
And on setLogger, we could even check for the existence of all those functions we require. (No runtime errors please 😂)

[MeerBiene]

2 idioten ein Gedanke ("2 idiots one thought" for the english fellas)

[MeerBiene]

@T0TProduction can you take a look at the alternative concept and tell me which one you would want to go with? I would then implement it if you want.

[maybeanerd]

@T0TProduction can you take a look at the alternative concept and tell me which one you would want to go with? I would then implement it if you want.

oh, I like it! both parameters would be optional in this case?
If so, go for it! 😁

edit: ist blapi though, not blabi ^^

[maybeanerd]

if we get it done "soonish", I would even include it in v 2.1.0, so I'll wait before releasing that to npm.

[MeerBiene]

Yes indeed, to save others and me some typing I would probably allows these three

setLogging(true) // only extended logging, still normal console output

setLogging({ extended: true }) // only extended logging, still normal console output

setLogging({ logger: myLogger }) // extended logging will not be used but the custom logger

[maybeanerd]

Nice, that would also be backwards compatible

[MeerBiene]

Nice, that would also be backwards compatible

That was my intention, last thing i wanna do is break someones production code

if we get it done "soonish", I would even include it in v 2.1.0, so I'll wait before releasing that to npm.

So is the plan. Wanted to wait for @Huskydog9988 's input maybe he has some ideas we didn't think about yet.