Setup a Winston logger for grunt runtime. Winston is "a multi-transport async logging library for node.js."
This plugin requires Grunt
If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:
npm install grunt-winston --save-dev
Configure one or more winston logger, the minimal config would be:
config hash will be passed in directly when calling the
winston.Logger constructor. Typical options would be
transports (https://github.com/flatiron/winston/blob/master/docs/transports.md) and
levels (https://github.com/flatiron/winston#logging-levels). Read the docs on https://github.com/flatiron/winston for more details
Noted: for transport, this plugin takes a hash of configurations for different transport setups, with the keys being the name of one of the default transports provided by winston. (e.g. if you want to use winston.transports.File, the key would be 'File'). If you want to use custom transports (e.g. 'winston-loggly'), you would have to do it in the 'hooks' as described below.
Winston provide a set of APIs for finer-grain controll over the logger instance. grunt-winston provide
hooks for your convenience to add such kind of controlls. You may provide a function (or an array of functions), with each takes a single parameter
logger that represents the instance of logger for the current grunt task.
It would not be useful if you define a logger and not use it anywhere, so the idea of this
defineLogger is for you to set the logger to the context of your own. Usually in a grunt runtime, it maybe useful to set the logger on the
global object so from any module you may just do
logger.log() as if the logger is defined locally. (For this matter,
defineLogger is by default setting
global object, so you don't have to set this yourself).
A less common use case would be place the logger directly on
Object.prototype (much like how should.js is done). Please be warned that when you do so, you actually DID extended the Object.prototype and in many cases this is something to avoid. But if it does fit your case, doing so allows you call
logger.log and any object, without having to set the property. (e.g.
myClass.logger.log(...)). You can do it like so:
It is totally optionaly to call your logger
logger, feel free to provide your own
defineLogger function to name it your way.
Copyright (c) 2013 Brian Lai Licensed under the MIT license.
v0.2.0fixed transport config bug