"Unbound Breakpoint" when switching to "debug.node.useV3": true + other issues

[jasonwilliams]

I've had a debugging session with "debug.node.useV3": true both set to on and off, each gives me issues. I've found a couple of bugs, thought it was worth sharing them here.

Desc

When switching to "debug.node.useV3": true the server side debugging no longer works.

Steps to reproduce.

• Clone https://github.com/jasonwilliams/nextjs9-typescript-server-vscode-example
• npm install
• npm run-script dev
• in VSCode "launch server" debugger
• add a breakpoint in server/index.ts (line 12 const expressApp = express())

First issue:
For some reason this breakpoint triggers instantly, even though the server doesn't seem to have restarted. (this could also be a bug)

Second issue:
Now clicking continue seems to kill the debugger. This isn't expected, as the server itself is still running.

Third issue (main issue):

• in .vscode settings.json add "debug.node.useV3": true
• Launch the "launch server" debugging session again
• add a breakpoint in server/index.ts (line 12 const expressApp = express())
  Now you will find that the breakpoints don't work, "Unbound Breakpoint"

Logs

https://gist.github.com/jasonwilliams/3ad5f388e8b81bc0ecb3bf65e40bb6b9 (before nightly debugger was turned on)

https://gist.github.com/jasonwilliams/4a1686af9626d279658cfbcf86455d68 (attempting to set breakpoints with nightly debugger on)

https://gist.github.com/jasonwilliams/0897396a203a53cf5e487564681d1fbe (attempting to set breakpoints with nightly debugger off)

Versions

• Windows 10.0.18363 Build 18363
• VSCode 1.42.0-insider (system setup)
• Javascript Debugger (Nightly) - 2020.1.43263
• Node v13.1.0

[connor4312]

Thanks for the issue and thorough information!

First/Second Issue

The existing (not-V3) debugger doesn't support ts-node. The tricky thing there is that that files get rewritten in-memory, and the debugger doesn't realize that the script we just loaded purportedly at "$folder/server/index.ts" isn't the same index.ts that's on disk. The new debugger fixes this 🙂

Third Issue

This is related to #214 (comment). We added logic in the extension's configuration resolution step that strips these out, but the useV3 setting bypasses this step. To resolve this you can wait until today's nightly, or remove the --inspect flag from your launch args.

[jasonwilliams]

I've just tested this by removing the --inspect flag in launch.json, it starts up for a few seconds then quits. Is this expected?

Edit: Does this need insiders to work?

[connor4312]

You shouldn't need Insiders to work provided js-debug-nightly is installed.

I'm actually having some trouble reproducing the exiting issue, either on the old or the new debugger, on my windows machine. Is there any environment setup you have that might make your version behave differently than mine?

[jasonwilliams]

@connor4312 my bad, i had the server already running, the error was that there's already a server running on that port and i didn't see the error because it closed so quickly!

[jasonwilliams]

Its working as expected now thank you

[connor4312]

no worries, glad you got it working! Let us know if you run into any more problems.