Optionally Run Language Servers/Extensions using Windows Subsystem for Linux

[joewood]

Similar to the request for #20220 but more general. Running the Windows version of Code from bash on Windows using WSL works really well. The problem with the set-up is that the language server and extension environment in code is using the Windows environment, but the terminal is using the WSL environment. These are essentially two different operating systems, different executables installed and configured.

It would be better to be able to configure VSCode on Windows to fork all processes using WSL (bash) rather than the native Windows command shell. This applies to language servers and other extensions.

[bpasero]

@joewood when we fork a process (e.g. the one for running the extension host process), there is no shell involved at all (why would we need that?). Are you talking about the integrated terminal maybe?

[joewood]

Without knowing too much about the language server implementation, I'm talking about running the language service/extension process under the bash shell using node.js installed under WSL. So this would mean using spawn or exec, rather than fork.

As implied here - bash -c node languageserver.js, and then use the I/O stream from WSL based process than the process events.

The alternative is to run the Linux version of vscode, and use a XWindows server on the Windows side. Something that I was trying to avoid.

[bpasero]

@joewood ok and what would be the benefit of running the language service in a shell environment?

[wclr]

@bpasero You may look at my explanation of the problem with TSserver running in windows and if symlinks for packages are made in WSL - it won't work, it will not be able to access WSL symlinks. When working with vscode npm packages should be linked in windows natively, but it makes impossible most of the operations with packages in WSL shell (like installing upgrading or running node services).

[joewood]

@bpasero To add to @whitecolor said, there are many reasons why a consistent editor environment should match the shell. At the moment building with one OS and editing in another introduces too many consistencies, technical challenges and roadblocks.

[wclr]

@joewood btw I use docker to run dev processes (installing deps, running node, etc), it allows to get rid of many problems, but if there is no need in complication like docker, setup causes troubles on windows.

[Tyriar]

It might make sense to wait for this until Electron apps are better supported launching from WSL?

[wclr]

It might make sense to wait for this until Electron apps are better supported launching from WSL?

I think no, this doesn't relate. Because it is ok to run vscode as normal windows app, but run the console and other terminal based tools (like git, build tasks, etc) in WSL.

[Tyriar]

@whitecolor I think it should all just work if the Linux app is launched from WSL. Special casing the Windows client to make a bunch of calls to Linux sounds like it would be difficult to cover all cases to me.

[wclr]

Well, need to see how VSCode will work launched from WSL.

[joewood]

I've still not managed running the Linux version of VSCode from WSL. The XWindows experience isn't great anyway for Electron apps, which is why I was hoping for a more native WSL experience using the Windows executable.

[wclr]

The XWindows experience isn't great anyway for Electron apps,

Yeah I too think it is not going to change anytime soon. So IDE UI will need to run nativly on windows, but there should be ability to run terminal/shell tasks using WSL. And it seem like a not very difficult to add.

[xcdr]

This feature is very important in my opinion, actually making dev environment like Go, Rails, Python and others on windows is terrible comparing to Linux/OSX - all stuff should be based on VSCode + WSL, without installation native windows versions.

[giovdk21]

Hello,
in the meantime I tried to write a powershell script as a hack/workaround for this:

https://github.com/giovdk21/wsl-bash-tools

It's pretty ugly, but I tested it with the insider version of VSC (1.14.0-insider) and it seems to work fine with solargraph and it can also be used to run custom tasks. I included some sample config files in case you want to give it a go.

Please note that if the script thinks an argument is a windows path it will convert it to the equivalent Linux path for WSL. This is needed for example by solargraph as it passes the URL of the view to the server when displaying the ruby documentation ("Search Ruby Documentation").

[stankul]

@giovdk21 Tried running one of the sample tasks from the repository with your workaround in VSC 1.14.0 and couldn't figure out why it doesn't work. Am I missing something?

> Executing task: C:\dev\utils\wsl-bash-tools\wsl-bash-run.bat uname -a <

& : The term 'C:\Windows\System32\bash.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again.
At C:\dev\utils\wsl-bash-tools\wsl-bash-run.ps1:21 char:7
+     & C:\Windows\System32\bash.exe -c "$args_str"
+       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Windows\System32\bash.exe:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Running C:\dev\utils\wsl-bash-tools\wsl-bash-run.bat uname -a in cmd.exe works as expected.

[giovdk21]

Hi @OctoTot ,
could you please post this as an issue/question on https://github.com/giovdk21/wsl-bash-tools/issues ?

thanks

edit: I did create an issue and released a quick fix for it

[fongandrew]

This feature request wasn't something I appreciated until I started using VSCode for stuff outside of Node/JS/Typescript. With NodeJS, you have a decent Windows runtime you can use. And dependencies (node_modules) are generally colocated in the same directory for both WSL and VSCode.

Those things are not always true for other languages. Sometimes there is no proper Windows build for a language's compiler / interpreter. Or package dependencies live in odd locations that aren't shared between the WSL runtime and the Windows runtime for some language, which means you generally have to do a lot of messing around symlinks and environment variables to get everything to play nice. Or sometimes the Windows version of a dependency is completely different from the WSL version (e.g. the packaging tool downloads a binary rather than source), so you have to install each dependency twice (once on WSL and once on Windows).

[sgharms]

I want Windows 10 to be a better OSX for developers than what OSX provides. Presently WSL + VSCode is slightly below parity to VSCode + OSX. This issue, when integrated will, to my mind, set the two at parity.

The bar of user expectation is set by Linux and OSX. Both of these provide a principle-of-least-surprise-compatible model of "a shell environment that is a natural subsystem upon which GUI tools run."

Or, to put it in language that Gates-era Microsoft would recognize from the curious case of bundled IE and Win95: the apps' seamless integration is the competitive advantage.

Right now this internecine split between (VSCode + WSL) or (VSCode + Windows Powershell EXEs) serves to weaken the developer perception of the stability of the platform. Given the hassle, why not just stick with OSX or Linux?

This issue is the blocker in my and, I'll wager, others' (re-)adoption of the Windows platform for development. One clear decision here, an abstraction, and then everything can fall into place!

Guide us, O sages!

Edits: 2018-02-07

[shanghaikid]

Still waiting for this feature!

[lightrow]

yep, still waitin'

[Voronoff]

This is my biggest blocker for vscode on Windows being a good development environment.

[NapalmCodes]

I want to do all my development in windows using WSL for the better tooling experience, bash, etc. Having to use vscode on a linux vm is just annoying when the same app is installed on windows ready to go.

[mterrel]

Yep, after years of happily developing web/Node/Linux software using OSX, I'm back on Windows because Apple screwed up their hardware platforms and Microsoft's Surface is the hardware I need.

But the developer experience isn't quite there yet. With Microsoft very publicly focusing so much energy on developers and especially trying to bring non-Windows devs into the fold, the Microsoft UX team needs to sit down with some folks that really like developing on Linux and OSX and bring the learning back to Windows. WSL and VS Code are HUUUGE improvements already!

But fixing this particular issue would make my life better EVERY DAY. 😃

[relston]

+1 Here. Same boat. Love the progress so far. This would make life great for people who want to stick with Linux tools.

[adminroot0000]

For me this issuer is the only problem blocking Windows become my development environment, Installing every language tools twice in WSL and Windows is really annoying.

[Tyriar]

We just announced remote development with VS Code, check out the blog post for details https://code.visualstudio.com/blogs/2019/05/02/remote-development

[joewood]

Wow, this is great and a game changer. The container support is exactly what I hoped this WSL request would lead. Big thanks to the team!

[andrewkress]

Excited to try it out, finally makes code more than a text editor!