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

Add support for Windows Subsystem Linux #158

Merged
merged 1 commit into from Sep 18, 2017

Conversation

Projects
None yet
4 participants
@bzoz
Contributor

bzoz commented Aug 29, 2017

Continued from #156.

Refactored the code to a separate file and kept the code changes to the minimum. Per @nelak suggestion now we use bash -ic.

Add support for Windows Subsystem Linux
Add new "useWSL" launch attribute. When used, Bash on Windows will be
used to launch runtimeExecutable. Source files directory mapping will
also be automatically added.

@kieferrm kieferrm referenced this pull request Sep 12, 2017

Closed

Iteration Plan for September 2017 #34160

45 of 48 tasks complete

@weinand weinand merged commit 518e53d into Microsoft:master Sep 18, 2017

2 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
license/cla All CLA requirements met.
Details

@weinand weinand added this to the September 2017 milestone Sep 18, 2017

@weinand weinand self-assigned this Sep 18, 2017

@weinand weinand referenced this pull request Sep 25, 2017

Closed

Test WSL #34996

1 of 1 task complete
@noinkling

This comment has been minimized.

Show comment
Hide comment
@noinkling

noinkling Oct 6, 2017

Not sure if this is the correct place to ask, but how do I use something like the node_modules/.bin/babel-node executable instead of node?

I've tried all the combinations I can think of for runtimeExecutable and all I get are messages like Attribute 'runtimeExecutable' does not exist (when it's a Windows path), and Cannot find runtime '...../node_modules/.bin/babel-node' on PATH (when it's a WSL path).

I could install babel-node globally so it's in my PATH, but that's not recommended and is a pain to remember to update.

Edit: Actually it looks like this might be to do with the fact that babel-node is a symlink (I'm using yarn if it matters) not recognized properly by Windows.

Edit 2: If I turn it into a proper file I get a little further, however a new issue crops up:

Debugging with inspector protocol because a runtime executable is set.
c:\Dev\Projects\my-project/node_modules/.bin/babel-node --inspect=19380 --debug-brk src\server\index.js 
Node process error: Error: spawn c:\Dev\Projects\my-project\node_modules\.bin\babel-node ENOENT

That shouldn't have a Windows path should it? But using a WSL path in for runtimeExecutable just gives the other error I already mentioned.

If I run the equivalent with a relative path within a WSL terminal like:

$ node_modules/.bin/babel-node --inspect=19380 --debug-brk src\server\index.js
Debugger listening on ws://127.0.0.1:19380/4e50a4f8-39e7-4a8c-bd2a-ab513e0c91c4
...

you can see it works fine.

launch.json config:

{
  "type": "node",
  "request": "launch",
  "name": "Launch Server",
  "useWSL": true,
  "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/babel-node",
  "program": "${workspaceFolder}/src/server/index.js"
}

noinkling commented Oct 6, 2017

Not sure if this is the correct place to ask, but how do I use something like the node_modules/.bin/babel-node executable instead of node?

I've tried all the combinations I can think of for runtimeExecutable and all I get are messages like Attribute 'runtimeExecutable' does not exist (when it's a Windows path), and Cannot find runtime '...../node_modules/.bin/babel-node' on PATH (when it's a WSL path).

I could install babel-node globally so it's in my PATH, but that's not recommended and is a pain to remember to update.

Edit: Actually it looks like this might be to do with the fact that babel-node is a symlink (I'm using yarn if it matters) not recognized properly by Windows.

Edit 2: If I turn it into a proper file I get a little further, however a new issue crops up:

Debugging with inspector protocol because a runtime executable is set.
c:\Dev\Projects\my-project/node_modules/.bin/babel-node --inspect=19380 --debug-brk src\server\index.js 
Node process error: Error: spawn c:\Dev\Projects\my-project\node_modules\.bin\babel-node ENOENT

That shouldn't have a Windows path should it? But using a WSL path in for runtimeExecutable just gives the other error I already mentioned.

If I run the equivalent with a relative path within a WSL terminal like:

$ node_modules/.bin/babel-node --inspect=19380 --debug-brk src\server\index.js
Debugger listening on ws://127.0.0.1:19380/4e50a4f8-39e7-4a8c-bd2a-ab513e0c91c4
...

you can see it works fine.

launch.json config:

{
  "type": "node",
  "request": "launch",
  "name": "Launch Server",
  "useWSL": true,
  "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/babel-node",
  "program": "${workspaceFolder}/src/server/index.js"
}
@bzoz

This comment has been minimized.

Show comment
Hide comment
@bzoz

bzoz Oct 9, 2017

Contributor

@noinkling try this:

{
  "type": "node",
  "request": "launch",
  "name": "Launch Program",
  "useWSL": true,
  "program": "${workspaceFolder}/src/server/index.js",
  "protocol": "legacy",
  "runtimeExecutable": "./node_modules/.bin/babel-node"
}

When you specify runtimeExecutable, the inspector protocol will be used. It does not support WSL just yet, it is still WIP, so you have to explicitly use legacy protocol.

The ${workspaceFolder} will contain Windows-like path separator. This was fixed recently, see Microsoft/vscode#35249.

Contributor

bzoz commented Oct 9, 2017

@noinkling try this:

{
  "type": "node",
  "request": "launch",
  "name": "Launch Program",
  "useWSL": true,
  "program": "${workspaceFolder}/src/server/index.js",
  "protocol": "legacy",
  "runtimeExecutable": "./node_modules/.bin/babel-node"
}

When you specify runtimeExecutable, the inspector protocol will be used. It does not support WSL just yet, it is still WIP, so you have to explicitly use legacy protocol.

The ${workspaceFolder} will contain Windows-like path separator. This was fixed recently, see Microsoft/vscode#35249.

@noinkling

This comment has been minimized.

Show comment
Hide comment
@noinkling

noinkling Oct 10, 2017

Thanks, it seems I missed the

for this milestone "legacy" protocol only

disclaimer in the release notes (or maybe it was added later?). I'm using Node 8 so the legacy protocol isn't an option, guess I'll just have to wait a little longer.

noinkling commented Oct 10, 2017

Thanks, it seems I missed the

for this milestone "legacy" protocol only

disclaimer in the release notes (or maybe it was added later?). I'm using Node 8 so the legacy protocol isn't an option, guess I'll just have to wait a little longer.

leotulipan added a commit to leotulipan/wp2md that referenced this pull request Oct 15, 2017

@alanosman

This comment has been minimized.

Show comment
Hide comment
@alanosman

alanosman Oct 15, 2017

YES! It's in the latest production release. Thank you!

alanosman commented Oct 15, 2017

YES! It's in the latest production release. Thank you!

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