Real logger about gulp-util

[yocontra]

Progress: https://github.com/gulpjs/gulp-util/tree/descope

[sindresorhus]

Logging levels:

• .log() => stdout
• .error() => stderr
• .verbose() => stdout when --verbose flag is used. Useful for non-essential debugging info

?

[sindresorhus]

I'm also not in love with [gulp] for the output, it looks kinda weird when the brackets are white, but gulp is green. I think we can come up with something more pretty. Also would like a better way to display plugin names. Plugins logging should be prefixed with the plugin name and not [gulp].

[yocontra]

var Logger = require('log-module-thingy');
var logger = Logger('plugin-name or thing-name');

// stdout, always
logger.log('stuff');

// stderr
// error stack will be displayed when --verbose or --verbose <thing-name>
// this will automatically be converted to a PluginError (or BetterError, whatever I end up calling it)
logger.error(new Error('wot'));

// stdout, when --verbose or --verbose <thing-name>
logger.debug('');

--verbose should turn on debugging for everything, or you should be able to specify different things via --verbose thing1 thing2 thing4

[yocontra]

The trickiest thing is figuring out how to keep one logger instance shared between everything so that the CLI can manage it

[sindresorhus]

lgtm

[laurelnaiad]

The subject of suppressing logging for certain plugins didn't really carry over the the previous issue, but +1 for being able to suppress the logging of plugins from one's gulpfile -- more easily than with this technique.

[jasonrhodes]

OK just to get this ball rolling, I threw this together just to start a discussion about what else this logger needs to do or do differently.

var Logger = function (options) {
    this.verbose = options.verbose || false;
    this.prefix = options.prefix || false;
};

Logger.prototype.log = function (message) {

    console.log(this.prepare(message));

};

// warn level method?

Logger.prototype.error = function (error) {

    console.error(this.prepare(error.message));
    if (this.verbose) {
        console.error(error.stack);
    }
};

Logger.prototype.debug = function (message) {

    if (this.verbose) {
        console.log(this.prepare(message));
    }
};

Logger.prototype.prepare = function (message) {

    if (this.prefix) {
        message = [this.prefix, message].join(" ");
    }

    // add timestamp?

    return message;
};

module.exports = Logger;

With the exception of solving the issue of maintaining one instance across all gulp plugins, etc., what else would need to be added or changed about something like this to make it work for what you want here?

[yocontra]

@jasonrhodes Ability to switch out the logger for different transports.

The real issue is not making the logger, but figuring out the best way to make it available to the plugins and maintain a single instance when each could have a different version of the logger as a dependency

[jasonrhodes]

Right, that makes sense. Sorry if this has already been discussed somewhere else, but it seems like the easiest way to do this is to make gulp instantiate a Logger object that all plugins have to use with var log = gulp.Logger()

[laurelnaiad]

If plugins are dealing with it, then either they should get it from gulp-util or it should be given to them as part of their context.

[jasonrhodes]

