I'm working on an ASP.NET application in Visual Studio 2017, and I'm noticing a "Node.js: Server-side JavaScript" process running at 1.3 GB to 1.8 GB of memory. My IIS worker process is the normal size it is in Visual Studio 2015.
My application doesn't include any Node.js libraries. I'm not able to figure out how to turn this Node.js: Server-side JavaScript process off. It's eating up too much memory for something I have no use for.
Is there a way to kill this apart from uninstalling Visual Studio 2017 and switching back to Visual Studio 2015?
Killing the main process in Task Manager doesn't affect anything in Visual Studio. However, if I go to the Details tab and kill the individual running processes, it crashes Visual Studio. I took a video of what happened after I killed the process and ran my local web page (sorry for the quality; Stack Overflow limited image size to 2 MB):
In menu Tools → Options → Text Editor → JavaScript/TypeScript → Language Service...:
Uncheck 'Enable the new JavaScript language service'.
Restart Visual Studio
This appears to prevent the Node.js process from starting.
I raised feedback on this issue:
Visual Studio 2017 - Node.js Server Process - Turn off?
I got a response back from the Microsoft team - he directed me to this post:
Node.js server-side JavaScript process consuming too much memory
The node.exe process has the command line:
Effectively I was told:
In Visual Studio 2017, several features are implemented in JavaScript. Node.js is used by Visual Studio to run that JavaScript. Among other things, Node is used to run the code that provides formatting and IntelliSense services when a user is editing TypeScript or JavaScript. This is a change from Visual Studio 2015.
You have to disable TypeScript support in Visual Studio:
Menu Tools → Extensions and Updates → TypeScript for Microsoft Visual Studio → Disable.
After that, just restart Visual Studio, and you are good to go.
Ryan Ternier's answer pointed me in what I believe is the right direction. Following his link led me to Bowden Kelly's answer, right beneath the accepted answer.
Here is Bowden Kelly's answer:
The node process you are seeing is powering the JavaScript language service. You will see this process appear anytime you edit a JS file, TS file, or any file with JS/TS inside (html, cshtml, etc). This process is what powers IntelliSense, code navigation, formatting, and other editing features and it does this by analyzing the entire context of your project. If you have a lot of .js files in your project, this can get large, but more than likely the issue is that you have a lot of library files that are being analyzed. By default, we will scan every .js/.ts file in your project. But you can override this behavior and tune the language service to only focus on your code. To do this create a tsconfig.json in your project root with the following settings:
{
"compilerOptions": {
"allowJs": true,
"noEmit": true
},
"exclude": [
"wwwroot/lib" //ignore everything in the lib folder (bootstrap, jquery, etc)
// add any other folders with library code here
],
"typeAcquisition": {
"enable": true,
"include": [
"bootstrap",
"jquery" //list libraries you are using here
]
}
}
Once I added the folder with all my script libraries into the tsconfig.json file, life was good again.
The dirtiest workaround ever: just rename the ServiceHub.Host.Node.x86.exe to something else. It hasn't bothered me since. When (if) you actually need it, just rename it back.
The same trick works in Adobe Photoshop which also runs Node.js for some reason I haven't discovered in my usual workflow yet.
It turns out...
You can't just rename it and expect things to keep working. Who knew!
Apparently this renaming trick only works if you suspend the Visual Studio process, kill Node.js, and then resume Visual Studio. If you try to launch Visual Studio with the Node.js EXE file renamed, it will crash when opening a project with an "unknown hard error".
Also, while working on an already loaded project, the lazy reference counter above methods and properties won't work because apparently that relies on Node.js being there somehow.
So it might be okay to just suspend the Node.js process and let Windows paging swap its memory out from RAM onto the hard drive, without renaming the EXE file, so you could start Visual Studio again later without going through the renaming hassle. If you're willing to live with the consequences, that is.
Something that can help the projects mitigate the Node.js weight is to reassign the node version used under menu Tools → Options → Projects and Solutions → Web Package Management to an installed 64-bit version. Visual Studio will still launch its internal Node.js process for a tsserver.js instance, but any TypeScript code in the project will default to the supplied version -- and this helped me firsthand.
Also, another time I found the language service to be running down, I discovered using a simple tsconfig.json file above the directories used as repositories, and specify to skipLibCheck: true, and add node_modules to exclude—it tremendously helped along the service, and one file does all folders beneath it, regardless of direct project references. P.S.—if you do want JavaScript intellisense support still, make sure to set the allowJs: true and noEmit: true option.
Lastly, verify in the TypeScript Options under the menu Tools → Options → Text Editor → JavaScript/Typescript → Project that it is not checked to Automatically compile TypeScript files which are not part of a project since that can also tie up resources for auxiliary third-party projects using Node.js or TypeScript.
These are not foolproof. Each has to find their exact bottleneck, but I have found these have worked for me and my team more often than not.
I am just noting that the high-memory consumption has been fixed in the 2017-05-10 version of Visual Studio 2017 (version 15.2, 26430.04) release.
Release notes are at Visual Studio 2017 version 15.9 Release Notes.
Specific notes about the fix are at
Node.js server-side JavaScript process consuming too much memory.
In my case I did not want to kill the Node.js process, and I did the following things to lower the CPU consumption of Node.Js processes that run under Visual Studio 2019:
I removed folder "Program Files (x86)/MicrosoftSDK/TypeScript
I run npm rebuild fsevents
I turned this off in Chrome browser: Settings-System-Continue running background apps ...
It now seems much better to me. But not 100% unfortunately.
To disable Language Services in Visual Studio Code, go to extensions, then filter on built-in extensions and disable the TypeScript/JavaScript language service.
I finally discovered this after Visual Studio Code's Node.js service crashed my server about a million times. It was annoying that this was so hard to find documentation about.
we made one application on Visual Studio 2008 , it about to release. but now we are getting the crash while launching the application . could you please any give a suggestion how do i debug on this particular issue
You can run the Release build in the debugger, too. Turn on debug-info settings in both the compiler and linker tabs (I think that was not the default in vs2008 and there were two distinct places to set) but don't change any optimization options or other setting.
Then launch the program from the debugger. If the resulting EXE shows the crash when run normally but not when started via the debugger, there are more things to make the situations work the same (and that shows clues as to what is wrong, too). So let us know if that still doesn't reproduce.
There could be a lot of reasons for your application's Release is crashing.
Did you link proper Release libraries with your application in Visual Studio project configuration ?
Check your code for some missing Release specific code.
My best guess is you are not linking to proper libraries for the Release version of your application.
Also, one reason could be that your application may be trying to load some file that may not exist. This happens with me sometimes when my Release build of application does not find file that it needs (Eg: OpenGL application trying to load a shader file that is missing); and you don't check for errors.
How do I debug a Node.js server application?
Right now I'm mostly using alert debugging with print statements like this:
sys.puts(sys.inspect(someVariable));
There must be a better way to debug. I know that Google Chrome has a command-line debugger. Is this debugger available for Node.js as well?
node-inspector could save the day! Use it from any browser supporting WebSocket. Breakpoints, profiler, livecoding, etc... It is really awesome.
Install it with:
npm install -g node-inspector
Then run:
node-debug app.js
Debugging
Joyent's Guide
Debugger
Node Inspector
Visual Studio Code
Cloud9
Brackets
Profiling
node --prof ./app.js
node --prof-process ./the-generated-log-file
Heapdumps
node-heapdump with Chrome Developer Tools
Flamegraphs
0x
jam3/devtool then Chrome Developer Tools Flame Charts
Dtrace and StackVis — Only supported on SmartOS
clinicjs
Tracing
Interactive Stack Traces with TraceGL
Logging
Libraries that output debugging information
Caterpillar
Tracer
scribbles
Libraries that enhance stack trace information
Longjohn
Benchmarking
Apache Bench: ab -n 100000 -c 1 http://127.0.0.1:9778/
wrk
Other
Trace
Vantage
Bugger
Google Tracing Framework
Paul Irish's Guide
Legacy
These use to work but are no longer maintained or no longer applicable to modern node versions.
https://github.com/bnoordhuis/node-profiler - replaced by built-in debugging
https://github.com/c4milo/node-webkit-agent - replaced by node inspector
https://nodetime.com/ - defunct
The V8 debugger released as part of the Google Chrome Developer Tools can be used to debug Node.js scripts. A detailed explanation of how this works can be found in the Node.js GitHub wiki.
Node has its own built in GUI debugger as of version 6.3 (using Chrome's DevTools)
Simply pass the inspector flag and you'll be provided with a URL to the inspector:
node --inspect server.js
You can also break on the first line by passing --inspect-brk instead.
Node.js version 0.3.4+ has built-in debugging support.
node debug script.js
Manual: http://nodejs.org/api/debugger.html
Visual Studio Code will be my choice for debugging. No overhead of installing any tools or npm install stuff.
Just set the starting point of your app in package.json and VSCode will automatically create a configuration file inside your solution. It's build on Electron, on which editors like Atom are built.
VS Code gives similar debugging experience as you might have
had in other IDEs like VS, Eclipse, etc.
I personally use JetBrains WebStorm as it's the only JavaScript IDE that I've found which is great for both frontend and backend JavaScript.
It works on multiple OS's and has Node.js debugging built-in (as well as a ton of other stuff](http://www.jetbrains.com/webstorm/features/index.html).
My only 'issues'/wishlist items are were:
It seems to be more resource hungry on Mac than Windows It no longer seems an issue in version 6.
It would be nice if it had Snippet support (like those of Sublime Text 2 - i.e. type 'fun' and tap 'tab' to put in a function. See #WickyNilliams comment below - With Live Templates you also have snippet support.
A lot of great answers here, but I'd like to add my view (based on how my approach evolved)
Debug Logs
Let's face it, we all love a good console.log('Uh oh, if you reached here, you better run.') and sometimes that works great, so if you're reticent to move too far away from it at least add some bling to your logs with Visionmedia's debug.
Interactive Debugging
As handy as console logging can be, to debug professionally you need to roll up your sleeves and get stuck in. Set breakpoints, step through your code, inspect scopes and variables to see what's causing that weird behaviour. As others have mentioned, node-inspector really is the bees-knees. It does everything you can do with the built-in debugger, but using that familiar Chrome DevTools interface.
If, like me, you use Webstorm, then here is a handy guide to debugging from there.
Stack Traces
By default, we can't trace a series of operations across different cycles of the event loop (ticks). To get around this have a look at longjohn (but not in production!).
Memory Leaks
With Node.js we can have a server process expected to stay up for considerable time. What do you do if you think it has sprung some nasty leaks? Use heapdump and Chrome DevTools to compare some snapshots and see what's changing.
For some useful articles, check out
RisingStack - Debugging Node.js Applications
Excellent article by David Mark Clements of nearForm
If you feel like watching a video(s) then
Netflix JS Talks - Debugging Node.js in Production
Interesting video from the tracing working group on tracing and debugging node.js
Really informative 15-minute video on node-inspector
Whatever path you choose, just be sure you understand how you are debugging
It is a painful thing
To look at your own trouble and know
That you yourself and no one else has made it
Sophocles, Ajax
Theseus is a project by Adobe research which lets you debug your Node.js code in their Open Source editor Brackets. It has some interesting features like real-time code coverage, retroactive inspection, asynchronous call tree.
Node.js Tools for Visual Studio 2012 or 2013 includes a debugger. The overview here states "Node.js Tools for Visual Studio includes complete support for debugging node apps.". Being new to Node.js, but having a background in .NET, I've found this add in to be a great way to debug Node.js applications.
Visual Studio Code has really nice Node.js debugging support. It is free, open source and cross-platform and runs on Linux, OS X and Windows.
You can even debug grunt and gulp tasks, should you need to...
I wrote a different approach to debug Node.js code which is stable and is extremely simple. It is available at https://github.com/s-a/iron-node.
An opensource cross-platform visual debugger.
Installation:
npm install iron-node -g;
Debug:
iron-node yourscript.js;
I created a neat little tool called pry.js that can help you out.
Put a simple statement somewhere in your code, run your script normally and node will halt the current thread giving you access to all your variables and functions. View/edit/delete them at will!
var pry = require('pryjs')
class FizzBuzz
run: ->
for i in [1..100]
output = ''
eval(pry.it) // magic
output += "Fizz" if i % 3 is 0
output += "Buzz" if i % 5 is 0
console.log output || i
bar: ->
10
fizz = new FizzBuzz()
fizz.run()
If you are using the Atom IDE, you can install the node-debugger package.
Using Chrome Version 67.0.3396.62(+)
Run node app
node --inspect-brk=0.0.0.0:9229 server.js(server js filename)
Browse your app in chrome e.g. "localhost:port"
Open DevTools.
Click the the node icon beside the responsive device icon.
There will be another DevTools window that will pop out specifically for debugging node app.
There is built-in command line debugger client within Node.js. Cloud 9 IDE have also pretty nice (visual) debugger.
I put together a short Node.js debugging primer on using the node-inspector for those who aren't sure where to get started.
Visual Studio Code will work for us in debugging.
Use Webstorm! It's perfect for debugging Node.js applications. It has a built-in debugger. Check out the docs here: https://www.jetbrains.com/help/webstorm/2016.1/running-and-debugging-node-js.html
If you need a powerful logging library for Node.js, Tracer https://github.com/baryon/tracer is a better choice.
It outputs log messages with a timestamp, file name, method name, line number, path or call stack, support color console, and support database, file, stream transport easily. I am the author.
Assuming you have node-inspector installed on your computer (if not, just type 'npm install -g node-inspector') you just have to run:
node-inspector & node --debug-brk scriptFileName.js
And paste the URI from the command line into a WebKit (Chrome / Safari) browser.
Just for completeness:
The PyCharm 3.0 + Node.js Plugin offers an awesome development + run + debug experience.
Start your node process with --inspect flag.
node --inspect index.js
and then Open chrome://inspect in chrome. Click the "Open dedicated DevTools for Node" link or install this chrome extension for easily opening chrome DevTools.
For more info refer to this link
There is the new open-source Nodeclipse project (as a Eclipse plugin or Enide Studio):
Nodeclipse became #1 in Eclipse Top 10 NEW Plugins for 2013. It uses a modified V8 debugger (from Google Chrome Developer Tools for Java).
Nodeclipse is free open-source software released at the start of every month.
There are many possibilities...
node includes a debugging utility
node-inspector
Code editors / IDEs (see debug instructions for one of the following)
Atom,
VSCode
Webstorm
and more
Debug support is often implemented using the v8 Debugging Protocol or the newer Chrome Debugging Protocol.
IntelliJ works wonderfully for Node.js.
In addition, IntelliJ supports 'Code Assistance' well.
The NetBeans IDE has had Node.js support since version 8.1:
<...>
New Feature Highlights
Node.js Application Development
New Node.js project wizard
New Node.js Express wizard
Enhanced JavaScript Editor
New support for running Node.js applications
New support for debugging Node.js applications.
<...>
Additional references:
NetBeans Wiki / NewAndNoteworthyNB81.
Node.js Express App in NetBeans IDE, Geertjan-Oracle.
Use this commands
DEBUG_LEVEL=all node file.js
DEBUG=* node file.js
node file.js --inspect
ndb is an improved debugging experience for Node.js, enabled by Chrome DevTools
https://github.com/GoogleChromeLabs/ndb
node-debug -p 8888 scriptFileName.js
Are there any reliable debuggers for Haxe out there, in an ActionScript 3 context, and do they support breakpoints, conditional breakpoints, watches, locals and stacks?
FlashDevelop has a pretty good debugger now and it supports haxe AS3.
For haxe it must be enabled per project - see 'Enable Debugger' in the Project's Compiler options.
Correct me if I'm wrong but I believe you can add -D fdb to the hxml build arguments and then in FlashDevelop I think you will be able to use breakpoints and such.
Never tried it myself though as I don't run FlashDevelop on my Mac.
When you run with Flow you just add the --debug flag like this:
haxelib run flow run --debug