gRPC Proto Linter

A validator checks that your .proto file is structurally correct — required fields, valid syntax, no duplicate field numbers. A linter checks code style, naming conventions, and best practices — things that compile fine but may cause issues with SDK generation, readability, or cross-team consistency. This linter focuses on style and conventions.

Following Google's Protocol Buffer Style Guide: service and message names must be PascalCase (e.g. UserService, GetUserRequest), RPC method names must be PascalCase (e.g. GetUser, ListUsers), field names must be snake_case (e.g. user_id, created_at), and enum values must be SCREAMING_SNAKE_CASE prefixed with the enum type name (e.g. STATUS_ACTIVE for enum Status).

The Request/Response naming convention is a widely adopted best practice (used by Google's own APIs and buf.build's style guide). It makes it immediately clear which messages are input vs output, allows tools to auto-detect request/response pairs, and improves readability when many message types are defined in one file.

A field like 'repeated string role' is ambiguous — is it one role or many? Using 'repeated string roles' makes the intent clear. This is a recommendation from Google's API design guide and adopted by most protobuf linting tools.

google.protobuf.Timestamp is a well-known type that maps to RFC 3339 timestamps in JSON, is timezone-aware, and works consistently across all language bindings. Using int64 forces consumers to decide whether it's milliseconds, seconds, or microseconds — a common source of bugs. Timestamp also provides clear semantics for tooling.

In proto3, enum values share the namespace of the enclosing .proto file. If you have two enums that both define ACTIVE = 1, the compiler will complain. Prefixing (STATUS_ACTIVE, ROLE_ACTIVE) avoids these collisions. It also makes the value self-documenting when used outside the enum context.