Visual Studio 2017 - Node.JS Server Process - Turn off?

node.jsasp.net MvcVisual Studio-2017

node.js Problem Overview


I'm working on a ASP.NET App in Visual Studio 2017 and I'm noticing a Node.JS: Server-side Javascript process running at 1.3GB to 1.8GB of memory. My IIS worker process is the normal size it is in VS 2015.

My app 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 aside from uninstalling VS 2017 and switching back to VS 2015?

enter image description here

Killing the main Process in Task Manager doesn't affect anything in VS, however if I go to the Details tab and kill the 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, SO limited image size to 2MB):

enter image description here

node.js Solutions


Solution 1 - node.js

Tools > Options > Text Editor > JavaScript/TypeScript > Language Service...

Uncheck 'Enable the new JavaScript language service'.

Restart Visual Studio

This appears to prevent the NodeJS process from starting.

Solution 2 - node.js

I raised feedback on this issue:

https://developercommunity.visualstudio.com/content/problem/31406/visual-studio-2017-nodejs-server-process-turn-off.html

I got response back from a MS Team - he directed me to this post:

https://developercommunity.visualstudio.com/content/problem/27033/nodejs-server-side-javascript-process-consuming-to.html?childToView=27629#comment-27629

The node.exe process has the command line: enter image description here

Effectively I was told:

In VS 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 VS 2015.

It answers my question, but brings to light another - why do you need 1.4GB of memory to give me intellisense on JavaScript files ... or is this one of the solutions that has been built into VS so it uses Less Memory so it doesn't hit the 2GB(4GB) limit of 32-bit processes? Questions questions questions.

Solution 3 - node.js

You have to disable TypeScript support on Visual Studio:

Tools > Extensions and Updates > TypeScript for Microsoft Visual Studio > Disable

After that, just restart Visual Studio, and you are good to go.

Solution 4 - node.js

Ryan Ternier's answer pointed me in what I believe is the right direction. Following his link (https://developercommunity.visualstudio.com/content/problem/27033/nodejs-server-side-javascript-process-consuming-to.html?childToView=27629#comment-27629) 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.

Solution 5 - node.js

The dirtiest workaround ever: just rename the ServiceHub.Host.Node.x86.exe to something else. Hasn't bothered me since. When (if) you actually need it, just rename it back.

Same trick works in Adobe Photoshop which also runs Node for some reason I haven't discovered in my usual workflow yet.


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 VS process and kill Node, then resume VS. If you try to launch VS with Node 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 being there somehow.

So it might be okay to just suspend the Node process and let Windows paging swap its memory out from ram onto the hard drive, without renaming the exe so you could start the VS again later without going through the renaming hassle. If you're willing to live with the consequences, that is.

Solution 6 - node.js

Something that can help the projects mitigate the nodejs weight: is to reassign the node version used under Tools > Options > Projects and Solutions > Web Package Management to an installed 64bit version. Studio will still launch its internal Node for a tsserver.js instance, but any typescript in 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 above the directories used as repositories, and specify to skipLibCheck: true, and add node_modules to exclude -- 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 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 auxillary 3rd party projects using node or typescript.

These are not fool-proof, each has to find their exact bottleneck, but I have found these have worked for me and my team more often than not

Solution 7 - node.js

Just noting that the high-memory consumption has been fixed in the May 10, 2017 - Visual Studio 2017 version 15.2 (26430.04) Release.

Release Notes Here: https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes

Specific notes about the fix here: https://developercommunity.visualstudio.com/content/problem/27033/nodejs-server-side-javascript-process-consuming-to.html

Solution 8 - node.js

In my case I did bot wanted to kill node.js process and I did following things to lower the CPU consumption ov Node.Js processes that run under Visual Studio 2019:

  • I removed folder "Program Files (x86)/MicrosoftSDK/TypeScript
  • I run npm rebuild fsevents
  • I turned off in Chrome browser: Settings-System-Continue running background apps ...

It seems to me much better now. But not 100% unfortunatelly.

Hope this helps someone out there too. Good luck guys! :-)

Solution 9 - node.js

To disable Language Services in VS Code, go to extensions, then filter on builtin extensions and disable the TypeScript/Javascript language service.

I finally discovered this after VS code's node service crashed my server about a million times. Annoying that this was so hard to find documentation about.

disable builtin ts/js language service extension

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionRyan TernierView Question on Stackoverflow
Solution 1 - node.jsAndy TawView Answer on Stackoverflow
Solution 2 - node.jsRyan TernierView Answer on Stackoverflow
Solution 3 - node.jsGabrielView Answer on Stackoverflow
Solution 4 - node.jsRalphView Answer on Stackoverflow
Solution 5 - node.jsuser1306322View Answer on Stackoverflow
Solution 6 - node.jsNathan TeagueView Answer on Stackoverflow
Solution 7 - node.jszulumojoView Answer on Stackoverflow
Solution 8 - node.jsHonza P.View Answer on Stackoverflow
Solution 9 - node.jsBen OlayinkaView Answer on Stackoverflow