Hi @yoheimuta, thanks so much for creating protolint!
I'd like to propose a new opt-in rule that reports a violation when the same message type is used as a repeated field in more than one message.
Background
message ItemInfo {
string id = 1;
string name = 2;
}
message CreateOrderRequest {
repeated ItemInfo items = 1;
}
message GetOrderResponse {
repeated ItemInfo items = 1;
}
In this design, if we later need to add a field specific to CreateOrderRequest (e.g., quantity per item), we cannot modify ItemInfo without exposing the field in GetOrderResponse as well. The reason this rule targets repeated fields specifically is that for singular fields, request-specific data can simply be added to the parent message itself — whereas with repeated, the element type is shared and cannot be evolved independently.
Proposed rule
- Rule ID:
NO_SHARED_REPEATED_MESSAGE
- Default: disabled (opt-in)
- Logic: Report a violation when the same message type is referenced as a
repeated field from two or more distinct messages. Scalar types are excluded.
Violation example:
foo.proto:8:3: "ItemInfo" is used as a repeated field in multiple messages (CreateOrderRequest, GetOrderResponse). This limits flexibility for adding message-specific fields. Consider creating dedicated types per message.
I'd be happy to submit a PR implementing this if you're open to it.
Hi @yoheimuta, thanks so much for creating protolint!
I'd like to propose a new opt-in rule that reports a violation when the same message type is used as a repeated field in more than one message.
Background
In this design, if we later need to add a field specific to
CreateOrderRequest(e.g.,quantityper item), we cannot modifyItemInfowithout exposing the field inGetOrderResponseas well. The reason this rule targetsrepeatedfields specifically is that for singular fields, request-specific data can simply be added to the parent message itself — whereas withrepeated, the element type is shared and cannot be evolved independently.Proposed rule
NO_SHARED_REPEATED_MESSAGErepeatedfield from two or more distinct messages. Scalar types are excluded.Violation example:
I'd be happy to submit a PR implementing this if you're open to it.