Sp-dev-docs: 馃悶SPFx v1.7.0 generated launch.json breaks VSCode+Chrome Debugging (with workaround)

Created on 27 Nov 2018  路  7Comments  路  Source: SharePoint/sp-dev-docs

Category

  • [ ] Question
  • [ ] Typo
  • [x] Bug
  • [ ] Additional article idea

Expected or Desired Behavior

When following instructions in the docs (Debug SharePoint Framework solutions in Visual Studio Code), debugging projects in VSCode with Chrome should work.

Observed Behavior

Breakpoints aren't hit.

Reason: hint path for sourceMapPathOverrides in launch.config is no longer correct for latest recent SPFx projects (v1.5.* => current [1.7]).

Steps to Reproduce

  • Create new project with SPFx v1.7 with a web part
  • Set a breakpoint on the [..]WebPart.render() method's return .. line
  • Start web server: gulp serve

    NOTE: Can't use gulp serve --nobrowser as the runtime packages aren't added to load the local API server / local workbench. This is a somewhat related, but not directly related issue

  • Close & quit all instances of Chrome

  • Start the debugging process in VSCode
  • Use the opened instance of Chrome, navigate to local workbench, add web part of the page
  • Observe breakpoint not hit

THE FIX: Steps for Workaround

After step 1 above, after creating the project...

  • open config/launch.json
  • Add this line to the sourceMapPathOverrides array:
"webpack:///.././src/*": "${webRoot}/src/*",
  • Continue with step 2 above... except replace the last step: "Observe breakpoint is hit"

Consider removing the other options... not sure if they are still possibilities...

The problem is a change to the project structure in the generated files by the SPFx Yeoman generator change the path where webpack thinks the files are located.

Related issues:

These can be closed when this bug is fixed: #2062, #2267, #2831

generator bug-suspected

Most helpful comment

Why did this get closed? The issue is still present. Even if it was fixed on the pre-release codebase for the next SPFx release, it shouldn't be closed until it's actually released and fixed.

All 7 comments

Thanks.

Why did this get closed? The issue is still present. Even if it was fixed on the pre-release codebase for the next SPFx release, it shouldn't be closed until it's actually released and fixed.

I've the same issue, and even with the workarounds I can't debug... is there any update? it's quite critical, thanks in advance

I had the same issue and this workaround fixed it! Cheers @andrewconnell

@MarianoPrz ... you modified the launch.json config & the breakpoint isn't getting hit? Can you describe exactly what's happening?

I can't debug

Need a bit more info to understand what's not working & what you're doing.

This was fixed in 1.7.1

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues

Was this page helpful?
0 / 5 - 0 ratings