I would suggest to abandon console.log and adopt infinitedg:winston
It’s a multi-trasport async log library (console, AirBrake, database and Loggly) that allows you to gather all your log traces on the server.
I don’t have a clear answer to your question though. Honestly I don’t see many other ways to understand if something is not working in production other then logging and profiling your app.
@massimosgrelli you are right that there are many good ways, but for a third party dev who knows nothing about your library the chrome console is a life saver.
@muaddib sure. winston library is exactly this but you avoid to refactor your code 3 months for now to adopt a more structure approach.
In my case I’m using wiston library to write logs on the console and the only think I need to do was:
a. meteor add infinitedg:winston
b. create one logger object for the server and one for the client
Seriosly, though, please don’t. I hate it when packages clutter my browser console or the server logs.
If the log item is a serious piece of information that needs to get recorded, perhaps for identifying problems later, and that it happens only once in a while, maybe it can be acceptable. Otherwise it is just noise. Especially in the browser. In fact I kind of consider a security threat due to its revealing nature.
You can perhaps make it opt-in. Allow your package to accept a configuration paramater that turns logging on/of, better yet separately for the server and the client.
I wish meteor had a defacto logging framework into which packages could individually register their namespaces with and the app developer themselves could configure what gets to be displayed, what gets to be diverted elsewhere etc.
If it’s a 3rd party package I would recommend looking for a global variable like __mything_debug__ === true and then spew out all the logs with console.log. I normally use a simple log function at the bottom of the page to abstract it away in case I need to use more intense logging like Winston later. This log fn can also check for the debug which keeps your code clean.
Maybe the package should be done as a wrapper of winston logger. In this way you could get a seamless integration with packages like loggly ─ or MongoDB ─ that you might want to use once in production.