Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Make "onboarding" as easy as it is in the Debugger for Chrome #57
This started as a bug report with the title: "Unverified Breakpoing" with webpack's 'eval-source-map' but after lots of time I could resolve the issue and hence renamed it...
I know this is OpenSource and I am grateful for this VSCode plugin. So really, Thank you so much :) Take this like kind of a user feedback.
I do not know if I am too stupid to set up vscode-firefox-debug correctly or if it is really a bug.
Anyway with Chrome and this config it works out-of-the-box:
But with Firefox (Nightly 59) it does not work:
I looked into the log file but could not find an Error regarding the pathMapping. Here's some excerpt from the log:
Damn it, the message shows me the error:
It should be
Now it works. Long story short: I know this is an OpenSource project and I am very thankful for it, really.
In the end I think two things could be better here:
Yeah, I agree that configuring this adapter for webpack projects is error-prone. Since webpack has become so widely used I guess I should include the
Silghtly off-topic: I see that you use
Thanks for considering! Yes, this would be awesome
In the end if the Firefox VSCode Adapter would work with webpack (and the above mentioned starter kits) this would work for 99% of use cases.
Maybe also supporting rollup ootb would be great since it is the second greatest option when it comes to building JS these days, at least when building js libaries: https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c
One idea I'd have is that a typical VSCode notification message on top of VSCode (like when there's a new release or something else) could pop up like
Well, I was looking for a reason why the source mappings did not work and found your comment at #44 (comment) Since I am also using Firefox Nightly and the new Firefox Debugger.html frontend I thought that using
Can't you share/reuse code with Debugger.html on this? Totally agree, that having to maintain your own implementation here is really error-prone. As I see it Debugger.html was really setup to be built in a component based way and I'd guess that there community is really open for something like this.
Thanks for pointing this out, I'll have a look at this (I've heard of rollup but have no experience with it, I'll have to find out what kind of
Concerning your suggestion that the debug adapter should warn the user whenever a source can't be mapped to a local file: the problem is that this situation occurs in many setups even if the
Of course I will still add the
I am using the
For a minimal working example for rollup you could use the repo linked at devtools-html/debugger.html#4799 (comment) (I found a bug for this with the new debugger.html, so rollup is definitely doing something different). OTOH, this is grunt+rollup, so probably not the 99% defaults setup...
Then there's also https://github.com/rollup/rollup-starter-lib and https://github.com/rollup/rollup-starter-app (these are linked from https://rollupjs.org/#quick-start so I guess most developers will use these)