vscode-eslint: Bug: "Launching server using runtime node failed. Error: spawn node ENOENT"
Type: Bug
At times when starting VS Code the ESLint server is stopped. It happens intermittently and quite seldom. Using the command ESLint: Restart ESLint Server does not help. Here is the output from the OUTPUT panel.
[Info - 11:21:39 AM] ESLint server is starting
[Info - 11:21:40 AM] ESLint server stopped.
[Error - 11:21:40 AM] ESLint client: couldn't create connection to server.
Launching server using runtime node failed. Error: spawn node ENOENT
[Error - 11:21:40 AM] Starting the server failed.
Launching server using runtime node failed. Error: spawn node ENOENT
### Here I executed the command 'ESLint: Restart ESLint Server' from the command palette ###
[Error - 11:23:15 AM] Restarting client failed
Error: Client is not running and can't be stopped. It's current state is: startFailed
at w.shutdown (/home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.2.6/client/out/extension.js:1:107590)
at w.stop (/home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.2.6/client/out/extension.js:1:107171)
at w.stop (/home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.2.6/client/out/extension.js:1:266246)
at w.restart (/home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.2.6/client/out/extension.js:1:266113)
at /home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.2.6/client/out/extension.js:1:376159
at s.h (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:94:107622)
at s.$executeContributedCommand (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:94:108311)
at u.N (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:104:11208)
at u.M (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:104:10926)
at u.H (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:104:10019)
at u.G (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:104:9000)
at /home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:104:7788
at d.invoke (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:145)
at v.deliver (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:2029)
at g.fire (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:1667)
at h.fire (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:72:14314)
at /home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:120:15804
at d.invoke (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:145)
at v.deliver (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:2029)
at g.fire (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:1667)
at h.fire (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:72:14314)
at c.y (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:72:17324)
at /home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:72:15795
at d.invoke (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:145)
at v.deliver (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:2029)
at g.fire (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:1667)
at g.acceptChunk (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:72:12045)
at /home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:72:11332
at d.invoke (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:145)
at v.deliver (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:2029)
at g.fire (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:63:1667)
at g.t (/home/userA/.vscode-server/bin/97dec172d3256f8ca4bfb2143f3f76b503ca0534/out/vs/workbench/api/node/extensionHostProcess.js:72:25895)
Using the terminal, node does exist:
> node --version
v18.12.1
> which node
/home/userA/.local/share/nvm/v18.12.1/bin/node
I have set "eslint.runtime": "node", both in the user and workspace settings.json files.
I have no idea what could be wrong. I have been using the ESLint extension for years, but this started to happen more recently within the past few months.
Extension version: 2.2.6 VS Code version: Code 1.74.3 (97dec172d3256f8ca4bfb2143f3f76b503ca0534, 2023-01-09T16:59:02.252Z) OS version: Windows_NT x64 10.0.19044 Modes: Sandboxed: No Remote OS version: Linux x64 5.4.0-137-generic
System Info
| Item | Value |
|---|---|
| CPUs | 11th Gen Intel® Core™ i5-1145G7 @ 2.60GHz (8 x 2611) |
| GPU Status | 2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off |
| Load (avg) | undefined |
| Memory (System) | 31.69GB (18.23GB free) |
| Process Argv | –crash-reporter-id e332dab4-91ea-49d1-8a1f-d8f6e06fa4e1 |
| Screen Reader | no |
| VM | 0% |
| Item | Value |
|---|---|
| Remote | SSH: vm |
| OS | Linux x64 5.4.0-137-generic |
| CPUs | Intel® Xeon® Gold 6148 CPU @ 2.40GHz (8 x 2394) |
| Memory (System) | 31.33GB (27.66GB free) |
| VM | 18% |
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vscaat:30438848
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
azure-dev_surveyonecf:30548226
pyindex848cf:30577861
nodejswelcome1cf:30587006
2e4cg342:30602488
f6dab269:30613381
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 2
- Comments: 71 (34 by maintainers)
Honestly I think such an API request will not be implemented due to the fact the NodeJS doesn’t provide it. It would a require poll/compare implementation which is never good.
This explains why the restart doesn’t work. The restart fails because the original start fails since it is using the same client object to not loose any internal client state when restarting the server.
What we could do is to use a new client in the restart case if a previous start failed.
I opened https://github.com/microsoft/vscode-eslint/issues/1808
@eldarshamukhamedov there is a setting to control which node version to use
eslint.runtime. This can even point to a script where you can do some magic in case you need to.Every org I’ve ever worked at ran ESLint via CI, build tools, and/or terminal, in addition to devs using it with VS Code, so it is very important to be able to force the VS Code plugin to use the same version of Node as the rest of the application stack. Who knows what version of Node VS Code is going to choose to ship tomorrow 🤷 The built-in version is meant for use with tools/extensions/internal VS Code features that don’t have local app NPM dependencies, and ESLint will almost always have local dependencies.
That said, there is perhaps a bigger VS Code extension issue here: it’s not always easy to force VS Code to use the specific version of Node that version managers install. The bootstrapping process for a Node instance that an extension uses is obscure and I’ve had to wrestle with it many times (e.g. Volta+Prettier/ESLint, Jest test runner, etc.).
@magnusriga I would only use a node version different the one the come with VS Code if you need to (e.g. using a eslint plugin that requires some special node features)
@dbaeumer I am using 2.4.2 right now, but at the time of writing the above post I am not sure. I will continue monitoring and report back.
My comment was to run that command before reproducing the issue, but if it’s intermittent, you can probably ignore that. I’m not sure why it would be intermittent- it doesn’t seem like PATH is going to change.
You can grab the log when you see the issue, but it may or may not help, because if the current session connected to a remote vscode server that had already been started in a previous session then the log won’t show the environment for the earlier session that started the server.
@dbaeumer I just got the issue again. I have set
"eslint.trace.server": "messages"both in the User, Remote SSH and Workspace settings. It seems to give no information about which Node version gets used. Probably because the error indicates it does not even find it.Restarting VS Code does not help.
If I open the terminal I see:
Using the command
ESLint: Restart ESLint Serverdoes not help.Disabling the ESLint plugin, reloading VS Code, and enabling it again (without reloading) does make it work again.
Thanks for investigating further.
I will still keep the issue open
Sure, I just provided my temporary issue as an illustration, because it was fixed by proper nvm setup.
BTW, may be it’s possible to improve error message a bit? “Error: spawn node ENOENT” -> ‘Error: spawn node ENOENT, PATH=xxx, cwd=yyy’, or something like that. Now it’s a black box, and debugging (especially for people not so familiar with OS / shell) is really hard.
The ESLint server is relying on the fact that node is available on the PATH or you provided an absolute path to it. If
zsh-nvmdoes some PATH magic it certainly might be the cause of this issue.@dbaeumer have the same issue recently. May be it related to https://github.com/lukechilds/zsh-nvm (need to investigate a bit), because “eslint.runtime”: “MY_HOME/.nvm/versions/node/v19.8.1/bin/node” (from ‘which node’ in integrated terminal) works fine.
Stack trace with ‘node’:
@thernstig you could enable tracing in the ESLint server using
"eslint.trace.server": "messages". When it happens you could provide me with the ESLint output channel which should have some information about which node version got used.I’m running in macOS, and changing the config via
.vscode/settings.json. I usevoltato manage my Node.js version if that matters, and again, this has been working for years and somehow it broke in the last <2 weeks now.@dbaeumer the use case to use our own runtime is of course that all our ESLint tests run with constructs available in the Node.js version we use? Or am I missing something?