Debugging old NodeJS applications (v8debug) in Webstorm 2017.3 and later
Hello
Modern NodeJS applications are debugged with Inspect (--inspect --debug-brk or --inspect-brk parameter), but old NodeJS verions (like 0.8) were debugged with v8debug (--debug-brk --expose_debug_as=v8debug). This could be forced in Webstorm 2017.1 by unchecking the debugger.node.use.inspect registry flag, but the flag is gone in 2017.3. Is there any way to force old debugging method in current versions of Webstorm?
I've found similar thread that points to this issue, wchich is marked as 'fixed', but flag is still missing.
Please sign in to leave a comment.
https://youtrack.jetbrains.com/issue/WEB-30007 is not about restoring the registry flag; it adds a possibility to override default parameters by passing either
--debug-brkor--inspect/--inspect-brkexplicitly in Node.js configuration, Node parametersOk, so I'll rephrase the question: is there any way to debug legacy NodeJs applications? I was able to do that in 2017.1, but I can't apply the same method in 2017.3.
Sure it's possible
what problems have you faced? What does your run configuration look like?
All configurations are just plain node executables pointed on a remote server and js file name, without any additional parameters. I've created a test file. When run using node 8.0.0.1, debugging is working like expected - execution stops at the breakpoint:
But when I try to debug the same file using legacy node 0.8, it fails becouse wrong parameter is passed to the node interpreter:
In older Webstorm version (2017.1) it would also fail... until I disable the debugger.node.use.inspect flag. With this flag unchecked, debuger works as expected (notice the parameters):
How can I force Webstorm 2017.3 to use correct debuging method for old node (0.8) just like I did in 2017.1?
Looks similar to https://youtrack.jetbrains.com/issue/WEB-30779 that is fixed in 2018.1
Please see https://youtrack.jetbrains.com/issue/WEB-30779#focus=streamItem-27-2680194-0-0 for a workaround
Thank you - now the parameters are correct. I still have some issues (sh wrapper makes the debugger to work only in 50% of tries), but I'll investigate it on my own (looks like local problem).