Support multiple file paths in buf format
#4281
Conversation
The only real complexity here is that we're enforcing `-o` (if used) specifies a directory for now if multiple files are passed (I don't think there's a use-case for formatting multiple files that output to a single file, or a non-matching number of output files), and we disallow using `--path` with multiple input files. Fixes #4233.
|
The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).
|
Shouldn't need the additional assertions.
There was a problem hiding this comment.
This approach makes sense to me -- it's non-breaking to existing customers, and I think the most reasonable approach is not to mix the use of --path with multiple path arguments to avoid confusion.
EDIT: Actually, I lied, this is actually a bit of a breaking change. So the buf CLI always expects the argument to be an input. By merging all the arguments together and expecting them to always be paths, this breaks the idea that the arguments are inputs.
The way you have it implemented, it's mostly safe because you're forcing multiple arguments to always be interpreted as paths with the . input, but then it wouldn't allow the user to specify a different input with those paths, e.g. you can't make a positional argument equivalent for buf format proto --path <path> --path <path>.
Since the invocation buf format . --path <path> --path <path> means the compiled input is . and the paths we're targeting are --path.
For the invocation buf format path/to/foo.proto, the compiled input is the proto file ref, path/to/foo.proto. This compiles the module/workspace that contains said proto file, which may or may not be ., and then culls the input down to path/to/foo.proto and its dependencies. But the resolution specifically accounts for that single proto file as the input.
It's a very low level distinction, and I think one that creates a bit of an inconvenient UX, so I think it is reasonable to consider this change, but I do think we'll need to make the --help very clear.
This matches the behavior of
gofmt, as well as other tools mentioned in #4233.The only real complexity here is that we're enforcing
-o(if used) specifies a directory for now if multiple files are passed (I don't think there's a use-case for formatting multiple files that output to a single file, or a non-matching number of output files), and we disallow using--pathwith multiple input files.Fixes #4233.