breakpoints in client side javascript not hit in express project

[chris-miner]

Environment (please complete the following information):

• OS (e.g., Windows 10):macOS 12.1
• Extension version (e.g., 1.2.3): v1.4.5

Describe the bug:

I set a break point in a self invoking anonymous function and it was not hit.

Repro steps:

1. use npx express-generator --no-view to create an express static site
2. cd into the new project directory
3. execute npm install
4. launch the express server DEBUG=bug-express:* npm start
5. Generate a launch.json file with the standard launch edge and open dev tools configuration.
6. update configuration url entry to http://localhost:3000/
7. While in the launch.json file add an edge launch configuration and update the url for that too.
8. Add a script block to the projects default index.html file:

   <script>
   (function () {
   console.log("not going to work")
   })()
   </script>

9. set a break point on the console.log line
10. Using your Launch Edge configuration launch edge
11. notice that Edge launches, and the page is displayed. Notice that the console log message appears in the console.

Expected behavior:

I expected my break point would be hit.

Additional context:

If you use npx reload -d public -p 3000 to serve the index page, the break point is also not hit.

Also, if you copy the html and launch.json file to a newly initialized node project npm init -y it also does work.

I was sure I'd seen this actually work before, so I deleted the node package.json file, but that did not help.

Finally, I have noticed that if you launch edge, then bring up the dev tools from the browser and set the break point using those tools (i.e. go into sources, find index.html, set a breakpoint) then the break point is hit and the file is opened in vs code. Oddly the file opened contains only the contents of the script tag, and the rest of the file is empty.

[chris-miner]

I notice in another project I'm using reload as the server, but the index.html file is in the project root. Breakpoints are hit in that case and the expected file is opened in vs code.

If I move the file into a subdirectory (e.g. resources) and restart reload with the -d option the breakpoints are still hit. Sometimes. I just repeated that exercise and it didn't hit the breakpoints. So I guess that is inconclusive.

[chris-miner]

Okay, so one last noticing. In a no-express project served with reload and the index.html file in a subdirectory, the only way I could get break points hit is if if didn't use the -d option to reload, and instead included the full path to the index.html file. So when I go to http://localhost:3000/public/index.html break points are hit. So there is maybe something about the path that edge is using verses where the file is in the project directory?

[chris-miner]

Based on #896 I got the idea to try the headless option on my edge launch config. That didn't help me at all, but it did lead to me changing my "webRoot": "${workspaceFolder}" entry to "webRoot": "${workspaceFolder}/public". And now my breakpoint is hit.

[chris-miner]

I notice that https://docs.microsoft.com/en-us/microsoft-edge/visual-studio-code/microsoft-edge-devtools-extension#automatically-attaching-to-microsoft-edge-and-launching-devtools-in-visual-studio-code makes mention of make sure the variable {workspaceFolder} resolves but doesn't tie that into how debugging would be affected by that detail. Docs for launch.json have this to say about webRoot:

This specifies the workspace absolute path to the webserver root. Used to resolve paths like /app.js to files on disk. Shorthand for a pathMapping for "/"

Still, if this is the make or break for hitting breakpoints, maybe it needs to be better highlighted in the docs somewhere.

[codepo8]

This looks to me more like an issue of JS debug, let's find out more about that. Thanks for bringing it up.