The project setup, is a basic express application, generated with express-generator.
The project, vscode-debugging-node is available at GitHub
Please refer the screencast at Visual studio Code - Debugging node application
The Gruntfile.js in root of the project, manages the dev process. The purpose of the Gruntfile.js is simple, it starts the server and watches for any file changes.
On detecting changes in the desired file(s), it restarts the server (kills the existing process and starts a new one).
The Gruntfile.js uses ./task/server.js to start/restart the server.
The Gruntfile.js is developed in this manner, that later on, it will incorporate cookie management, in order to provide a logged in experience.
While executing the $ grunt start task, if a env variable named NODE_INSPECTOR=* is passed, the server is started in --debug mode.
When the grunt task is executed in --debug mode, along with node-inspector running in parallel, I can use Chrome to debug the complete application.
With reference to Debugging in Visual Studio Code, I tried to achieve the same by updating the .settings/launch.json, with "program": "/usr/local/bin/grunt", "args": ["start"] and "env": {"NODE_INSPECTOR":"*"}.
I could find that debugger is attached only till ./task/server.js but on the whole application. I doubt, it may be due to the spawned server.
Is this possible to debug such situation in visual studio code? If yes, it will be of great help to know the details.
Your doubts are correct, you are configuring Visual Studio Code to attach to the grunt task starting the server, not the server itself.
You have two options to order to debug this:
Execute NODE_INSPECTOR=* grunt start form the terminal.
Once the server has started, attach the the running server to the Debugger, using the same Attach configuration available in launch.json. In the Debugger view choose the Attach from the profile dropdown and start the Debugger (green ► play button).
UPDATE --
Sarbbotam recorded a screencast for successfully attaching to his node.js app, you can find it here Visual studio Code - Attaching a Node App to Debugger
Configure VSCode to run the server directly, for that you won't have the grunt task listening to the changes and restarting the server. In order to do that change the program option to "bin/www"
Related
I am working on a fresh install of Windows 10 Pro (10.0.18362) and trying to get Visual Studio 2019 setup and configured for .NET Core 3.1 Web Development but am running into several issues.
I created a default React.js ASP.NET Core Web Application and ran the project. Things seemed to be working alright, except that after updating JavaScript code the browser updates after a fairly long pause; things seem to be lagging.
After closing Visual Studio 2019 from the default Web App (no updates) there are several processes that seem to hang, and have to be shut down manually:
I have tried installing Visual Studio 2019 with the Node.js provided by the Visual Studio Installer, in addition to installing Node.js V12.4 and V13.6 manually with the same results.
Another problem: If I update the project from JavaScript to TypeScript using npx create-react-app client-app --typescript, Hot Updates stop working entirely. But after updating the JavaScript code and refreshing the browser things seem to update, so it does seem to be recompiling. I have tried debugging in Firefox and Chrome, both with the same results.
I am very hesitant to continue working with this install as I have had several issues when these processes. If these hang unexpectedly and are not shut down they will continue to use the old versions of the code and nothing that is done will update until the processes are shut down, causing complete insanity.
Could there a specific install procedure I need to perform as a workaround? Or am I possibly missing NuGet packages or Add-Ons? Since this is a fresh install of the operating system, are there Windows Features that I need to install? Or other configuration/permission changes that could be causing this?
Prior to this install, only projects created in Visual Studio 2017 seemed to work as expected. But I need to develop this site in .NET Core 3.0 and it looks like only Visual Studio 2019 is supported for that.
Update
After some messing around, it looks like Node is causing the problems. If I manually shut down the Node processes, then Visual Studio will finally shut down—but it leaves other processes like the VSCompiler and Consoles running. This happens even if I run Visual Studio as an administrator.
Should I install node before Visual Studio, or visa versa? Is there possibly some setup that I need to perform with Visual Studio or Node to get things working correctly?
Update 2
After not finding any fix I tried a complete reinstall of Windows, including a disk format, and then only installed Visual Studio and Node.js.
One interesting thing I found when doing this: I originally only installed Visual Studio and selected both the "Web Development" and "NodeJS Development". But when I tried to run a new .NET Core Web Application without any changes, I received an error saying that Node.js was not installed—even though I was able to find a node.exe in the MsBuilds folder under Visual Studio.
I completely uninstalled Visual Studio and all other components, installed Node.js, and then Visual Studio, but the problem still persists. Any time I try to run any kind of JavaScript using the SPA Templates, the Node.js processes don't shut down. If I kill the Node.js process then Visual Studio will finally shutdown, but it leaves the Console Window Host and VBCSCompiler running which have to be shut down manually.
I also tried creating a new .NET Core Web Application, except this time selecting the Angular Template and it works better: The Hot Reload works and it seems to run much faster. But the processes still don't shut down. The only difference is killing the Node.js processes doesn't let Visual Studio shutdown.
Update 3
Also not sure if this helps, but I tried setting the node.exe properties to "Run this program as an Administrator" to see if it happen to be a permission issue. This yielded the same results. I noticed that two windows will pop up, however: First a blank one, then the actual Angular server window.
I'm not sure if it's related, but when I tried to run the Angular Application again it looks like Angular is pointing at another (random) port than is set in the debug settings in the project.
One thing I did notice is that the usual Server Messages are not showing in the Output Window. It used to display the node.js messages such as "the server is running" and other compiler messages, but now it only displays the .NET output.
Update 4
Getting closer, I uninstalled Visual Studio and Node.js, then made sure to clean out any left over Visual Studio and node_modules folders from my AppData and User/Local directories, and then did a disk cleanup. Finally, I reinstalled Visual Studio—making sure to run the installer as Admin—and reinstalled Node.js.
I ran Visual Studio as an admin and created a new Angular App. Now, the Angular app works as expected, HMR works and things seem to run smoothly except that the processes still hang. The major difference is that killing the Microsoft Visual Studio 2019 process kills everything, whereas before it was leaving the VBSCCompiler, Node.js and consoles running.
When creating a React App things load fine. But, again, the HMR doesn't work and also leaves processes running. shutting down the main Visual Studio process seems to clean these up now too.
I'm afraid I don't have a fix but if anyone wants a quick way to kill all the errant node processes and speed things back up they can run:
taskkill /IM "node.exe" /F
I haven't had any issues executing this while VS is running.
In Visual Studio 2019, go to Tools, Options, Debugging, General and towards the bottom there is a checkbox for Automatically close the console when debugging stops. It is unchecked by default on new versions of VS and if you look at your ASP.NET Core project properties you will see that it is a console project. So without the checkbox checked, the console does not automatically close.
The problem is that it is a hidden console so you can't see it to shut it down manually. If you check the box for closing the console automatically, then the consoles and node.js will stop running whenever you stop the debugger. Also in Options, there is a Node.Js Tools area that you may want to look at as well. It has a checkbox for Wait for input when process exits abnormally. If the console is hidden, there is no way for you to do input so that could hold the process open as well.
Another option, if you don't want to change any of the debugging options, is to go to your project properties > Debug and change the Launch settings for the IIS Express profile to Project instead of IIS Express. This will actually make the console / command prompt visible and when you are done debugging you can Ctrl-C to stop the debugger or when you hit stop the console will give you the message to Press any key to close this window . . .
I had the same issue with React SPA, this worked for me:
Tools -> Options -> Debugging -> General -> Enable JavaScript debugging for ASP.NET (Chrome, Edge and IE) (Visual Studio 2017 and 2019) <- unchecked
also the dropdown next to the play button:
Script Debugging -> disabled
There are possibilities to run pre and post build tasks in Visual Studio. I would look for them in project settings.
I use VSCode. So, if you follow the explanation below you'll be able to tackle the problem.
Create a .bat file in your project root folder (for instance kill-node.bat) with the followwing content:
tasklist | find /i "node.exe" && taskkill /im node.exe /F || echo process "node.exe" not running.
Add a pre-build-task executing the .bat file
Add a post-build-task executing the .bat file
Done! Now every single time you start debugging/redebugging your app, the .bat file kills all node-zombie instances. And ditto for your stopping dubug moment.
The VSCode guide:
Perform step 1 of the algorithm above.
Open the file tasks.json in .vscode folder and prepend at top of its tasks the new one:
{
"label": "kill-node",
"command": "kill-node.bat"
},
Now alter the build task code (to activate our kill-node task at the pre-build time):
{
"label": "build",
"dependsOn": "kill-node", // <<< extra string to run kill-node task prior to build task
"command": "dotnet",
//... the rest of build task code
}
Open launch.json file and insert new string:
{
"version": "0.2.0",
"configurations": [
{
"name": ".NET Core Launch (web)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"postDebugTask": "kill-node", // <<< extra string to run kill-node on debug end
//... the rest of launch.json file
}
}
That's it. Now you can no longer care of the node-zombie instances consuming your memory.
This should be fixed in ASP.NET Core 5.0, try upgrading if possible.
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 recently installed NodeJS Tools for Visual Studio which touts support for Node environments in VS. Notably, it has the ability to set debug breakpoints from the IDE.
It's unclear to me if it is possible to set breakpoints when debugging Gulp tasks. The Task Runner has the ability to detect the Gulp task and output console.log statements to a window, but I haven't found a better means of debugging.
I found this post from a while back: How can I debug gulpfile.js when running it with Visual Studio Task Runner Explorer? However, this post doesn't involve NodeJS Tools for VS. So, I'm re-asking the question to take that plugin into consideration.
You can. Right-click the Node project, select Properties, and configure your app as follows (in the image, default is the Gulp task that you want to run).
Alternative method:
In a terminal, and in the directory where the gulpfile is, run node --debug=44331 --debug-brk ../node_modules/gulp/bin/gulp.js default. In my case, default is the task name I want to run/debug.
In Visual Studio, go to Debug | Attach to Process. Select Node.js Remote debugging as Transport, and in the qualifier select localhost:44331. Press enter and you should see the Node process appear in the list. Click Attach.
Voila, the breakpoints are hit.
A couple of things to notice:
If you get something like Unable to attach to process. Error 0x80004005 use a different port. I couldn't get it to work with port 5858.
It may not work the first time you attach to the process (see my previous screenshot how I got ECANCELED?). Try again.
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.
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 :)