The last week my pipeline works fine, but yesterday it failed caused of npm not found error. The pipeline was not changed since the last time it works well.
I also tried default docker image and other versions of node images, but all get the same error.
I even tried "which npm" and got "bash: npm: command not found", seems no command is available.
$PATH is an environment variable which the shell uses to find commands, but I accidentally defined it again in repository settings, rename $PATH solved the problem.
Related
Whenever I try to use ionic command in Git Bash, I get a "command not found" error. But when I test this command in Powershell or CMD, it works. It's only in Git Bash where it doesn't work.
This worked fine earlier, but then stopped working after downgrading my node to v13.13.0 and npm to v6.12.1.
This is the complete error:
C:\Users\Administrator\AppData\Roaming\npm/node_modules/node/bin/node: line 1: This: command not found
And what I also realized about this file path is that it used both "\" and "/" symbols instead of sticking to only 1. I made sure to check my environment variable path if it's set correctly, and also restarted my Git Bash but the error still persists.
npm.cmd says "The system cannot find the file specified. (os error 2)" on every command.
For example
>npm -v
Error:
x The system cannot find the file specified. (os error 2)
8.11.0
The command works fine seemingly, but the process return code is nonzero, which causes many npm scripts to fail.
I've installed several node versions (with nvm for windows) on two different laptops (win 10 and win 11), but they all have the same problem. Googling this yields nothing to my surprise.
Another interesting observation is that the bash script called npm (located beside npm.cmd in the installation directory) does not have this problem when running it in git bash. However, some programs and scripts depending on npm will use the npm.cmd regardless of how I call them apparently, so the issue still persists for me.
I've tried running npm config set script-shell bash to workaround this, but it does not seem to work.
I had a custom shell configured in the ComSpec environment variable. Removing this fixed the problem.
I'm trying to init my first NestJS project but met this fail:
-----------------------------------------
$ nest new testproj
⚡ We will scaffold your app in a few seconds..
'node' is not recognized as an internal or external command,
operable program or batch file.
Failed to execute command: node #nestjs/schematics:application --name=testproj --directory=undefined --no-dry-run --no-skip-git --no-strict --package-manager=undefined --language="ts" --collection="#nestjs/schematics"
------------------------------------------
Tryed to reinstall NodeJS, but no luck.
$ node -v
v16.13.1
$ nest -v
8.1.6
$ npm -v
8.3.0
Any help will be appreciated.
tl;dr:
If your PATH somewhere has a file in it and not a folder (can also be in the middle of a path, with some \other\stuff appended like C:\stuff\somefile.txt\stuff), then this can happen due to an error when Git bash is translating PATH before calling cmd.exe, resulting in part of the PATH not being forwarded and making binaries in that part "not found".
Details:
After some investigation via chat, it turned out that the root cause was a bad GRADLE_HOME environment variable.
Yes, Gradle has nothing to do with node.js or nest, but bear with me, this is one of those moments where a TV episode starts with a totally crazy scene and you wonder what the heck happened that led to this, and then you get "6 hours earlier..." 😁
So, Git bash obviously succeeded in finding node, because it ran the nest CLI (which is a node script). But then, somehow, cmd (which is called by node when executing shell commands) did not find node. This normally should not happen.
Tracing the events with Process Monitor revealed that bash (sh.exe) passed a truncated PATH variable to node.exe. It just ended abruptly somewhere in the middle, and C:\Program Files\nodejs (which was towards the end of it) was not passed along.
The reason for this turned out to be an entry in the PATH that looked like this: C:\foobar\file.zip\bin. The transition into bash worked, as the full path (including this bad entry as /c/foobar/file.zip/bin) could be seen in bash's $PATH, and /c/Program Files/nodejs was there too.
But the transition from bash to node.exe failed. In the process of converting the Linux-style paths to Windows-style paths before passing the variable on to node.exe, bash silently failed in the middle of the string and stopped processing it - as soon as this /c/foobar/file.zip/bin entry was encountered. C:\foobar\file.zip did exist, and it turns out Git bash behaves like this when it unexpectedly encounters a "not a directory" error from the OS when querying the path segment ("file not found" is fine) - as a result of attempting to access a "subdirectory" of a file. Removing this entry from the PATH made everything work normally.
The source of this entry was actually %GRADLE_PATH%\bin in the Windows PATH, and the reason this caused the problem was that GRADLE_PATH itself was incorrectly set to a file (C:\foobar\file.zip) instead of a directory.
There are three ways to resolve this:
Remove %GRADLE_PATH%\bin from the PATH.
Fix GRADLE_PATH to point to a directory.
Delete or rename the C:\foobar\file.zip file.
Whenever I try to run any npm related command such as npm -v or npm install , it gives me the error:
From the screenshot, you can see that it is trying to navigate to find the module but the module can not be found at:
C:\Program Files\nodejs\node_modules\npm\bin\node_modules\npm\bin\npm-cli.js
Actually, the location of the npm-cli in my system is:
C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js
In fact, I have set the path in the environment variable like this:
User variables:
System variables:
The solution I got is to run this command every time I want to run any npm related command:
SET PATH=C:\Program Files\Nodejs;%PATH%
But it is not a solution to run this command in the terminal every time I start working on my project in VS Code. I want to permanently set the path in the environment variable.
How can I resolve this?
Same issue, this was first major post I saw, so adding my fix for others who find themselves here. Hope it's helpful:
Restart PC, open VS Code, and delete any terminal instances that are still open, as they will not inherit the new path(s) if they are 'session-restored'.
My root cause was updating Node, which for whatever reason prefaced an environmental variable in $PATH$ with a semi-colon ';'. Worked in external cmd.exe, but didn't work in VS Code integrated terminal until I realized I had to restart the old ones.
This thread was the one that eventually got me there:
VS Code terminal doesn't recognize PATH variables
Before I start, I want to say that I already checked these answers:
Jenkins build step fails on 'npm install <whatever>'
Jenkin's build failing on npm install
Now, I'm dealing with this issue for a while already and thus I tried a bunch of stuff.
Firstly, I installed node + npm via homebrew. A simple $ node -v and $ npm -v echoed the version v0.10.36 for node and v2.3.* for npm, which also means I HAVE THEM IN THE PATH and they work while called in the terminal.
Simply adding node -v; npm -v to the execute shell in Jenkins didn't do it. After a bit of tinkering I copied what $: which node yielded in the terminal to the above mentioned script, which now looked like this: /usr/local/bin/node and apparently that worked. The Jenkins build succeeded and 'node-v0.10.36' was proudly displayed in the console output.
When doing the same for 'npm' which happened to be /usr/local/bin/npm --version the computing gods weren't so merciful anymore. A big 'env: node: No such file or directory' error was thrown this time and the whole build failed.
The actual command that fails is
$ /bin/sh -xe /var/folders/wr/g_dl81tn5_x0t_yz3jw602cr0000gn/T/hudson8770480548136671253.sh and "surprisingly" when I run the same command in the terminal it succeeds.
I also uninstalled the homebrew node & npm versions and installed them afterwards via the package manager. Same results.
Ultimately I also did this: https://gist.github.com/DanHerbert/9520689, with no luck.
Notes:
I'm running Jenkins 1.613 and tried with 1.5**
I didn't create a "Jenkins" specific user but instead I'm using the admin. This happens to be the same user that Jenkins runs, since the who am i command inside the executable script yields the admin's user name.
sudo'ing doens't help
I'm also running the whole thing in a Virtual Environment - vagrant
I'm not running Jenkins as a deamon, as it's conflicting with xtools, but as a simple process
I also tried out jenkins-node plugin with various configs (can detail if needed)
Thanks a lot for your help, and let me know if you need any other info, screenshots, logs, etc.
I found my own solution. The problem was that the PATH although visible in shell was not exported for the Jenkins job, and so, the first workaround, as found here, was to export it in the actual script like so:
but this feels like a hack!
The right and elegant solution is to use Jenkins EnvInject Plugin and export the path in the added Properties content textarea on the configuration page, like so:
Manage Jenkins -> Configure System -> Global properties -> Environment variables