buf icon indicating copy to clipboard operation
buf copied to clipboard

buf format and an buf lint behave inconsistently when no *.proto files discovered.

Open nightlyone opened this issue 2 years ago • 0 comments

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 complains Failure: 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.

nightlyone avatar Jun 24 '22 15:06 nightlyone

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.

amckinney avatar Aug 10 '22 23:08 amckinney

It's been several days, so I'll close this one out (we don't plan to make any changes here).

amckinney avatar Aug 18 '22 16:08 amckinney