Debug support

[lukepighetti]

I noticed if I hit F5 to run & debug it doesn't work. What's the status and upstream work to be done for this feature?

[justjavac]

wip

[connor4312]

Hi, I work on the VS Code javascript debug extension. Since you're based on V8 and CDP, and there are reports of attach configs just working, it may sense to plug into our existing Javascript debugger. (Note that we're working on releasing a new debugger; I'd recommend targeting that as the standard.)

More than happy to provide pointers / brainstorm, Let me know how I can help 🙂

[rodolphocastro]

Using the current node debugger on VSCode worked just fine for me.

Had to created a new launch.json with the following settings:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug Deno (Allow All)",
            "type": "node",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "runtimeExecutable": "deno",
            "runtimeArgs": [
                "run",
                "--inspect",
                "-A",
                "index.ts"
            ],
            "port": 9229
        }
    ]
}

Which tells vscode to call deno run --inspect -A ./index.ts and run the debugger on 127.0.0.1:9229.

Then running with f5, attaching breakpoints, inspecting and logging to the debug console worked like a charm:

[bartlomieju]

Docs for VSCode debugging: https://deno.land/manual/tools/debugger#vscode

[justjavac]

thanks

[millsp]

I had problems displaying to the standard output with the default configuration, console.log not showing up in the debugger's console. Just in case some of you are facing the same problem, I fixed it by adding this to the configuration:

"console": "integratedTerminal"

Not sure if this is a known bug @bartlomieju

[cvlvxi]

I followed the guideline using the following launch.json

{
  "version": "0.2.0",
  "configurations": [
      {
          "name": "Debug Deno (Allow All)",
          "type": "node",
          "request": "launch",
          "cwd": "${workspaceFolder}",
          "runtimeExecutable": "deno",
          "runtimeArgs": [
              "run",
              "--inspect-brk",
              "-A",
              "samplesheet.ts"
          ],
          "port": 9229,
          "console": "integratedTerminal"
      }
  ]
}

Which starts the debugger session and then immediately quits...

➜  deno_samplesheet git:(master) ✗ /usr/local/bin/deno run --inspect-brk -A samplesheet.ts 
Debugger listening on ws://127.0.0.1:9229/ws/af029d1b-98ad-49a5-8a0b-1520f5a63a16
Debugger session started.

Any ideas?

[gewoonwoutje]

@cvlvxi Maybe your samplesheet.ts does not have a process that keeps running (happened to me😅).

[gewoonwoutje]

@pirix-gh If you don't like that the debug output occupies a terminal window, you can also add "outputCapture": "std" to your config instead of your console setting. It works better for me.

[millsp]

@gewoonwoutje this does not work for me, unfortunately. Not sure why, but I always had the same problem with Node.js. Could be from my environment (ubuntu).

[cvlvxi]

@gewoonwoutje thanks from the response. How can I make it so that my ts file has a process that keeps running?

[ZenLiuCN]

@cvlvxi just see deno offical document like run a http server

import { serve } from "https://deno.land/std/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
    req.respond({ body: "Hello World\n" });
}

[frankhale]

I've following the comments here as well as on https://deno.land/manual/tools/debugger#vscode but my breakpoints are always unbounded and they will never be able to be hit when the program executes. I'm on Windows 10 using VSCode Insiders. I've even tried using the sample program and setting the breakpoint on the console.log message but it's still unbound. I'm using Deno 1.1.3. Anyone else having issues like this?

[connor4312]

@frankhale can you try with our new debugger? (This debugger will become the default in the VS Code release upcoming this week.) If that doesn't work, please file an issue!

[frankhale]

Here is a screenshot of what I see when I start the debugger along with my launch.json

[frankhale]

I think I know what's going on in my case. For the record I'm on Windows 10 and have tried VSCode (regular release) and Visual Studio Insiders (latest build from today, using nightly version of the JavaScript Debugger).

It really looks like --inspect-brk is being completely ignored when using the following launch.json. When pressing F5 the app will launch but the debugger is never started and consequently cannot attach.

{
      "name": "Deno",
      "type": "node",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": ["run", "--inspect-brk", "-A", "${file}"],
      "port": 9229
}

If I run my app from the terminal using: deno run --inspect-brk -A main.ts and then use a configuration in my launch.json to just attach to the debugger then everything works as expected:

{
      "name": "Deno (Attach)",
      "type": "node",
      "request": "attach",
      "port": 9229
}

[David-Else]

@connor4312 I am using the brand new code-1.47.0 with the new debugger and get the same results as @frankhale . I can't set a breakpoint and run the Deno config. It starts the debugger but nothing is happening, the breakpoint is 'unbound'. I can run the attach and it starts debugging but on the .ts imports it says unable to retrieve source content

