WebStorm Debugger for Node Stopping at Non Breakpoints

Question

In WebStorm, I have a Node application and I simply hit debug and on load the debugger stops on a bunch of seemingly random lines in node_modules. I can continue through about 5 files until I get to a router/index.js file that gets stuck on a single line for countless continues.

I have no breakpoints in any of the node_modules files, obviously, and WebStorm does not show a breakpoint. However it stops every time. My solution has been to mute all breakpoints, wait for the app to load, and then unmute. Sometimes, though, I have to re-add my breakpoints if I want the checkbox to check and be able to hit those breakpoints. At this point I have no issues. Any idea why it's getting stuck in node_modules with no breakpoints?

Answer 1

Figured out a workaround. I chose "view breakpoints" and although the points that were consistently stopped at were not listed, I simply removed all breakpoints, and I can now debug without stopping in random node_modules.

Answer 2

Sometimes a file may have hidden chars in it that confuses the parser, and setting a breakpoint in your primary file causes a break at a random line.

to determine if you have hidden chars open vi alongside the webstorm view of same file.

in vi...

:set list
:set number

from the top of the file scroll down looking at the end of each line to see if the $ isn't where you think it should be when moving down the same line in Webstorm editor.

if you find something like...

let j = 'hello' $

in the vi view, but see

let j = 'hello'^

^ being your cursor in webstorm, delete from the cursor one char. It will not move, keep going until the first visible char is deleted, then put it back, move to the next occurrence.

Answer 3

I ran into a similar issue in Webstorm 2017.2.4 while debugging clusters and workers. I have a file named worker.js and a number of breakpoints in it. When I debug through Webstorm, the debugger is pulling up every file it can find named worker.js and breaking on the same line number as marked in the "real" worker.js .

The only workaround right now is to rename the file while debugging it.

Answer 4

I've also encountered this problem and solved it by moving entrypoint code to another file, for example "lib/main.js".

index.js :

module.exports = require('./lib/main');