
Show HN: Debugging Babel and Node done right - nullxone
Requirement:
- Excellent feedback during development
- Debugging with source maps<p>Method:<p>I&#x27;m using these scripts in package.json.<p><pre><code>  &quot;scripts&quot;: {
    &quot;di&quot;: &quot;node-inspector -d=7000 -p=8000 --save-live-edit --hidden node_modules&#x2F;&quot;,
    &quot;ds1&quot;: &quot;babel .&#x2F;server -d .&#x2F;build&#x2F;server -s -w&quot;,
    &quot;ds2&quot;: &quot;nodemon --watch .&#x2F;build&#x2F;server --delay 100ms --debug=7000 .&#x2F;build&#x2F;server&#x2F;main.js&quot;
  },
</code></pre>
Then run &quot;npm run ds1; npm run ds2; npm run di&quot;<p>Why:<p>I took some time to put this together, after navigating all the tools out there. I personally find this to be &quot;correct&quot;. Thought I&#x27;d share.<p>Did not use: babel-watch, babel-node, forever, etc. I found configurations with those tools to not meet the requirements.
======
eknkc
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?

~~~
noir_lord
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.

------
glenjamin
This "just works" IME: [https://github.com/CrabDude/babel-node-
debug](https://github.com/CrabDude/babel-node-debug)

~~~
nullxone
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
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
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.