I am running Centos 8.2 Linux.

[frankhale]

@David-Else correct I see those same results but I'd like to mention that when it says "Unable to retrieve source content." you can click the debugger continue button and it will resume execution of your app and if you have breakpoints you should be able to hit them. This is the work around I'm using currently.

I'd also like to thank you for providing another example of the behavior. I am thinking that the bug is happening with the launch.json profile for launching deno and attaching with just an F5 press and I think it has something to do with the runtimeArgs property "runtimeArgs": ["run", "--inspect-brk", "-A", "${file}"]. When I press F5 it seems to be completely skipping --inspect-brk and the debugger user interface in Visual Studio Code is just stuck in a state where it's waiting but it's never going to start. Here is why I came to that conclusion.

[David-Else]

@frankhale Cheers! Also, it won't work with -- in front of any argument, try "inspect-brk" and it accepts it! What is going on? That has to be a VS Code parsing bug?

[connor4312]

What is going on?

It's related to how the new debugger works -- it actually includes a "bootloader" file to set up debugging. This has many advantages, but is incompatible with --inspect-brk: that would cause Node to break in our bootloader, at which point VS Code will not have been told that there's something to debug! If the new debugger sees --inspect-brk, it filters it out and instead manually sets a breakpoint on the first line of user code that would be run.

Deno somewhat predictably (but I wanted to check) doesn't read from the NODE_OPTIONS environment variable that we leverage to inject the bootloader, so something else will need to be done there. I will introduce some compatibility logic into js-debug within the coming days.

[David-Else]

@connor4312 I have deleted the line and now and it still does not work. Can this config be made compatible?

    {
      "name": "Deno",
      "type": "node",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": ["run", "-A", "${file}"],
      "port": 9229
    },

[connor4312]

Given you're on 1.47 where the new debugger is now the default, you have a couple options until this capability is unlocked in js-debug:

• Set debug.javascript.usePreview to false in your user settings to use the old debugger for now

• Make it a task instead and attach to it:

  launch.json

  {
    "version": "0.2.0",
    "configurations": [
      {
        "type": "node",
        "name": "Launch Program",
        "request": "attach",
        "port": 9229,
        "preLaunchTask": "run my program" // this will run the program task before debugging
      },
  }

  tasks.json

  {
    "version": "2.0.0",
    "tasks": [
      {
        "label": "run my program",
        "type": "shell",
        "command": "deno run --inspect-brk greet.js", // your program args
        "isBackground": true // don't wait for the task to end before debugging
        "problemMatcher": { // tells vscode to wait for this line before debugging
          "background": {
            "activeOnStart": true,
            "beginsPattern": "Debugger listening"
          }
        },
      }
    ]
  }

[David-Else]

@connor4312 Thanks for the additional help, but I get the following error with your task:

Error: the description can't be converted into a problem matcher:
{
    "background": {
        "activeOnStart": true,
        "beginsPattern": "Debugger listening"
    }
}

Deno runs OK:

> Executing task: deno run --inspect-brk -A mod.ts <

Debugger listening on ws://127.0.0.1:9229/ws/89e852ba-3c5e-4db7-8da7-aed56cab359a

And here is the exact code I copied from yours, just changing the file name and adding -A for deno permissions:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "run my program",
      "type": "shell",
      "command": "deno run --inspect-brk -A mod.ts", // your program args
      "isBackground": true, // don't wait for the task to end before debugging
      "problemMatcher": {
        // tells vscode to wait for this line before debugging
        "background": {
          "activeOnStart": true,
          "beginsPattern": "Debugger listening"
        }
      }
    }
  ]
}

[brandonkal]

@David-Else did you try just the first option? That worked for me

Set debug.javascript.usePreview to false in your user settings to use the old debugger for now

[David-Else]

@brandonkal It works!!! Finally after all this time I can now debug deno, thanks!

(note: just use official settings https://deno.land/manual/tools/debugger#vscode and the old debugger in VS Code 1.47)

[connor4312]

Hi all, I've added 'official' support for this in js-debug now. See microsoft/vscode-js-debug@540fbca for details and reasoning, the tl;dr is that (if you'd like to continue using the new debugger, which I'd encourage 🙂 ) you need to do two things:

1. Grab the nightly js-debug extension (will be available shortly after 5PM PST today)
2. Change the port property in your launch.json to attachSimplePort and type to pwa-node (to go directly to our new debugger and get the new config option)

Update: following a separate issue, I've also added the ability to set attachSimplePort: 0. If you do this, js-debug will pick a random free port on your machine and append the appropriate --inspect-brk flag to the runtimeArguments automatically. Less configuration for you 🙂

Then it should work. This change will land in the next VS Code stable release, at which point you will no longer need to be on the nightly extension build. I will PR to the deno docs to update this)

