Description
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:
{
"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
}
]
}
- 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();
-
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)
-
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. 🕺🏻