I think that we should remove the functionality to local override the log function, here is why.

Writing a web server is, I would guess, one of the more common task for node apps. But there is also a lot of developers, including myself, using node for command line apps. We often rely, as all other unix apps, on pipes to shuffle data around. The unix philosophy is built upon a large collection of small programs, which you pipe data between.

Firstly I think that the decision to switch from stdout to stderr was wrong, and the only benefit I could see was that beginners didn't understand why their log output didn't get piped to the file. I believe that the correct thing would have been to educate the users.

This isn't the end of the world since you can globally override that. It's a bit annoying to have to make sure that debug is the exact first thing that you import, and then immediately switch the output to stderr to make sure that no output gets printed to stdout.

Remember that even one line of text output most likely will corrupt the entire output of your program and make it unreadable by the next program. If your program outputs a tar file which you then pipe to gzip, the output .tar.gz file will be unusable.

What you can't currently do is to make sure that no library that you use doesn't override the log function locally. Then you are stuck with the log inside your data, and the only thing you can do to fix it is to unset the DEBUG env variable as soon as your program starts, making your debugging sessions very annoying.

My suggestion is that we:

• remove the function to override log destination locally
• switch back to use stderr by default
• introduce an easy api to set log destination

e.g. this could be use to select log destination:

var debug = require('debug');

debug.logTo('stdout');
debug.logTo('/var/log/myapp.log');
debug.logTo(function (str) { /* Send to mysql, paper-trail, etc. */ });