mcmire
commented
2 months ago My suggestion to solve this problem is to add the concept of reporters to the tool. The current strategy could be named "plain", and we could add a new "json" reporter. The user could specify one or more reporters when running the tool by passing a --reporter option. For instance, the user could run:
module-lint --reporter plain --reporter jsonThe ability to specify multiple reports would be useful if we still want to show something that is both human-readable but also have something that's machine-readable.
If multiple reporters would output to stdout, how would they be represented? In the example above, the tool would output the plain version of the output (the one that exists now), followed by an empty line, followed by --, followed by another empty line, and finally followed by the JSON representation of the output. (In this way, this would be similar to HTML's multipart/form-data media type.)
To implement reporters we would need to extract the existing implementation to a separate file, then implement the JSON reporter as another file, and use the strategy pattern to select them.
Why do we need to implement reporters at all? We don't absolutely need to now, but the ability to specify reporters at all dovetails with a larger strategy we have for this tool, which is to display results from runs across various repos in a dashboard. Fast forwarding, we could imagine passing --reporter "html:dashboard.html" to produce an HTML version of the output, and write it to dashboard.html instead of stdout.
In order to report the number of passing and failing rules for a repo in a Slack message, currently we need to extract this information from the output of the tool. It would be nice if we could run the tool in a different mode that would produce machine-readable output so that we wouldn't have to do any parsing.