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

Debugging Deno programs no longer works as of VS Code 1.47 #638

Closed
masonmark opened this issue Jul 19, 2020 · 2 comments
Closed

Debugging Deno programs no longer works as of VS Code 1.47 #638

masonmark opened this issue Jul 19, 2020 · 2 comments
Assignees
Labels
*duplicate Issue identified as a duplicate of another issue(s)

Comments

@masonmark
Copy link

Describe the bug
Existing launch configurations for debugging Deno programs, which worked in VS Code 1.46 and prior, no longer work in 1.47.

The reason appears to be that in 1.47, if the runtimeArgs array property of the launch configuration contains "--inspect-brk", it is swallowed/removed, and is not passed to the launch configuration's specified runtimeExecutable (which will be "deno" for Deno programs).

To Reproduce
Steps to reproduce the behavior:

  1. Create a launch.json file with a single launch configuration, like this:
{
  "version": "0.2.0",
  "configurations": [
    {
      "console": "integratedTerminal",
      "name": "Debug Deno (Allow All)",
      "type": "node",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": ["run", "--inspect-brk", "-A", "${file}"],
      "port": 9229
     }
  ]
}
  1. Create a trivial program in TypeScript (presumably you'd be using Deno's APIs in real life, but any TypeScript program can be used to demonstrate the issue):
class Greeter {

  static sayHello() {
    console.log("hi!");
    console.log("helloooooooooo!!!");
  }
}

Greeter.sayHello(); // set VS Code breakpoint on this line
console.log("Did we attach the debugger?");
Greeter.sayHello();
  1. Set a breakpoint (by clicking in the margin in the VS Code GUI) on the first Greeter.sayHello() line. Press F5 to debug the program, using your single launch configuration which will attempt to debug it with Deno.

  2. If using VS Code 1.46 or earlier, debugging will commence, and execution will stop at the breakpoint. But if using VS Code 1.47, the program will fully execute and exit. The breakpoint will be ignored and no debugging will occur.

VS Code Version: 1.47.2 (17299e413d5590b14ab0340ea477cdd86ff13daf)

Additional context
Comparing the behavior of 1.46 (works) and 1.47 (doesn't work), it seems that VS Code is treating the argument --inspect-brk specially, and if present, skipping it when invoking the runtimeExecutable. The argument is not passed to Deno.

...VS Code 1.46 emits a command like this in the terminal when you hit F5:

cd /Users/mason/Documents/Syncthing/CODE/deno-greet ; /Users/mason/.local/bin/deno run --inspect-brk -A /Users/mason/Documents/Syncthing/CODE/deno-greet/main.ts

That looks right, and does work.

But in VS Code 1.47 the emitted command is:

env 'NODE_OPTIONS=--require "/Applications/Visual Studio Code-LATEST.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js" ' 'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":"/var/folders/_m/p_1dc3dj3mv12hr0nl1s1chh0000gn/T/node-cdp.13593-1.sock","deferredMode":false,"waitForDebugger":"","execPath":"/Users/mason/.nodenv/shims/node","onlyEntrypoint":false,"fileCallback":"/var/folders/_m/p_1dc3dj3mv12hr0nl1s1chh0000gn/T/node-debug-callback-b6731a1c153c29aa"}' /Users/mason/.local/bin/deno run -A /Users/mason/Documents/Syncthing/CODE/deno-greet/main.ts

That doesn't work, because Deno isn't receiving the --inspect-brk argument when it is invoked, so it doesn't enable debugging.

It's not clear to me if "working great to debug Deno programs" was the intended behavior, prior to 1.47, or if perhaps it was just a happy accident. Removing the "--inspect-brk" argument from the args passed to the program seems to me to be a surprising behavior, but perhaps this makes sense for node.js programs and that is all that was intended to be supported?

I think passing all arguments exactly as specified in the launch configuration would fix this issue for the case of debugging Deno apps. Perhaps this behavior could be conditional, depending on the launch configuration's runtimeExecutable value?

If more background info is useful, I have written about the topic of using VS Code to debug Deno programs on my personal blog 3 times, and he links are below. (Be warned, though, they might contain cuss words and slightly more puerile versions of the sample code above 🙈.)

  1. debug your Deno programs with VS Code — documents that a new Deno beta release had made debugging with VS Code possible, albeit with some manual steps needed (April 2020)

  2. debug your Deno programs with VS Code — NOW WITH LESS F***ERY!!! — a fix to Deno in 1.0.0 made the manual steps unnecessary, and you could now just debug a Deno program by pressing F5 (assuming the above launch configuration was defined) (June 2020)

  3. debug your Deno programs with VS Code Part III — RETURN OF THE F***ERY 💀 — writeup of how debugging Deno programs stopped working in VS Code 1.47 and how to workaround it (either downgrade to 1.46, or go back to the manual method outlined in post chore: make sourcePathResolver function per-thread #1 from April) (July 2020)

Thank you, and I hope debugging Deno programs will work again, because it was very useful and fabulous. 🕺🏻

@masonmark masonmark added the bug Issue identified by VS Code Team member as probable bug label Jul 19, 2020
@masonmark
Copy link
Author

Reading the docs of this project, I learned that it is possible (for now) to disable the debug.javascript.usePreview setting and go back to the old debugger. This will work around the problem with debugging Deno programs in VS Code 1.47.

But the new debugger has lots of cool features, so I hope Deno will be supported in a future version.

@connor4312
Copy link
Member

Thanks for the detailed issue and background information -- see here for a fix denoland/vscode_deno#12 (comment). The commit linked there had some additional rationale/background information behind what's going on.

I have a PR in to update the Deno docs, but their CLA requires review from Microsoft's legal team before I can sign it, so it may take some time to get in.

@connor4312 connor4312 added *duplicate Issue identified as a duplicate of another issue(s) and removed bug Issue identified by VS Code Team member as probable bug labels Jul 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
*duplicate Issue identified as a duplicate of another issue(s)
Projects
None yet
Development

No branches or pull requests

2 participants