| # Package structure |
| |
| - `private/pkg` contains utility packages that are not Buf-company-specific. In theory, any of these packages could be split into a separate repository in the future, and not depend on Buf types or concepts. |
| - `private/bufpkg` contains utility packages that *are* Buf-company-specific, but not specific to github.com/bufbuild/buf. These packages could be split into separate repositories in the future. |
| - `private/buf` contains packages specific to github.com/bufbuild/buf. In other repositories, this should be named after that specific repository, for example `github.com/bufbuild/foo` would contain `private/foo`. |
| |
| There's a strict dependency graph imposed at this level: |
| |
| - `cmd/{binary}` packages must be `main` packages, and any sub-packages must be `internal`. `cmd/{binary}` packages can import from any `private` package. |
| - `private/buf` packages can import from `private/bufpkg` and `private/pkg` packages, but not `cmd` packages. |
| - `private/bufpkg` packages can import from `private/pkg` packages, but not `cmd` or `private/bufpkg` packages. |
| - `private/pkg` packages can only import from other `private/pkg` packages. |
| |
| That is, the ordering is strictly `cmd -> private/buf -> private/bufpkg -> private/pkg`. This is enforced by linting tools. |
