You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Create a launch.json file with a single launch configuration, like this:
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):
classGreeter{staticsayHello(){console.log("hi!");console.log("helloooooooooo!!!");}}Greeter.sayHello();// set VS Code breakpoint on this lineconsole.log("Did we attach the debugger?");Greeter.sayHello();
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.
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 🙈.)
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)
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.
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
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
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 specifiedruntimeExecutable
(which will be "deno" for Deno programs).To Reproduce
Steps to reproduce the behavior:
launch.json
file with a single launch configuration, like this: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.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 theruntimeExecutable
. The argument is not passed to Deno....VS Code 1.46 emits a command like this in the terminal when you hit F5:
That looks right, and does work.
But in VS Code 1.47 the emitted command is:
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 🙈.)
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)
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)
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. 🕺🏻
The text was updated successfully, but these errors were encountered: