VSCode JavaScript Debugger is not binding breakpoints nor printing console logs

[KinIcy]

Issue Type: Bug

Since the last update where the old debuggers were removed from VS Code, I'm not able to get the new debugger working on my projects. I tried both a JS project and a TS project. The script runs (I'm able to send requests and get responses as usual) but all breakpoints say "unbound breakpoint" and I don't see any of the console logs that should normally be there.
I tried to create a new launch configuration from the templates but I got the same result.

This is the config I'm using for typescript:

"version": "0.2.0",
  "configurations": [
    {
      "name": "Lauch Local Server",
      "type": "node",
      "request": "launch",
      "runtimeExecutable": "node",
      "runtimeArgs": ["--nolazy", "-r", "ts-node/register/transpile-only"],

      "args": ["local/server.ts"],
      
      "cwd": "${workspaceRoot}",
      "internalConsoleOptions": "openOnSessionStart",
      "skipFiles": ["<node_internals>/**", "node_modules/**"]
    },
  ]
}

I also tried to run the debugger with the Run Script option but I get this error message: Configuration 'Run Script: dev' is missing in 'launch.json'.

Before the update, this launch configuration worked without issues if I had the new debugger disabled.

VS Code version: Code 1.60.0 (e7d7e9a, 2021-09-01T10:41:52.311Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No
Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2

System Info

Item	Value
CPUs	AMD Ryzen 7 4800H with Radeon Graphics (16 x 2895)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.42GB (5.27GB free)
Process Argv	--folder-uri vscode-remote://wsl%2Bubuntu/home/kinicy/abo/api --crash-reporter-id 3896dca9-2d59-4930-8d77-77ee16397d02
Screen Reader	no
VM	0%

Item	Value
Remote	WSL: Ubuntu
OS	Linux x64 5.10.16.3-microsoft-standard-WSL2
CPUs	AMD Ryzen 7 4800H with Radeon Graphics (16 x 2894)
Memory (System)	12.02GB (11.42GB free)
VM	0%

Extensions (7)

Extension	Author (truncated)	Version
remote-wsl	ms-	0.58.2
vscode-eslint	dba	2.1.25
gitlens	eam	11.6.0
vscode-graphql	Gra	0.3.18
vscode-docker	ms-	1.16.1
angular-console	nrw	17.10.0
code-spell-checker	str	2.0.4

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspyt653:30270858
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30358480
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805cf:30301675
pythonvspyt200:30340761
vscextlangct:30333562
binariesv615:30325510
vsccppwt:30364497
pythonvssor306:30344512
bridge0708:30335490
pygetstartedt2:30360495
bridge0723:30353136
pythonrunftest32:30364559
pythonf5test824cf:30361778
javagetstartedc:30364665
pythonvspyt187:30362782
pydsgst2:30361792
vscus224cf:30358040
vssid140cf:30363604

[connor4312]

/duplicate microsoft/vscode-js-debug#1100 Please see my comment there for a resolution

[KinIcy]

/duplicate microsoft/vscode-js-debug#1100 Please see my comment there for a resolution

Hello, I just tried the steps in that issue, but it is still not working. Remember this is not specific to ts, because it is also happening in a javascript project.

this is the launch file I use in the js project:

  {
    "name": "Launch Program",
    "program": "${workspaceFolder}/local/server.js",
    "request": "launch",
    "skipFiles": [
      "<node_internals>/**"
    ],
    "type": "pwa-node"
  },

Just tried the nightly build of the debugger but no luck so far.

[connor4312]

/jsDebugLogs

[KinIcy]

vscode-debugadapter-f1af0f8b.json.gz

These are the logs for the js project.

[KinIcy]

I just noticed I have the nightly build enabled, following logs are for the stable extension:

vscode-debugadapter-319c6b79.json.gz

[connor4312]

Thanks for the logs. What happens if you console.log(process.env.NODE_OPTIONS, globalThis.$jsDebugIsRegistered) in your app?

[KinIcy]

Thanks for the logs. What happens if you console.log(process.env.NODE_OPTIONS, globalThis.$jsDebugIsRegistered) in your app?

Funny thing I don't see any logs in the debug console (this is part of the issue), is there any other way to test this?

[KinIcy]

if this is of any use, this is the output when running the app directly from the console.

kinicy@kinicy-a15:~/abo/api$ yarn dev
yarn run v1.22.10
$ node local/server.js
Local server listening at:
  Port: 8000
  Origin: by request
--require /home/kinicy/.vscode-server/data/User/workspaceStorage/f982aa6f5c9357ef20db92e699ca784a/ms-vscode.js-debug/bootloader.js  undefined

JavaScript Debug Terminal

kinicy@kinicy-a15:~/abo/api$ yarn dev
yarn run v1.22.10
$ node local/server.js
Local server listening at:
  Port: 8000
  Origin: by request
--require /home/kinicy/.vscode-server/data/User/workspaceStorage/f982aa6f5c9357ef20db92e699ca784a/ms-vscode.js-debug/bootloader.js --require /home/kinicy/.vscode-server/bin/83bd43bc519d15e50c4272c6cf5c1479df196a4d/extensions/ms-vscode.js-debug/src/bootloader.bundle.js --inspect-publish-uid=http undefined

[LeSphax]

I'm having a similar problem but for me it seems that the debugger is just very slow to start.

I'm running my tests in debug mode with this config

 {
          "name": "Attach to Node tests",
          "type": "node",
          "request": "attach",
          "protocol":"inspector",
          "address": "localhost",
          "port": 9230,
          "localRoot": "${workspaceFolder}",
          "remoteRoot": "${workspaceFolder}",
          "restart": true,
          "timeout": 100000
      },

But my tests usually end before the debugger understand that I have breakpoints set.
Even though I get Debugger attached. in the console right away.

Adding await new Promise(resolve => setTimeout(resolve, 5000)); at the beginning of a test I want to debug fixes the issue. But it's obviously very suboptimal.

EDIT: Actually even 5 seconds isn't always sufficient.

[connor4312]

Slow to start is an entirely separate issue.

Usually this means you have a large workspace and can tune the necessary scanning by configuring your outFiles. Also, when starting tests, you should use --inspect-brk instead of --inspect for them to wait for the debugger to attach before executing. Or just using a launch request instead of an attach request which seems more appropriate here.

[LeSphax]

Ah indeed this worked. I had assumed it was a bug since I didn't have this problem with the previous debugger but I should have digged deeper.

Thanks for the tips !

[KinIcy]

I just updated vscode to version 1.61. Same results. I also tried a fresh vscode install but no luck.

This config from jest site does not work either:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Jest Tests",
      "type": "node",
      "request": "launch",
      "runtimeArgs": [
        "--inspect-brk",
        "${workspaceRoot}/node_modules/.bin/jest",
        "--runInBand"
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "port": 9229
    }
  ]
}

