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

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:

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

2. Quit VS Code.

3. 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.

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.

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.

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

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"
}

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

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.

source ~/.zshrc &&

it hepls for me thx

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.