node_modules/.bin/jest: line 16: exec: node: not found

[guysenpai]

Environment

1. vscode-jest version: 4.0.3
2. node -v: 14.17.3
3. npm -v or yarn --version: 6.14.13
4. npm ls jest or npm ls react-scripts (if you haven’t ejected): jest@27.0.6
5. your vscode-jest settings if customized:
   • jest.jestCommandLine? node_modules/.bin/jest
   • jest.autoRun? {"watch": true, "onSave": "test-file", "onStartup": ["all-tests"]}
   • anything else that you think might be relevant?
6. Operating system: MacOS Big Sur

Prerequisite

• are you able to run jest test from the command line? yes
• how do you run your tests from the command line? (for example: npm run test or node_modules/.bin/jest) npm test or pnpm test

Steps to Reproduce

After reload VS Code window, vscode-jest don't auto run and stopped

Relevant Debug Info

node_modules/.bin/jest: line 16: exec: node: not found
Jest process "watch-tests" ended unexpectedly
 see troubleshooting: https://github.com/jest-community/vscode-jest/blob/master/README.md#troubleshooting

Expected Behavior

vscode-jest auto run and launch all test

Actual Behavior

vscode-jest stop auto run

---

The fastest (and the most fun) way to resolve the issue is to submit a pull-request yourself. If you are interested, feel free to check out the contribution guide, we look forward to seeing your PR...

[carlos-algms]

I have similar behavior.
the command: ./node_modules/.bin/jest works from the VSCode terminal, but not when set for jest.jestCommandLine.

My Error:

env: node: No such file or directory

Worth mentioning that my Node is installed using NVM

[connectdotz]

this extension spawns a child process with shell, per node.child_process document (https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options):

... Uses '/bin/sh' on Unix, and process.env.ComSpec on Windows.

Chances are it's shell setup-related?

It is on our wish list to pass custom shell... Until it is available, the workaround is probably to make sure the default shell above is setup accordingly...

[obiknows]

same

I have similar behavior.
the command: ./node_modules/.bin/jest works from the VSCode terminal, but not when set for jest.jestCommandLine.

My Error:

env: node: No such file or directory

Worth mentioning that my Node is installed using NVM

Same issue over here but I use Volta

[carlos-algms]

Worth mentioning that for my case, restarting VSCode, which was started automatically after I logged into my machine, fixed the issue.
Probably, when VSCode started, the PATH was not fully populated, but when a terminal is open, it will read all the environment variables, while a child process spawned will use the initially loaded variables.

Try to open the developer tools and check for process.env at the console and double-check if all your variables are there.

[golergka]

@carlos-algms restarting vscode worked for me too, but this problem still happens sometimes even when vscode wasn't opened automatically

[MrStanDu33]

Hey guys, Same problem here, but Node is installed on Debian (WSL2 setup). I think in my case it cannot access node because it try to launch the process on the host system, instead of the context of VSC ... I don't think it's even fixable from the extension source code 🤔

[MrStanDu33]

Hello there !

Some updates regarding my problem :

As I use WSL and NVM, I decided to try to create a symlink from /usr/bin/node that sources /root/.nvm/versions/node/v15.5.1/bin/node (as I use node 12.5.1). and it seems working.

It would mean that the problem isn't from WSL itself (I mean the fact that I use WSL in Windows isn't the problem), I think it's more due to the fact that when Jest invokes a shell to execute its commands, It do not invoke the shell as the user that openned VSCode. So your session's file ~/.bashrc or whatever you are using (bash, zsh ...) is not read, so if you use NVM, the NVM path is not exported.

[BBlackwo]

My Error:

env: node: No such file or directory

Worth mentioning that my Node is installed using NVM

I had the same error due to my path in VS Code not having my NVM node directory in it (thanks @carlos-algms for the suggestion to check the process.env.PATH in the developer tools!).

