How can we provide options to config Request/Response Suffix (eg. MethodNameReq MethodNameReply) ?

[edocevol]

In my team, there is already a lot of historical code that uses MethodNameReq and MethodNameReply as request parameters. I would like to introduce validation rules, but the current configuration is not compatible with the historical rules.

[bufdev]

Right now you can't customize the request/response suffix - it is something that we could add to buf.yaml as a configuration option, but it won't be a high priority right now. I would just ignore the rule for now.

[edocevol]

Yes, We have ignored the relevant rules in the buf.yamlfile. At the same time, We also want to verify that the newly generated Request and Response meet the naming rule.

[KinNeko-De]

@edocevol Can you not ignore the one rule only for the legacy files?
New files would then fall under the lint rules

https://buf.build/docs/configuration/v2/buf-yaml/

Example:

lint:
  use:
    - STANDARD
  ignore_only:
    ENUM_ZERO_VALUE_SUFFIX:
      - proto/bar/a
      - proto/bar/b/f.proto

[edocevol]

Thanks for your reply! In fact, I'm unable to configure the rules to the snippet you provided. It's very difficult for me to make this change that breaks the team's habits. A more appropriate approach, as I mentioned before, is to enforce the constraint that MethodNameReq and MethodNameReply be used as the rules.

[KinNeko-De]

@edocevol The snippet is not a snippet to your concrete example. It was just an idea I had when I read your second comment.
I also do not have some concrete examples, so I can not provide you a working solution

As far as I understand you have the following structure

- newcode/where/I/want/request/response
      newservice.proto
- legacycode/with/request/reply
      legacyservice.proto
buf.yaml

And you want to apply the rule RPC_REQUEST_STANDARD_NAME and RPC_RESPONSE_STANDARD_NAME for newservice.proto and not for legacyservice.proto.

Did I understand you correct?

I do not understand why this breaks the team habit, as you already said you the teams wants to apply the rules for new services

[edocevol]

😀Thank you for your reply! Let me describe the current situation of my team to you again. The team has already been using XXXReq and XXXReply as the de facto norms. It's very difficult for me to introduce XXXRequest and XXXResponse as new norms. Because it's not good to have two sets of norms in the same team's repository. And it's also hard for me to persuade team members to accept another suffix norm, since we generally maintain the naming norm of using Method + Req/Reply for ProtoMessage.

[edocevol]

Therefore, the lint rules I want are as follows:

It should be able to use RPC_REQUEST_STANDARD_NAME and RPC_RESPONSE_STANDARD_NAME, and at the same time, it's possible to CHANGE Req and Reply as the suffixes of STANDARD_NAME.

[KinNeko-De]

CHANGE Req and Reply as the suffixes of STANDARD_NAME.

@edocevol
Thank you for your explanation. Now I understand your request-

While I not agree that it is not possible to have two conventions in the same repository, I know the problem that people refuse to change and envolve. I guess this is a problem that can not be solved by technical solutions. And yes there are several examples in the official documentation of protobuf that violates the style guide of google.

But I also understand that a company like Buf might not plan to fullfill your wishes. There would be a freetext configuration value because some people will complain that you do not use "Request" instead of "Req". One time you accept it at one place you will open a gate. Faster than you can imagine you will end up in a very complex full configurable framework which is very hard and expensive to maintain.

But as far as I understand you have the option to write your own plugin: https://buf.build/blog/buf-custom-lint-breaking-change-plugins
I think that would solve your problems.