Starting Angular with debugger fails #167353
Comments
|
Same issue on windows 10. |
|
I have the same issue in VS2022 |
|
@ringodotnl Thanks for the work-around, got the debugger working! |
|
Another bug I noticed, if I stop my debug session using @ringodotnl work-around. Chrome shuts down, but ng serve keeps running in the terminal. As a result, I need to add the "Launch Chrome" configuration, switch to it and then press F5 to enter debug mode. The other option is, I stop 'ng serve' in the terminal or kill the terminal and press F5 without adding the "Launch Chrome" confguration. I think this behariour is wrong and needs to be corrected. Here is my launch.json |
Background tasks are made for this purpose: https://code.visualstudio.com/docs/editor/tasks#_background-watching-tasks |
connor4312
added
bug
|
Let me rephrase what I said. I should be able to press "F5" all the time and expect the same behaviour without any surprises to debug angular code. |
|
Thanks for the issue. Can someone who's experiencing this please provide the output of the following three commands? curl -I http://127.0.0.1:4200/vendor.js.map
curl -I http://\[::1\]:4200/vendor.js.map
node -e 'dns.lookup("localhost", console.log)'This is going to be based a bit on your local network, but I can reproduce this by explicitly telling |
|
|
Thanks. It looks like resolution is actually correct in your Node CLI environment. But maybe it does resolve to ipv4 localhost for VS Code, for whatever reason. I will attempt a fix. |
|
Please try out the fix in the next nightly build, available when this comment is 7 hours old. Thanks! |
|
I don't think it's working? just to be sure, do I just create a fresh angular project and then press F5 to run the deugger? or do I still need to create a "Launch Chrome" configuration from the debug panel and then change the port to 4200 and run the debugger? I've tried both with code-insider and it's still broken? |
|
Here is a silent video of me showing the bug: https://www.youtube.com/watch?v=Fy5MLBHVd4s There is also another bug with vscode, halfway through this video vscode get stuck going into debug mode and never gets there or opens the browser. You see me having to close vscode down and re-open it. |
|
Insiders does not matter. You must be using the nightly debugger build using these instructions: https://github.com/microsoft/vscode-js-debug#nightly-extension In the video it doesn't look like you're using that version of the debugger. |
|
The new debugger looks really nice, however I followed the steps and still can't debug an angular application using the new extension. |
|
Also if I use the workaround to add the --host switch to the npm script, the new extension works when:
However vscode insists on showing a greyed out breakpoint, but once the browser opens the breakpoint is hit and turns red. This is super confusing behaviour. |
|
Another observation, when using the workaround: From the basic terminal when I click on a link it will open the default browser which I have set to brave, but debugging will fail to work. From the JS Debug Terminal clicking on a link will open Chrome browser and debugging seem to work, again using the workaround method. |
|
Hello should I open a new bug as this one is closed? |
|
@connor4312 This workaround worked. |
|
@connor4312 Any ETA on when this issue will be fixed to be able to run and debug angular apps as an SWA? |
The workaround stopped working with the recent release of SWA CLI 1.1.0. There is no option left to debug the app and everything has turned into a nightmare to proceed! @connor4312 is there a way to fast-track an emergency release? |
|
Same thing is happening to me. I'm blocked and can't debug Angular |
Debugging with SSLI have to debug with SSL (Because reasons. Mainly OIDC provider refuse to return user with PKCE to http site). And I cant generate myself ssl cert with IP as DNS. Symptoms:Lots and lots of Breakpoints dont want to bind, even with Usage of ssl while debugging: angular.json "projects": {
"my-cool-but-super-secret-project": {
"architect": {
"serve": {
"options": {
"ssl": true,
"sslKey": "../../../../../../certs/domain/localhost.key",
"sslCert": "../../../../../../certs/domain/localhost.crt",
"host": "localhost"
}
}
}
}
}And my curl: My workaround for HTTPS / SSL / TLS:Change "host" to "127.0.0.1" (same as previous workarounds) angular.json {
"projects": {
"my-cool-but-super-secret-project": {
"architect": {
"serve": {
"options": {
"ssl": true,
"sslKey": "../../../../../../certs/domain/localhost.key",
"sslCert": "../../../../../../certs/domain/localhost.crt",
"host": "127.0.0.1"
}
}
}
}
}
}Now, when you try to We can run node with environment variable AFAIK simplest solution is to use npm install cross-env --save-dev
# OR
yarn add cross-env --devThen, I just add new script to "package.json": {
"scripts": {
"start": "cross-env NODE_TLS_REJECT_UNAUTHORIZED=0 ng serve",
"test": "cross-env NODE_TLS_REJECT_UNAUTHORIZED=0 ng test"
},
"devDependencies": {
"cross-env": "^7.0.3"
}
}And I start my serve throught this script: npm run start # Not sure if I wrote this correctly, I am using yarn :)
# OR
yarn startAnd thats it. Breakpoints are bound, debugging work. |
|
Does microsoft/vscode-js-debug#1475 not have an error?
This does not look right... why did this get merged? No wonder, why this is still not working correctly, or am I overlooking something here? |
|
Forcing the dev server to 127.0.0.1 works okey until then, but it's sad. |
|
Just to be clear, I misread that code and @rajinder-yadav (here) probably did, too.
This line in the PR is absolutely correct since it is the fallback code. It already has tried to send the request and failed. This code means "I have already tried IPv6 and now I need to try IPv4" or "I have tried IPv4 already and now I need to try IPv6". The code line on its own is misleading but makes sense in its context. |
|
Question is, if the PR got merged in January, when does hit the VSCode release? |
|
Why are they even trying to resolve the IP? Why not DNS/FQDN? It makes a problem with SSL because (self-signed) certs can't be on IP... 😩 |
|
They ONLY do it for const response = await this.requestHttp(url, options, cancellationToken);
if (response.statusCode === 503 && parsed.hostname === 'localhost') { // <-------------------- HERE
let resolved: LookupAddress;
try {
resolved = await dns.lookup(parsed.hostname);
} catch {
return response;
}
parsed.hostname = resolved.family === 6 ? '127.0.0.1' : '::1';
return this.requestHttp(parsed.toString(), options, cancellationToken);
} |
TIL that assigning an invalid value to `url.hostname` silently fails if invalid. Fixes microsoft/vscode#167353
TIL that assigning an invalid value to `url.hostname` silently fails if invalid. Fixes microsoft/vscode#167353
* fix: sourcemap lookups on ipv6 localhost addresses TIL that assigning an invalid value to `url.hostname` silently fails if invalid. Fixes microsoft/vscode#167353 * fix: debugger failing on Node <=12 Fixes #1624 Updates @vscode/l10n to allow it to be tree-shaken away. Also moves `checkContentHash` that likewise had a dependency on more modern language features. I think webpack was just extra aggressive about tree shaking before and assumed `new Hasher()` was side effect free. Which is was, it's just a big assumption to have made. And when I had updated versions in our pipelines, I accidentally updated the minspec to no longer target Node 8 🤦♂️. Targeting the latest 10 should be good. Node 8 thankfully <0.25% of users nowadays. * keep broken minspec for the moment
* fix: sourcemap lookups on ipv6 localhost addresses TIL that assigning an invalid value to `url.hostname` silently fails if invalid. Fixes microsoft/vscode#167353 * fix: debugger failing on Node <=12 Fixes #1624 Updates @vscode/l10n to allow it to be tree-shaken away. Also moves `checkContentHash` that likewise had a dependency on more modern language features. I think webpack was just extra aggressive about tree shaking before and assumed `new Hasher()` was side effect free. Which is was, it's just a big assumption to have made. And when I had updated versions in our pipelines, I accidentally updated the minspec to no longer target Node 8 🤦♂️. Targeting the latest 10 should be good. Node 8 thankfully <0.25% of users nowadays. * keep broken minspec for the moment
That fixed the issue for a brand-new application, but not for an application already using lazy-loading modules 😢 |
well your module needs to be loaded for the break-point to be triggered, if you got the debugger working. |
roblourens
added
the
author-verification-requested
|
@rajinder-yadav Can you confirm that your issue is resolved in the latest Insiders version of vscode? |
|
@roblourens it is working kind of, when I add the host entry ::1 to the host file. $ ping localhost
PING localhost(ipv6-localhost (::1)) 56 data bytes
64 bytes from ipv6-localhost (::1): icmp_seq=1 ttl=64 time=0.024 msHowever when I refresh or hard-refresh sometimes the breakpoints don't get it, and sometime it will get it. Also I've noticed things run much slower now to the point I wouldn't want to use this debugger. So to check, I commented out host entry ::1 in my hosts file and the debugger works all the time and it really responsive. When I do a refresh the breakpoint gets hit instantly. $ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.162 ms |
Type: Bug
I am unable to get the debugger to connect to angular in debug mode, using angular v15.
I am using opensuse TW with KDE desktop.
In my case the breakpoint becomes disabled (hollow circle with grey outline). The browser opens up and take a long time to show anything. The messages below are dumped in the terminal and the web-page gets displayed with no breakpoint hit.
VS Code version: Code - Insiders 1.72.0-insider (835d39c, 2022-09-28T05:18:50.781Z)
OS version: Linux x64 6.0.8-1-default
Modes:
Sandboxed: Yes
System Info
Operating System: openSUSE Tumbleweed 20221126
KDE Plasma Version: 5.26.3
KDE Frameworks Version: 5.100.0
Qt Version: 5.15.7
Kernel Version: 6.0.8-1-default (64-bit)
Graphics Platform: X11
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7A38
System Version: 8.0
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: disabled_software
video_encode: disabled_software
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off
Extensions (64)
(8 theme extensions excluded)
A/B Experiments
The text was updated successfully, but these errors were encountered: