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

Question

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.

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:

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.

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.

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.

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.

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