VSCode doesn't make level of Windows Subsystem for Linux integration support (or lack thereof) clear

[sgharms]

First, let me say I'm over the moon with the current state of Microsoft: VSCode, the WSL, etc. You all are doing fantastic work.

That said, I would like to see Windows become a development platform that embraces "full stack developers" coming from OSX or Linux and makes their transition simple. At present, using Windows 10 + WSL + VSCode together has some glaring issues for simple use patterns that make VSCode easier to use on OSX than on Windows 10. By hitting these basic issues so hard so quickly, I think VSCode may not have the chance to reach the many it could. Here's my problem:

The challenge here is: Write Hello World In JavaScript (node) and Run It (Using WSL-originated install of node within Ubuntu). While having reported this question at Stack Overflow several days ago, there is not yet a single reply. I'm surprised to find such a mute audience or that this question hasn't been asked before. The introductory development documentation and video seems to assume that developers are using Windows terminals only.

To the extent that the WSL is now available, I'd like to be able to use it with VS code and have, effectively, the same development experience I have in OSX. Write code in an editor, drop to the shell to run complex git commands, cat some output that I open up in the editor, etc. In short, the integration between code and the (wsl) shell still feels "gappy" or non-integrated.

Could I get some official guidance on what the roadmap is or what the integration expectation is?

• VSCode Version: 1.18.1
• OS Version: 1709 / 16299.64

Steps to Reproduce:

• With WSL + Ubuntu I installed the nodejs package.
• I create a "Hello World" in VS Code using JavaScript
• I run the debug command
• Cannot find runtime 'node' on PATH. Make sure to have 'node' installed.

Hrm. OK. I'm prompted to open up launch.json or close.

So I thought as a workaround to try adding an alias for node to nodejs.

I restarted VS Code, tried the same process, same failure.

I then tried a symlink between /usr/bin/node to /usr/bin/nodejs. Same error.

Reproduces without extensions: Yes

[weinand]

@sgharms You've seen this?
https://code.visualstudio.com/updates/v1_17#_first-steps-towards-wsl-support
https://code.visualstudio.com/updates/v1_18#_more-wsl-support-for-nodejs

Make sure to set the useWSL flag in your launch config.

[sgharms]

@weinand Thank you so much for the prompt reply. Let me try to document my steps here.

Processing: https://code.visualstudio.com/updates/v1_17#_first-steps-towards-wsl-support

1. The debugger supports launching Node.JS apps in WSL-land. Great!
2. With this feature, you can add a useWSL flag to a debug configuration. I'd really like to see "debug configuration" hyperlinked here. I hope I do this right. Navigate to: https://code.visualstudio.com/docs/editor/debugging based on search for "vscode debug configuration"
3. Read...Open folder for work, create app.js write Hello, World code in it
4. "For advanced debugging, you first have to open a folder and then set up your launch configuration file - launch.json." OK, that would seem to be me. My default belief, from this documentation is that I should create a ${workspaceFolder}/\\.vscode directory as a "folder-specific" configuration. Thus:

 sgharms@DESKTOP-439JPNR  ~/winhome/foo  ls -alR
.:
total 0
drwxrwxrwx 0 root root 4096 Nov 27 14:37 .
drwxrwxrwx 0 root root 4096 Nov 27 13:41 ..
-rwxrwxrwx 1 root root  386 Nov 27 14:23 app.js
drwxrwxrwx 0 root root 4096 Nov 27 14:39 .vscode

./.vscode:
total 0
drwxrwxrwx 0 root root 4096 Nov 27 14:39 .
drwxrwxrwx 0 root root 4096 Nov 27 14:37 ..
-rwxrwxrwx 1 root root  476 Nov 27 14:38 launch.json

Configurations added here are locally sourced! 💯

For future reference, here was the content:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch in WSL (local config)",
            "useWSL": true,
            "program": "${workspaceFolder}/app.js"
        },
// Add another configuration that stands out by referencing an episode of "The Sopranos."
        {
            "type": "node",
            "request": "launch",
            "name": "Launch with Joey Pepitone magic",
            "useWSL": true,
            "program": "${workspaceFolder}/app.js"
        }
    ]
}

With this change, I'm good. @weinand, you pointed me in the right direction, but this information, seems buried in these milestone notes. I'll propose a PR in the vscode-docs repo based on the narrative above. Thanks.

[weinand]

@sgharms sorry for only referring to the incremental documentation of WSL in the release notes. I was assuming that you are following our monthly release notes and only need "the deltas".
Of course you can find the same information expanded into the full VS Code documentation about Node/JavaScript here: https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_remote-debugging. Since WSL support is a variant of remote debugging, you'll have to scroll a bit down to the bullet item "debugging Node.js in the Linux subsystem on Windows".

[sgharms]

@weinand Noted. I'd like to make this easier to find in the docs insofar as "debug my node app" is not an obvious equivalence to "I want to use a remote debugger" for many people coming from other editors.

Would it be correct to derive from this that we will have to see this modification for each language environment e.g. Python will need to integrate a similar change in pythonVSCode, for example and if I wanted to open an issue for lack of WSL integration that would be the correct project to do it in?

[weinand]

Please be assured that we are working on a general solution to WSL. The useWSL approach is just a first outcome of this. We will provide a more general solution that does not require that every extension environment has to tackle this on their own. But first we have to understand the problem and the useWSL flag is the first step towards this.

[sgharms]

This seems a sensible path forward. I'll start tracking the updates waiting for the joyous diff wherein Python can be used in the WSL layer. Thanks for helping define an official stance that can be readily communicated and understood.

[rcarmo]

I'd like to chime in regarding Python (and Go, and Java, and even .NET Core) on WSL. All my deployments run on Linux machines, and WSL is the way I am productive in Windows, so having Code work natively with WSL is essential.