Webstorm Nodejs Debugger just executing but not stopping for the breakpoints

Ok. So, what does this command look like? please provide the command line (as shown in console) plus screenshot of your Attach to Node.js/Chrome configuration. Also, is debugger attached? Do breakpoints work?

Webstorm console image

Attaching to NodeJs config

After debugging again Using `already_running_attach_debugger` config

Here as you can see No debugger is showing.

Therefore Now No debugger nothing works.

What is your Node.js version? You are passing both `--inspect` and `--debug-brk` to it, so you should be using Chrome option for attaching to it. And why do you use 3000 as a port number? it should be a debug port, not the port your server is listening on

Can you please tell me where is port defined ?

Also, I have not set any params `--inspect` and `--debug-brk` they have added automatically, can you tell me what config params should I use and where to change their values?

Also my node version on client is `8.9.1` and on remote server is `6.14.2`

>Can you please tell me where is port defined ?

You can see the port debugger is listening on in console; when starting node manually in terminal, you can specify the debugger port explicitly, like --debug-brk=5858

But note that Node debugger binds to 127.0.0.1 by default, so attaching to remote process is not possible. You have to either provide a public IP address / 0.0.0.0, etc.in a command (like node --inspect=0.0.0.0:5858), or use port forwarding (ssh -L 8080:127.0.0.1:8080 <username>@<host> -N)

When starting node 6.14.2, please use --debug-brk; for 8.9.1, use --inspect-brk

> I have not set any params `--inspect` and `--debug-brk` they have added automatically

You must have chosen remore interpreter in your run configuration...we don't detect version for remote interpreters as it seems expensive, --inspect --debug-brk is always used for remote interpreters

please start your server manually, not via run configuration, and make sure to pass appropriate options to Node.js.When connecting to node 6.14.2 started with --debug-brk, use Node option in .Attach to Node.js/Chrome configuration

Normally the code that can be debugged in VSCode works equally well in WebStorm. If it's not the case, please provide the project we can use to recreate the issue

I am having similar issues.  I have gotten it to stop in the debugger but it is on the wrong line.  How can i refresh the map that the IDE uses?  I am using webpack also, if that complicates matters.

This works fine in the chrome debugger, fwiw

don't understand what you mean by refreshing the maps... The debugger uses the sourcemaps generated by your build tool (webpack?)

hmmm, so if that is true, then how can the line numbers be off?  In other words, I added some code and the breakpoint works but it stops me in a completely different area (where the original code was) and not the new area

in most cases it just means that the sourcemaps are wrong, i.e. the debugger can't map the actual code to original source using them

right, and that is what i was asking originally.  How can i make sure they are refreshed?  I am also using live reload if that complicate things

whay should they be refreshed? Does the issue only occur if you edit your code while debugging?

Elena, here is a case where A) the lines are way off and B) the call stack isn't near as good as the chrome debugger.

I love the fact that it marries the 2 debuggers so i can see in chrome where the issue is.  When i am editing code, i would prefer to just put a breakpoint in WS and go.  It is a little bit of a pain to do this but I also hate having to track down the module and line number within ChromeTools.  

What would be amazing is if there was a feature where i could click a button and it would open that piece of code in ChromeTools.

I am a huge fan of WS, don't get me wrong, but i have to say that the Chrome Debugger is much nice and easier to work with.

so, it's about client-side app debugging, not Node.js one. From screenshot I can see that the compiled runtime version is loaded in IDE instead of the actual source. This indicates that the original source file can't be resolved from sourcemap for some reason. Specifying URL mappings in run configuration might help.

Unfortunately I can't advise on exact mappings, etc. unless I have a project to play with

BTW, what about creating separate threads/support tickets if you like to report an issue? Your problem clearly has nothing in common with the original issue (and other problems described in this forum thread)