Emit protovalidate constraints for core TypeSpec decorators

[folded]

Following up on #4090 and #7838 (cc Denis (@rhodee) & Will Temple (@witemple-msft)) I put together a working implementation and wanted to check whether it covers what you're after before opening a PR.

The idea: the protobuf emitter currently drops the constraint information people already put on their models. If you write @minLength, @maxValue, @pattern, @format, etc., none of it makes it into the generated .proto. Those decorators are core TypeSpec and the OpenAPI emitter already honours them, so rather than invent anything protobuf-specific, the emitter can translate them into the ecosystem-standard buf.validate field options.

It's behind an opt-in emitter option (emit-protovalidate). When it's on, any file that emits at least one constraint also gets import "buf/validate/validate.proto";.

e.g.:

model User {
  @field(1) @minLength(3) @maxLength(32) @pattern("^[a-z0-9_]+$") username: string;
  @field(2) @format("email") email: string;
  @field(3) @minValue(0) @maxValue(150) age: int32;
  @field(4) @minItems(1) @maxItems(10) roles: string[];
}

produces:

import "buf/validate/validate.proto";

message User {
  string username = 1 [(buf.validate.field).string.min_len = 3, (buf.validate.field).string.max_len = 32, (buf.validate.field).string.pattern = "^[a-z0-9_]+$"];
  string email = 2 [(buf.validate.field).string.email = true];
  int32 age = 3 [(buf.validate.field).int32.gte = 0, (buf.validate.field).int32.lte = 150];
  repeated string roles = 4 [(buf.validate.field).repeated.min_items = 1, (buf.validate.field).repeated.max_items = 10];
}

Currently mapped:

• @minValue -> <type>.gte, @maxValue -> <type>.lte, @minValueExclusive -> <type>.gt, @maxValueExclusive -> <type>.lt (where <type> is the field's numeric proto type, e.g. int32, sint64, double)
• @minLength -> string.min_len, @maxLength -> string.max_len
• @pattern -> string.pattern
• @minItems -> repeated.min_items, @maxItems -> repeated.max_items
• @format -> the matching string rule for the values with a direct buf.validate analogue: email, uuid, hostname, ip, ipv4, ipv6, uri

I didn't add anything that isn't already expressable by TypeSpec decorators, even if it had a protovalidate representation (CEL cross-field expressions, required/ignore semantics, well-known-type rules). Those would need new protobuf-specific decorators, which felt like a separate conversation (and closer to #4090).

Denis (@rhodee) -- does this cover your use case, or were you relying on any of the out-of-scope pieces above? And for the maintainers: if the general direction is acceptable, I'm happy to open the PR.

[github-actions]

🎯 Issue Triage

A feature proposal to extend the protobuf emitter to translate core TypeSpec constraint decorators (minLength, maxValue, pattern, format, etc.) into buf.validate field options in the generated .proto files, behind an opt-in emit-protovalidate emitter option.

Category: Feature Request

Area: emitter:protobuf

🔍 Analysis

• Affected component: typespec/protobuf emitter
• Related issues: This is a follow-up to [Feature Request] [protobuf] Support schematized declaration options. #4090 (schematized declaration options for protobuf) and Runtime validation for Protobuf Emitter? #7838. It intentionally scopes to only constraints expressible via existing TypeSpec core decorators, avoiding any need for new protobuf-specific decorators.
• Approach: Opt-in via emit-protovalidate flag. Adds import "buf/validate/validate.proto" automatically when at least one constraint is emitted. Maps standard TypeSpec constraint decorators to the corresponding buf.validate field option rules.
• Mapping coverage: numeric range (min/maxValue + exclusive variants), string length, pattern, repeated item counts, and a subset of format values (email, uuid, hostname, ip, ipv4, ipv6, uri).
• Out of scope (per author): CEL cross-field expressions, required/ignore semantics, well-known-type rules — these would need new protobuf-specific decorators.
• The OpenAPI emitter already honours these same decorators, so this closes a parity gap with an ecosystem-standard validation library.

📝 Suggested next steps

• Maintainers confirm whether the general direction (emit-protovalidate opt-in + buf.validate mapping) is acceptable
• Author opens a PR with the working implementation
• Decide whether format values beyond the listed set should warn or be silently ignored
• Consider adding docs / changelog entry for the new emitter option

Generated by Agentic Triage

[prankstrisse]

I need this feature too! Feel free to reach out if I could be of any help implementing or reviewing