I have installed nvm on my windows machine and with nvm, I installed 2 node versions but it's not letting me change the version.
Microsoft Windows [Version 10.0.16299.64]
(c) 2017 Microsoft Corporation. All rights reserved.
C:\Windows\system32>nvm use 12.18.0
exit status 1: 'C:\Users\Sarmad' is not recognized as an internal or external command,
operable program or batch file.
C:\Windows\system32>nvm version
1.1.7
C:\Windows\system32>nvm ls
* 15.8.0 (Currently using 64-bit executable)
12.18.0
C:\Windows\system32>nvm use 12.18.0
exit status 1: 'C:\Users\Ali' is not recognized as an internal or external command,
operable program or batch file.
Ali you are getting this error because you are installing nvm in the default location. And that is your user's directory. Nvm for windows is an attempt to port from the linux and currently does not support spaces in the path.
I spent several hours trying to figure this out and none of these solutions work for me. If you install nvm in c:\tools\ directory, (you might already have one if not just create it) should solve the problem.
UPDATE Jan - 2023
The writer of NVM for Windows has decided to deprecate it and there will be something coming up to replace it. See the announcement:
https://github.com/coreybutler/nvm-windows/wiki/Runtime
From the link:
I intend to deprecate NVM for Windows after Runtime is released. There
are two things slowing work on Runtime. First, client engagements. I
am wrapping up the most time-consuming project this quarter and will
have much more time in early spring 2023. The other thing slowing down
Runtime development is this project. So, I'm freezing feature
development on NVM for Windows.
I had the same issue in a windows environment. I solved it by running the nvm commands in the command line cmd in the root directory C:/ rather than the integrated terminal of vscode.
Run cmd as an administrator
Download the node version you want to use and use it
$ nvm download 12.18.0
$ nvm use 12.18.0
If you see the same error, you should configue the PATH in the Environment Variables like this answer is saying.
Go back to the other directory or in VsCode and try
node -v
and you'll see that you're using 12.18.0
Try to install the nvm directly in C:/ or in other folder without spaces in the PATH.
You'll need to start powershell or Command Prompt as Administrator to use nvm-windows. See here https://github.com/coreybutler/nvm-windows
Spacing in the path is the problem
you can run
nvm root and find the root folder
then copy the contents to another folder without any spaces on the path
after that move the nvm root to that folder by running the command below (with full path)
nvm root [path]
Related
I'm new on Angular, and I'm not able to run ng commands on WSL version 2.
I installed Angular CLI running:
npm install -g #angular/cli
After that I created a new npm project folder and a package.json running:
npm init
But every ng command returns:
/mnt/c/Users/xxxxxx/AppData/Roaming/npm/node_modules/node/bin/node: 1: This: not found`
I installed Node.js on Windows with an executable (so under PowerShell, everything works as expected). Am I wrong with this?
I installed Node.js on Windows with an executable before (so on PowerShell works), am I wrong with this?
Not, necessarily "wrong", but it's likely part of the problem. But you are certainly correct to question it and provide it as a critical detail in your post!
While WSL can launch Windows executables, keep in mind that those Windows executables (npm in this case) typically only understand Windows paths, processes, environment variables, etc.
npm on the Windows version of Node is a bit unusual, thought. It provides a Bash shell script, which is actually what is being called when you run npm under WSL. That shell script was originally designed for Cygwin and Git Bash, but I see that Node recently added checks in it for WSL as well. Before that, even (the Windows version of) npm itself would have issues under WSL.
But regardless of whether they've fixed npm to work under WSL, then you run into the next level of issues since Angular hasn't modified ng to detect when it is running under WSL.
Without having dug into the source code, ng is going to see that it is running under the Windows version of Node and try to use Windows tools and paths. In my test under WSL (using the Windows version of Node/npm), what seems to happen is that ng new project tries to start CMD.exe. Since it is running under the Windows version of Node, it naturally assumes that CMD.exe is available.
And it is, but starting CMD.exe from inside WSL will attempt to start in a UNC path (\\wsl$\<distroname>\path\to\current\project\dir or \\wsl.localhost\...). CMD doesn't support UNC paths, so it defaults to the Windows directory itself, and I get:
EPERM: operation not permitted, mkdir 'C:\Windows\project'
While you are getting a different error, to be sure, it's almost certainly related to this root issue.
To make a long story longer, see my advice in the question, How to organize programming languages and libraries in WSL and Windows 10.
To summarize it, when using development tools, either:
Use the Windows version of the toolchain (editor, commandline, SDK, tools, etc.)
Or use all-Linux versions of the toolchain.
Also, though, be careful with Node specifically. You can install:
The Windows version of Node for when you are using Windows tools
The Linux version of Node for when you are using WSL tools
But when you are running in WSL/Linux, make sure that the Linux version of npm and node appear first in the path, before the Windows version. This is, again, because of the fact that the Windows version provides that shell script. If the Windows version comes before the Linux version in your Linux PATH, then you will continue to have issues since the Windows npm will get called under WSL (as it is now).
I installed the latest (stable) version of Node and now I get the
"'node' is not recognized as an internal or external command, operable program or batch file.
" in my terminal.
I have:
C:\Users\myuser\appdata\roaming\npm;C:\Program Files\nodejs\
in my system environment variables in the PATH value.
I have also restarted my computer.
I'm using Windows 8.1
What else can I do? I don't remember how I got this to work half a year ago with the older version of Node.
Solved it by giving admin rights to my normal user and removing everything node related and then installing latest node again with my now administrator-privileged user account.
I use Visual Studio Code to develop a TypeScript Node application on Windows 10, with WSL enabled.
Thanks to other threads, I'm almost able to run a VSCode task with Bash on Ubuntu on Windows.
But now I try to do the same with a launch configuration. How can I make a launch configuration to use the node executable installed in WSL instead of the one installed on Windows?
If I run this command directly in the integrated terminal, with Bash, it works :
node src/start.js
But when I press "[F5]" and start a launch configuration that runs this same file, I get an error : "Error: %1 is not a valid Win32 application". This is because the oracledb library is used and has been compiled in Bash, not in Windows.
How can I make a launch configuration use Bash to run Node?
UPDATE : I opened an issue about that on VSCode's GitHub page.
Not if sure you still need help.
open bash outside of the vs code.
then run the following command, to install node.
sudo apt install nodejs-legacy
and you should be able to run node with bash in vs code.
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.
Sometime back I've installed nodejs via cygwin which shows me the version 0.4.12 when I do node -v in bash.
Recently I've installed nodejs with the window installer which shows me the version 0.10.20 in window command prompt.
My Problem is I'm using Claymate for GumbyFramework in cygwin and it requires nodejs version above 0.8.0. How can I update the Nodejs in cygwin to the latest version?
Btw I'm using Windows Vista OS.
Pls. help!! Thanks in Advance..
Please know that Cygwin is not a supported platform. There would be a node version which would break things for you. The latest version that compiles natively on Cygwin is 0.4.12. Though the wiki page mentions some people had success building Node.js 0.10 on MinGW+MSYS. Try the following instructions : http://opensourcepack.blogspot.co.uk/2013/06/nodejs-with-posix-path-support.html
Don't mess with compile on Windows. You may want to just replace the old version Node.exe file with the newer Node.exe file on disk. You should be able to find the Cygwin folders within Windows explorer. You can search the entire disk, in windows not cygwin, for the file name node.exe. You should see the node.exe windows is finding, and the one cygwin is finding, under the cygwin folders.
Rename the cygwin node.exe and copy in the newer node.exe. Now, you nay get an issue with npm, in which case you may want to try the same thing with the npm folder.
I know cygwin isnt officially supported, but when you get it installed correctly it works.