I see a lot of posts how to debug posts and talks on how debug node application and they mostly points to vs code and other command line tools.
As a fan of IntelliJ and WebStorm IDE, is anything I am missing which can save my day while debugging my Node.js application?
Please see https://blog.jetbrains.com/webstorm/2014/05/guide-to-node-js-development-with-webstorm/ - this post is not new, but still relevant
Jetbrains has a write up of how to debug Node.js applications that is a good starting point:
https://www.jetbrains.com/help/idea/running-and-debugging-node-js.html
The biggest issue that I've run into is that none of the provided solutions automatically restart your application when changes are made. I've worked around this by using their remote debug functionality and attaching to a server running with nodemon. However, I still have to manually restart the remote debug job in IntelliJ as it does not automatically reconnect when the remote debug server restarts.
There is an open YouTrack request to add this functionality, but Jetbrain's recommendation is to instead use their Live Edit functionality.
Live Edit is bundled by default with Webstorm, but has to be installed on IntelliJ Ultimate. I have not tried using Live Edit with a Node.js application, but their documentation says that it should work.
Related
I recently joined the team which uses the node.js for the development. I am new to the whole node.js ride. I have used IntelliJ based IDEs in the past to configure to run and debug different programming languages. However lack of my understanding of node.js or for some other reason I cannot debug node.js application currently I am working on.
Using node v0.10.48, npm 2.15.1
I can run the application using the WebStorm IDE, but when I run the application, following is what I get in the console tab of debug panel. It also returns a > prompt in the console.
/usr/bin/node --debug-brk=44917 --expose_debug_as=v8debug <path_to_startup_js_file?
debugger listening on port 44917
debugger listening on port 44918
It stops for the break points that I put in the beginning of the file, but after starting the server nothing happens. Now I can't open client UI application, which makes calls to this node.js/express REST service. Even though it is up and running, I think.
By the way I know how to debug using node-inspector & browser. But not sure what am I doing wrong with IDE. The run profile works fine, but the same profile is not working for debug.
It turned out that application I was working on was spawning child process, which has to be debugged separately as a remote debugger. Webstorm was nice enough to support debugging both master and child thread at the same time, via two separate debugger.
The current node version used by the project is also relatively old. Which was also the part of the issue with the webstorm. It was verified by the jetbrain support team member.
I am creating a purely server side nodejs app in visual studio and the majority of times I go to debug it, it does not start running my javascript.
I see "Debugger listening on port xxxx" and nothing else.
Opening and closing the project solves it and have had some luck manually ending the VSHub.exe process (maybe coincidental) but I don't want to have to do this everytime I debug.
Anyone seeing this or got any ideas?
This is a known issue with the node js tools extension.
The fix was included in dev build v1.1.Dev-9.17.2015 which is available from here until it is included in an official release.
I had the same problem with the Community version, deleting the project, reinstalling VS2015, then recreating the project seems to have fixed it.
Mysterious.
I'm investigating using NTVS (https://nodejstools.codeplex.com/) with Visual Studio 2013 to debug my Meteor/Node application. I can't figure out how to get debugging to work.
The problem is that when Meteor starts it copies all of my sources to the .local directory and runs them in a new instance of Node.exe. This confuses NTVS because it can't follow on into the child process. And I can't set breakpoints because Visual Studio doesn't know how to deal with the fact that the files I am editing being different than the ones that are running in the .local directory.
What I'd like is some way to run my Meteor based code under Node.exe straight from my sources, without the pre-bundling steps. Is this possible?
I'm fine with not having development niceties like hot-code pushing and package updates on-the-fly. I can manage that in other ways.
'meteor bundle' doesn't do the trick because (a) it takes too long and (b) it still makes the copy that throws off breakpoints.
Hopefully there is a way to use Meteor as an awesome library separate from Meteor as a runtime environment so I can debug it with NTVS.
Thanks,
/Michael Ost
if the functionality of the meteor tools for Visual Studio are not sufficient, why not contribute to the project.
It's a bit old (last commit 18 months ago) and hence probably outdated, but it will give you a head start as to how to make things work.
You can run your app in debug mode using meteor debug and then attach debugger to port number 5858, It should work for all type of node.js debuggers e.g. Visual Studio, Visual code, Webstorm etc because they all have "attach" debugger option next to "debug" option.
Hoping someone can help. I've been through every forum, the online help, every youtube, and every example to find an answer. This either means it's incredibly nuanced or incredibly simple and I'm just missing something that seems to work for everyone.
Nodeclipse/chromedevtools failed to connect to Standalone V8 VM
( Check Help (F1) and Support http://www.nodeclipse.org/#support )
. Info:
connect timed out
I get the above error when I use nodeclipse to debug a node app using the right-click menu on the project. DEBUG AS -> NODE APPLICATION.
When I RUN AS -> NODE APPLICATION, it launches just fine. But when I run with debug-as, I get that error and the debug info looks like.. (or not.. I can't post images... but it terminates the V8 VM entry)
I've installed JDK 8, the most recent NodeJS, the express packages, enide studio from nodeclipse.org, and followed the instructions to build a starter app (new - express project), then attempted to debug that app with debug-as->node application.
I can successfully debug a node instance (my actual project) that I start from the command line, and it lets me step through the virtual project files, etc.. but I was looking for the "all in one" nature where I am debugging the same files I'm editing and can launch/test it all from within eclipse.
Win 7, 64bit
JDK 1.8.0_11 64bit
node 0.10.29 64bit
nodeclipse/enide studio 2014-011-20140228-win64
I've tried it with JDK1.7 as well (64 bit).
Any and all help would be appreciated.
Regards,
Zig
While the issue happened before it is hard to reproduce on other machines.
More stats is needed.
http://www.nodeclipse.org/#support gives links to Online Help (the same as built-in by F1)
in particular
https://github.com/Nodeclipse/nodeclipse-1/blob/master/org.nodeclipse.help/contents/run.md
and https://github.com/Nodeclipse/nodeclipse-1/blob/master/org.nodeclipse.help/contents/debug.md
Have you tried to
to run node --debug-brk app.js first, and then again in Eclipse/Enide Studio ? #107
I've had some luck getting around this error by:
Right clicking in the server and selecting run as -> node application
Navigating in Firefox to the address where my server is listening
Stopping the server in the console
Right clicking in the server and selecting debug as -> node application
I also created a new perspective called "visualstudio" and do no switch perspectives between development and debug (though I doubt perspectives have much to do with the issue)
Using this approach, I get an interesting anamoly where the debugger breaks on line 1 when the server starts, and I then have to click resume. However, after resuming, execution only stops when a request hits a breakpoint.
You have to run the command to debug the node.js file:
node --debug-brk yourfilename.js (this is not working now)
node --inspect-brk yourfilename.js
Can anyone provide a short list of steps on how to connect a Meteor app to the WebStorm debugger please?
WebStorm is the only IDE with native support for debugging Meteor server code - check this video. Even on Windows, debugging is very simple:
WebStorm 9+
Go to Run --> Debug --> Edit configurations... , click the plus sign, click "Meteor". You can add environment variable like ROOT_URL if you need to.
WebStorm older than 9
This answer is kept only for historical purposes. You should upgrade WebStorm.
On older WebStorms, you used to have to create a Node.js debugging configuration.
on the server, export the environment variable NODE_OPTIONS=--debug=47977. For instance,
NODE_OPTIONS=--debug=47977 meteor # Linux/Mac
set NODE_OPTIONS=--debug=47977 & meteor` # Windows
create a WebStorm/PhpStorm Run/Debug configuration using the port above (47977) and the server host. Leave 127.0.0.1 if you're debugging locally.
in WebStorm, Run -> Debug <myapp>, or press Shift+F9. Make sure that you see "Connected to <your host> in the Debug panel
Now you can set breakpoints, have access to local variables etc.
For client debugging, just use the Chrome debugger, or Firebug.
Troubleshooting
Process disconnected unexpectedly - this happens when meteor restarts automatically because of lack of specific support for Meteor. Just Run -> Debug <myapp>, or press Shift+F9 again.
you can't connect to the server - make sure the firewall rules allow incoming connections to whatever port you chose for the Node.js debugger (47977 here).
The other answers are now out of date. Don't add a Node.js debug configuration as described above, or bother with spyjs.
If you're using Webstorm 9.0, it's as simple as going to Run --> Debug --> Edit configurations... , click the plus, click "Meteor".
WebStorm may also ask you to install a browser add-on, but that's just for client-side debugging; just add a breakpoint in the server-side code and you'll see it works out of the box.
JetBrains have updated the video which was linked to in Dan Dascalescu's answer above, and it shows you the process I just described.
For applications using webpack:webpack, using WebStorm's Meteor debug profile did not seem to work.
My setup uses webpack:webpack v1.0.12, Meteor v1.3.0 and WebStorm 2016.1, but is likely to work with later versions (note that a fix for just this issue was released in v1.0.12, so earlier versions are likely not to work with this procedure).
Here is what I did in order to get it working:
Create a webpack.json file at the project root.
It should include the devtool config, which generates source maps that assist in debugging. The rest may be changed according to your specific setup.
{
"root": "src",
"devServer": {
"host": "localhost"
},
"devtool": "source-map"
}
Create a debug setup:
Node.js Remote Debug, port 5858 (the port is configurable).
Run meteor debug
You may specify a port using --debug-port <port number>.
See meteor help debug for the full details.
Connect WebStorm to the debugger
start the debugger
the status message should indicate that it is connected. Scripts should available in the Scripts tab.
the server should be running in the console
Hit your breakpoints and rejoice.
WebStorm 9 will have Meteor support. While WS 9 isn't released yet (as of Oct 7, 2014), there is an early access program for WS 9.
Read the JetBrains WebStorm blog which describes some of the Meteor support features and includes a brief video.
I'm new to Meteor, WebStorm (and JavaScript for that matter) and have been using the WS 9 EAP build 138.2406 for a couple of weeks. I can launch my project from within the IDE, set breakpoints, walk though code, inspect values, jump to definitions, and issue completions. It's quite helpful.
You can try spyjs plugin for Webstorm: http://blog.jetbrains.com/webstorm/2014/04/spy-js-webstorm-secret-service/
There is a bug with old versions of Webstorm to debug server-side of Meteor 1.2.x. The latest version of Webstorm (11.0.3) released on Dec 24th, 2015 fixed it. Release notes can be found here: https://confluence.jetbrains.com/display/WI/WebStorm+143.1559.5+Release+Notes
I am now able to debug without any problem from Webstorm :)