Single file inputs with a buf.work.yaml

[amckinney]

The buffetch.ProtoFileRef input type doesn't work if the file is not contained in a directory specified in the buf.work.yaml (if any). For reference, buf will ascend directories until it finds a buf.yaml or buf.work.yaml so that it knows where to build the file from. If neither of these files exist, it'll continue to the root of the filesystem.

Suppose that I have the following tree:

.
├── acme
│   ├── buf.yaml
│   ├── payment
│   │   └── v1
│   │       └── payment.proto
│   └── pet
│       └── v1
│           └── pet.proto
├── buf.work.yaml
└── vendor
    └── external.proto

The buf.work.yaml content is shown below (it omits the vendor directory):

version: v1
directories:
  - acme

If I try to build the vendor/external.proto file independently, I'll notice the following:

$ buf build vendor/external.proto
Failure: path is empty

However, everything works fine if I build a file in the acme directory (since it's contained in the workspace):

$ buf build acme/payment/v1/payment.proto

This affects any of the buf commands that interact with buffetch.ProtoFileRef, including buf format (where it's most likely to bite people). The error message was adapted to handle this case specially (marked with a TODO).

$ buf format vendor/external.proto
Failure: input vendor/external.proto was not found - is the directory containing this file defined in your buf.work.yaml?

We need a better answer here - we might not be able to guarantee that the file will be independently buildable without knowing where to derive the import statements from (usually done with the buf.work.yaml or buf.yaml), but we can certainly handle more common cases than we do today.

[doriable]

I think specifying a single proto file as a part of a workspace is unfortunately not something we will be supporting -- modules will continue to be scoped by directory. If this is desired, then --path and --exclude-path or the build.exclude configuration keys can be used.