@stu-salsbury gulp-util is going to be deprecated (gulpjs/gulp#360) but yes, I think plugins could get the logger instance from gulp itself. I think part of the strength of gulp is its ability for "plugins" to just be node functions and modules, so I'm not sure gulp does any "context setting" for them.

[laurelnaiad]

Ah, gotcha -- thanks.

[yocontra]

@jasonrhodes plugins shouldn't have gulp as a dependency.

The way I see this being broken out is in two parts:

1. a module the plugins can use that simply sends messages on the main bus
2. a module that listens to this main bus for messages, then logs them out. this is where you would switch transports/log levels/etc. - this is what the gulp cli would use and the gulp object would expose this
3. the main bus. I think we can possibly use the process object here and we can emit prefixed events to it.

[jasonrhodes]

@contra, so if I understand you correctly, there would be a module like gulp-logger that everyone requires, that provides a function like this:

function log(message, level) {
  process.emit("gulp:log", { message: message, level: level });
}

And then in that module it would just listen and handle:

process.on("gulp:log", function (data) {
  // handle based on level
})

Is this something like what you're thinking? And what exactly do you mean by "switch transports"?

[yocontra]

@jasonrhodes The second part would also be it's own module. Essentially I'm just trying to isolate the "logging" portion into something that will never change so we don't get versioning issues, and then the "log consuming" portion can be less strict and change often

[jasonrhodes]

For the actual log emitting module, how is this for a start?

https://github.com/jasonrhodes/gulp-log-emitter

[yocontra]

@jasonrhodes Yup that looks pretty good. Are you okay with transferring the repo to the gulp org?

[jasonrhodes]

Sure, no problem.

On Wed, Mar 26, 2014 at 2:08 PM, Eric Schoffstall
[email protected]:

@jasonrhodes https://github.com/jasonrhodes Yup that looks pretty good.
Are you okay with transferring the repo to the gulp org?

Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-38719105
.

[laurelnaiad]

In a sophisticated build process, it's really really important to cut the noise in the console. There needs to be a way for gulpfile authors to control logging on a task or line level. Will this be the state of the art?

var cl = console.log;
console.log = function () {
    var args = Array.prototype.slice.call(arguments);
    if (args.length) {
        if (/^\[.*gulp.*\]$/.test(args[0])){
           // you could of course use any RE here
            return;
        }
    }
    return cl.apply(console, args);
};

[yocontra]

@stu-salsbury No, not at all. You will be able to configure gulp.logger (which is listening to the bus for logs) to ignore things, use log-levels, etc.

[jasonrhodes]

@stu-salsbury The new logging strategy will have plugins emit messages that gulp can handle on a case-by-case basis. I imagine it won't be too hard to devise strategies for blocking and/or grouping and delaying whole groups of log messages, or even setting levels ("nothing below 'warn'") from within a gulpfile.

[jasonrhodes]

@contra I'll need admin rights in order to transfer the repo to gulpjs

https://help.github.com/articles/how-to-transfer-a-repository#transferring-from-a-user-to-an-organization

[yocontra]

@jasonrhodes Transfer it to me and I will transfer it to the org

[sindresorhus]

Another feature request for the logger. Print out the task name when logging from a plugin. Currently task runs concurrently and if two tasks uses the same plugin the output can be hard to read. See: sindresorhus/gulp-size#6

[yocontra]

@sindresorhus That may be a little difficult since the plugin emitting the logs to the bus doesn't know which task it's in... I'll have to think on that a little and see if I can figure out a way to do it

[laurelnaiad]

Kind of related to this.. I'd like to be able to filter the logging in my gulpfile by:
(a) task
(b) plugin
(c) plugin within task
(d) regex when all else fails or if a, b, and c are not all possible.

[jasonrhodes]

This kind of filtering should be possible from the gulp listening side, where the listener will have access to the task being run as well as the plugin name via event.source and can apply filters before printing to stdout

On Mar 26, 2014, at 5:30 PM, Stu Salsbury [email protected] wrote:

Kind of related to this.. I'd like to be able to filter the logging in my gulpfile by:
(a) task
(b) plugin
(c) plugin within task
(d) regex when all else fails or if a, b, and c are not all possible.

—
Reply to this email directly or view it on GitHub.

[jasonrhodes]

So this is exactly what @contra already said, but I'm slow and needed a few days to process it, so I figured I'd record the explanation in case other people are as dense as I am.

Filtering logs by task is a lot harder than it sounds. gulp would have to pass the current task context to every plugin, somehow, which would then have to be attached to the emitted log message object so that when gulp listens for that object, it has a reference to the task that was being run when that log was emitted.

[laurelnaiad]

Indeed. Nobody said it would be easy! :)

I imagine there's no good way to do this without an API change... the fact that the "task patient" is lying on the operating table anesthetized with new body parts on the gurney at the moment seems to present an opportunity, though.

[yocontra]

We could horribly abuse stack traces to get a sense of what task a function is running in.

[dylang]

Has this conversation moved elsewhere?

[yocontra]

@dylang nope this is the spot

[dypsilon]

Is there any easy way to use bunyan with gulp right now?

