node -v: no version installednpm -v: no version installednpm ls react-scripts (if you haven’t ejected): N/A
Operating system: Windows 10 + WSL
Use Windows 10 + Windows subsystem for linux. Install node/npm/jest within the subsystem only, not in windows.
There should be a way to use the version of jest installed within WSL rather than duplicating the installation of all the tools required, once within linux and once in windows
'jest' is not recognized as an internal or external command, operable program or batch file.
(Quite rightly, as there's absolutely no node/jest/npm installed outside WSL)
I've tried to look through docs and other open bugs but cannot find anything similar, apologies if I've missed it!
Note that I'm not sure if there are any guidelines for extension authors around using WSL, but it's e.g. possible to debug files using node installed within WSL, so assuming it's doable for extensions as well.
Is your whole project residing within WSL or did you just run npm install within WSL?
Is your whole project residing within WSL
Sorry, not sure what you mean - I ran yarn create react-app within WSL, but both windows and WSL effectively have access to the whole filesystem - does that answer your question?
The problem here is that windows doesn't have any of the binaries that the extensions uses, and I'd like to use the binaries installed inside WSL instead
That answers my question. You could set "jest.pathToJest": "node node_modules/jest/bin/jest.js" in VS Code's settings, which should work with your setup (since jest.cmd basically just runs that command).
That doesn't work, and I would've been surprised if it did, because the command still runs within the windows context, which does not have node. Only WSL has it installed.
This is the error that I'm getting, which is interesting:
'npm' is not recognized as an internal or external command,
operable program or batch file.
Note how it refers to npm. Where does that come from?
That made me try calling something that doesn't exist, e.g. "jest.pathToJest": "foobar".
Same error, referring to npm. In fact, absolutely everything I try as a value for "jest.pathToJest" results in the same error, which makes me think it might not be working correctly in windows?
I _believe_ I've found the correct command that should be used by the extension: wsl jest. It does not seem to be executed when I change that property, however.
Thoughts?
If you want to get yours hands dirty it's simple to debug the extension and see if wsl jest will work. From CONTRIBUTING.md:
git clone https://github.com/jest-community/vscode-jest
cd vscode-jest
yarn install
code .
When you get vscode-jest open in VS Code, run the Debug: Select and Start Debugging command and start the Launch Extension configuration. That'll open up a new workspace where you can load your own project. Jump back into the extension and set set a breakpoint at this.runner.start(...) and step in to the point where it's going to spawn the command and change the values to try your hand at the wsl prefix.
Alternatively, I'd suggest creating a minimal JS file from Windows that spawns a process that can access the WSL. They're likely going to be the same amount of work.
Since the whole node_modules folder is already present, what speaks against installing just Node? I think that would be the only tool needed.
vscode-jest 2.9.0 has shipped, which could help addressing this issue. Please give it a try and let us know if it works for you.

@connectdotz please see the screenshots above - it still doesn't work, with the same error.
What I find bizarre is that the following user setting _should_ work, as I explained with a little more info above
{
"jest.pathToJest": "wsl jest"
}
But instead, it says
'wsl' is not recognized as an internal or external command,
operable program or batch file.
The same wsl jest used with cmd.exe within the integrated vs code terminal works (ignore the fact that tests themselves fail)

Which means that whatever context this extension is running with, it's missing something, possibly the correct PATH
If you follow the README docs to setup this report and the Jest repo, you'll be able to debug the process launch and see how we're calling child_process.spawn. The give some clues..
Hey,
I'm also having issues getting the extension running with a wsl only setup. The issue is that the workspace path (which is provided by jest-editor-support afaik) is used from the windows environment, not from the WSL environment - leading to errors like this:
`
react-scripts-ts test --env=jsdom "C:UsersMojaAppDataLocalTemp/jest_runner.json"
....
Pattern: C:UsersMojaAppDataLocalTemp/jest_runner.json - 0 matches
`
Therefore wsl jest alone will be sufficient - is there a way to overwrite the Workspace? In the debug configuration, there's a 'useWSL' flag, would something like this make sense in vscode-jest?
I would also be willing to fix it and create a PR.
any update on this issue?
I set up the extension for development/debugging and will see if I find a fix or workaround tomorrow
From: Yehonathan Sharvit
Sent: Tuesday, August 14, 2018 7:45 PM
To: jest-community/vscode-jest
Cc: Jannis Moßhammer; Comment
Subject: Re: [jest-community/vscode-jest] No way to use jest installed withinWindows Subsystem for Linux (#331)
any update on this issue?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Thanks @mojadev
See https://github.com/jest-community/vscode-jest/pull/361 - although I would also be ok with this PR to be rejected and updating jest-editor-support where necessary. Opinions/Suggestions on how to improve path detection and mapping are welcome.
With that state I was able to get it running locally:


@viebel & @mojadev please can you help me with this problem.
I've read the thread twice and it's like the solution is hidden. I had a look at the PR but that sort of stuff seems to be beyond my level. I've got jest running in the console but not properly integrated into vscode.
npm test
command prompt
node node_modules\jest\bin\jest.js
The following runs in the debug console but it does throw up an error.
{
"type": "node",
"request": "launch",
"name": "Launch via NPM",
"runtimeExecutable": "node",
"runtimeArgs": [
"${workspaceFolder}\\node_modules\\jest\\bin\\jest.js",
],
"cwd": "${workspaceFolder}",
"port": 9229
},
I also had a linked at the PR but that didn't help me much. Please could someone explain to me how to get the jest integrated with vscode properly.
@mojadev Any update on this issue ? I'm looking forward having this extension working with WSL 😄
Yes, support is currently in work (at them moment in facebook/jest).
@stephtr Thanks, gonna wait for this PR merge then :)
Any updates on this ? It seems that jest has added support in this issue (If I'm not mistaken, this is the PR that was talked about in previous comments)
Hi I'm deeply sorry it takes so long - functionality wise it is there, and the PR worked, but due to a unfortunate mixture of either me or reviewers not being available (either me not having time or the reviewer) and a bigger restructuring in the jest repository this got heavily delayed.
For me the next weeks are less crowded and I just need to take the code and move it to the new repository that has been introduced by jest. I'll try to binge-watch a couple of 'just-do-it' motivational speeches and finish it this week.
Don't be sorry for our bottleneck reviewing @mojadev. 😥
Can you help test the PR @bogdan-calapod? I reviewed it last night.
Sure, I'll check it out tomorrow
I overlooked that we'll need a change to jest-community/jest-editor-support as well. Check for a PR there first. https://github.com/jest-community/jest-editor-support/pulls
@seanpoulter : Did you find time to look over the issues in the PR?
No, sorry. I got as far as confirming the tests are failing in the jest-editor-support repo.
I receive the following error when trying to run it in WSL
Error: ENOENT: no such file or directory, open '/mnt/c/Users/cjk/Development/projects/myapp/C:/Users/cjk/AppData/Local/Temp/jest_runner.json'
It looks like it's trying to run tests with the node/jest in WSL, but some path stuff is getting messed up.
Workspace Settings:
"jest.pathToJest": "node node_modules/jest/bin/jest.js",
User settings:
"terminal.external.windowsExec": "C:\\WINDOWS\\System32\\bash.exe",
"terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe",
I was able to trick jest into working by telling vscode-jest to run the following script:
"use strict";
const cp = require("child_process");
const args = [];
for (const arg of process.argv.slice(2)) {
if (arg.startsWith("C:\\")) {
args.push(`/mnt/c/${arg.slice(3).replace(/\\/g, "/")}`);
} else args.push(arg);
}
cp.spawnSync("wsl", ["node", "node_modules/.bin/jest", ...args], {
cwd: process.cwd(),
stdio: "inherit"
});
However vscode-jest doesn't seem to apply the failures -- most likely because it doesn't understand the file paths in the test results JSON (which use WSL /mnt/c´ paths rather than WindowsC:` paths).
I think I can adjust the script to intercept the JSON file though.
Telling vscode-jest to use wsl directly didn't work because it used Windows paths. The output indicated the backslashes are being swallowed at some point but either way jest wouldn't know what to do with the outputFile Windows path.
EDIT: Adjusted the script to intercept the file and do a naive search & replace to fix paths:
"use strict";
const fs = require("fs");
const cp = require("child_process");
const args = ["--json", "--no-color"];
const i = process.argv.indexOf("--outputFile");
if (i === -1) {
console.error("Unexpected args", process.argv.slice(2));
process.exit(1);
}
if (process.argv.includes("--watch")) {
args.push("--watch");
}
const winOutputFilePath = process.argv[i + 1];
const proc = cp.spawn("wsl", ["node", "node_modules/.bin/jest", ...args], {
cwd: process.cwd(),
stdio: "pipe"
});
proc.stdout.on("data", buf => {
const str = buf.toString("utf-8");
fs.writeFileSync(
winOutputFilePath,
str
.replace(/\/mnt\/[a-z]/g, str => `${str.charAt(5).toUpperCase()}:`)
.replace(/\//g, "\\\\")
.replace(/\n/g, "\r\n")
);
});
proc.stderr.on("data", buf => {
const str = buf.toString("utf-8");
process.stdout.write(
str
.replace(/\/mnt\/[a-z]/g, str => `${str.charAt(5).toUpperCase()}:`)
.replace(/\//g, "\\")
.replace(/\n/g, "\r\n")
);
});
proc.on("error", err => {
console.error(err);
});
However it looks like this isn't sufficient to get watch mode working. The plugin gets stuck on "starting watch mode" and still doesn't apply the output. I'm guessing it expects some kind of signal or something.
EDIT2: Looks like this is a dead end. I've looked into jest-editor-support and there's probably no way around using jest directly. For now I'll just install jest on Windows and try to stub out any native dependencies in all tests.
I already created a fix for this half a year ago that got stuck after reworks in the base repo and breaking tests (that weren't really affected by the changes)- see https://github.com/mojadev/jest-editor-support/tree/WSL_Support . Technically it's easy, but getting it into the master seems to be the actual issue :)
I'll try to pull the current master of the editor support once and see if the base repo is more stable now.
Any updates on this? I'm having the same issue. Thanks! 🙏
@connectdotz just informed me that the jest-editor-support changes are about to be finished, afterwards I'll check my PR again for conflicts and we should be able to close this issue.
Any updates on this? I'm having the same issue. Thanks! 🙏
I've been using the Remote WSL extension and it's been working fine with that.
Get Outlook for Androidhttps://aka.ms/ghei36
From: Mike Lyons notifications@github.com
Sent: Monday, June 17, 2019 10:47:09 PM
To: jest-community/vscode-jest
Cc: Bogdan Calapod; Mention
Subject: Re: [jest-community/vscode-jest] No way to use jest installed within Windows Subsystem for Linux (#331)
Any updates on this? I'm having the same issue. Thanks! 🙏
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjest-community%2Fvscode-jest%2Fissues%2F331%3Femail_source%3Dnotifications%26email_token%3DABJVVR4JUR5ADGQTHTQKMSTP27S33A5CNFSM4FA6VHK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX4H5GQ%23issuecomment-502824602&data=02%7C01%7C%7C1afc5c9f5ba14d09f69308d6f35c96a6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636963976315261259&sdata=yONvuPAcrjgl%2B33L2Kgz6B%2FelniwrHaUpeE%2Bil3he5Q%3D&reserved=0, or mute the threadhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABJVVR25DGJF3XIQOQ4WARDP27S33ANCNFSM4FA6VHKQ&data=02%7C01%7C%7C1afc5c9f5ba14d09f69308d6f35c96a6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636963976315271270&sdata=th3b7E7TH%2BxCZNdJJomIzBfTTAoCbD2B0q4vzbrAAmg%3D&reserved=0.
Note that the extension currently only works with the Insiders version. But now that VS Code is getting native support for WSL via the Remote WSL extension I think this ticket can be closed.
I agree. I could update my fix now that the 3.0.0. release is out but given that the Remote WSL extension is out (soon) I think using that one is the better solution.
I used my wsl-support branch for development in WSL until now and will also switch to the remote extension, as this is the better solution imho.
Even Microsoft is now deprecating the use of useWSL for Node.js debug configurations in favor of the Remote-WSL extension.
I'll therefore finally mark this issue as solved. For further details on how to use VS Code on WSL, see their documentation.
Finally thank you all, especially @mojadev, for the effort put into trying to solve this issue!
That answers my question. You could set
"jest.pathToJest": "node node_modules/jest/bin/jest.js"in VS Code's settings, which should work with your setup (sincejest.cmdbasically just runs that command).
[Window Title]
Visual Studio Code
[Main Instruction]
Visual Studio Code
[Content]
Version: 1.46.0 (system setup)
Commit: a5d1cc28bb5da32ec67e86cc50f84c67cc690321
Date: 2020-06-10T09:03:20.462Z (5 days ago)
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363
[OK] [Copy]
Thanks @stephtr this Works.
Since we are mostly developing and deploying Docker, this also exposed some assumptions we've made about handling dates too.
Most helpful comment
That answers my question. You could set
"jest.pathToJest": "node node_modules/jest/bin/jest.js"in VS Code's settings, which should work with your setup (sincejest.cmdbasically just runs that command).