`npm run test` fails when run from both win10 and wsl
See original GitHub issueEnvironment data
- VS Code version: 1.43.2
- Extension version (available under the Extensions sidebar): 2020.4.0-dev
- OS and version: Windows 10 - 1903
- Python version (& distribution if applicable, e.g. Anaconda): 3.8 but not relevant
- Type of virtual environment used (N/A | venv | virtualenv | conda | …):
- Relevant/affected Python packages and their versions:
- Relevant/affected Python-related VS Code extensions and their versions:
- Jedi or Language Server? (i.e. what is
"python.jediEnabled"
set to; more info #3977): - Value of the
python.languageServer
setting:
Expected behaviour
npm run test
successfully runs when the command is issued in win10.
When the command is rerun in WSL, the script only checks for the presence of ./.vscode-test/vscode-[ver]
.
However, the installer places the downloaded copy for windows and the copy needed for WSL in different locations. So it skips installing the extra version it needs, and subsequently crashes.
This is also happens in reverse (I.E. wsl successfully runs and then the command is run from win10)
Actual behaviour
root @ win10 .../projects/all_msft/vscode-python 19:22 0
@In [2] $ npm run test
> python@2020.4.0-dev test /mnt/c/Users/fac/projects/all_msft/vscode-python
> node ./out/test/standardTest.js && node ./out/test/multiRootTest.js
****************************************************************************************************
Start Standard tests
Found .vscode-test/vscode-1.43.2. Skipping download.
Test error: Error: spawn /mnt/c/Users/fac/projects/all_msft/vscode-python/.vscode-test/vscode-1.43.2/VSCode-linux-x64/code ENOENT
Exit code: -2
Done
End Standard tests (with errors) Failed
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! python@2020.4.0-dev test: `node ./out/test/standardTest.js && node ./out/test/multiRootTest.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the python@2020.4.0-dev test script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2020-03-26T23_22_08_810Z-debug.log
Sorry if anything here is unclear at all. I’d be happy to elaborate if so.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
After installing npm on WSL Ubuntu 20.04 I get the message ...
From WSL run sudo apt install nodejs npm to install node & npm; From PowerShell/CMD run wsl --shutdown to restart the WSL service;...
Read more >Set up Node.js on WSL 2 - Windows - Microsoft Learn
Install Windows Terminal (optional). Windows Terminal is an improved command line shell that allows you to run multiple tabs so that you can ......
Read more >WordPress testing suite vs Windows 10 and WSL
Develop on Windows 10, run tests in WSL. CMB2 uses unit tests, and inherits a testing suite from WordPress, using its tools to...
Read more >Setting Up Docker for Windows and WSL to Work Flawlessly
Here's step by step instructions for both versions of Windows: Running Windows 10 18.03+ or Newer? First up, open a WSL terminal because...
Read more >Windows Subsystem for Linux Setup - RedwoodJS Community
So now let's start this setup process! Developing Redwood Projects on Windows. Install WSL*. Prerequisites. You must be running Windows 10 ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@farisachugthai, thanks for the update. I’m going to mark this issue as an enhancement request and we’ll make a decision in the near future on whether to proceed with it. Thanks again.
Thanks for the suggestion! We talked about it with the team and we have unfortunately decided we will not be moving forward with this idea. We think there isn’t an enough widespread need for this to warrant the maintenance cost for the feature.