Where is that console.log?

Did you ever have phantom console.log – or more specifically you’ve no idea where it was happening?

I have. This tiny bit of code will help you identify where the logging is being called from. The nice thing is it works in the browser and in node.

Honourable mention: @garychambers108′s node.js better logging – I’ve been wanting to do something about my rogue consoles and Gary’s article kicked me in to action.

Upgrading log to show where logging is happening

['log', 'warn'].forEach(function(method) {
  var old = console[method];
  console[method] = function() {
    var stack = (new Error()).stack.split(/\n/);
    // Chrome includes a single "Error" line, FF doesn't.
    if (stack[0].indexOf('Error') === 0) {
      stack = stack.slice(1);
    }
    var args = [].slice.apply(arguments).concat([stack[1].trim()]);
    return old.apply(console, args);
  };
});

If you include this as high as possible in your code base, all subsequent console.log (or warn) calls will include the line the call was made from:

Here’s a simplified demo: http://jsbin.com/wataw/2/edit?js,console

All the code is doing is rewriting the log and warn methods and appending the location of the call at the end of the log. Note that I’m not overloading the error method because it comes with it’s own stacktrace.

The location of the call is deduced using new Error, then looking at the stack property (disclaimer: this won’t work in all browsers – I’ve only tested in Firefox, Chrome and Node).

Simple. Now I can hunt down those rogue logs and remove them from the codebase.

9 Responses to “Where is that console.log?”

  1. This is very useful. I’ve had issues in node where some dependency is angry and logging out nonsense, but I couldn’t for the life of my find WHERE or WHICH LIBRARY was causing it! The message was super generic. I debugged for hours before I found myself nested deep within a long node_modules hierarchy where the logging was happening. Turned out the parent lib of the lib throwing a fit just needed to upgrade its dependencies to the latest version and all was well.

    With a little adapting for node (possibly including the __filename), this code would have helped sooooo much.

  2. I think it do not work for all lgs if you are using iframes or web workers.

  3. The whole Error workaround is a very clever hack for “arguments.caller” not working in strict mode. Might even be a bug.

  4. Vladimir Varankin May 23rd, 2014 at 10:36 pm

    In IE (10?) you have to try-catch threw error, to get `stack` property from your error object

  5. I’ve created a gist which includes grouping to reduce the visual noise.

    https://gist.github.com/fdn/85563337ca5cd815ca6e

  6. Chromium console actually shows the file and line from console.log() calls.

    You shall not debug minified files, use the uncompressed version, and production code should not include console.log() calls anyway — if some dependency lib does, you can easy find it with a grep.

  7. Sure, but node.js doesn’t which is my actual issue and use case.

  8. [...] to, Remy Sharp. This entry was posted in JavaScript on May 30, 2014 by [...]

  9. Awesomeeee! I was actually trying to solve this myself, for my little logger https://github.com/gabrielcatalin/tint.js/ , but didn’t quite get it, and I dropped it for a while. Great to see a solution. Thanks Remy Sharp.

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight