17 comments

[ 2.6 ms ] story [ 47.9 ms ] thread
Great points Josh - it's pretty common for new Meteor devs to rely only on console.log - this is a valuable reminder of all the other options for stepping up our debugging game :)
Thanks. I was on the fence about listing testing as another form of debugging. Didn't feel right, but maybe I will write a separate article on that at some point.
Thanks josh! It's always good to remember some of the lesser used functionalities, such as meteor debug.
Huh. Never new about meteor debug. That's pretty awesome.
Thanks. Yeah, always one of those 'wow' moments during my Mastering Meteor class :)
Same here. Though I have a Webstorm license and that has worked quite well for the server side debug. Good to know though that 'meteor debug' exists.
I wonder why meteor debug wasn't advertised more by the core team, it looks like a pretty neat feature. I'm going to give it a whirl!
It is a neat feature. I also hear that it will persist changes from node-inspector web interface back to your code itself... I didn't mention in the article as I didn't have time to confirm it myself.

Yeah, I am thinking of adding a debugging section as a PR to the Meteor docs.

Cool reference guide. The https://github.com/rclai/meteor-ddp-inspector is also helpfull!
My main issue with meteor and debugging is that getting into node-inspector inside of a velocity test is seemingly impossible. Any ideas?
I've been playing with Meteor since 0.5 and only recently discovered the WebStorm IDE. I HIGHLY recommend it even for personal projects. It has built in support for meteor, and gives you a truly powerful debugging environment. You can set breakpoints and examine the state of the app (var values, etc...) while viewing the console within the IDE itself. It also has a Chrome plugin that allows the IDE to launch and debug apps in the browser.

Here's the link to download the 30 day trial: https://www.jetbrains.com/webstorm/

Simple set up instructions: https://www.jetbrains.com/webstorm/help/using-meteor.html