I am using a Windows machine as my primary development machine. I usually use WSL for most of my projects, but one of my electron projects requires me to work in the Windows environment. So I've set up node, npm, yarn & git on the Windows side as well. But I am having troubles with locally installed dependencies.
Say, I have added concurrently to my project using yarn add concurrently. Now if I do yarn run concurrently, it fails saying that 'C:\Users\Praneet\Projects\my-project\node_modules\.bin\concurrently' is not recognized as an internal or external command. But if I do yarn run concurrently.cmd, it works. Same thing happens for scripts in package.json. I have to change react-scripts start to react-scripts.cmd start to make it work. But I don't want to do this for every script, because there are other devs working with me who use MacOS. I will be really grateful if someone could help me with this.
Have you tried running these commands using Windows Powershell? It might work.
Another option (the one I use when I must code in a Windows environment) is to use Git Bash: https://gitforwindows.org/
It simulates a BASH for Windows, so the commands you are trying to run should work without the .cmd.
Related
TL;DR
I cannot execute commands such as tsc unless I include npx before it (e.g npx tsc). How can I fix this?
The title is a bad explanation of the problem I have.
Say I have installed an npm package with a CLI with it (typescript in this example). And the CLI is used like
tsc <filename> or just tsc. But whenever I try to do it like that, I get an error like
'tsc' is not recognized as an internal or external command,
operable program or batch file.
But... when I do
npx tsc
then it works!
So whats the problem?
The problem with doing npx tsc is because
npx is slow at executing commands
its annoying having to type npx and the front of every command.
And the thing is, this was originally not a problem with WSL.
Why dont you just use WSL?
I have always had problems with WSL (primarily permission issues due to security reasons) and so I uninstalled WSL and just used command prompt. I would have perferred using WSL but it was simply not an option.
Other Info:
I am using Windows command prompt.
I have installed the packages globally
So is there a way to just execute commands that way or is it Command prompts fault?
! this only works for Windows !
Ok, so I came across this post and thankfully, the first answer there was the solution!
Just add %USERPROFILE%\AppData\Roaming\npm to the path variable in system variables!
To access the system variables, press the Windows key, type Environment variables and click on Environment variables at the bottom of the window. The path variable can be found under User variables for (profile name).
Trying to run the command npm run build on my system but keep getting this
error. Tried uninstalling node but no luck. Any pointers would be helpful
The issue for me was that I am using nvm, and for reasons I don't yet know, when I try to set my node version to 12.14.0, and then run nvm list, no versions are selected. I went back to 13.8.0 and nvm list showed that 13.8.0 was selected.
Long story short, make sure you have a selected node version.
you should follow one of two option:
Option 1 – Setup by running the .msi installation file
Its a typical Windows installation and automated.
No need to add entries in environment varaiable
Option 2 – Setup by extracting .zip file
This method does not require admin access and can be used to install on nodejs on a system on which you dont have admin access such as you official laptop or desktop.
Removing nodejs is as simple as deleting the folder.
You will have to add entries in environment variable if you want to execute node command from any location in windows command prompt.
See the link below for more details : install Node.js and NPM on Windows 10
I have Node.js + NPM installed; I can run node -v in my console and get back the current version.
I have also tried using NVM Windows as a Node.js version manager and can run both node -v and npm -v there as well.
HOWEVER, when trying to use another framework like Gulp or Ionic or whatever, I keep getting the error:
'node' is not recognized as an internal or external command,
operable program or batch file.
node is obviously a cmdlet as I can run node -v.. but somehow my other frameworks are no longer able to find it.
Path is correct and everything looks good.
What am I missing here?
The program ConEmu for windows terminal management wasn't pulling or allowing programs to access the paths through subcalls or something it seems. I tested with CMD and Powershell respectively and both worked as expected.
I couldn't get ConEmu to seemingly pass these path to subroutines.. so I uninstalled it and found an alternative called Cmder that is built on ConEmu and it was able to pick them up just fine.
I don't know specifically if it was just a setting in ConEmu I couldn't find or if I needed to manually add these--but happy knowing Cmder just does it automatically.
First of all, I think this is more of a Linux issue as the problem seems to be on a linux-flavoured Docker container, but I'm happy to accept that I can do something to the team city config to overcome this.
I'm also not very experienced with Linux, Docker or node/npm, though I do have a lot of development experience and am very comfortable with command line interfaces in general.
Background
We currently have Team City set up as a build server, for building a variety of projects:
.Net Framework,
.Net Core
Angular CLI
A couple of simple websites which use node packages to generate HTML from Markdown.
The server is running as a Docker container using Docker for Windows on a Windows Server box, and this is working well.
We have one Windows 10 Build agent (a VM) which is also working fine, and builds all the .Net and .Net Core stuff fine.
The simple docs site stuff primarily uses the markdown-to-html node package, so its build steps simply get all the source .md files and compile to html with markdown-to-html, plus use some other npm packages for SASS compilation and minification of js etc. No actual node code as such, just some jQuery. In order to not tie up the other agent, and because this stuff can run happily on Linux, I want to have this running on a small docker image rather than a full VM build agent somewhere.
I previously successfully used a node.js team city agent docker image (either jacobpeddk/teamcity-agent-nodejs or omez/teamcity-agent-nodejs - can't recall) which did work for a time, though I had issues with being able to install some npm packages globally in build scripts, which meant I had to get a bash terminal into the container and run some manual npm commands. I also I think had to run apt-get install zip to get a zipping step to work. This worked fine for a while (weeks).
I added some extra JS stuff to one of these simple projects, and suddenly I was getting errors when trying to build. I (perhaps stupidly) decided that this was probably due to the container having older versions of node and/or npm etc, so I attempted to update this by getting a bash shell into the container, installing nvm and updating node.js & npm.
This ended up with a rather broken container (node errors), so I thought I'd instead start again, but actually start with the jetbrains/minimal-build-agent Docker image instead, with the aim of ending up with a nice bespoke image for our needs specifically (as I couldn't find a very up-to-date pre-existing one)
I've running a Bash shell directly on the build agent container by executing this on the host:
docker exec -it basicagent /bin/bash
then from there I've installed nvm, Python (required for node install step) and node:
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh | bash
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
apt-get update
apt-get install python 3.6
nvm install v8.11.1 (matching version on my dev machine)
npm install -g markdown-folder-to-html (npm package I previously found I had to install globally)
apt-get install zip (just used for a build step to zip up artifacts)
If I now run (via the bash shell) npm -version I get back 5.6.
If I try to get a build to run that uses npm in a command line step, then I get this error in the build log:
/opt/buildagent/temp/agentTmp/custom_script2764770419520852926: npm: not found
I wondered if it was an issue with the user/path that the team city agent process is using vs. the one I'm using in Bash, so I added the following to the build script:
echo PATH = $PATH
echo user var = $USER
echo user via 'id':
id -u -n
the output of which is:
PATH = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
user var =
user via id:
root
So it's running the agent as root, and doesn't appear to have node in the $PATH at all.
If I run the above directly from Bash however, I can see that I am root, but my $PATH is different:
PATH = /root/.nvm/versions/node/v8.11.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root
So I'm now confused: I've re-started the container and this has had no effect - it seems that when I'm logged in as root manually I have a certain path set, but when the build agent service is running as root it's different.
I have no idea why this happens, but I've basically worked around the problem by adding:
export PATH=$PATH:/root/.nvm/versions/node/v8.11.1/bin
to the top of every build step that uses npm in a script. To my mind this seems a rather daft thing to have to do - considering this used to work without this, and the only real difference is possibly a slightly different flavour of linux container. AFAIK the original build agent container was based on the jetbrains minimal-build-agent one, so unless they've changed what they base that on it should be roughly the same...
I also had to change the compressor being used in a node-minify build step from gcc (google closure compiler) to babel-minify as the former was basically hanging indefinitely, but that is a separate problem (though also something that was fine and now isn't...)
Thanks to anyone who took the time to read... though I do wonder if one-day I'll exhaust my own research options, and finally go ask the internet and actually get someone respond - for some reason whenever I get to the point where I have to ask, it always seems no-one else has the answer either and I end up having to work it out myself. It's probably character-building though I suppose.. (this isn't just SO - I've found this be the case for over 15 years on various forums about various things...)
I'm sure this title is unclear, but perhaps my explanation will help.
I had originally installed nodejs on my Windows7 laptop. I had also done "npm install -g" for some modules, like "karma", which resulted in the "karma" script being available globally. I reference "karma" from at least one build script in my Eclipse workspace on the Windows7 laptop. I'm running Cygwin on Windows7, so the shell script on Windows works fine.
(I note that referencing karma "globally" means that I can call it from anywhere, but it will only do anything useful if my current directory has a "node" or "node_modules" folder.)
I now have a Linux VM running on the laptop, and I can reference the host filesystem. I've installed all the obvious tools on the VM, including Maven and NodeJS. When I run my Maven build that references "karma", it fails because it can't find "karma".
What is the proper thing to do at this point, so I can reference "karma" globally on the VM? I could conceivably just copy the "karma" script that npm put into my "AppData/Roaming/npm/karma" folder on Windows, and put that into my $HOME/bin folder on the VM. This looks like it would work, but if there's an "automatic" way to fix this that is preferred, I'd like to do that instead of relying on manual patching.