buf
buf copied to clipboard
bufbuild
Custom and configurable lint rules
Do you have any plans to make it easier to contribute or load (private) custom lint checkers?
I really like where buf is going, but the lint-rules are already too rigid. E.g. I want to use the PACKAGE_VERSION_SUFFIX but we have a v1experimental convention it doesn't support and we need the flexibility to change it to something else in the future.
We also have specific needs covering which options are required (e.g. c# namespaces etc.)
Even more, we have an ambitious style guide which I would like to encode in automatic rules. Things ranging from what to name fields, which annotations to use etc.
Without built-in support for loading extensions, my options might be to either fork buf or try to find a different tool.
I have similar concerns about the bc checks.
Regarding the PACKAGE_VERSION_SUFFIX I also have the need to allow different version-patterns for different roots. E.g. all protos in experiments root must use v\d+experiment but protos in the stable root must conform to the version-convention buf currently enforce (but v\d+test not allowed).
If the current implementation of the PACKAGE_VERSION_SUFFIX check would be replaced with a regexp like:
/\.v[1-9]\d*(p[1-9]\d*)?(((beta|alpha)[1-9]\d*)|test\w*)?$/ it would be easy to make it configurable when customization is needed.
The above passes all the current tests: http://refiddle.com/refiddles/5e4e567b75622d458f040000
After som contemplation today we might opt for using the alpha-based version instead of a custom scheme. I'm still interested in understanding more on the plans for custom lint rules and it would still be useful to apply different versioning rules (patterns) to different roots.
I know this won't be the best answer for your use case here, but Buf won't have the ability to add custom lint or breaking change checks. The goal of Buf is to have a single decision as to what constitutes proper Protobuf design, for widespread consistency. The goal for Buf is to simplify Protobuf usage by having a single way to do things - other languages have similar constructs.
We will add a STRICT group in the future that goes further in adding checks for things like file options as you mentioned above.
Current rules is good in general, but we still need custom rules/linter to match with project's policy. it's not just an opinion, in some project, it's a must.
Not supporting plug-in custom rules may be for the commercialization of buf, but this is too important for a community project.
We have many existing projects and cannot use the default rules directly.
I am reopening this issue because we have recently started to consider how we might enable others to write custom lint plugins that can enforce custom lint rules. We don't have a final design or concrete timeline for this, but will update this issue when we have new information.
The workaround today (if you have more strict or specific requirements) is to just write a protoc generator.
You can invoke your custom protoc gen from buf.gen.yaml as normal. Inside the generator, as long as you do not use Plugin no output is generated.
func LintProtoResources(_ *protogen.Plugin, f *protogen.File) error {
return nil
}
you can return an error. It is getting the job done for me.
