Event-based output

[eibens]

The current logger outputs a call-tree of edcb actions. This works for the build command, where everything is sequential, but fails hard for the serve command, where requests may be resolved in parallel. While we can still have the tree-view, it should be based on a more general event-based output. This would further allow for new output modes as mentioned in #30, such as a --json flag that simply prints the event as JSON lines.

[eibens]

Runner Events

During an invocation of an action (e.g. build, serve) the runner will emit events. These events have the following API:

type RunnerEvent = {
  id: number // unique for the whole run
  call: number // unique for the invocation of the action
  parent?: number // call number of the action that started this invocation
  time: number // time when event was emitted
  type: ActionType // name of the action
  kind: string // sub-category of action (e.g. enter, exit, error, result, stdout, stderr, request, socket)
  data: unknown // depends on the type and kind
}

By aggregating these events in a reducer, it should be possible to replicate the current logging behavior and allow for many new features and output formats.

Direct Action Events

Events have to be available at the action layer. For example, the exec, watch, and listen actions potentially run for a long time, during which they constantly emit events (e.g. stdout, stderr, request, socket). This is the minimal data that must be emitted directly by an action:

type Event<Kind extends string = string, Data = unknown> = {
  kind: Kind
  data: Data
}

The other properties are related to the call graph and runner, so they can be generated. The generic interface of an action can be described by this type, although it might be implemented differently:

type Action<Result, Options, Deps, Event extends Event> = {
  options: Options
  deps: Deps
  events: AsyncIterable<Event & CallEvent<Options, Result>>
  func: (deps: Deps) => (options: Option) => Result
}

The CallEvent is a generic event type, which documents the lifecycle of a function call:

type CallEvent<Options, Result> = 
  | Event<"enter", Options>
  | Event<"result", Result>
  | Event<"error", Error>
  | Event<"exit", void>

These events can be generated automatically, by wrapping the function similar to the current withRunner middleware.