4 ms·

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

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.