Enhance logging support about nodegoat HOT 3 CLOSED

I'm also strongly against this over-engineering proposal. I'll reiterate my points from the email thread so there'd be a central log of the arguments:

Karl Düüna (@DeadAlready) wrote:
I also suggest we refrain from using console.log (seeing as it is also disabled in the jsHint "devel": false, // Allow development statements e.g. console.log();.) and use a logger like bunyan (https://github.com/trentm/node-bunyan) which creates JSON logs and provides a CLI tool for better readability and debugging.

And again — which problem of console.log is Bunyan solving? Console.log statements are a marvelously simple solution as a lot of init daemons (like Upstart) already log stdout output to a text files. If you want JSON, just print objects.

If we precisely require remote logging, then I strongly suggest keeping away from all "fancy" logger reinventions and just send plain text to Syslog. There are bigger benefits in trusting the work of Unix neckbeards than brogammers. ;-)

Karl Düüna (@DeadAlready) wrote:
Logging - again console.log is sufficient if the project stays simple.

Then we're in agreement again. Until a problem becomes a problem, let's not solve it.

Karl Düüna (@DeadAlready) wrote:
I suggested bunyan because it allows easy separation of logging based on files and/or modules and/or sessions and/or log level(by creating child loggers and using different log levels) and the CLI tool provides easy filtering for logged values. Something I find useful both in development and production environments to better track down the problem part or user specific behaviour.
Those can of course be also achieved with console.log and grep if you repeatedly remember log everything in the right manner. And is of course not necessary just helpful. But if the projects aim is (besides the vulnerabilities that are to be introduced) to be an example then proper logging is a must in my opinion.

We'll first have to decide what is proper logging. Proper logging is also a different question from "proper" library. No library helps you if you don't know what you're doing. And until you have a need to log more than mere requests, it's counter-productive to think about logging libraries. But I understand it's in human nature — there are countless people buying running shoes and camera lenses that never take a hike nor a picture. ;-)

Logging libraries that are bundled with their own CLI tools are already doing a lousy design decision on their part. Printing stuff out in a standardized format and filtering data are two different responsibilities.

Fortunately this app is running on Heroku which comes with its own request logging. ;)

from nodegoat.

OK. Lets stick with console.log() for now. Moving issue to milestone 3 to review again after getting better idea of actual project needs.

from nodegoat.

Closed for version 1.0.0

from nodegoat.