feat: Addition of XHR/feat Breakpoints

[OnesAndZer0s]

[connor4312]

I wonder if we could fold this into the existing Event Listener Breakpoints view to avoid add more UI clutter. Spitballing:

• There should be a special "XHR Breakpoints" category to contain these. The category has an inline + action to add a new breakpoint
• If no XHR breakpoints were set yet, the category has a child item to "Add new breakpoint for URL", which opens a quickpick to add the BP
• Child items have a checkbox to enable/disable as well as an inline X action to remove them

[OnesAndZer0s]

• There should be a special "XHR Breakpoints" category to contain these. The category has an inline + action to add a new breakpoint

I agree, that sounds like a good idea. However, I have some qualms:

• There is a decent change that the "XHR/Fetch Breakpoints" category would get confused with the xhr event breakpoint category.
• I do not know if it is able to add a condition to make a Category with custom buttons within generate-contributions. Maybe something with when?

Otherwise, yeah that does sounds nice.

[connor4312]

Perhaps we call them "URL XHR Breakpoints"?

Maybe something with when?

Indeed, ctrl+f for "If you want to show an action for specific tree items" on https://code.visualstudio.com/api/extension-guides/tree-view#view-actions

[connor4312]

It seems like the package-lock.json was rewritten, probably with a newer version of npm. Can you undo that change? We use Node 18 and its included version of npm in our pipelines.

[connor4312]

If we add parent and checked on the XHRBreakpoint then we can avoid this :)

[OnesAndZer0s]

XHRBreakpoint already has checked. What would be avoiding?

[connor4312]

looking good, a couple last comments

[OnesAndZer0s]

It seems like the package-lock.json was rewritten, probably with a newer version of npm. Can you undo that change? We use Node 18 and its included version of npm in our pipelines.

Fixed.

Is there any other suggestions?