[towelong]

Your server does not do any put REST commands which is where I was seeing the problem. I forked your repository and created: mret https://github.com/mwoodpatrick/deno-server There is a v3 controller which has a post endpoint to add another dog the promise I get from the post is not resolved for me. Can you get post requests to work for you?
…
On Sat, Jul 18, 2020 at 7:19 PM ToWeLong @.***> wrote: I'm have Deno running on Ubuntu with latest version of Visual Studio Code - Insiders with JavaScript Debugger (Nightly) Version: 2020.7.1717 running on Ubuntu 20.04 LTS running inside WSL-2. With the above launch.json I am able to launch & debug my simple REST api. I'm using Oak and in the POST handler below the value of the body is a promise with state 'pending' despite the await. Any suggestion as to what the problem is or best way to debug this? export const addDog = async ({ request, response, }: { request: any; response: any; }) => { const body = await request.body(); const dog: Dog = body.value; dogs.push(dog); console.log(Adding ${dog.name}); response.body = { msg: "OK" }; response.status = 200; }; Also if I restart the debug session I get the error: /home/mwoodpatrick/.deno/bin/deno run --inspect-brk -A /mnt/c/Users/mlwp/projects/deno/api.ts Debugger listening on ws://127.0.0.1:9229/ws/f3688378-63d8-4d5f-b7f2-ddc24719dfb0 �[38;5;10mCheck file:///mnt/c/Users/mlwp/projects/deno/api.ts Debugger session started. thread 'main' panicked at 'already borrowed: BorrowMutError', /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4/src/libcore/cell.rs:878:9 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace fatal runtime error: failed to initiate panic, error 5 Any suggestions on how to debug you can see my repository,deno_server ToWeLong/deno-server https://github.com/ToWeLong/deno-server — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ6SQUT3OL7RMNTZF2JT2TR4JJZPANCNFSM4M62RWTQ .
-- Mark Wood-Patrick

POST:

PUT:

Whether it is a post or put request, I can receive the information in the body

[mwoodpatrick]

I'm having a problem stepping into library code e.g. Oak next function vscode tells me "Unable to retrieve source contents" also I'm seeing a problem going to source code definitions. vscode displays the IntelliSense but when I select got definition vscode reports it can't find the definition of function (e.g. validateJwt).

I'm using deno 1.2.0.

Library is imported in a deps.ts file:

export { makeJwt } from "https://deno.land/x/djwt@v1.2/create.ts";

export {
validateJwt,
Jose,
Payload,
} from "https://deno.land/x/djwt@v1.2/validate.ts";

Then included into the code using

import { Status, validateJwt } from "../deps.ts";

Any suggestions as to what the issue is or best way to debug.

see:

https://discordapp.com/channels/684898665143206084/689420767620104201/739903606978904196

[yubaoquan]

@connor4312
I installed nightly js-debug, and change debug config to

{
    "type": "pwa-node",
    "request": "launch",
    "name": "Deno",
    "runtimeExecutable": "deno",
    "runtimeArgs": ["run", "-A", "index.ts"],
    "cwd": "${workspaceFolder}/leetcode/ts",
    "outputCapture": "std",
    "attachSimplePort": 0
  },

and then got error:

[Window Title]
Visual Studio Code

[Content]
Error processing launch: Error: Could not connect to debug target at http://127.0.0.1:44740: Promise was canceled
    at Object.e [as retryGetWSEndpoint] (c:\Users\xxx\.vscode\extensions\ms-vscode.js-debug-nightly-2020.8.517\src\extension.js:1:92977)
    at processTicksAndRejections (internal/process/task_queues.js:85:5)

[Open launch.json] [Cancel]

But if I change attachSimplePort from 0 to 9229, and add --inspect-brk to runtimeArgs, it will run well.

[newtack]

I successfully used code-insiders to debug Deno.

It probably should also work with the just released 1.48.

I use a config like this:

{
// 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": [

{
"name": "Deno Debug Example",
"type": "pwa-node",
"request": "launch",
"cwd": "./scripts",
"runtimeExecutable": "deno",
"runtimeArgs": ["run", "--inspect-brk", "-A", "--unstable", "--importmap", "import_map.json", "debug.ts"],
"attachSimplePort": 9229
}
]
}

[bela53]

Whenever I debug a project now, a file _constants.ts is opened in VS code with following content:

