Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to use jest installed within Windows Subsystem for Linux #331

Closed
therazor opened this issue May 21, 2018 · 36 comments
Closed

No way to use jest installed within Windows Subsystem for Linux #331

therazor opened this issue May 21, 2018 · 36 comments

Comments

@therazor
Copy link

Environment

  1. node -v: no version installed

  2. npm -v: no version installed

  3. npm ls react-scripts (if you haven’t ejected): N/A

  4. Operating system: Windows 10 + WSL

Steps to Reproduce

Use Windows 10 + Windows subsystem for linux. Install node/npm/jest within the subsystem only, not in windows.

Expected Behavior

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

Actual Behavior

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

@stephtr
Copy link
Member

stephtr commented May 21, 2018

Is your whole project residing within WSL or did you just run npm install within WSL?

@therazor
Copy link
Author

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

@stephtr
Copy link
Member

stephtr commented May 22, 2018

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

@therazor
Copy link
Author

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?

@seanpoulter
Copy link
Member

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.

@stephtr
Copy link
Member

stephtr commented May 26, 2018

Since the whole node_modules folder is already present, what speaks against installing just Node? I think that would be the only tool needed.

@connectdotz
Copy link
Collaborator

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.

@therazor
Copy link
Author

therazor commented Jul 26, 2018

image

@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)

image

Which means that whatever context this extension is running with, it's missing something, possibly the correct PATH

@seanpoulter
Copy link
Member

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

@mojadev
Copy link

mojadev commented Jul 27, 2018

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.

@viebel
Copy link

viebel commented Aug 14, 2018

any update on this issue?

@mojadev
Copy link

mojadev commented Aug 14, 2018 via email

@viebel
Copy link

viebel commented Aug 15, 2018

Thanks @mojadev

@mojadev
Copy link

mojadev commented Aug 15, 2018

See #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:
grafik

grafik

@unparagoned
Copy link

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

bash
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 added a commit to mojadev/vscode-jest that referenced this issue Sep 3, 2018
mojadev pushed a commit to mojadev/jest that referenced this issue Sep 3, 2018
…unner

* Add useWsl configuration flag to project worksapce
* Translate windows paths in call args to POSIX paths valid in WSL

see jest-community/vscode-jest#331
mojadev pushed a commit to mojadev/jest that referenced this issue Sep 3, 2018
…unner

* Add useWsl configuration flag to project worksapce
* Translate windows paths in call args to POSIX paths valid in WSL

see jest-community/vscode-jest#331
@kevinmarrec
Copy link

@mojadev Any update on this issue ? I'm looking forward having this extension working with WSL 😄

@stephtr
Copy link
Member

stephtr commented Sep 28, 2018

Yes, support is currently in work (at them moment in facebook/jest).

@kevinmarrec
Copy link

@stephtr Thanks, gonna wait for this PR merge then :)

mojadev added a commit to mojadev/vscode-jest that referenced this issue Oct 14, 2018
mojadev pushed a commit to mojadev/jest that referenced this issue Oct 14, 2018
…unner

* Add useWsl configuration flag to project worksapce
* Translate windows paths in call args to POSIX paths valid in WSL

see jest-community/vscode-jest#331
mojadev pushed a commit to mojadev/jest that referenced this issue Oct 14, 2018
…unner

* Add useWsl configuration flag to project worksapce
* Translate windows paths in call args to POSIX paths valid in WSL

see jest-community/vscode-jest#331
mojadev added a commit to mojadev/vscode-jest that referenced this issue Oct 14, 2018
@bogdan-calapod
Copy link

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)

@mojadev
Copy link

mojadev commented Nov 27, 2018

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.

@seanpoulter
Copy link
Member

Don't be sorry for our bottleneck reviewing @mojadev. 😥

Can you help test the PR @bogdan-calapod? I reviewed it last night.

@bogdan-calapod
Copy link

Sure, I'll check it out tomorrow

@seanpoulter
Copy link
Member

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

@mojadev
Copy link

mojadev commented Dec 6, 2018

@seanpoulter : Did you find time to look over the issues in the PR?

@seanpoulter
Copy link
Member

No, sorry. I got as far as confirming the tests are failing in the jest-editor-support repo.

@offero
Copy link

offero commented Jan 18, 2019

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

@pluma
Copy link

pluma commented Mar 1, 2019

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 Windows C:` 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.

@mojadev
Copy link

mojadev commented Mar 2, 2019

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.

@jsonMartin
Copy link

Any updates on this? I'm having the same issue. Thanks! 🙏

@mojadev
Copy link

mojadev commented Apr 18, 2019

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

@mikelyons
Copy link

Any updates on this? I'm having the same issue. Thanks! 🙏

@bogdan-calapod
Copy link

bogdan-calapod commented Jun 17, 2019 via email

@pluma
Copy link

pluma commented Jun 28, 2019

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.

@mojadev
Copy link

mojadev commented Jun 30, 2019

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.

@stephtr
Copy link
Member

stephtr commented Jul 3, 2019

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!

@airtonix
Copy link

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests