Input (schema .proto)

Output (report di validazione)

Cosa fa questo strumento

Salvi un file Protocol Buffers, lanci protoc o buf, e la build muore con un errore criptico di riga/colonna. Questo validator analizza il tuo .proto con le stesse regole di un compilatore rigoroso e ti dice cosa non va — in linguaggio chiaro, prima che tu faccia commit e che la pipeline CI te lo segnali.

Oltre al "ha fatto il parse?", lo strumento esegue un passaggio di lint con i controlli che la spec richiede davvero: i numeri di campo devono stare in 1..536870911, l’intervallo 19000..19999 è riservato internamente da Google, ogni numero di campo in una message deve essere unico, e i nomi di campo non possono ripetersi. Sono queste le violazioni che producono fallimenti di build reali, e il validator le mostra tutte in una sola passata invece di farti vedere un errore alla volta come fa il compilatore.

Tutto gira nel tuo browser — il tuo .proto, i nomi delle tue message, i tuoi package path non lasciano mai la tua macchina. Il parser gestisce le direttive syntax/package/import, commenti di linea e di blocco, blocchi message ed enum annidati, oneof, map<K, V>, repeated, optional, services (saltati) e options di campo. Pensato per lo stesso flusso di lavoro della guida ufficiale del linguaggio proto3.

Come usarlo

Tre passaggi, gira mentre digiti. L’editor di output si aggiorna ~300 ms dopo che smetti di scrivere.

Incolla il tuo schema .proto

Lascia cadere lo schema nell’editor di sinistra — un singolo file, della lunghezza che vuoi. syntax = "proto3"; in cima va bene ma è opzionale. Il parser riconosce le import (le salta — la risoluzione tra file è fuori scope qui; se ti servono validate, incolla le message importate inline). I commenti vengono rimossi prima del parsing.

Se il tuo editor inserisce virgolette tipografiche quando incolli, il validator può segnalare un errore di tokenizzazione. Toglile o incolla da una sorgente di testo semplice.

Leggi il report

A destra: una spunta verde se lo schema è pulito, un elenco di problemi altrimenti. Ogni voce punta alla message e al campo esatti, così li sistemi nel tuo editor senza bisogno di grep. Il report riassume anche numero di message, numero di enum e totale dei campi.

Sistema e re-incolla

Applica il fix nel tuo editor, incolla lo schema aggiornato. L’output viene rivalidato in meno di un secondo. Niente reload, niente rebuild, niente attesa che la CI torni rossa. Quando lo schema è pulito, copia il report in un commento di PR se vuoi tenere traccia della validazione.

Quando fa davvero risparmiare tempo

Beccare gli errori prima di pushare in CI

Il tuo team lancia buf lint in CI. Validare prima in locale significa non fare push, aspettare, vedere rosso, sistemare e ripushare — l’intero ciclo si comprime in una sola scheda del browser.

Revieware un PR Protobuf di un collega

Stai reviewando una modifica di schema ma non hai la toolchain di protoc installata in locale. Incolla il nuovo .proto qui, vedi se è strutturalmente pulito e lascia una review mirata invece di un "sembra ok, vai".

Migrare da proto2 a proto3

Gli schemi vecchi spesso usano required (sparito in proto3) o hanno numeri di campo che sembrano a posto finché non li controlli. Il validator segnala duplicati e numeri fuori range in una sola passata, che è più rapido che leggere a mano 800 righe di .proto.

Validare un .proto generato da uno strumento di code-gen

I generatori (es. JSON Schema → Protobuf, OpenAPI → Protobuf) ogni tanto producono schemi con errori al margine — campi duplicati, finiscono nell’intervallo riservato. Passa l’output dal validator prima di fidartene.

Domande frequenti

Il mio schema .proto viene mandato a un server?

No. Il parser e i controlli di lint girano interamente nel tuo browser come JavaScript. Apri i DevTools e guarda il tab Network mentre incolli — zero richieste. Utile per schemi che includono nomi di tipi interni, package path, o qualsiasi cosa che non vorresti spedire a un validator di terze parti.

Cosa controlla esattamente il passaggio di lint?

I numeri di campo devono stare in 1..536870911 (escluso il range 19000..19999 riservato da Google), ogni numero di campo in una message deve essere unico, e ogni nome di campo in una message deve essere unico. Tutto ciò che fallisce uno di questi controlli viene riportato con il path esatto message.field. Il passaggio di parse fallisce anche su punti e virgola mancanti, parentesi non bilanciate, token inaspettati e così via.

Valida contro la spec di proto3 o di proto2?

Accetta entrambe le sintassi (default-zero proto3, qualificatori required/optional di proto2 ecc.). I controlli di lint sono definiti dalla spec e si applicano a entrambe. I controlli più stringenti tipo "niente required in proto3" non vengono forzati qui — ci pensa protoc.

Perché il mio campo numero 19000 viene segnalato?

L’intervallo 19000..19999 è riservato internamente da Google per l’implementazione di Protocol Buffers. Se assegni un numero di campo in quell’intervallo, il vero protoc rifiuta lo schema. Il validator lo prende presto, così te ne accorgi da questo strumento invece che da un messaggio di build confuso.

Segue gli import?

No. Le import vengono riconosciute e saltate — i tipi message di altri file vengono risolti come "sconosciuti" e non sono validati. Se devi validare una message che dipende da tipi importati, incolla anche le message importate nello stesso input.

Quanto può essere grande lo schema?

Decine di migliaia di righe senza problemi. La validazione è locale, nessun upload, nessun rate limit, nessun round-trip di rete — incolla pure l’intero repo, il limite è la memoria del tuo browser.

Strumenti correlati

Se stai lavorando con Protobuf e JSON, questi si abbinano bene:

Validator Protobuf