🛠️ Task: Implement configurable "reporters" #55

andreuz commented 2026年03月23日 12:02:33 +01:00

For task automation, it might be useful to make it possible to configure "reporters", so the output of our CLI tools can be easily parsed & processed by other scripts & tools.

• standard/original text reporter (already exists, but it hasn't been extracted as a "reporter")
• JSON

For task automation, it might be useful to make it possible to configure "reporters", so the output of our CLI tools can be easily parsed & processed by other scripts & tools. - [ ] standard/original text reporter (already exists, but it hasn't been extracted as a "reporter") - [ ] JSON

unixunion commented 2026年05月15日 17:58:23 +02:00

Is the plan here for automation in workflow testing as the code-base develops, or is this more aimed at plugins / tools in a user's workflow ( or both? )

Depending on whether this is implemented in slicer-cli or at core level, the complexity and maintainability differ:

a) In slicer-cli, each new error variant would need changes in two places, declared in core, then translated into a ReportMessage (or equivalent) in slicer-cli. The wire format is decoupled from internal types, so refactors in core don't break downstream JSON consumers, but all this at the cost of more boilerplate per variant.

b) Use derives in core, which has zero slicer-cli boilerplate per variant, the core types are serialized directly. The downside is that the JSON wire format becomes coupled to internal field names in core. Renaming a field in core results in a breaking change for any external tool parsing the output. This may be acceptable, but the implication should be acknowledged up front.

c) A middle ground: derives in core plus explicit #[serde(rename = "...")] on every wire field. Same low slicer-cli cost as (b), but the wire contract is explicit and reviewable in core. Renames in core don't propagate to consumers unless the serde annotation is also changed, which would show up clearly in a diff.

Also, is it a streaming "array" of JSON objects or one unified report? Errors also need to be serialized into the report or is stderr and error code still the way to finalize a fatal error?

Is the plan here for automation in workflow testing as the code-base develops, or is this more aimed at plugins / tools in a user's workflow ( or both? ) Depending on whether this is implemented in _slicer-cli_ or at _core_ level, the complexity and maintainability differ: a) In _slicer-cli_, each new error variant would need changes in two places, declared in _core_, then translated into a `ReportMessage` (or equivalent) in _slicer-cli_. The wire format is decoupled from internal types, so refactors in core don't break downstream JSON consumers, but all this at the cost of more boilerplate per variant. b) Use _derives_ in _core_, which has zero _slicer-cli_ boilerplate per variant, the _core_ types are serialized directly. The downside is that the JSON wire format becomes coupled to internal field names in _core._ Renaming a field in _core_ results in a breaking change for any external tool parsing the output. This may be acceptable, but the implication should be acknowledged up front. c) A middle ground: _derives_ in _core_ plus explicit `#[serde(rename = "...")]` on every wire field. Same low _slicer-cli_ cost as (b), but the wire contract is explicit and reviewable in core. Renames in _core_ don't propagate to consumers unless the `serde` annotation is also changed, which would show up clearly in a diff. Also, is it a streaming "array" of JSON objects or one unified report? Errors also need to be serialized into the report or is stderr and error code still the way to finalize a fatal error?