Support pretty-printing and colorizing JSON responses for the api command when using jq expressions

[mestebangutierrez]

Describe the feature or problem you’d like to solve

When using the api command with a jq expression, the CLI currently does not pretty-print nor colorize the post-processed response, even though jq already supports both features. The resulting output nowadays is a compact JSON representation that may be quite difficult to interpret visually.

Proposed solution

This would be a nice to have when you are exploring the GitHub API leveraging the client during the development of integrations with the GitHub API.

A possibility would be to have the means to enable these behaviors -in case they should not be enabled by default for other reasons (i.e., performance or safety)- via additional api command flags:

$ gh api --jq <expression> --prettyprint --colorize <path>

[alex-grover]

This would be great to have, not only are colors and pretty-printing features of jq, they are the default. My use case is the following, and it's counterintuitive that these produce different results:

$ gh api repos/{owner}/{repo}/compare/prod...main | jq '.commits[].commit | {author: .author.name, message}'
$ gh api repos/{owner}/{repo}/compare/prod...main --jq '.commits.[].commit | {author: .author.name, message}'

[mjpieters]

This requires two changes:

• the go-gh/pkg/jq/jq.go:Evaluate() function needs to indenting the marshalled output on the encoder, if pretty printing is enabled.
• the cli/pkg/cmd/api/api.go:processResponse() function needs to use a new buffer to write the jq evaluation result to, then replace the response body buffer with the new buffer and continue processing (removing else before if opts.Template != "" ...). Perhaps the pretty-print flag should probably only be set if the output is a TTY.

Because go-gh is a separate repository, I'll make two PRs for this.

[mjpieters]

A possibility would be to have the means to enable these behaviors -in case they should not be enabled by default for other reasons (i.e., performance or safety)- via additional api command flags:

My PR implementation enables the feature when connected to a TTY; this allows existing tools that expect the output to be compact to still work when piping the output.

[mjpieters]

This would be great to have, not only are colors and pretty-printing features of jq, they are the default. My use case is the following, and it's counterintuitive that these produce different results:

$ gh api repos/{owner}/{repo}/compare/prod...main | jq '.commits[].commit | {author: .author.name, message}'
$ gh api repos/{owner}/{repo}/compare/prod...main --jq '.commits.[].commit | {author: .author.name, message}'

With my PR that would look like: