Entrada (esquema .proto)

Saída (relatório de validação)

O que esta ferramenta faz

Você salva um arquivo Protocol Buffers, roda protoc ou buf, e o build morre com um erro críptico de linha/coluna. Este validador faz o parse do seu .proto com as mesmas regras que um compilador rigoroso aplica e te diz o que está errado — em linguagem clara, antes de você commitar e o pipeline de CI te entregar a conta.

Além do "passou no parse", a ferramenta executa um lint com as checagens que a própria spec exige: números de campo precisam estar em 1..536870911, a faixa 19000..19999 está reservada pelo Google internamente, todo número de campo dentro de uma message tem de ser único, e nomes de campo não podem se repetir. São essas as violações que produzem falhas reais de build, e o validador mostra todas de uma vez em vez de uma por uma como o compilador faz.

Tudo roda no seu navegador — seu .proto, seus nomes de message, seus caminhos de package nunca saem da sua máquina. O parser lida com diretivas syntax/package/import, comentários de linha e bloco, blocos message e enum aninhados, oneof, map<K, V>, repeated, optional, services (ignorados) e options de campo. Pensado para o mesmo workflow do guia oficial da linguagem proto3.

Como usar

Três passos, roda enquanto você digita. O editor de saída atualiza ~300 ms depois que você para de editar.

Cole seu esquema .proto

Jogue o esquema no editor da esquerda — um único arquivo, do tamanho que for. syntax = "proto3"; no topo é bem-vindo, mas opcional. O parser reconhece import (mas pula — resolução entre arquivos está fora do escopo aqui; cole as messages importadas inline se precisar validá-las junto). Todos os comentários são removidos antes do parse.

Se o seu editor inserir aspas tipográficas ao colar, o validador pode reclamar de tokenização. Tire as aspas ou cole de uma fonte de texto puro.

Leia o relatório

À direita: um check verde se o esquema está limpo, uma lista de problemas caso contrário. Cada item aponta a message e o campo exatos, então você corrige no seu editor sem precisar de grep. O relatório também resume contagem de messages, contagem de enums e total de campos.

Corrija e cole de novo

Aplique a correção no seu editor e cole o esquema atualizado. A saída revalida em menos de um segundo. Sem reload, sem rebuild, sem esperar o CI voltar vermelho. Quando o esquema estiver limpo, copie o relatório para um comentário do PR se quiser deixar registro da validação.

Quando isso realmente economiza tempo

Pegar erros antes de empurrar para o CI

Seu time roda buf lint no CI. Validar localmente primeiro significa que você não faz push, espera, vê vermelho, conserta e empurra de novo — o ciclo inteiro vira uma única aba do navegador.

Revisar um PR de Protobuf de um colega

Você está revisando uma mudança de esquema mas não tem a toolchain do protoc instalada. Cole o novo .proto aqui, veja se está estruturalmente limpo e deixe uma review focada em vez de "tá ok, manda".

Migrar de proto2 para proto3

Esquemas antigos costumam usar required (que sumiu no proto3) ou ter números de campo que parecem certos até você conferir. O validador aponta duplicidades e números fora da faixa em uma só passada, o que é mais rápido do que ler 800 linhas de .proto na unha.

Validar um .proto gerado por uma ferramenta de code-gen

Geradores (p. ex. JSON Schema → Protobuf, OpenAPI → Protobuf) às vezes produzem esquemas com erros de borda — campos duplicados, colisões com a faixa reservada. Passe a saída pelo validador antes de confiar.

Dúvidas comuns

Meu esquema .proto é enviado para algum servidor?

Não. O parser e os lints rodam totalmente no seu navegador, em JavaScript. Abra o DevTools e olhe a aba Network enquanto cola — zero requisições. Útil para esquemas que incluem nomes de tipos internos, caminhos de package ou qualquer coisa que você não mandaria para um validador de terceiros.

Quais checagens o lint efetivamente faz?

Os números de campo precisam estar em 1..536870911 (excluindo a faixa 19000..19999 reservada pelo Google), todo número de campo dentro de uma message precisa ser único, e todo nome de campo dentro de uma message precisa ser único. Tudo o que falhar em qualquer dessas é reportado com o caminho exato message.field. A etapa de parse também falha em ponto-e-vírgula faltando, chaves não pareadas, tokens inesperados etc.

Valida contra a spec do proto3 ou do proto2?

Aceita as duas sintaxes (default-zero do proto3, qualificadores required/optional do proto2 etc.). As checagens de lint são definidas pela spec e valem para ambas. As checagens mais rigorosas, do tipo "nada de required em proto3", não são impostas aqui — o próprio protoc cuida disso.

Por que meu campo número 19000 está sendo apontado?

A faixa 19000..19999 é reservada pelo Google internamente para uso da implementação do Protocol Buffers. Se você atribuir um número nessa faixa, o protoc real recusa o esquema. O validador pega isso cedo, então você descobre por aqui em vez de por uma mensagem de build confusa.

Ele segue os imports?

Não. Declarações import são reconhecidas e puladas — tipos de message de outros arquivos resolvem como "unknown" e não são validados. Se você precisa validar uma message que depende de tipos importados, cole as messages importadas no mesmo input.

Qual o tamanho de esquema que ele aguenta?

Dezenas de milhares de linhas tranquilamente. A validação é local, sem upload, sem rate limit, sem ida e volta de rede — cole o repositório inteiro se quiser, o limite é a memória do seu navegador.

Ferramentas relacionadas

Se você está trabalhando com Protobuf e JSON, estas combinam bem:

Validador de Protobuf