How do you debug your apps and Blaze templates in particular?


Struggling newb here would like to know how you vets debug your meteor apps?

WebStorm seemed to provide the most extensive support but there this issue that even on toy examples the debugger stops on lines that are different from those were breakpoints are inserted (which is a killer IMHO). It is almost one year old and seems to resurface after each fix with the release of every new Meteor version.

AFAIK VSCode does not feature a Meteor debugger extension, but only a Node debugger and a Chrome debugger. Which one to use for the isomorphic code that Meteor runs on both the client and the server?

If I understood well, the philosophy of Atom is that there should be no debugger with breakpoints, watches, variables, call stack and the like because this is what IDE provides and apparently thought of being somehow undesirable. I guess this is for people who feel more productive writing and commenting in and out console.log statements rather than just clicking on a pair of button.

For all options above, the more puzzling part for me is how to debug blaze templates in jade (using mquandalle package) or spacebar. Neither Webstorm nor VSCode seems to accept putting breakpoints in template files and neither these template languages support console log function calls AFAIK, so even this rawest debugging fallback approach seems unavailable.

The only option I could think of was to put breakpoints or console.log function calls inside the app.js file generated by meteor, which IMHO is kind of reverting to programming directly using DOM functions, i.e., defeating the purpose of having a nice declarative template language integrated in a powerful framework abstracting from all that.

Any hint, advice, recommendations or lessons learned much much welcome (other than smug sweeping statements like “real programmers don’t need productivity tools, Vim and Linux is enough” that is)!

Thanks very much in advance.

Meteor Toys and Constellation both have template inspectors that have greatly decreased the number of console.log( ... ) statements I’ve needed to use when debugging.

1 Like