I'm working on Mac and I cannot change node version from terminal window in VS Code
What's interesting, when I open iTerm I have no problems with switching versions. So the problem only seems to appear on VS Code.
Any idea why and how to solve it?
vscode has a shell integration, which you can configure. e.g. placing the following configuration in your vscode settings
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\cmd.exe"
or you can use the shell launcher plugin, which supports launch multiple shell configurations in the terminal.
Related
I am on Windows running Intellij and Git for Windows SDK for a feature rich terminal on Windows (pacman, oh my zsh, etc...)
I looked up previously on which command to use to make it the default Intellij Terminal and SO delivered:
How can I launch git-for-windows SDK's git-bash in Windows Terminal?
I am using the cmd from above's 2nd post:
C:\git-sdk-64\msys2_shell.cmd -defterm -here -no-start -mingw64
Everything works fine except for a stubborn resizing issue :
Every time I resize the Intellij Terminal, the MSYS terminal stops receiving key strokes and I have to reopen a new one:
( can't type after the resize under the echo hello )
Trying to avoid WSL for now as I noticed maven builds through wsl were noticeably slower than directly on powershell or via git terminal.
Workaround
Not exactly a solution but if you run with MinGW32, the resize no longer causes the problem
To be seen if I will suffer from other 32/64 bit incompatibilities
using for now:
C:\git-sdk-64\msys2_shell.cmd -defterm -here -no-start -mingw32
I know there are various questions about the nodejs version used by Visual Studio Code, but none of them helped, and I noticed a very peculiar discrepancy:
If I run terminal inside vscode, I see the new version of node:
But as soon as I launch the debugger (F5), it invokes an old version of node:
I've already checked, and I am not specifying runtimeExecutable or runtimeVersion in my launch.json (and I prefer not to).
In desperation, I tried deleting /opt/node-v8.12.0-* and then F5 resulted in the error: Cannot find runtime 'node' on PATH -- but clearly it can in the terminal!
So how is it possible that vscode finds two different versions of nodejs?
Aha! While I was closing my VSCode window between attempts, I wasn't closing every VSCode window on my system (even on multiple workspaces.)
Presumably VSCode (I'm using 1.40.2 on Linux) detects the location/version of node on initial startup, and it doesn't detect new installations of node unless you shut down all instances of vscode (close all windows, or more severely, killall code.)
That's an hour I'll never get back, hope this helps someone else. :)
I'm trying to figure out how to do my web development on Windows using the relatively new Windows Subsystem for Linux (Bash on Ubuntu on Windows) in conjunction with Visual Studio Code. I've configured the IDE to use the Bash in its integrated terminal, and I've set the project up such that the files are accessible in both the Linux and Windows file system.
The last thing I want to get set up is to get the IDE set up with NodeJS, but not NodeJS for Windows. I want it to use an installation of NodeJS in the Linux Subsystem. Does anyone know if it's possible to point VS Code to the Node installation in the Linux Subsystem?
This was a stumbling block for me too, until I found out that the real problem is that there's a pathing issue with WSL that creates a conflict if you already have NPM installed for Windows. Hopefully you've already figured this out yourself, but for anyone else who hits this, I'm copying in an excerpt from my longer guide on Visual C + WSL that's specific to this problem alone.
Given what you've said, I'll assume you already have node and NPM already installed in WSL's Ubuntu.
Using your favorite CLI editor (such as nano, vim, emacs, cat and sed… etc), open your ~/.profile
nano ~/.profile
Note: do NOT attempt to edit Linux files using Windows tools. (Thanks to #david-c-rankin's comment for the official link with the bold red text explaining this) If you don't want to use a CLI editor for this in the terminal, see the bottom of the answer this is excerpted from for a link on how to get a GUI one running.
Currently, the default bash PATH variable in WSL is
PATH="$HOME/bin:$HOME/.local/bin:$PATH"
Which is injecting the windows path after the first two binary directories. Unfortunately, this doesn't result in /usr/bin being used before the windows installed npm, so add that before the final $PATH:
PATH="$HOME/bin:$HOME/.local/bin:/usr/bin:$PATH"
Save out, and then either reload the terminal or just source the path file
source ~/.profile
VSCode (v1.18) now has better WSL support for Node:
I use nvm to install Node on Ubuntu, although it should work fine if you install it normally.
e.g.
nvm install 9.2.0
nvm alias default 9.2.0
From the VSCode docs
If you want to run Node.js in the Linux subsystem on Windows (WSL), you can use the approach from above as well. However to make this even simpler, we've introduced a useWSL flag to automatically configure everything so that Node.js runs in the Linux subsystem and source is mapped to files in your workspace.
Here is the simplest debug configuration for debugging hello.js in WSL:
{
"type": "node",
"request": "launch",
"name": "Launch in WSL",
"useWSL": true,
"program": "${workspaceFolder}/hello.js"
}
I opened bash outside of the vs code and run the following command, to install node.
sudo apt install nodejs-legacy
and I'm able to run node with bash in vs code.
I had been using Git for Windows 1.9.5 (installed from Git-1.9.5-preview20150319.exe). There was colored output from my nodejs program (gulp) in git-bash terminal. But when I uninstalled 1.9.5 and then installed 2.8.2 (Git-2.8.2-64-bit.exe) all output became monochrome except git-bash prompt line. How to utilize colored output in this newer 2.8.2 version? Or may be there is other suitable 2.x.x version (Visual Studio Code recommends this)
Create a Windows environment variable FORCE_COLOR and set it's value to true or 1.
This solved my issue and all other team-members using Windows who had the same colors problem.
Looks like the reason is in the new default type of terminal: MinTTY (the default terminal of MSYS2). The decision is to utilize a little bit modified (with regard to paths) version of the Git Bash.vbs file from version 1.9.5.
Just like the title.I'm writing an game which is using ncurses.External terminal doesn't work correctly.
I tried to look for the setting in Clion but nothing was found.
Here you can find how to execute a clion C program in an external terminal
the only difference is that you have to replace the executable path of gnome-terminal with your path to xterm.
Another option is remote debugging as it's supported by clion since 2016.1 version.
check out the official jetbrain blog or the official youtube tutorial.