问题
Is it possible for VS Code to use node version specified by NVM?
I have 6.9.2 installed locally. Even after switching to another version, from the OS X terminal (not the VS Code terminal), restarting VS Code, VS Code still shows using 6.9.2.
OS X terminal
MacBook-Pro-3:~ mac$ node -v
v7.8.0
VS Code Terminal
MacBook-Pro-3:QB-Invoice-API mac$ node -v
v6.9.2
回答1:
In VS Code, go to your launch.json file and add the runtimeVersion attribute inside configurations, as shown below. (In this example, we are assuming 4.8.7 is already installed using nvm)
{
"version": "<some-version>",
"configurations": [
{
"type": "node",
"runtimeVersion": "4.8.7", // If i need to run node 4.8.7
"request": "launch",
"name": "Launch",
"program": "${workspaceFolder}/sample.js"
}
]}
回答2:
The solution is to set alias default. In the OS terminal run -
nvm alias default 7.8.0
Open vscode, now running node -v returns 7.8.0
It seems vscode takes up this (alias default) value and not the node version that is set by nvm use X.X.X
Update (12/04/2018) - This solution might not work for everyone. Please see below answers for other solutions.
回答3:
add runtimeExecutable to your .vscode/launch.json like this
{
"type": "node",
"request": "launch",
"name": "App",
"program": "${workspaceRoot}/index.js",
"runtimeExecutable": "${env:HOME}/.nvm/versions/node/v6.9.2/bin/node"
}
回答4:
I had the same problem of being unable to keep my node version specified trough nvm in my OS X environment not only with VSCode but also with Atom Editor (using the platformio-ide-terminal package for managing the integrated terminal in it). None of the suggestions in the previous answers worked for me, besides me not using the debugger but using gulp and grunt for specific tasks. Apparently nvm does not get along with the integrated terminals or sub shells at least in these editors because when loading them the environment variable $PATH is modified internally and does the following according to a comment by one of the contributors of this package in this issue reported here NVM fails to load within nested shell #1652:
" @charsleysa I know why nvm is throwing this error. In your subshell, somehow the /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin part of your PATH has been moved from the end of the PATH to the start.
- When nvm is then started, it calls nvm_change_path (my contribution changed it to this from nvm_prepend_path), which modifies the nvm-relevant part of the path in place.
- Nvm then checks the current npm prefix by asking npm what it is. Since /usr/local/bin/npm now has precendence, it reports /usr/local/bin.
- Nvm then checks whether the current prefix as reported by npm is in the directory tree of the current nvm node version (at this stage, the installation directory of the node version your default nvm alias resolves to).
- The prefix is not part of that tree, so it deactivates itself (calling nvm_strip_path in the process, which is why there's no nvm-related path in your subshell's PATH), and bails with the error you're getting. macOS's /etc/profile (or /etc/zprofile) calls /usr/libexec/path_helper, which does the PATH switcheroo.
In the parent shell, the PATH doesn't yet have an nvm dir in it, so by the time nvm runs, it prepends its directory to the path. But in the subshell, PATH has been reconfigured by macOS to put any non-system directories at the end and we have the problem."
I was always getting this message when launching any integrated terminal:
nvm is not compatible with the npm config "prefix" option: currently set to "/usr/local"
Run npm config delete prefix or nvm use --delete-prefix vx.x.x --silent to unset it.
What I did to solve this in my case was the "workaround" part of that same issue reported which is essentially the following:
- Reset the path by adding the following line inside my ~/.bash_profile at the very top before anything else: PATH="/usr/local/bin:$(getconf PATH)"
And after that no more warnings when I launch any integrated terminal on both editors and I can interact with nvm to switch between any node version easily and without problems at all.
Here it is another alternative just in case this one doesn`t help that much.
回答5:
I had the same problem, but the above answers didn't help.
Apparently the default shellArgs for osx are set to bash while I'm using zsh. I solved the problem by setting the shellArgs in my user settings to an empty array:
"terminal.integrated.shellArgs.osx": []
回答6:
A alternative solution I've found is to simply launch code from the shell after you pick your node using nvm.
You need to first open the command pallet and select "install 'code' into path".
And then launch a terminal and select your node via nvm and then launch "code".
回答7:
I am using oh-my-zsh and it too was not using the node version specified by nvm. Tried several suggestions posted here, but the only way I managed to resolve this issue was by adding the following line to the top of ~/.zshrc
PATH="/usr/local/bin:$(getconf PATH)"
回答8:
I tried all the suggested solutions but nothing was working.
/usr/local/bin/node was pointing to somewhere. i made a symlink to a specific nvm node folder and that was solving the issue for me:
ln -s /Users/mad/.nvm/versions/node/v11.1.0/bin/node /usr/local/bin/node
回答9:
I have the same problem and I found that I have node installed by brew and nvm. I uninstalled node installed by brew and the versions on both terminal and visual studio code are the same now.
回答10:
Particularly with the shell I had no problems, but you may:
- check your shell is properly configure or change it (you might be using different shells for vscode or your terminal)
- check your env and if it's not properly set use the terminal.integrated.env.<platform>
I had issues with vscode itself and no solution could help me. So I finished using the following launch script.
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"program": "${workspaceFolder}/server.js",
"runtimeExecutable": "/bin/bash",
"runtimeArgs": ["-c", ". ~/.nvm/nvm.sh;nvm run default \"$@\"", "dummy"]
},
this assumes you have it configure for bash (otherwise change it to your shell) and you want to use the default node version as configured by nvm (you may also change it).
Note: The "dummy" parameter is required so the rest of the parameters are properly parsed.
A longer explanation of "dummy": Shell scripts use positional parameters where the first one will be the script location itself (addressed by $0), when using the -c flag the script is read inplace an there is no $0 being set. vscode will pass some arguments, like the node start script location which will be wrongly interpreted, so "dummy" pushes all parameters one spot. It can be just anything, but it must be there.
回答11:
Did not tried all of the solution, but for me updating nvm simply worked.
Just follow the installation here and make sure that you bash_profile is updated.
回答12:
I had this same issue and I found a strange workaround that may be helpful to someone else in the future.
If I do not set eslint.runtime my system was running node v10.11.0 for eslint server, whereas I wanted it to be running v12.13.0 which I had installed and made default via nvm.
I found that the v10 version of node was installed by brew based on @franziga's answer but my desired version of node was installed by nvm. So, I uninstalled v10.11.0 via brew and closed/reopened VS Code. Strangely, eslint was still reporting that it was started using v10.
I tried running a shell without any changes to my PATH in any startup scripts, and the version of node was still correctly pointed to v12 as expected, but VS code still starts up v10 for eslint.
I'm not sure how to check the path of the executable that is being run by eslint, and if I open an integrated terminal everything works fine with the expected version of node (v12).
Solution (for me):
I found that if I set "eslint.runtime": "node" in settings.json that it will now use whatever version of node was active when I opened vscode using code . on the terminal. Just "node" - no path.
来源：https://stackoverflow.com/questions/44700432/visual-studio-code-to-use-node-version-specified-by-nvm