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.