Node.js Debugging

By  on  

Proper logging is of massive utility for web apps, both during development and after deployment.  What can sometimes be difficult is organizing both the code and output of logging, i.e. knowing where each log message is coming from.  I recently found debug, a Node.js utility for organized and optimized debugging.

Creating an instance of debug is simple and you can create multiple loggers per file:

// Create multiple instances of debug
// In theory these would serve two different purposes
var debuggerA = require('debug')('worker:a'),
    debuggerB = require('debug')('worker:b');

// Sample usages of the debugger
function work() {
  debuggerA('doing lots of uninteresting work');
  setTimeout(work, Math.random() * 1000);
}

work();

function workb() {
  debuggerB('doing some work');
  setTimeout(workb, Math.random() * 2000);
}

workb();

Node.js Debug

The namespace given to a debug instance as you must use an environment variable to signal which loggers should go to STDOUT when the script is run:

// Show all debugger messages prefixed "worker:_____"
DEBUG=worker:* node app.js

The environment variable strategy for signaling which instances should output is brilliant as you may want only certain types of messages logged in production vs. development.  Use namespaces wisely!

I was also able to use chalk to color messages as desired:

var chalk = require('chalk');

debuggerA(chalk.red.bold('OMG an awful error!'));

debug is one of those utilities that has a very simple purpose and accomplishes the task well.  Don't skimp when it comes to logging informative messages -- they'll help you during development and could be critical when auditing the app after a security incident!

Recent Features

  • By
    5 Awesome New Mozilla Technologies You’ve Never Heard Of

    My trip to Mozilla Summit 2013 was incredible.  I've spent so much time focusing on my project that I had lost sight of all of the great work Mozillians were putting out.  MozSummit provided the perfect reminder of how brilliant my colleagues are and how much...

  • By
    Create Namespaced Classes with MooTools

    MooTools has always gotten a bit of grief for not inherently using and standardizing namespaced-based JavaScript classes like the Dojo Toolkit does.  Many developers create their classes as globals which is generally frowned up.  I mostly disagree with that stance, but each to their own.  In any event...

Incredible Demos

  • By
    Smooth Scrolling with MooTools Fx.SmoothScroll

    I get quite a few support requests for my previous MooTools SmoothScroll article and the issue usually boils down to the fact that SmoothScroll has become Fx.SmoothScroll. Here's a simple usage of Fx.SmoothScroll. The HTML The only HTML requirement for Fx.SmoothScroll is that all named...

  • By
    Introducing MooTools NextPrev

    One thing I love doing is duplicating OS functionalities. One of the things your OS allows you to do easily is move from one item to another. Most of the time you're simply trying to get to the next or the previous item.

Discussion

  1. Allain

    Thanks for making this known. I’m pretty sure debug logs to STDERR so that piping still works.

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!