nicosommi

devops

posts

slides

about

Debugging node

May 02, 2014
4 min read

Para ver este artículo en español click aquí.

When we write scripts on node.js there is always some things flying around our minds.There is a lot of things to think about. Is simple, but you need to know what are you doing because if you don’t you can get into a mess quickly. Javascript. npm. The good, the bad and the uggly.

One of the things that scared me the most in this node-hell at my begining was the debug method. Some of us are used to use frequently different kinds of logging utilities, from the built in console object to cool npm packages like debug, ain2, winston, etc. But what about the old well known debug process? Yes! I’m talking about that one that allow us to watch expressiones in the current context, view the backtrace, and that kind of things.

In my experience I was debugging node when I started to use it, but in a heavy way. Using eclipse. I came from Java so that was familiar for me and the V8 eclipse plugin works great and it’s easy to use. You just start node with –debug flag and connect the plugin to that port. It’s a very good alternative. You can also use Chrome browser the same way. But today I’m working on a lighter environment. Now I use Sublime Text and Gedit. Lose the fear to the console is something that we must do. Many of us learn that from ubuntu, git and such. Lose the fear to the console is actually a key part for a light and easy debug with node.

So easy as the well known debugger on complex IDE but in the console. Some programmers are used to this kind of debugging, but for people that worked mostly with Java, C#, TIBCO and that kind of high level programming languages that is not the common thing and this was my first time debugging through the console for real.

First of all let’s take a look at the need. This came from real environments in which you have to solve a complexs issues all the time. Console logging sometimes does not give us the flexibility we need and in the time we need to know what is happening. Sometimes is just difficult to reproduce just one execution of some case. Many people can discuss about this and some maybe prefer to just trust in his skills… I don’t, I just prefer to not feel that pressure, I just want to know how to debug and detect problems watching the environment and using the tools the language provides for doing that.

Well… now that we know the benefits, let’s go deep on how do you do this. It’s so simple… like everything in js. We just need to put the debugger; sentence in the places that we want, taking care of the asynchrounous nature of most apps on node, of course. Then we just execute the app with the debug argument….

node debug script.js

That simple. That leave us in the debug console. Now is easy, but from command line. Command we are use to execute with F8, F10, and all that, now are commands like ‘n’, ‘s’, ‘c’, or ‘repl’. Yes, n is for next, s if for step into, c is for continue or run. Repl is for entering to a console to eval.

The command list is obviously on the official documentation here http://nodejs.org/api/debugger.html

As I pre-announced some, the most used are:

  • step in: just with s
  • step out: writing o
  • next step: n
  • pause (just writing that)
  • watch(‘variableName’) : this will print the variable value on each step
  • unwatch(‘variableName’) : delete some watch to stop printing it
  • list(4) : prints the context in a 4 line radious of the code, you can provide some other number
  • repl : very important it allows as I said before to eval something in the current context like the browser’s console (we can see but we can’t modify ). Exit with CTRL+C

There is extra “problems” to people who use gulp or grunt (almost everyone) to execute some previous task before running. But if that is your case you can use for example nodemon with the nodeArgs option like this:

nodemon({script: './app.js', nodeArgs: ['debug']})

Another common case: test unit. With debug? Yes. For example if we execute

mocha debug test/example.js

then we also get the debugger.

Combining mocha and grunt/gulp you can do this currently (also with nodemon):

nodemon({script: './node_modules/mocha/bin/_mocha', nodeArgs: ['debug']});

where you put your path to the _mocha (with the underscore, is just a file on the mocha module) file on the script option. And you get your test on debug with your previous tasks configured.

You get a ENOSPC Error?

That’s because of too many files open (either or you have an editor like Sublime or nodemon is including too much files).

You can solve this by increasing the maxuserwatches with this command

sudo sysctl fs.inotify.max_user_watches=20000

The correct number depends on your needs. You can see your current by executing this

more /proc/sys/fs/inotify/max_user_watches

Also remember to execute nodemon with the -i node_modules argument.

So, if you didn’t do this yet, do it, is easy and very useful. Just do a simple for script and try it by yourself. Is going to make your life easier.

Do you have an idea to improve this article? tell me to nicosommi@gmail.com

nico
Copyright by nicosommi 🦀