I have a single process node.js application, which I wish to debug with Intellij IDEA 11 32 bits (node.js is 32 bits too).

So, I place an initial breakpoint and run. The debugger stops at the breakpoint, but then it refuses to do any of the following:

• step into
• go to another breakpoint
• pause execution

When I step into, it seems just to run, without stepping through the code. Once running, it ignores any subsequent breakpoints and does not break when I press the pause button.

This issue drives me crazy. Any ideas on how should I troubleshoot it?

EDIT

More info. After IDEA breaks on the first breakpoint (the only successful time) I try to inspect the variables and am unable to see any. IDEA is stuck on "Collecting data..." The watch window does not work too.

EDIT2

Justed posted an issue to their bug tracking system -

I have a single process node.js application, which I wish to debug with Intellij IDEA 11 32 bits (node.js is 32 bits too).

So, I place an initial breakpoint and run. The debugger stops at the breakpoint, but then it refuses to do any of the following:

• step into
• go to another breakpoint
• pause execution

When I step into, it seems just to run, without stepping through the code. Once running, it ignores any subsequent breakpoints and does not break when I press the pause button.

This issue drives me crazy. Any ideas on how should I troubleshoot it?

EDIT

More info. After IDEA breaks on the first breakpoint (the only successful time) I try to inspect the variables and am unable to see any. IDEA is stuck on "Collecting data..." The watch window does not work too.

EDIT2

Justed posted an issue to their bug tracking system - http://youtrack.jetbrains./issue/IDEA-112925

• javascript
• node.js
• debugging
• intellij-idea

• Are you using node.js plugin for Intellij IDEA? – vinayr Commented Aug 30, 2013 at 9:47
• 1 Not that it's helpful, but I have the same problem sometimes with WebStorm sometimes, another JetBrains product. You're not alone. :) I've noticed if I clear all breakpoints set (by using the breakpoint dialog), and debug again they sometimes work more reliably. Sometimes. – WiredPrairie Commented Aug 30, 2013 at 10:39
• An interesting feature it that break points only work with certain styles of function definition! So: function someFunction (params) { console.log("say hello");// we can break here } but not here: var someFunction= function (params) { console.log("say hello");// we can NOT break here } – Tony Eastwood Commented Nov 5, 2013 at 16:59
• Another strange feature is that console.log() sometimes works – and sometimes doesn't. Even to the point that having two console.log() statements one after another - and one of them produces output and the other does not! I tried to report this as a jet brain issue but its not letting me on their site. I'm using 12.1.6 IntelliJ – Tony Eastwood Commented Nov 6, 2013 at 14:20
• I have the same issue Tony Eastwood described with the var functionName vs function functionName declaration. I'm using 13.0.2 intellij, node 0.10.26, node plugin 133.434, windows. I can break using his workaround or ;debugger;, but my variables aren't there and stepping once loses the break – David Lee Commented Mar 18, 2014 at 13:53

2 Answers 2

I've been noticing that IntelliJ's node.js debugger kinda sucks. It's death by 1000 cuts. I love IntelliJ to death, its such a nice IDE. But for node, the debugger has a million different scenarios where breakpoints don't work properly, and another million where it doesn't properly give you access to the in-scope variable values, and another million where it doesn't step properly...

I'm gonna hafta try looking for another tool..

UPDATE 2014-01-13: I've been using IntelliJ's debugger for a while now (having found no other good tool). It seems some of the problems with it are problems with node or v8 itself. Most of the problems I was having have either actually been solved by newer versions of IntelliJ, or by using this workaround:

1. create a file called proxyDebug.js

2. put the following content in it:

require('path/to/the/script/you/want/to/debug.js')

3. point your debugger to that file

Apparently the node.js debugging hooks go buggy at the entrypoint script, so by creating this proxy entrypoint that we don't care at all about, there won't be any weird bugs caused by that in the scripts you do care about. The bugs this workaround fixed were missed breakpoints, predefined variables (exports, module, process, etc) being inaccessible by the debugger, and one or two other things I can't remember.

Last WebStorm version I tried (7.0.3) actually takes ages in collecting data but eventually works. If it seems stuck to you, try to leave it for a minute