Turbo sourcemaps not hitting TS breakpoints in imported modules

[MattReimer]

I believe this issue is in relation to the new debugger optimizations in patch 1.75 last week

When the patch hit last week we were unable to put breakpoints into '*.ts' files in imported modules and have them hit. We're running a lerna monorepo if that's useful.

• Breakpoints on the '*.ts' files in the package we execute the code did work.
• Breakpoints on the '*.js' files in our /dist/ folders for both the original package and the imported ones did hit correctly.
• Breakpoints on any '*.ts' files from imported modules did not fire.
• Adding "enableTurboSourcemaps": false to our launch.json file fixes the issue

I'm not sure what would be helpful to debug this but here is my profile from launch.json

    {
      "name": "🚀 GQL Lambda API: (RUN)",
      "type": "node",
      "request": "launch",
      "runtimeArgs": [
        "-r",
        "ts-node/register"
      ],
      "cwd": "${workspaceRoot}",
      "console": "integratedTerminal",
      "program": "${workspaceFolder}/src/servers.ts",
      "sourceMaps": true,
      "enableTurboSourcemaps": false, // this fixed the issue
      "envFile": "${workspaceFolder}/../../.env.local.${input:environment}",
      "outFiles": [
        "${workspaceFolder}/../dist/**/*.js",
        "!**/node_modules/**"
      ],
    },

This worked flawlessly until VSCode updated last week. The note in the changelog said enableTurboSourcemaps will eventually be depprecated so obviously we'd like to see some kind of resolution to the issue before that happens.

[segevfiner]

I'm hitting something similar, in a debug configuration that debugs a VS Code extension built with webpack, and recursively attaches to a node process that the extension starts, and is built with tsup/esbuild, the breakpoints are no longer hit after the update, even with "enableTurboSourcemaps": false, as I'm not sure it is applied correctly to the attached debugger.

Sadly the code is proprietary but here is a debug log: vscode-debugadapter-e8aac7a4.json.gz, though I'm not sure it will help. The breakpoint in some TS file imported and bundled into app.js is not hit.

[segevfiner]

MWE/reproduction: https://github.com/segevfiner/vscode-js-debug-bug

Try breaking in app.ts (Code in the server)

[MattReimer]

Here's another interesting datapoint:

It seems like when there's a double ** in my output files in launch.json it won't work.

So this doesn't work:

      "outFiles": [
        "${workspaceFolder}/../**/dist/**/*.js",
        "!**/node_modules/**"
      ],

But this DOES work.

      "outFiles": [
        "${workspaceFolder}/../lambda-api/dist/**/*.js",
        "!**/node_modules/**"
      ],

I wonder if **/something/** is forbidden or something

[SaschaAusUlm]

After reading this (and after spending the afternoon trying to find the cause) I can now again debug into my Vue2 + Typescript application after rolling back VS Code to 1.74.0.
Setting a breakpoint in 1.75.1 seemed to ignore the generated source maps and just showed "app.js" in "Breakpoints". Setting a breakpoint as before directly in my TS file was impossible. When I started to debug, the breakpoint disappeared and the "app.js" entry in "Breakpoints" showed up.

[segevfiner]

@connor4312 Did you get a chance to try my reproduction?

[connor4312]

@segevfiner thanks for the repro. The issue you're hitting is specific to extension host debugging, and I'm not sure why it would have worked before. But that'll be fixed in the next nightly build.

@MattReimer I'm not able to repro the issue with multiple glob stars in isolation.

For others, please provide either similar repros, or log files using the instructions given in the "bug" issue template:

If you're able to, add "trace": true to your launch.json and reproduce the issue. The location of the log file on your disk will be written to the Debug Console. Share that with us.

⚠️ This log file will not contain source code, but will contain file paths. You can drop it into https://microsoft.github.io/vscode-pwa-analyzer/index.html to see what it contains. If you'd rather not share the log publicly, you can email it to [email protected]

[segevfiner]

Argh. Built the nightly myself from commit 8d34776 and I was able to get it to debug the reproduction, but not the proprietery code I tried to debug, the "Debug Diagnostics" seems to say that app.js.map for app.js is not loaded for some reason, so any breakpoints in files bundled into it don't work, here is a log: vscode-debugadapter-d4acb6f6.json.gz vscode-debugadapter-13a567dc.json.gz where I can see the "sourceMapUrl" for app.js, but no "Creating sources from source map" for its source map. (The source map is there on disk right next to the file)

[connor4312]

Thanks for the log, that actually is an issue that regressed last month 😄

[segevfiner]

@connor4312 Tried with latest main and it worked now.

[SaschaAusUlm]

Sorry ... out of curiosity ... milestone 2 .... which release will that be?

[connor4312]

This was released in VS Code 1.76

[SaschaAusUlm]

... because I am on 1.76.1 and I still see the issue ...

[connor4312]

You probably have a different issue then. Please collect a trace log using the instructions I shared above and I can look into it.

[SaschaAusUlm]

Sent an email ...

[connor4312]

I don't seem to have received anything, can you double check that it went through?

[SaschaAusUlm]

Will send it again from my private mail account .... give me a minute ....

[SaschaAusUlm]

Hope it arrived?

[connor4312]

I didn't get anything. You may also try my personal email [email protected] if the work email is not getting through for some reason...

[SaschaAusUlm]

Oh boy, tried what you said. If it still doesn't go through, I will send you a OneDrive share link.

[SaschaAusUlm]

Did it work?