Could not load source 'proj/std@0.63.0/path/https:/deno.land/std@0.63.0/path/_constants.ts': Unable to retrieve source content.

I can close that file and resume debugging, though it gets cumbersome. The .js file to be debugged contains:

import * as path from "https://deno.land/std@0.63.0/path/mod.ts";
// ...

launch.json debug config:

    {
      "name": "Deno",
      "type": "pwa-node",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "run",
        "--inspect-brk",
        "-A",
        "main.js"
      ],
      "outputCapture": "std",
      "attachSimplePort": 9229,
    }

Also tried resolveSourceMapLocations without success.

 "resolveSourceMapLocations": [ "${workspaceFolder}/**",  "!**/node_modules/**" ]

Does anybody experience similar issues? What could be the cause? (VS Code 1.48, vs-deno 2.0.15)

[kryptish]

I got this up and running witout big issues, but pretty new to vscode debugger, so my question might be dumb =): Is it somehow possible to interact with the running code trough the debugger? E.g. is it somehow possible to inspect a variable at runtime with console.log(yourvar) somehow? like an interactive mode? And I don't want to set a breakpoint, the program should just continue to run but when I "wish" I'd like to inspect some stuff...

[connor4312]

@kryptish you might like logpoints https://code.visualstudio.com/docs/editor/debugging#_logpoints

[yubaoquan]

If I change --inspect-brk to --inspect, vscode will report an error. It is an error? @connor4312

[Window Title]
Visual Studio Code

[Content]
Error processing launch: Error: Could not connect to debug target at http://127.0.0.1:9229: Promise was canceled
    at Object.e [as retryGetWSEndpoint] (c:\Users\111\.vscode\extensions\ms-vscode.js-debug-nightly-2020.9.1917\src\extension.js:15:2455839)
    at processTicksAndRejections (internal/process/task_queues.js:94:5)
    at t (c:\Users\111\.vscode\extensions\ms-vscode.js-debug-nightly-2020.9.1917\src\extension.js:73:54237)
    at S.launch (c:\Users\111\.vscode\extensions\ms-vscode.js-debug-nightly-2020.9.1917\src\extension.js:15:2477504)
    at t.Binder.captureLaunch (c:\Users\111\.vscode\extensions\ms-vscode.js-debug-nightly-2020.9.1917\src\extension.js:73:115308)
    at t.Binder._launch (c:\Users\111\.vscode\extensions\ms-vscode.js-debug-nightly-2020.9.1917\src\extension.js:73:114859)
    at async Promise.all (index 3)
    at t.Binder._boot (c:\Users\111\.vscode\extensions\ms-vscode.js-debug-nightly-2020.9.1917\src\extension.js:73:114119)
    at t.default._onMessage (c:\Users\111\.vscode\extensions\ms-vscode.js-debug-nightly-2020.9.1917\src\extension.js:15:2463780)

[Open launch.json] [Cancel]

[connor4312]

It means your program is not listening on that port, or if it is we couldn't connect to it.

[yubaoquan]

It means your program is not listening on that port, or if it is we couldn't connect to it.

So the conclusion is if change --inspect-brk to --inspect, then debug extension will not be able to connect to the port?
Is it because deno ignores the '--inspect' or some other bug in debug extension?
@connor4312

[YuriyTigiev]

How to set ENV="development" for debugging?

[ghost]

@YuriyTigiev There are env and envFile config entries in launch.json under configurations, which can be used to set environment variables.

[TinyZzh]

vs code can not debug deno

[jsejcksn]

@bela53 I am experiencing a very similar message:

Could not load source '/path/to/workspace/std@0.79.0/_util/os.ts': Unable to retrieve source content.

☝️ This is always a reference to a remote module.

And I get a VS Code notification in the bottom right that reads:

This is a missing file path referenced by a sourcemap. Would you like to debug the compiled version instead?

with the options

• Always
• Always in this Workspace
• No
• Yes

It seems that I can just click the Continue button (looks like a play button or triangle) and the debug will continue to my first breakpoint successfully.

If it's helpful, this is my launch.json:

{
  // 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": [
    {
      "name": "Launch Deno",
      "request": "launch",
      "type": "pwa-node",
      "program": "${file}",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "run",
        "--inspect-brk",
        "--allow-all"
      ],
      "attachSimplePort": 9229
    }
  ]
}

I'm not sure what is causing this problem.

@bartlomieju Do you have any insight?

[benediktwerner]

I just set up debugging with deno in VS Code and in general it works well but when I want it to output everything to the console I always get an error message "The terminal process terminated with exit code: 1".

