fix(#2123): Move output to stderr

[jzorn]

Description

This change moves informational command outputs from console.log (prints on stdout) to console.warn/console.error (prints on stderr) to enable stdout processing in pipelines.

I am not sure how to properly test if this breaks anything, if I have missed anything I am happy to fix any problems.

Fixes #2123

Contribution Checklist:

• [x] The pull request only addresses one issue or adds one feature.
• [x] The pull request does not introduce any breaking changes
• [x] I have added screenshots or gifs to help explain the change if applicable.
• [x] I have read the contribution guidelines.
• [x] Create an issue and link to the pull request.

Note: Keeping the PR small and focused helps make it easier to review and merge. If you have multiple changes you want to make, please consider submitting them as separate pull requests.

Publishing to New Package Managers

Please see here for more information.

[jzorn]

Hey, is there anything I can do to improve this PR to get it merged? :)

[jzorn]

Friendly ping :)

[jzorn]

Do you happen to have feedback on this one too, @andreassiegel? Your feedback on the one was valuable to me! Thanks!

[andreassiegel]

Hi @jzorn, I had mixed feelings regarding the proposed change at first:

While I absolutely understand and like the idea of being able to build up command chains and to pipe the output into other tools like jq, I'm not sure about the idea of logging everything else to stderr since it actually isn't about errors.

So, to me, this felt like a "misuse" of output streams due to the conflict between "actual" (result) output and intermediate log information. This relates to my personal work context as a backend engineer: I'm trying to be careful about log levels and want to make conscious decisions about when to use which log level (although there may be reasons to do things differently on client side).

For this reason, a few outputs feel odd here:

• writing the information about recursive runs to the warning log (line 408)
• writing the run summary or output status to the error log (lines 472 and 495)

You see, my concerns are more about log levels than about output streams. However, both are related. Personally, I'd only use the stderr for actual error information but I also see that stderr could be used for diagnostic information, and you could consider all intermediate log output as such diagnostic information.

On the other hand, what we actually may want to have is three different output streams:

• standard output for log information in happy cases
• error output in case of failure
• result output for further processing

Looking at the Bru CLI Overview, this seems to be possible with the -o or --output flags. So I think something like this would be possible without any changes:

bru run folder --output results.json
echo "results.json" | jq

So, to make a long story short:

I'm not sure whether the proposed changes are necessary or if they add more confusion. I think this requires a general (opinionated) decision about the usage of output streams, and with the flag to write output to a dedicated file this decision probably has been made already.

Personally, I also like the idea of having the output available as a separate file that I could persist as a pipeline artifact for later inspection. So this actually opens more option for further processing than just being able to pipe the command output into some other command.

[jzorn]

to stderr since it actually isn't about errors.

I don't think we should take the name of stderr too literal - I can't think of an application I use that would log warnings to stdout. Kubernetes comes to mind.

I am of course aware of the output file option in bruno cli, but it breaks (or hinders) building proper pipelines (see also this answer and the linked article https://stackoverflow.com/a/41766832). Something along the lines of bru run foo --output json | jq -r ".something.somethingElse" | cut -d" " -f2 | sort | uniq. Cleanup of temporary files is another burden in the current solution I'd like to avoid. Without proper separation of actual output and "debug information", the bru cli is limited in it's value for scripting.

[andreassiegel]

Thanks a lot for that link to the Stack Overflow issue! The referenced article was also a good read.

Also, Google doesn't really have a suggestion in their Shell style guide.

With that in mind, I'm fully with you, although the output file would be a bit redundant as it would basically do the same as redirecting the output to a file.

[jzorn]

I think removing the output file may cause a backwards-incompatibility though. What do you think? Maybe it could be considered for v2 of the cli?

[andreassiegel]

Yeah, I would not remove it, just accept the redundancy and maybe mark it as deprecated at some point.

It doesn't relly make a difference in the end, but for some users it might be more convenient to be able to specify an output file as an argument instead of redirecting the output stream.

[jzorn]

@helloanoop Would you like to weigh in on this? Anything else I/we can do to get those PRs merged? Thanks! :)

[jzorn]

Anything? :)

[jzorn]

Friendly ping :)

[jzorn]

Is there anything I missed? Do I need to follow a different process to get a change merged?

[jzorn]

Anything @helloanoop ?

[helloanoop]

Hey @jzorn

I had to revert the merge, Need some more time to review this,

[jzorn]

Sure thing - can I help you in any way to get this merged? Did I miss a backwards incompatibility or a bug? I am happily elaborating on this change, if you want me to.

[jzorn]

Can we somehow re-open this pr? I am afraid we may lose it otherwise.

[andreassiegel]

Can we somehow re-open this pr? I am afraid we may lose it otherwise.

I'd probably just open a new PR with the same changes on the recent baseline. Just like you, I assume this will get lost otherwise.

[jzorn]

Make sense to me. Thanks Andreas!