Wejście (schemat .proto)

Wyjście (raport walidacji)

Co robi to narzędzie

Zapisujesz plik Protocol Buffers, odpalasz protoc albo buf, a build umiera na zagadkowym błędzie z numerem linii i kolumny. Ten walidator parsuje twój .proto z tymi samymi regułami, które wymusza rygorystyczny kompilator, i mówi prostym językiem, co jest nie tak — zanim zrobisz commit i pipeline CI wyłapie to za ciebie.

Poza samym "czy się zparsowało", narzędzie robi też pass lintera ze sprawdzeniami, których faktycznie wymaga spec: numery pól muszą mieścić się w 1..536870911, zakres 19000..19999 jest zarezerwowany przez Google na potrzeby wewnętrzne, każdy numer pola w obrębie message’a musi być unikalny, a nazwy pól nie mogą się powtarzać. Właśnie te naruszenia powodują realne porażki buildów, a walidator pokazuje wszystkie naraz, zamiast wyrzucać błąd po błędzie jak kompilator.

Wszystko działa w twojej przeglądarce — twój .proto, nazwy message’y i ścieżki package’y nigdy nie opuszczają twojej maszyny. Parser obsługuje dyrektywy syntax/package/import, komentarze liniowe i blokowe, zagnieżdżone bloki message i enum, oneof, map<K, V>, repeated, optional, services (pomijane) oraz field options. Zaprojektowany pod ten sam workflow, co oficjalny przewodnik języka proto3.

Jak go używać

Trzy kroki, leci podczas pisania. Edytor wyjścia odświeża się ~300 ms po tym, jak przestaniesz pisać.

Wklej swój schemat .proto

Wrzuć schemat do lewego edytora — pojedynczy plik, dowolnej długości. syntax = "proto3"; na górze jest okej, ale opcjonalne. Parser obsługuje statementy import (są pomijane — rozwiązywanie międzyplikowe jest poza zakresem; jeśli chcesz zwalidować również importowane message’e, wklej je inline). Wszystkie komentarze są usuwane przed parsowaniem.

Jeśli twój edytor przy wklejaniu dodaje "inteligentne" cudzysłowy, walidator może zgłosić błąd tokenizacji. Wywal je albo wklej z czystego źródła tekstowego.

Przeczytaj raport

Po prawej: zielony ptaszek, jeśli schemat jest czysty, lista problemów, jeśli nie. Każdy problem wskazuje dokładnego message’a i pole, więc poprawiasz w edytorze bez grepowania. Raport zawiera też podsumowanie: liczbę message’y, liczbę enumów i sumę pól.

Popraw i wklej ponownie

Wprowadź poprawkę w swoim edytorze i wklej zaktualizowany schemat. Wyjście rewaliduje się w mniej niż sekundę. Bez przeładowania, bez rebuildu, bez czekania, aż CI zrobi się czerwone. Gdy schemat jest czysty, skopiuj raport do komentarza w PR-ze, jeśli chcesz mieć ślad walidacji.

Kiedy to naprawdę oszczędza czas

Łapanie błędów przed wypchnięciem do CI

Twój zespół odpala buf lint w CI. Walidacja najpierw lokalnie oznacza, że nie pushujesz, czekasz, widzisz czerwień, poprawiasz i pushujesz znowu — cały cykl zwija się do jednej karty przeglądarki.

Review PR-a Protobuf od kolegi

Reviewujesz zmianę schematu od kolegi z zespołu, ale nie masz lokalnie postawionego toolchaina protoc. Wklej nowy .proto tutaj, sprawdź, czy strukturalnie jest czysty, i zostaw konkretny review zamiast "wygląda ok, mergujemy".

Migracja z proto2 na proto3

Stare schematy często używają required (zniknęło w proto3) albo mają numery pól, które wyglądają w porządku, dopóki ich nie sprawdzisz. Walidator wyłapuje duplikaty i numery poza zakresem w jednym przebiegu, co jest szybsze niż czytanie ręczne 800 linii .proto.

Walidacja .proto wygenerowanego z narzędzia code-gen

Generatory (np. JSON Schema → Protobuf, OpenAPI → Protobuf) potrafią produkować schematy z błędami brzegowymi — zduplikowane numery pól, trafienia w zarezerwowany zakres. Przepuść wynik przez walidator, zanim mu zaufasz.

Częste pytania

Czy mój schemat .proto jest wysyłany na serwer?

Nie. Parser i sprawdzenia lintera działają w całości w twojej przeglądarce jako JavaScript. Otwórz DevTools i obserwuj zakładkę Network podczas wklejania — zero żądań. Przydatne dla schematów zawierających wewnętrzne nazwy typów, ścieżki package’y albo cokolwiek, czego nie chciałbyś wysyłać do walidatora od kogoś z zewnątrz.

Co konkretnie sprawdza pass lintera?

Numery pól muszą być w 1..536870911 (z wyłączeniem zarezerwowanego przez Google zakresu 19000..19999), każdy numer pola w obrębie message’a musi być unikalny, a każda nazwa pola w obrębie message’a musi być unikalna. Wszystko, co łamie którąś z tych reguł, jest raportowane z dokładną ścieżką message.field. Krok parsowania też wywala się na brakujących średnikach, niedopasowanych klamrach, nieoczekiwanych tokenach itd.

Czy waliduje względem speca proto3 czy proto2?

Akceptuje obie składnie (proto3 default-zero, kwalifikatory required/optional z proto2 itd.). Sprawdzenia lintera są zdefiniowane przez spec i obowiązują w obu przypadkach. Najsurowsze checki w stylu "żadnego required w proto3" nie są tu egzekwowane — od tego jest sam protoc.

Dlaczego mój numer pola 19000 jest oznaczany?

Zakres 19000..19999 jest zarezerwowany wewnętrznie przez Google na potrzeby implementacji Protocol Buffers. Jeśli przypiszesz numer pola z tego zakresu, prawdziwy protoc odrzuci schemat. Walidator wyłapuje to wcześnie, więc dowiadujesz się od tego narzędzia, a nie z mglistego komunikatu buildu.

Czy podąża za importami?

Nie. Statementy import są rozpoznawane i pomijane — typy message z innych plików rozwiązują się jako "unknown" i nie są walidowane. Jeśli musisz zwalidować message zależny od importowanych typów, wklej importowane message do tego samego wejścia.

Jak duży schemat to obsłuży?

Dziesiątki tysięcy linii bez problemu. Walidacja jest lokalna, bez uploadu, bez rate limitu, bez round-tripa po sieci — wklej całe repo, jeśli chcesz, limitem jest pamięć twojej przeglądarki.

Powiązane narzędzia

Jeśli pracujesz z Protobuf i JSON, te dobrze ze sobą grają:

Walidator Protobuf