Hacker News new | ask | show | jobs
by bcruddy 3464 days ago
Babel and webpack make debugging with the v8 debugger a nightmare. How do you approach that and avoid using console.log everywhere? console.log can be great and 90% of the time it's enough but for that other 10% I'd rather my debugging observe the execution context instead of being part of it.
4 comments

As long as sourcemaps are setup correctly it's not bad at all.

That being said, setting up sourcemaps correctly can be a bear... But it's taken most of the pain away from our debugging issues.

And if that's not possible, as long as you aren't using some of the "heavy to transpile" features like async/await, looking at the translated code directly (and stepping through it) is generally close enough to get the gist of what's going on.

Edit: the bigger headache for me is code which loses it's full stack-trace, which is becoming more and more common when transpiling async/await for reasons I haven't had time to look into.

In addition to sourcemaps, another option that I've been meaning to try is to skip most of the babel transforms for typical development builds. Chrome has had full ES2015 support for a while now and it looks like it now has async/await on stable, so it's getting to a point where it should be possible to just debug your ES2015/ES2016/whatever code within Chrome without needing source maps.

You'd still need to do some transpiling for imports/exports and JSX, though, depending on what you use. And running different code in development and production has its risks.

(I feel like i'm all over this thread...)

I actually tried this for a bit. I found that it really increased the complexity of the build system for not that much of a gain.

Instead of having a "dev" build and a "prod" build, we needed a "chromeDev", a "otherBrowsersDev", and a "prod" build.

So now you have 3 separate environments for your babel configs which you need to keep in-sync, and you run the risk of the semantics being slightly different natively vs the transpiled version (Which IMO isn't that bad when you go from transpiled->native as the transpiled is normally a subset of the "native" functionality, so you are less likely to hit issues)

I don't have any such issue.

What I've been doing is just writing in ES6 and testing on Chrome, then after its towards V 1.0 I'll add webpack to the staging branch.

Very little work to switch from a bunch of script tags to a bundle towards the end of active development, much faster than bundling every single time I change the code a little bit.

That is, of course, unless I have to compile typescript, then I'll just target ES5 anyways.

We have been using [Bublé](https://buble.surge.sh) as our transpiler, and it's output is extremely readable. Bublé only supports a subset of ES6, but I think that's a worthwhile tradeoff for better debugging. Sourcemaps are nice too, but sometimes you have to go under the covers to find the real problems.
Isn't this what SourceMaps are for?

Edit: What he said /\