[zckrs]

GulpJS need to include a advanced logger formatted.

• winston
• bunyan
• log4js

@contra, @sindresorhus what NPM modules you prefer ?

winston is awesome with logstash but maybe too heavy for GulpJS

[sindresorhus]

Those are made for busy web servers, not a simple CLI tool. Way too much IMHO. We need something simple.

[zckrs]

Right.
npmlog can be a good solution ?

[mahnunchik]

@sindresorhus @contra Hi, it is not advertising. I'm developing logger which fit the following requirements:

1. a module the plugins can use that simply sends messages on the main bus
2. a module that listens to this main bus for messages
3. the main bus.

logger - mag
main bus - mag-hub

Messages can be transformed or mutted by pipeline:

hub.pipe(info())
  .pipe(format())
  .pipe(myCustomFormatter())
  .pipe(colored())
  .pipe(process.stdout);

[vbauer]

@mahnunchik +1

[weitzj]

I am using log4js right now.
I basically duplicated the bin/gulp.js file and added the following 2 lines:

var path = require('path');
var log = require('log4js').getLogger(util.format('[%s]', path.basename(__filename)));

All calls for gutil.log get exchanged to log.info all error logs use log.error

The renamed gulp.js file is called publish.js. A sample output looks like:

[2014-11-07 17:32:54.171] [INFO] [publish.js] - Starting 'styles:stylus'...
[2014-11-07 17:32:54.178] [INFO] [publish.js] - Starting 'scripts:browserify'...
[2014-11-07 17:32:54.191] [INFO] [publish.js] - Starting 'images:dist'...
[2014-11-07 17:32:54.193] [INFO] [publish.js] - Starting 'icons:dist'...
[2014-11-07 17:32:54.194] [INFO] [publish.js] - Starting 'fonts:dist'...
[2014-11-07 17:32:54.467] [INFO] [publish.js] - Finished 'images:dist' after 276 ms
[2014-11-07 17:32:54.468] [INFO] [publish.js] - Finished 'icons:dist' after 275 ms
[2014-11-07 17:32:54.470] [INFO] [publish.js] - Finished 'styles:stylus' after 297 ms
[2014-11-07 17:32:54.470] [INFO] [publish.js] - Starting 'styles:dist'...
[2014-11-07 17:32:54.470] [INFO] [publish.js] - Finished 'styles:dist' after 5.51 μs
[2014-11-07 17:32:54.504] [INFO] [publish.js] - Finished 'fonts:dist' after 310 ms
[2014-11-07 17:32:56.040] [INFO] [publish.js] - Finished 'scripts:browserify' after 1.86 s
[2014-11-07 17:32:56.040] [INFO] [publish.js] - Starting 'scripts:dist'...
[2014-11-07 17:32:56.040] [INFO] [publish.js] - Finished 'scripts:dist' after 4.03 μs
[2014-11-07 17:32:56.040] [INFO] [publish.js] - Starting 'assets:dist'...
[2014-11-07 17:32:56.040] [INFO] [publish.js] - Finished 'assets:dist' after 3.88 μs
[2014-11-07 17:32:56.040] [INFO] [publish.js] - Starting 'default'...
[2014-11-07 17:32:56.040] [INFO] [publish.js] - Finished 'default' after 3.29 μs

Using

var log = require('log4js').getLogger(util.format('[%s]', path.basename(__filename)));

in all other files, which define gulp tasks is helpful for debugging, since the log indicates, in which file the task was used.

Also now it is possible to add a custom log4js config file, so I can mute some log levels.

[ben-eb]

+1 for mag/mag-hub. Personally I would prefer if gulp & plugins only log when there is an error, as I'm backgrounding watch tasks most of the time and don't need the hand-holding. Centralised logging with levels would be super sweet. 👍

(I'm aware of --silent, but gulp plugins seem to do their own thing...)

[phated]

Work being done at #105 and the gulplog module

[phated]

This has been published in 3.0.7 - sorry for the semver abuse, but we need people to start getting this by default when using the new CLI