buf
buf copied to clipboard
buf format and an buf lint behave inconsistently when no *.proto files discovered.
Given a project in extra git repository without any *.proto files but a buf.yaml configured
buf version 1.6.0 on x86_64 linux
buf workspace is not configured.
Observed behavior
- Calling
buf format --diff --exit-code
doesn't complain, shell exit code is 0 - Calling
buf lint
complainsFailure: no .proto target files found
shell exit code is 1
Expected behavior
- Calling
buf lint
should be silent and return code should be 0
Note
If backward compatibility is important here, please add an option to achieve the expected behavior when everything works but just yields not *.proto
files.
Thanks for the report - I'd actually argue that the formatter should respond with a non-zero exit code here so that it matches the behavior of buf lint
. We generally want such commands to be reported as failures - if no .proto
files were provided as input, then the command should fail (because these commands really require at least one .proto
file to do anything).
Backwards compatibility is very important here - we could add a flag to switch on this behavior, but I don't know how valuable it would be in practice. Sure, it's better to have a consistent experience between all of the sub-commands in the buf
CLI, but if it will require an additional flag, what would it really provide us? Plus, what would we name it anyway? It really doesn't feel very ergonomic or useful.
For some additional insight here, the behavior you're observing is largely because of how the linter and formatter are implemented. The linter acts upon the compiled intermediate representation (a FileDescriptorSet
or Image
in Buf parlance), whereas the formatter acts upon the AST of each file, one at a time. It looks like the formatter implementation was fine without any .proto
file inputs, but this should have been validated upfront.
I'll include the Won't Fix
label for now, but we can continue to debate whether or not this is necessary before I close it out.
It's been several days, so I'll close this one out (we don't plan to make any changes here).