Format accepts input from stdin

[jan-xyz]

I am working a lot with buf and have it also setup to work from inside Neovim and it would make life a bit more convenient if both buf lint and buf format would accept input from stdin.

It would allow to show diagnostics live and on unsaved buffers and have a better integration with the vim.lsp.buf.formatting() functions as used in null-ls.

Currently, this means that all changes are "undone" when running the formatting command on unsaved buffers as they revert back to what's on disc. Which happens a lot for me since I usually setup formatting like this

vim.cmd([[autocmd BufWritePre <buffer> lua vim.lsp.buf.formatting_sync(nil, 500)]])

which runs the formatting on the unsaved buffer before writing the buffer to disc every time I save a file.

Maybe by adding an option --stdin or detecting when something gets piped in would be an option?

[amckinney]

The reason we don't have a stdin input type is because there isn't an obvious answer for the default stdin input type in buf's case.

In most cases, buf operates on directories, modules, images, and more (outlined in the input documentation), all of which are collections of .proto files - not just a single one. Yes, buf supports single file inputs, but that isn't the common use case we want to promote. buf firmly believes that Protobuf should be thought of in terms of directories and packages instead.

With that said, we could add a flag that lets the user modify the stdin input type (kinda like the buf beta convert command's --input flag, but a little different). For buf lint, we'd probably want the default stdin input type to be an Image so that commands could be piped together easily with buf build, but that's a redundancy that we wanted to prevent - buf lint will already build the input on its own, so piping isn't necessary. It's important to call out that buf lint doesn't operate on source files directly - it acts upon the compiled representation (described here).

However, we'd probably want the default input to be a single file for buf format (it requires source files, not Images). The inconsistency isn't ideal, but it might be something we need to accept. I imagine this will be a common ask for developer tools (like it is for you).

So in general, I'm hesitant to introduce this feature just to ease this one use case, especially because it's not the common path we want to evangelize, but I think we need an exception for buf format. I'd like to keep this separate from buf lint though - I'm not as convinced that we should be doing anything there.

TL;DR - We'll design a solution for buf format to accept a single file on stdin, but we might not do anything for buf lint.

[jan-xyz]

I agree! That actually makes sense for the lint case. I stumbled across it because of buf format and then thought to include lint for completeness, but maybe that was a premature suggestion. Thanks for taking a look and I'm curious to see what buf format will bring! 🚀

[nedtwigg]

Just an FYI that the PR above (which has VS Code and IntelliJ plugins) is blocked on this feature.

[jimeh]

@amckinney Just to add my two cents to this, I think being able to provide file content via STDIN for buf lint as well would be useful if you want an editor setup to lint as you type before you've saved the file.

I understand that buf lint doesn't operate on a single file however, so may I suggest an option to effectively override a specific file's content with STDIN?

For example if a new --stdin <FILE> flag is provided, skip reading <FILE> content from disk, instead reading the content of that specific file from STDIN.

Rubocop for example works this way, which means it fully acts as if the the source provided on STDIN is ~/Projects/foo/bar/hello.rb on disk, and hence reads any related .rubocop.yml config files in parent directories, etc.

[fsaintjacques]

I'd like this feature for exactly the original use case, formatting buffers (not always files) in vim with autoformat.