Stack Trace shows localhost in links

[s4m0r4m4]

I'm seeing a similar issue as #6, #198, and #212. My setup:

• VS code v1.43.0
• Chrome: 78.0.3904.130
• Node.js: 12.8.1
• V8: 7.8.279.23-electron.0
• OS: Windows_NT x64 10.0.14393
• Debugger for Chrome: 4.12.6

Steps to Reproduce:

• I created a new angular 9 project using ng new
• I added the following launch.json and tasks.json files to my project
• I run the "ng serve" debug configuration, everything works fine and I can hit breakpoints no problem
• When I introduce a simple error in the code, it throws an error with a stack trace
• In the chrome inspection tools, the stack trace is rendered just fine with paths & links back through webpack to the associated source code. Clicking on those links opens the correct file/line.
• In VS Code, the stack trace is rendered with links to files on localhost:4200/... (see attached screenshot)

Here is my launch.json configuration:

{
    "name": "ng serve",
    "type": "chrome",
    "request": "launch",
    "preLaunchTask": "npm: start",
    "url": "http://localhost:4200/#",
    "webRoot": "${workspaceFolder}",
    "sourceMapPathOverrides": {
        "webpack:/*": "${webRoot}/*",
        "/./*": "${webRoot}/*",
        "/src/*": "${webRoot}/*",
        "/*": "*",
        "/./~/*": "${webRoot}/node_modules/*"
    }
}

From the issues mentioned above, it sounded like this was fixed and shouldn't be happening anymore, I believe I'm on the latest projects. Please let me know if I can provide any further information!

[roblourens]

I can't repro this, but could you try with our new JS debugger to see whether it reproes there? https://code.visualstudio.com/updates/v1_43#_new-javascript-debugger

[s4m0r4m4]

Thanks for the reply. I tried changing to the new JS debugger by installing the Nightly build extension and setting "debug.javascript.usePreview": true in settings.json. Unfortunately, even with the new debugger the error is still being rendered without successfully mapping the stack trace to the source files:

Interestingly enough, when I use the new debugger, my breakpoints become unbound. When I switch back to the old debugger, they bind again no problem.

I've also attached my tasks.json file for trying to reproduce:

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "npm",
            "script": "start",
            "isBackground": true,
            "presentation": {
                "focus": true,
                "panel": "dedicated"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": {
                "owner": "typescript",
                "source": "ts",
                "applyTo": "closedDocuments",
                "fileLocation": [
                    "relative",
                    "${cwd}"
                ],
                "pattern": "$tsc",
                "background": {
                    "activeOnStart": true,
                    "beginsPattern": {
                        "regexp": "(.*?)"
                    },
                    "endsPattern": {
                        "regexp": "Compiled |Failed to compile."
                    }
                }
            }
        },
    ]
}

and the scripts portion of my package.json:

  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

One final oddity: it prints the error twice in the Debug console (both in my original screenshot and when I tried the new debugger), not sure why.

[roblourens]

Does it work if you remove the /# from the url in your launch config? If not could you set "trace": true in your launch config, try this again, then share the log from the path it prints in the Debug Console?

[s4m0r4m4]

Thanks for the suggestions. I tried removing /# from launch.json url, but the issue still persists. I then set "trace" to true and have attached the file. Thank you again for your help!

vscode-chrome-debug.txt

[roblourens]

Oh, this isn't an error being thrown, it's an error object being printed with console.error or something. The old debug adapter isn't trying to map paths in that case. I don't think it is expected to work in the new debug adapter either. But it would be a good thing to do and, especially since you mentioned your breakpoints not working with the new debug adapter, I would really appreciate you getting a log from a run with the new debug adapter and opening an issue at https://github.com/microsoft/vscode-js-debug

Thanks!

[s4m0r4m4]

Ok I submitted a new issue here: https://github.com/microsoft/vscode-js-debug/issues/401

To follow up on this thread - I think what is happening is that the main angular file (main.ts) creates the application and handles errors by using console.error:

platformBrowserDynamic().bootstrapModule(AppModule)
    .catch(err => console.error(err));

I tried modifying it to log and rethrow the error:

platformBrowserDynamic().bootstrapModule(AppModule)
    .catch((err) => {
        console.log('Console.error output:');
        console.error(err);
        console.log('Throwing error output:');
        throw err;
    });

but the stack trace in VS code is still not rendering stack traces correctly:

Is this still expected behavior?

[s4m0r4m4]

Hi @roblourens, thanks again for your help on this issue. I wanted to follow up - is there something I should do to request this as a feature (i.e. maping paths for console.error) for the old or new debug adapter? Or is the answer that as a design decision the debugger will not map paths for console.error and instead I should change something in my code to avoid console.error and do something else (see my post direclty above for an attempt to simply throw the error, which was not successful in getting the stack to resolve file paths correctly)?

[roblourens]

Yes, you can file a feature request on https://github.com/microsoft/vscode-js-debug. Since it is on its way to becoming the default debug adapter, I am not going to spend much time adding things to this repo.

[s4m0r4m4]

Makes sense, thanks!