I fixed it by following these stackoverflow steps to make sure I had the correct path:

2. In VS Code, press ⇧⌘P and type install 'code' command if you haven't done so before.

3. Quit VS Code.

4. Launch VS Code not by clicking the icon in the dock or in Launchpad, but by opening Terminal.app and typing code. Your newly set path will be active in VS Code until you quit it.

[cw0]

I have been running into this issue for several weeks on OSX. So far I have tried creating an entry in ~/.bash_profile which worked for a few days then stopped again. I tried using a symlink in /usr/local/bin which had a similar result. It seems to be a dice roll whether or not my test runner is going to work every time I restart VSCode. If the child process shell is going to remain a problem for NVM users can we get an entry in the troubleshooting section of the docs about it? I wouldn't mind typing something up but so far every solution has only been a temporary fix. Using the above command to run code from the command line seems to be working for now though Ideally I'd like to use my taskbar too.

[ctsstc]

I remember they released the test explorer and this was working great for a week or so, then it stopped working, I thought it was intermittent, maybe my other window with workspaces was causing issues, or a recent change to our package.json. I swore I played around with the setup wizard and got it working but didn't like that crazy command I was using. Maybe my intentions were updated in one window and not another?

Now I cannot seem to get it to work at all and have even tried a vanilla configuration making my package.json scripts just "test": "jest".

The error I get in the output tab is:

not-test onProcessExit: process exit with code=127, signal=undefined
 see troubleshooting: https://github.com/jest-community/vscode-jest/blob/master/README.md#troubleshooting
/bin/sh: npm: command not found
/bin/sh: npm: command not found
Jest process "watch-tests" ended unexpectedly
 see troubleshooting: https://github.com/jest-community/vscode-jest/blob/master/README.md#troubleshooting

Whenever I see node or npm not found it means that my version manager is not bootstrapping properly. I coincidentally just ran through this with setting up Husky yesterday.

I use asdf for my version manager.

When fixing Husky they have a ~/.huskyrc I had to put this into it to bootstrap my version manager:

. /usr/local/opt/asdf/libexec/asdf.sh

I installed asdf via brew so I have to point to the weird directory to initialize asdf

I imagine something similar needs to happen with this extension now as well.

It's still super odd that it was working for a small period of time, and when it did the new test explorer was great. I wish it'd come back D:

[connectdotz]

This issue is somewhat complicated due to there are many possible causes and also many ways they can be fixed. Let me first explain how we spawn the process, which, hopefully, will shed lights on the issues and solutions...

how do we start the jest run process?

It uses node child_process to spawn a jest process with a "non-interactive & non-login" shell, which basically mean it will inherit vscode process env(1) + maybe-shell-initialization(2)

Note, the current implementation uses the default shells specified by the node child_process (however this will be customizable in the upcoming release):

Default: '/bin/sh' on Unix, process.env.ComSpec on Windows.

1. How does vscode initialize the process env?

You can read the first 3 paragraphs in this vscode doc. Basically depends on how you start vscode. It will do different things to try to make sure your environment is initialized with ".bashrc" or equivalent. However, sometimes this process might not succeed and you will end up in an incomplete environment, thus any subsequent jest process will be equally incomplete.

• How do you verify this inherited env? Use the developer console log:
  For example, if you use nvm, your env should have NVM variables already configured:
  vscode-jest-env-log.gif

• how to fix this issue ?
  There are many ways to fix this, for example:

  • starting vscode via CLI from a terminal that already has the correct env initialized
    • at least on mac, it might be sufficient to just open the terminal app and wait for it to be ready (when you see the prompt and are able to type in the terminal window), before launching vscode from either UI or CLI.
  • you can add source command in your "jest.CommandLine" or scripts in package.json, for example source abc.sh && jest
  • restart vscode sometimes can fix the incomplete env as well.

• But why do vscode integrated terminals seem to work just fine?
  The terminal will launch an interactive & login shell, which will initialize the environment explicitly again. (see the initialization rules below)

