Open dave-hart opened 2 years ago
Hi @dave-hart, thanks for reporting and for the detailed reproduction steps! I can definitely see the same behavior. What's strange is that if you have a default version defined (even if it's a different one than the project uses), the process launches using the project-local Node. So the final process is called correctly with Volta locating the appropriate Node version.
My guess as to what's happening: The internals of the VS Code debugger launch command rely on a globally-available Node (called from outside the cwd
of the underlying command), and that is failing to find Node, before it even gets to the point where it can launch the actual program.
I wasn't able to find what's happening with a quick look, but VS Code is a large program so it can be tricky to locate. I do know that better integration with IDEs / Editors is something we still need to work on, though I suspect this is slightly different, since it seems to work great as long as you have any Node selected for default.
Hi @charlespierce, many thanks for the response.
Given your hypothesis, would it be worth raising this issues with VSCode?
I created an issue in the vscode-js-debug repo: https://github.com/microsoft/vscode-js-debug/issues/1375
It will be fixed in the next vscode-js-debug release.
☝️ Fixed in vscode 1.72
I am using a vscode launch config to run a node app, but the app fails to start unless I have a global install or default tool sett of nodejs.
This git repo is a very simple example of the issue https://github.com/dave-hart/voltaTest
I have a monorepo with a sub package where its package.json contains a volta block pointing at the project root package json
subProject:
root:
Launch config:
Steps: ensure there is no global install of nodejs ensure there is no default nodejs set in volta checkout the git repo above open the root folder in vscode navigate to the debug view run the 'Launch Program` debug task
Nothing happens
Running
volta install node
to setup a default version and then running the debug task again results in a terminal opening with the expected console log