As you probably already know if you follow our community contributors, @msavin has created some great tools to develop and debug a meteor application. Namely, Mongol let you play with the subscriptions and the local database, and the new JetSetter tool let you see and modify session variables. The community has also created some tools for the Blaze rendering engine (for instance to see your original template name or the data context attached to a DOM node).
I feel like adding a package to the application is generally not the good way to use these tools, mostly because
- as you directly includes the debugger tool code in your application, it may have some side effects; more specifically the code is included in development mode but not in production, and we want to limit the risk of a different behavior in development and production;
- we can’t use these tools to debug production applications, and/or third-parties applications; it would be useful to explore the local state (minimongo, publications, sessions, template data context) of any meteor application — and it should be technically feasible.
If a debugger tool logic and UI shouldn’t be include in the debugged application source (as a dependency on a package), it could instead be distributed as an external tool independent of the debugged application.
Is that something that makes sense to others as well? How could we create a federated “Meteor debugger tool” that one could install in its browser?
There are of course some difficulties related to the varieties of incompatible debugger tools APIs (I use Firefox, but I know most of you are using Chrome). There is also some cases when you have to modify the application behavior anyway, but even in this case the UI could still be in the browser development tool. Any thought on this? @msavin?