feat(cli): Add silent / quiet global CLI flag #24232
Conversation
|
|
CodSpeed Performance ReportMerging #24232 will improve performances by 22.52%Comparing Summary
Benchmarks breakdown
|
There was a problem hiding this comment.
Hi @paulomarg
Thank you for submitting the PR. --quiet flag makes sense, however, I am pretty sure this PR won't quite achieve the functionality you want - unfortunately, we are pretty bad at centralizing our logging and there are bunch of other places within the CLI where rogue console.log might slip in.
If you want to do an attempt at centralized logging, we'll take it. However, that might be a lot of work and I think there is way for us to proceed with this PR - just that before we can merge it, we should at least be sure that we won't make this logging situation worse in the future. And for that we'd need to snapshot output from real commands, not the fake one. You can find the examples of how to do it in cli/src/__tests__ and migrate/src/__tests__.
Additionally, small nitpick - I don't think there is a good reason to have both --silent and --quiet flag, I'd prefer we'd just keep --quiet for now.
Thank you again for this PR and let me know if you need any help.
|
Hey, thanks for getting back to me! That was a good callout, I added some test that would check the actual output and it does seem like a lot of it isn't coming from the command return value (see the new snapshots), so my proposal was too shallow. I agree that the right solution would have to be centralizing all of the logging and using the flag to turn that off instead, but unfortunately I won't have the time to do that :( Thanks for taking the time to review, and I hope this PR helps whatever solution you end up implementing! I'm going to close it since it doesn't feel like it'll solve the problem. |
|
No worries, @paulomarg, thank you for submitting the PR anyway. It won't be able to be merged is more of our failure than yours, to be honest, so, my apologies about that. |
|
@SevInf , surely "some" fuctionality is better than a perfect solution for now. It can always be adjusted and improved in the future. as per #23192 (comment) |
|
@davecarlson I was not the one who closed the PR, but if you look at updated snapshots here, it is pretty far even from a baseline — |
|
sweet, thank you . that hopefully will do :) |
|
I agree with @SevInf, unfortunately this PR just didn't do what it intended, since we still had a lot of output going out even with the flag. I don't think it should be merged in the state it was in as having the flag omit only some messages would probably make it worse. |
Closes #23192
As mentioned in the issue, there are some scenarios where we want to omit the regular message returned from a command, where the output might make it harder to spot legitimate issues, or bloats the output of some scripts.
To achieve that, this PR introduces a new global
--quietflag (aliased to--silentif I understood the setup correctly 😄) that simply ignores the message returned from a command, unless that is anError.With this, users can toggle the regular output off but still catch any errors thrown by commands so we don't accidentally hide problems. Messages logged directly by a command (assuming no normal flow messages are logged that way) are still output normally.