Entrada (esquema .proto)

Salida (informe de validación)

Qué hace esta herramienta

Guardas un archivo de Protocol Buffers, ejecutas protoc o buf, y la build muere con un error críptico de línea/columna. Este validador analiza tu .proto con las mismas reglas que aplica un compilador estricto y te dice qué falla — en lenguaje claro, antes de que hagas commit y la pipeline de CI lo descubra por ti.

Más allá del "¿se ha analizado correctamente?", la herramienta hace un pase de lint con las comprobaciones que la propia spec exige: los números de campo deben estar en 1..536870911, el rango 19000..19999 está reservado por Google a nivel interno, cada número de campo dentro de un mensaje debe ser único y los nombres de campo no pueden repetirse. Estas son las violaciones que producen fallos de build en el mundo real, y el validador las muestra todas de una sola vez en lugar de ir error por error como hace el compilador.

Todo se ejecuta en tu navegador — tu .proto, tus nombres de mensaje y tus rutas de paquete nunca salen de tu máquina. El parser maneja directivas syntax/package/import, comentarios de línea y de bloque, bloques anidados message y enum, oneof, map<K, V>, repeated, optional, servicios (omitidos) y opciones de campo. Pensado para el mismo flujo de trabajo que la guía oficial del lenguaje proto3.

Cómo usarlo

Tres pasos, se ejecuta mientras escribes. El editor de salida se actualiza unos 300 ms después de que dejes de escribir.

Pega tu esquema .proto

Suelta el esquema en el editor de la izquierda — un solo archivo, de la longitud que sea. syntax = "proto3"; arriba está bien pero es opcional. El parser maneja sentencias import (se omiten — la resolución entre archivos queda fuera de alcance aquí; pega los mensajes importados en línea si necesitas validarlos). Todos los comentarios se eliminan antes del análisis.

Si tu editor añade comillas tipográficas al pegar, el validador puede marcar un error de tokenización. Quítalas o pega desde una fuente de texto plano.

Lee el informe

A la derecha: una marca verde si el esquema está limpio, una lista de incidencias si no. Cada incidencia apunta al mensaje y campo exactos, así puedes corregirlos en tu editor sin hacer grep. El informe también resume el número de mensajes, de enums y el total de campos.

Corrige y vuelve a pegar

Aplica el arreglo en tu editor y pega el esquema actualizado. La salida se revalida en menos de un segundo. Sin recargar, sin reconstruir, sin esperar a que CI te devuelva un rojo. Cuando el esquema esté limpio, copia el informe a un comentario de PR si quieres dejar constancia de la validación.

Cuándo realmente ahorra tiempo

Cazar errores antes de empujar a CI

Tu equipo ejecuta buf lint en CI. Validar primero en local significa que no haces push, esperas, ves rojo, arreglas y vuelves a empujar — todo el ciclo se reduce a una sola pestaña del navegador.

Revisar un PR de Protobuf de un compañero

Estás revisando el cambio de esquema de un compañero pero no tienes la toolchain de protoc montada en local. Pega el nuevo .proto aquí, comprueba si está estructuralmente limpio y deja una revisión enfocada en lugar de un "pinta bien, p'alante".

Migrar de proto2 a proto3

Los esquemas antiguos suelen usar required (desaparecido en proto3) o tienen números de campo que parecen correctos hasta que los compruebas. El validador marca duplicados y números fuera de rango en una sola pasada, lo cual es más rápido que leer 800 líneas de .proto a mano.

Validar un .proto generado por una herramienta de code-gen

Los generadores (p. ej. JSON Schema → Protobuf, OpenAPI → Protobuf) a veces producen esquemas con errores de borde — números de campo duplicados, choques con el rango reservado. Pasa la salida por el validador antes de fiarte de ella.

Preguntas habituales

¿Se envía mi esquema .proto a algún servidor?

No. El parser y las comprobaciones de lint se ejecutan completamente en tu navegador como JavaScript. Abre las DevTools y mira la pestaña Network mientras pegas: cero peticiones. Útil para esquemas que incluyen nombres de tipos internos, rutas de paquete o cualquier cosa que no querrías mandar a un validador de terceros.

¿Qué comprueba exactamente el pase de lint?

Los números de campo deben estar en 1..536870911 (excluyendo el rango reservado por Google 19000..19999), cada número de campo dentro de un mensaje debe ser único, y cada nombre de campo dentro de un mensaje debe ser único. Cualquier cosa que falle alguna de estas reglas se reporta con la ruta exacta message.field. El paso de análisis también falla ante puntos y coma faltantes, llaves desbalanceadas, tokens inesperados, etc.

¿Valida contra la spec de proto3 o de proto2?

Acepta ambas sintaxis (default-zero de proto3, calificadores required/optional de proto2, etc.). Las comprobaciones de lint las define la spec y aplican a ambas. Las comprobaciones más estrictas como "nada de required en proto3" no se imponen aquí — protoc se encargará de ellas.

¿Por qué se marca mi número de campo 19000?

El rango 19000..19999 está reservado por Google a nivel interno para uso de la implementación de Protocol Buffers. Si asignas un número de campo en ese rango, protoc real rechazará el esquema. El validador lo caza pronto para que te enteres por esta herramienta y no por un mensaje de build confuso.

¿Sigue las imports?

No. Las sentencias import se reconocen y se omiten — los tipos de mensaje en otros archivos se resuelven como "desconocido" y no se validan. Si necesitas validar un mensaje que depende de tipos importados, pega los mensajes importados en la misma entrada.

¿Cómo de grande puede ser el esquema?

Decenas de miles de líneas sin problema. La validación es local, sin subida, sin rate limit, sin ida y vuelta a la red — pega el repo entero si quieres, el límite es la memoria de tu navegador.

Herramientas relacionadas

Si estás trabajando con Protobuf y JSON, estas combinan bien:

Validador de Protobuf