2. How does an "non-interactive & non-login" shell got initialized?

Each shell might behave differently, you can read up on the following posts about how different types of shell starting types can impact the initialization:

• login/non-login and interactive/non-interactive shells
• Difference between Login Shell and Non-Login Shell?

It varied by shell. For example, by default, no initialization will occur unless you have BASH_ENV for bash or ENV for (Bourne) sh.

Therefore, even the initial env is not complete as described above, the new shell spawned by the extension can still be correct if there is a proper initialization configured. However, if you decide to fix the env issue via this route, please note that adding initialization during each spawned shell might have performance overhead.

More help on the way...

We know it is frustrating... We are working on adding 2 new settings (in v4.2) that could hopefully make it easier to address this issue:

• jest.nodeEnv: users will be able to add env variables directly regardless of how the vscode or node initializes the env
• jest.shell: allow users to pass their preferred shell instead of using the default shell, so you don't have to maintain multiple env.

[ctsstc]

If I try to set my "Setup Jest Command"
To: source ~/.zshrc && npm run test --

It returns:

/Users/coder/.zshrc: line 4: ${XDG_CACHE_HOME:-$HOME/.cache}/p10k-instant-prompt-${(%):-%n}.zsh: bad substitution
/Users/coder/.oh-my-zsh/tools/check_for_upgrade.sh: line 32: syntax error near unexpected token `)'
/Users/coder/.oh-my-zsh/tools/check_for_upgrade.sh: line 32: `() {'
/Users/coder/.oh-my-zsh/oh-my-zsh.sh: line 21: autoload: command not found
/Users/coder/.oh-my-zsh/oh-my-zsh.sh: line 39: syntax error near unexpected token `('
/Users/coder/.oh-my-zsh/oh-my-zsh.sh: line 39: `for plugin ($plugins); do'
/Users/coder/.p10k.zsh: line 16: local: can only be used in a function
/Users/coder/.p10k.zsh: line 20: builtin: setopt: not a shell builtin
/Users/coder/.p10k.zsh: line 22: syntax error near unexpected token `)'
/Users/coder/.p10k.zsh: line 22: `() {'
/usr/local/opt/fzf/shell/key-bindings.zsh: line 22: syntax error near unexpected token `)'
/usr/local/opt/fzf/shell/key-bindings.zsh: line 22: `  () {'
/usr/local/opt/zplug/init.zsh: line 4: typeset: -g: invalid option
typeset: usage: typeset [-afFirtx] [-p] name[=value] ...
/usr/local/opt/zplug/init.zsh: line 8: ${${(%):-%N}:A:h}: bad substitution
/usr/local/opt/zplug/init.zsh: line 11: /base/init.zsh: No such file or directory
Jest process "watch-tests" ended unexpectedly
 see troubleshooting: https://github.com/jest-community/vscode-jest/blob/master/README.md#troubleshooting

[connectdotz]

Please keep in mind your command will be executed in the default shell (i.e. /bin/sh) today... maybe there is some zsh specific syntax that the /bin/sh does not understand?

[ctsstc]

I think I was noticing if I opened from the command line it may work, or maybe it's opposite -- opening from the command line doesn't work. ie: code . code ~/someDirectory

[kerosan]

source ~/.zshrc &&

it hepls for me thx

[redbluenat]

My Error:

env: node: No such file or directory

Worth mentioning that my Node is installed using NVM

I had the same error due to my path in VS Code not having my NVM node directory in it (thanks @carlos-algms for the suggestion to check the process.env.PATH in the developer tools!).

I fixed it by following these stackoverflow steps to make sure I had the correct path:

2. In VS Code, press ⇧⌘P and type install 'code' command if you haven't done so before.
3. Quit VS Code.
4. Launch VS Code not by clicking the icon in the dock or in Launchpad, but by opening Terminal.app and typing code. Your newly set path will be active in VS Code until you quit it.

Works for me! thanks :)

[gihoekveld]

Meu erro:

env: node: No such file or directory

Vale ressaltar que meu Node é instalado usando NVM

Eu tive o mesmo erro devido ao meu caminho no VS Code não ter meu diretório de nó NVM nele (obrigado@carlos-algmspela sugestão de verificar process.env.PATHnas ferramentas do desenvolvedor!).

Eu consertei seguindo estas etapas de stackoverflow para garantir que eu tivesse o caminho correto:

2. No VS Code, pressione ⇧⌘P e digite o comando install 'code' se ainda não o fez.
3. Saia do VS Code.
4. Inicie o VS Code não clicando no ícone no dock ou no Launchpad, mas abrindo Terminal.app e digitando o código. Seu caminho recém-definido estará ativo no VS Code até você sair dele.

It worked for me. Thanks!

[CMCDragonkai]

I'm a nix-shell user. The nix-shell command initialises a bash environment for interactive and non-interactive usage. Generally you launch a nix-shell to start a terminal environment to then run other tools. This works well for CLI tools since I start a nix-shell and then run a CLI tool or tools.

Now the problem has always been that IDEs have always had their own environment setup. Now in vscode it has integrated terminal which allows me to run nix-shell inside and proceed.

But what about extensions and the commands they run? They aren't aware of the nix-shell environment and they running whatever global environment IDEs are started in.

The most common solution is to just run the IDE within the nix-shell. But this is not always a great solution especially given that I have multiple projects each with their own nix-shell configuration. If I start IDEs in each environment I don't get the UX of flowing between projects easily inside the IDE.

What I'd like to have is the ability to use 1 global vscode session, but the ability to run commands (including extension commands like vscode jest) inside designated "subsessions" which keep the environment live. Ideally this can work across all extensions.

Right now the vscode jest's customisation allows me to inject a nix-shell command prefix so that the jest CLI runs inside a nix-shell. But this adds a performance overhead that could be negated if there was a concept of subsessions tied with some subshell.

[ctsstc]

I believe another issue is if you launch via code in a terminal with the correct environment and then later you restart your system and it tries to relaunch windows it'll launch vscode out of the previous expected context unfortunately.

[radandevist]

The following in settings in the workspace settings i.e. "${workspaceFolder}/.vscode/setting.json, works for me:

{
  "jest.jestCommandLine": "source ~/.zshrc && yarn test",
  "jest.shell": "/usr/bin/zsh"
}

[connectdotz]

for people who landed here, this issue should be fixed in v5 pre-release, feel free to give it a spin and let us know how it works for you. Thanks.

[sneko]

@connectdotz I can confirm without any file modification and just by trtying the pre-release the extension is enabled correctly :) thank you!

(also, had this issue multiple times but if stuck do not hesitate to fully restart vscode... it seems a common issue with the Jest extension on MacOS)

[thasup]

The following in settings in the workspace settings i.e. "${workspaceFolder}/.vscode/setting.json, works for me:

{
  "jest.jestCommandLine": "source ~/.zshrc && yarn test",
  "jest.shell": "/usr/bin/zsh"
}

This one is working for me 🥰

my setting:

"jest.jestCommandLine": "source ~/.zshrc && npm run test --",
"jest.shell": "/bin/zsh"

[80avin]

For those who are facing this issue with mise, all I needed was to add mise x -- before the test command.
My setting:

"jest.jestCommandLine": "mise x -- yarn test"

And for context, I have added following line in my shell profile ( ~/.zprofile equivalent )

eval "$(mise activate zsh --shims)"

[equiman]

I solved my problem on macos, changing this configuration from -i (interactive) to -l (login).

    "terminal.integrated.profiles.osx": {
        "zsh": {
            "path": "zsh",
            "args": ["-l"]
        }
    },

Hope it can help others.