Groundskeeper - Remove forgotten debug statements from your JS files

We have a global "debug" function that wraps up a bunch of nice features, like safely printing circular objects, "highlighting" certain debug messages, and pretty-printing everything.

On top of that, we have a "show stack" method to print out the stack trace up to that point.

Here it is as a gist: https://gist.github.com/3796687

@richthegeek Probably I didn't understand your comment but.
Are you just stating that you have a nice function, or are you having a trouble using groundskeeper

@couto not "just" that I have a nice function: with proper debugging/logging tools (ie, not relying on raw console.log) you can easily do stuff like filtering what logs you see, or replace the debug/log function with an empty fn for production mode. Thus making a tool like groundskeeper fairly redundant.

@richthegeek those are nice features. You should wrap those in a component and distribute them.
Ultimately they still rely on console.log which breaks older IE's. So you have three options:

a) You overwrite with an empty function.
b) You wrap them in if statements that would evaluate if you are in a production or development environment.
c) You remove them completely.

With empty functions, you loose time calling empty functions... Performance wise, it's usually not significant but sometimes you just can't afford that.

With if statements, you create dead code, and if by accident you make a mistake in the evaluation you might call a console.log and break older IE's

To remove console.log statements entirely, is in my opinion the correct stance in this situation. You don't create dead code, and you don't waste time calling empty functions.

Anyway, every developer has a different workflow. This tool might not fit in your workflow, but it does in mine.

Luckily for all of us, older IE's are losing marketing share, which will render groundskeeper useless along the way and for that... I'm happy.

@couto we are using this function in a Node.js environment, so browser support isn't a consideration; having a debug/log function simply being rewritten to an empty one is the better choice in this case because when something breaks we can just turn the debugging output back on to track it down.

In a browser environment, as you said, console.log breaks IE. By wrapping in a debug/log function you can guard against exceptions by checking for the existence of console.log.