How to debug Node.js? What is the best way to debug Node.js?

I wanted to know, so I explored the following options.

Console

I have to admit, until recently I had been unsatisfied with debuggers for node and had been using the console and it is actually my favorite way to debug, especially with how blazingly fast node servers reboot with livereload compared to .NET or Java ones.  To do it fast, to start with I normally have my logging down to a minimum and usually isolated in the areas I’m currently working on. I tend to insert console.log calls as I’m writing new lines of code and have a terminal open on the side to see if the expected values are coming in. This doesn’t really add any overhead and it doesn’t interfere with your existing build automation tools like Grunt or Gulp which I like to run my projects through for the live reload and the front end automations.  If you run into visibility issues you can always use the 2 parameter option:

console.log(‘===== this is the output of var test: ‘, test);

or for even more visibility you can use  the Node colors module for which reason it is the 9th most depended on module on NPM.

var colors = require('./colors');

console.log('hello'.green); // outputs green text
console.log('i like cake and pies'.underline.red) // outputs red underlined text
console.log('inverse the color'.inverse); // inverses the color
console.log('Rainbows!'.rainbow); // rainbow (ignores spaces)

 

Besides logs you have the option of  using all the rest of the console methods in node:

console.log([data], […])
console.info([data], […])
console.error([data], […])
console.warn([data], […])
console.dir(obj)
console.time(label)
console.timeEnd(label)
console.trace(label)
console.assert(expression, [message])

You are also able to save these logs into files like the errors are being saved here:

node server.js 2> error.log

Node Debugger

There always comes, though, the time when what you’re doing becomes so complex it makes your head spin you need a real debugger with the ability to break so you can take a breath, scratch your head and think a bit.  Node actually ships with such a debugger built in which is quite cool. You can activate it by running a file with a debug option

node debug server.js

and then you use a combination of commands in your code and commands in terminal to break, resume etc. You pause where you want use the debugger command in your js code:

// myscript.js
x = 5;
setTimeout(function () {
  debugger;
  console.log("world");
}, 1000);
console.log("hello");

And then you are able to step through the code in your terminal by using the following commands:

contc – Continue execution
nextn – Step next
steps – Step in
outo – Step out
pause – Pause running code (like pause button in Developer Tools)

Web Storm

This is very cool and more or less gets the job done, but the UI is quite limited. So what about a real, nice debugger like the robust IDE’s have. I watched a youtube video about the abilities of Web Storm to debug Node projects and it looked pretty promising and I know many developers who use JetBrains IDE’s exclusively . I tried it with a brand new project and it worked right away well. However when I tried my existing project it was quite confusing and I only managed to break once and not sure why it stopped working. Furthermore while I was trying to do it my computer was overheating and hyperventilating, something it rarely ever does, the UI of the IDE was quite slow and it reminded me of why I ditched IDE’s after moving from .NET to Node – they’re heavy.

Node Inspector

Finally I read about Strong Loop’s Node Inspector in Node.js In Action. It is an npm module you install globally after which you are able to run your app with the node-debug command:

node-debug server.js

After that you hit in Chrome

http://localhost:8080/debug?port=5858

And after a bit of a delay you see  the awesome, familiar debugger from Dev tools which we all love debugging our client-side JS with. This debugger is my favorite I’ve ever used, it is highly usable yet light on the CPU and RAM. I know it almost sounds too good to be true, but voila:Screen Shot 2014-04-23 at 9.32.21 PM

As you can see here, I’m debugging Express code in Dev Tools, I’m paused on a breakpoint in an Express controller, I have my watch expressions, my call stack and my scope vars available. So Awesome.

A bit of a caveat, unlike with client-side JS code which you debug by right clicking and popping the dev tools in the same tab – to debug node like this, you have to have another tab open where you are hitting your project at its default location as set in the node env config – in my case localhost:3000. At first when I launch this debug mode in terminal it takes a while for the actual node server on 3000 to launch. Then the tab which hits localhost:8080 itself takes a bit to load and finally it ends up paused so you wonder where your server is as nothing opens on 3000. I have to unpause the debugger’s initial break, then wait a second and hit localhost:3000 in another tab and everything starts functioning smoothly from then on. Here is a link to a video of the process, but it’s a bit outdated and it seems to go a lot more smoothly for him, not me, not sure why.

There you have it, these seem to be the best options for debugging Node.js at the moment and my favorite ones are the 1st – console and the last – Node Inspector, depending on the complexity of the issue I’m trying to resolve.

If anyone has any other tools, suggestions and techniques, please do share.

11 thoughts on “How to debug Node.js? What is the best way to debug Node.js?

    • Rob

      April 24, 2014 at 5:38pm

      Yeah, but that requires you to have/use Eclipse, which is lame.

    • Jan

      April 24, 2014 at 11:52pm

      Wow, that website looks like a bad phishing attempt.

  1. Paul T

    April 24, 2014 at 5:14pm

    Node-theseus works pretty well when combined with Brackets.


  2. (…) it ends up paused so you wonder where your server is as nothing opens on 3000. I have to unpause the debugger’s initial break (…)

    You can use –no-debug-brk to change that behaviour.


    Here is a link to a video of the process, but it’s a bit outdated and it seems to go a lot more smoothly for him, not me, not sure why.

    Node Inspector is trying to guess what files are part of the debugged application, so that you can set breakpoints in files that are not loaded yet. (Think of debugging Mocha unit tests.) It looks in two locations: current working directory and the directory of the main script file (process.argv[1]). If you have many files in your project (or run Node Inspector from outside of your project root, e.g. from your HOME), it may take some time to crawl your filesystem.

    You can disable this features with –no-preload option.

    • Martin Genev

      April 29, 2014 at 10:42pm

      thank, I will definitely experiment with this, great product btw :)

  3. Ekaterina Prigara (WebStorm team)

    May 6, 2014 at 9:15am

    However when I tried my existing project it was quite confusing and I only managed to break once and not sure why it stopped working.
    Really sorry to hear that, we’d really like to make it work for you. Are you using WebStorm 8 and Node.js 0.10.x? We’re working on a video with a few tips on Node.js debugging, may be it would be helpful.
    Moreover, if you have time, we’d really appreciate if you submit a report about the problem you faced with the debugging on our issue tracker. Thanks!

  4. Jason

    April 5, 2015 at 9:34am

    I tried this:

    .save myShell.js

    that followed by the error:
    Failed to save:myShell.js

    why i get this error ?

Comments are closed.