At first glance the issue seems to be that deno is exiting too quickly. If I try it with node it outputs "Waiting for the debugger to disconnect..." after the program terminated and only exits when I end the debugging but deno closes immediately. When I then press terminate in the debugging interface I get the aforementioned error.

Here's the configuration I am using:

{
      "name": "Deno: Debug",
      "request": "launch",
      "type": "pwa-node",
      "program": "${file}",
      "cwd": "${fileDirname}",
      "runtimeExecutable": "deno",
      "runtimeArgs": ["run", "--unstable", "--inspect-brk", "--allow-all"],
      "console": "integratedTerminal"    // <--- This is the problematic line
}

[drcallaway]

It looks like a debugger regression was introduced in v1.6.2. I can debug from VS Code fine with v1.6.1 and earlier using a configuration like this:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Deno",
      "type": "pwa-node",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "program": "${file}",
      "runtimeArgs": [
        "run",
        "--inspect-brk",
        "--allow-all"
      ],
      "outputCapture": "std",
      "attachSimplePort": 9229
    }
  ]
}

However, upgrading to v1.6.2 results in this error when trying to connect the debugger:

Error processing launch: Error: Could not connect to debug target at http://127.0.0.1:9229: Promise was canceled

A temporary fix is to just roll back to the last working version:

deno upgrade --version 1.6.1

[lucacasonato]

@drcallaway Could you open an issue on the denoland/deno repo?

[kitsonk]

This is a long thread that is unactionable as it stands at the moment. Closing.

If anyone has specific issues with debug or debug support, best to open a new issue.

[jsejcksn]

This is a long thread that is unactionable as it stands at the moment. Closing.

@kitsonk I have seen other posts closed with this kind of sentiment. Perhaps it would help to provide actionable criteria in new issue templates so that everyone affected and participating can subscribe to issues with confidence that they'll not be closed without resolution.

[kitsonk]

@jsejcksn can you please indicate what is not resolved with this issue?

The issues states:

I noticed if I hit F5 to run & debug it doesn't work. What's the status and upstream work to be done for this feature?

That feature is/has been available for a long time. Is that not working for you?

[jsejcksn]

@kitsonk Certainly; no problem.

It is still not working for me. I am still experiencing the same result as in my previous comment: #12 (comment)

Here is some additional information:

When I have no .vscode/launch.json config and simply press F5 (run the debugger), I am presented with a list of choices. I choose the one named "Deno: Run". After waiting several seconds, I receive this error dialog:

If I then create a custom launch config file, I can get further in the debug process, but only to the point described in my previous comment.

For comparison, here are multiple debug configs, commented to explain their sources:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Deno (from extension)", // generated by using "Add configuration... > Deno: Run"
      "type": "pwa-node",
      "request": "launch",
      "program": "${workspaceFolder}/main.ts", // it seems "main.ts" is assumed, but the file might not exist
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "run",
        "--inspect=127.0.0.1:9229",
        "--allow-all" // unsafe default
      ],
      "attachSimplePort": 9229
    },
    {
      "name": "Deno (from manual)", // from https://deno.land/manual@v1.8.3/getting_started/debugging_your_code#vscode
      "type": "pwa-node",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": ["run", "--inspect-brk", "-A", "${file}"], // unsafe default permissions
      "attachSimplePort": 9229
    },
    {
      "name": "Deno (custom)", // manually created
      "type": "pwa-node",
      "request": "launch",
      "program": "${file}",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "run",
        "--inspect-brk"
      ],
      "attachSimplePort": 9229
    }
  ]
}

I ran this test again today on WSL, but haven't tested again on macOS yet.

Here is a zip file containing the workspace folder used when I did this test before posting this comment:

debug-example.zip

Env:

$ deno --version
deno 1.8.3 (release, x86_64-unknown-linux-gnu)
v8 9.0.257.3
typescript 4.2.2

$ code --version
1.55.0
c185983a683d14c396952dd432459097bc7f757f
x64

$ code --list-extensions --show-versions | grep "deno"
denoland.vscode-deno@3.2.0

[kitsonk]

When an issue, which asked for a feature to be implemented, is implemented, the issue should have been closed at that point. It wasn't. This issue has around 30 comments, all over the place, for specific and non-specific problems. That is what makes an issue unactionable.

I have moved your example to a specific new issue.

[kjhughes]

Any cleanup of this issue's thread ought to update Deno Manual's documentation of Tools > Debugger > VSCode, which points to this issue as covering current status of the VSCode plugin. Might be a good idea to update the Limitations section and link it to any major individual issues if this current monolithic, catch-all issue is dead.