Show HN: Debugging Babel and Node done right | Hacker News Reader

Show HN: Debugging Babel and Node done right

22 pointsnullxone10 comments

Requirement: - Excellent feedback during development - Debugging with source maps

Method:

I'm using these scripts in package.json.

  "scripts": {
    "di": "node-inspector -d=7000 -p=8000 --save-live-edit --hidden node_modules/",
    "ds1": "babel ./server -d ./build/server -s -w",
    "ds2": "nodemon --watch ./build/server --delay 100ms --debug=7000 ./build/server/main.js"
  },

Then run "npm run ds1; npm run ds2; npm run di"

Why:

I took some time to put this together, after navigating all the tools out there. I personally find this to be "correct". Thought I'd share.

Did not use: babel-watch, babel-node, forever, etc. I found configurations with those tools to not meet the requirements.

View on HN

A little off topic but I'm curios if most devs use debugging tools? My main debugging tool has been printf and it's stdlib equivalents on other languages for 20 years of coding. I used to do some C# dev and used VS debugger, I feel like it is less efficient than print statements / assertions.

Am I missing out a lot?

I wonder if that's an age thing, I'm 36, I've been programming since I was 7 and seriously since I was 14 (I say seriously since that's when I started doing stuff people would pay for) and I rarely use a debugger.

These days I mostly program in PHP (it's where the money is locally and I actually don't mind the language, it's come along well) and use the excellent FirePHP (it allows you to put fp_log($foo) (fp_log is a wrapper around it I wrote for terseness - it also checks local context so that I don't leak debug stuff out into the wild accidentally) and $foo is then passed to the browser via headers (you need a browser extension to make it work but it integrates into the console) that does for 99% of the debugging I need to do, the 1% is when I fire up XDebug, I like XDebug but I've found over the years that printf debugging solves the vast amount of problems since they nearly always trace back to a faulty assuming about what $foo contains at a given point and it's (at least in interpreted languages) way quicker to just whap a print(foo) etc in there and see.

For me they can serve different purposes. Printing is effective, but I use it mostly when doing pre-emptive things like logging while coding. Or when I need more data in the log, since printing is persisted in the console. That way you can go back and inspect it.

Debugging is when you really want to take your time on each step of the execution and double check each value. It is also great if you quickly need to stop the code at a specific step without having to recompile. And while in the debugger you can also change values, execute code to some degree and so on.

So it just depends on what I want to do.

Debugging can save you time, depending on what you want to do.

When using scripting (js/php) i tend to type a print() with what i want to know and hit F5. But thats not always an option, or practical.

When things get more complex (which to me typically happens in compiled software, say a Windows or Android app or embedded) triggering a breakpoint and stepping through the code works faster than refreshing a page. I would not have to sit though recompiling the program and reproducing the exact same situation before seeing a print() show me something "thats also not it".

In some respects yes.

In my mind the debugger is a last resort tool, when other feedback loops don't provide enough information.

Where it really shines though, is when debugging rather terrible spaghetti like code, where a debugger really helps by allowing you to step through code, and see the whole state change. I guess most cases are in between the ideal and that.

Another nice thing is to be able to set a breakpoint and then actually mess with the variables at that point. That actually tightens the feedback loop because you can test out different states without having to go back, edit, and run the code path again.

In node and browser I mainly use 'console' debugging because of the async mess. Same when I need to know what branches are called etc. On native software I sometimes use breakpoints when stuff crashes. I don't think you miss a lot

This "just works" IME: https://github.com/CrabDude/babel-node-debug

I used that for a while, and it worked for me too, but found that it took a long while to reload the app, and also some time for node-inspector to bring up all the files.

There's babel-watch (https://github.com/kmagiera/babel-watch) that attempts to solve some of that, but I found that support for flags (debug) was limiting.

In the end, I figured why not just put together the fundamental tools. I use tmux and it's really not a problem to run multiple commands. Reloads are very rapid, and I never have to worry about things like flags or any other configuration being passed to the underlying tools, even as the ecosystem continues to evolve.

How often are you reaching for the debugger?

Most of the time I'm just writing tests / code, so spinning up babel-node-debug on the occasions when I'm stumped isn't a major problem.

I concede your point.

I suppose the nice thing here is that we both now have two ways of doing the same thing.

I've explained why I prefer running the underlying tooling; hopefully it will be useful as one of those snippets of internet knowledge.

Independent of debugging, I would contend that this set up is better than running babel-node with something like nodemon, again, because of much better reload times.

Again, thanks for babel-node-debug, I've used it before, and I won't be too surprised if I find myself reaching for it again in the future.

Reply on news.ycombinator.com