[KinIcy]

I was able to get it working again. Based on microsoft/vscode-js-debug#931 I set the default alias in nvm to the latest node 14 version (14.18.1 in my case) and it worked again after a VSCode reset.

the only issue I have right now is that the debugger is not skipping node_modules files, it is stopping on files in there when I have Caught Exceptions breakpoint enabled.

    {
      "name": "Lauch Local Server",
      "type": "pwa-node",
      "request": "launch",
      "runtimeExecutable": "node",
      "runtimeArgs": [
        "--nolazy",
        "-r",
        "ts-node/register/transpile-only"
      ],
      "args": [
        "local/server.ts"
      ],
      "cwd": "${workspaceRoot}",
      "internalConsoleOptions": "openOnSessionStart",
      "skipFiles": [
        "<node_internals>/**",
        "node_modules/**"
      ]
    }

[connor4312]

Oh, that could cause it. Do you know which Node version you were on before? Node 8 and certain minor 10.x versions have some known issues.

Please grab one more trace for the exception issue if you can 🙂

[KinIcy]

I was using v14.15.5 before but my default alias was pointing to v14, now I set it to 14.18.1.

I just tried to switch back to v14.15.5 and the issue came back. Do you want me to use "trace": true again?

[connor4312]

Hm, thanks. While I can't repro installing the same version of my Windows machine, that would seem to indicate something off in either Node or nvm rather than the debugger. Please let me know if you run into it again.