Automaton should be an emitter and emit meaningful events.

[satazor]

It would increate the flexibility to use automaton programatically.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/98455-automaton-should-be-an-emitter-and-emit-meaningful-events?utm_campaign=plugin&utm_content=tracker%2F39683&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F39683&utm_medium=issues&utm_source=github).

[marcooliveira]

Yep! I've been thinking about this, and there's more! The way we are currently handling logging limits the user a lot. We could instead emit events, that would be caught by the logger, which would then log the information. If the user wanted to, he could just disable the logging, and treat the events himself, since all the information would come structured, instead of just a text stream.

Of course this emitter strategy might be applicable to other things besides logging.

[satazor]

The easiest and more the most concise way of doing this is:

• automaton.run() should return an emitter instead of a stream
• events to emit:
  • start (passing the task definition)
  • end (passing the task definition)
  • log (passing the type, args, task definition that originated the log)

The task definition contains the actual task, the options, the depth, mute, fatal and other useful stuff.
Then, as @marcooliveira said, the log events would be listened to automatically generate the log but the user could disable it with verbosity: 0.