4 ms·

Show HN: Debugging Babel and Node done right

22 points by nullxone 10y ago

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.

glenjamin 10y ago
This "just works" IME: https://github.com/CrabDude/babel-node-debug https://github.com/CrabDude/babel-node-debug
- nullxone 10y ago
  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 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.
  - glenjamin 10y ago
    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.
    - nullxone 10y ago
      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.
eknkc 10y ago
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?
- rahkiin 10y ago
  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
- noir_lord 10y ago
  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.
- nullxone 10y ago
  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.

22 points by nullxone 10y ago

glenjamin 10y ago

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

nullxone 10y ago
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 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.
- glenjamin 10y ago
  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.
  - nullxone 10y ago
    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.

eknkc 10y ago

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?

rahkiin 10y ago
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
noir_lord 10y ago
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.
nullxone 10y ago
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.