emitter

[millermedeiros]

I initially said about emitter being a property of the task but I guess that it would be better if the task itself was an instance of an EventEmitter, that way I think it would be easier to make it work with random modules (which are already event emitters).

// do this
myTask.on('log', printLog);
// instead of
myTask.emitter.on('log', printLog);

And we should make it in a way that it would work with any EventEmitter that follows the same interface (not only EventEmitter2).

The main thing is that if we can agree with a simple format it will be easier to create decoupled helpers/tasks that can be used with any task runner or other node.js apps (not necessarily related to build scripts).

[tkellen]

Hmm. I don't think the spec should state the task is an instance of an event emitter, but I can agree with the idea that it should present a compatible API.

[tkellen]

We're publishing Grunt 0.4 today. Once that is done, I'm going to focus some effort this week on getting the recent requests for changes into the spec.

[tkellen]

Which of the methods do you think the spec should explicitly define support for? Obviously we need on, off, and emit.

[millermedeiros]

on should be enough (and optional), we only really care about listening to the events, the task is responsible for dispatching it, could be implemented like:

var emitter = new EventEmitter();
exports.on = emitter.on.bind(emitter);
// ...
exports.run = function(opts){
  emitter.emit('log', 'running task...');
};

I think duck-typing should be used, if on() is available we add the listeners, if not we simply skip it. Same thing for off() (which probably won't need to be called by the task runners that often).

[tkellen]

Actually, upon further reflection, I don't want to specify that people have to bind specific methods from their emitter to the task object. I'm going to stick with allowing emitter to be any compatible EventEmitter instance.

[tkellen]

I've come around to your point :)