Inndata (.proto-skjema)

Utdata (valideringsrapport)

Hva dette verktøyet gjør

Du lagrer en Protocol Buffers-fil, kjører protoc eller buf, og bygget dør med en kryptisk linje/kolonne-feil. Denne validatoren parser .proto-filen din etter samme regler som en streng kompilator bruker, og forteller deg på klart språk hva som er galt — før du committer og CI-pipen plukker det opp for deg.

Utover «ble det parset?» kjører verktøyet også et lint-pass med kontrollene specen faktisk krever: feltnumre må ligge i 1..536870911, området 19000..19999 er reservert internt av Google, hvert feltnummer i en message må være unikt, og feltnavn kan ikke gjenta seg. Det er disse bruddene som gir reelle build-feil, og validatoren henter dem alle frem i én gang i stedet for én feil av gangen slik kompilatoren gjør.

Alt kjører i nettleseren din — .proto-filen din, message-navnene dine og package-stiene dine forlater aldri maskinen din. Parseren håndterer syntax-/package-/import-direktiver, linje- og blokkommentarer, nøstede message- og enum-blokker, oneof, map<K, V>, repeated, optional, services (hoppes over) og field options. Designet for samme arbeidsflyt som den offisielle proto3-språkguiden.

Slik bruker du det

Tre steg, kjører mens du skriver. Output-editoren oppdateres ~300 ms etter at du slutter å skrive.

Lim inn .proto-skjemaet ditt

Slipp skjemaet inn i editoren til venstre — én fil, uansett lengde. syntax = "proto3"; øverst er greit, men valgfritt. Parseren kjenner igjen import-statements (men hopper over dem — oppløsning på tvers av filer er utenfor scope her; lim inn importerte messages inline hvis de skal valideres). Alle kommentarer fjernes før parsing.

Hvis editoren din legger til smarte anførselstegn ved innliming, kan validatoren flagge en tokeniseringsfeil. Fjern dem eller lim inn fra en ren tekstkilde.

Les rapporten

Til høyre: en grønn hake hvis skjemaet er rent, en liste over problemer ellers. Hvert problem peker på den eksakte messagen og det eksakte feltet, så du fikser i editoren din uten å greppe. Rapporten oppsummerer også antall messages, antall enums og samlet antall felt.

Fiks og lim inn på nytt

Påfør fiksen i editoren din, lim inn det oppdaterte skjemaet. Output revalideres på under et sekund. Ingen reload, ingen rebuild, ingen venting på at CI skal komme rødt tilbake. Når skjemaet er rent, kopier rapporten inn i en PR-kommentar hvis du vil ha en notering av valideringen.

Når det faktisk sparer tid

Fang feil før du pusher til CI

Teamet ditt kjører buf lint i CI. Å validere lokalt først betyr at du slipper push, vente, se rødt, fikse og pushe igjen — hele syklusen krymper til én nettleserfane.

Reviewe en Protobuf-PR fra en kollega

Du reviewer en skjema-endring, men har ikke protoc-toolchainen kjørende lokalt. Lim inn den nye .proto-filen her, sjekk at den er strukturelt ren, og legg igjen en fokusert review i stedet for «ser bra ut, ship it».

Migrere fra proto2 til proto3

Gamle skjemaer bruker ofte required (borte i proto3) eller har feltnumre som ser greie ut helt til du sjekker dem. Validatoren flagger duplikater og out-of-range-numre i én pass, noe som er raskere enn å lese 800 linjer .proto for hånd.

Validere en .proto generert av et code-gen-verktøy

Generatorer (f.eks. JSON Schema → Protobuf, OpenAPI → Protobuf) lager av og til skjemaer med edge-case-feil — dupliserte feltnumre, treff i det reserverte området. Send outputen gjennom validatoren før du stoler på den.

Vanlige spørsmål

Sendes .proto-skjemaet mitt til en server?

Nei. Parseren og lint-sjekkene kjører fullt ut i nettleseren din som JavaScript. Åpne DevTools og se på Network-fanen mens du limer inn — null requests. Nyttig for skjemaer som inneholder interne typenavn, package-stier eller hva som helst du ikke ville sendt til en tredjeparts-validator.

Hva sjekker lint-passet egentlig?

Feltnumre må være i 1..536870911 (utenom Google-reserverte 19000..19999), hvert feltnummer i en message må være unikt, og hvert feltnavn i en message må være unikt. Alt som faller på én av dem rapporteres med eksakt message.field-sti. Parse-steget feiler også på manglende semikolon, upparede krøllparenteser, uventede tokens osv.

Validerer det mot proto3-specen eller proto2?

Det godtar begge syntaksene (proto3 default-zero, proto2 required/optional-kvalifikatorer osv.). Lint-sjekkene er definert av specen og gjelder begge. De strengeste sjekkene som «ingen required i proto3» tvinges ikke gjennom her — det fanger protoc selv.

Hvorfor flagges feltnummer 19000?

Området 19000..19999 er reservert internt av Google for bruk i Protocol Buffers-implementasjonen. Tildeler du et feltnummer i det området, vil ekte protoc avvise skjemaet. Validatoren fanger det tidlig, så du oppdager det fra dette verktøyet i stedet for fra en forvirret build-feil.

Følger det imports?

Nei. import-statements gjenkjennes og hoppes over — message-typer i andre filer løses som «unknown» og valideres ikke. Må du validere en message som er avhengig av importerte typer, lim inn de importerte messagene i samme input.

Hvor stort skjema kan det håndtere?

Titusenvis av linjer uten problem. Validering er lokal, ingen opplasting, ingen rate limit, ingen nettverksrundtur — lim inn hele repoet hvis du vil, grensen er nettleserens minne.

Relaterte verktøy

Hvis du jobber med Protobuf og JSON, passer disse godt sammen:

Protobuf-validator