Add A Hook For Logging to the Server about loglevel

[pimterry]

There's a catch with doing this, which is that you can't change loglevel to actively do things when the log handlers are called, as they're not actually methods implemented in loglevel, they're just bound methods of console.log/debug/error/etc, if those are available (or no-ops if they're not). This is required, because if they're methods of their own which call the real log method in turn then they clobber the stacktrace, and you can't easily see where you were actually logging from.

That means this needs to be something that's opt-in only, and doesn't change the methods if you don't add things like this. My plan for that is #30, so you can override the bit that generates the log methods (currently with careful detection and then by binding the console methods if available) with whatever you like.

Does that make sense? Would that work in your use case? Does that sound like something you'd like to help add?

Alternatively: the easy answer for this is that you need to overwrite the console.X methods with something of your own that does whatever you want in that case, and then call log.setLevel(something) to rebind the logging methods used.

[xjamundx]

Hey I'm curious about how wrapping a function around console.log borks the stack traces. Any way you can show me a quick way to understand how that works? My main use case was going to be something like.

window.onerror = loglevel.error;

[pimterry]

If we start with some example logging code:

function fooBar() {
  doThings();
  log.warn("Oh no!");
}

When all the useful console methods are available and working, you can think of loglevel as sort-of basically doing:

loglevel.warn = console.warn
loglevel.error = console.error
...etc

Notably, this is very different from doing:

loglevel.warn = function(msg) { console.warn(msg); }

For quite a few reasons, but primarily here because most of the modern browsers will add a link to the relevant point in the code which called the console.log method in the log output, so you can a) see who's logging what very easily and b) jump straight to the relevant bits of code and work out what's up.

They essentially do this by taking the current stack trace inside the console.warn method, dropping the first row from it (the bit of that stack that's inside the console.warn method) and considering whatever's on the top of it after that to be the thing that called the log method, and thereby linking to it in the console.

Practically, in the above example, this means when you call log.warn you immediately actually call console.warn, without going through any other functions, so the top of the stack is console.warn, then it's fooBar immediately next. The browser then shows this in your nice console output as

⚠️ Oh no! (fooBar.js:27)

(and you can click fooBar.js:27 to go straight to the relevant bit of your code)

Meanwhile, if loglevel did the second thing, where the console.warn call is wrapped in a function, then the stack in console.warn is console.warn, followed by loglevel's anonymous function, followed by fooBar, so the logging output here, for this call and every single other one, is instead something like:

⚠️ Oh no! (loglevel.js:104)

Now you don't know where that came from, and you have to search your whole codebase for the message to work out where it came from. Very annoying.

Phew. Make sense?

[pimterry]

I'm going to close this; if you'd like to help out with adding a way to include this functionality yourself, feel free to implement #30.