Entrée (schéma .proto)

Sortie (rapport de validation)

Ce que fait cet outil

Vous enregistrez un fichier Protocol Buffers, vous lancez protoc ou buf, et la build meurt sur une erreur ligne/colonne cryptique. Ce validateur parse votre .proto avec les mêmes règles qu’un compilateur strict applique et vous dit ce qui ne va pas — en clair, avant que vous ne committiez et que la pipeline CI ne le détecte à votre place.

Au-delà du « ça parse ? », l’outil exécute une passe de lint avec les contrôles que la spec exige réellement : les numéros de champ doivent être dans 1..536870911, la plage 19000..19999 est réservée par Google en interne, chaque numéro de champ d’un message doit être unique, et les noms de champ ne doivent pas se répéter. Ce sont les violations qui produisent les vrais échecs de build, et le validateur les fait toutes remonter d’un coup au lieu d’une-par-une comme le compilateur.

Tout tourne dans votre navigateur — votre .proto, vos noms de message, vos chemins de package ne quittent jamais votre machine. Le parser gère les directives syntax/package/import, les commentaires de ligne et de bloc, les blocs message et enum imbriqués, oneof, map<K, V>, repeated, optional, les services (ignorés) et les options de champ. Conçu pour le même flux de travail que le guide officiel du langage proto3.

Comment l’utiliser

Trois étapes, ça tourne pendant que vous tapez. L’éditeur de sortie se met à jour ~300 ms après que vous arrêtez d’éditer.

Collez votre schéma .proto

Déposez le schéma dans l’éditeur de gauche — un seul fichier, peu importe la longueur. syntax = "proto3"; en haut est OK mais facultatif. Le parser gère les import (ignorés — la résolution multi-fichiers est hors périmètre ici, collez les messages importés en ligne si vous avez besoin de les valider). Tous les commentaires sont retirés avant le parsing.

Si votre éditeur ajoute des guillemets typographiques au collage, le validateur peut signaler une erreur de tokenisation. Retirez-les ou collez depuis une source en texte brut.

Lisez le rapport

À droite : un check vert si le schéma est propre, une liste de problèmes sinon. Chaque problème pointe sur le message et le champ exact, donc vous corrigez dans votre éditeur sans grep. Le rapport résume aussi le nombre de messages, le nombre d’enums et le total des champs.

Corrigez et recollez

Appliquez le correctif dans votre éditeur, recollez le schéma à jour. La sortie se revalide en moins d’une seconde. Pas de rechargement, pas de rebuild, pas d’attente que CI revienne en rouge. Quand le schéma est propre, copiez le rapport dans un commentaire de PR si vous voulez garder une trace de la validation.

Quand ça fait vraiment gagner du temps

Attraper les erreurs avant de pousser sur CI

Votre équipe lance buf lint en CI. Valider d’abord en local, c’est éviter le cycle push, attente, rouge, fix, push — tout l’aller-retour s’écrase dans un seul onglet de navigateur.

Reviewer une PR Protobuf d’un collègue

Vous reviewez le changement de schéma d’un collègue mais vous n’avez pas la toolchain protoc installée en local. Collez le nouveau .proto ici, vérifiez qu’il est structurellement propre, et laissez une review focalisée plutôt qu’un « ça a l’air bien, on ship ».

Migrer de proto2 vers proto3

Les vieux schémas utilisent souvent required (parti en proto3) ou ont des numéros de champ qui semblent corrects jusqu’à ce que vous les vérifiiez. Le validateur signale les doublons et les numéros hors plage en une seule passe, ce qui va plus vite que de relire 800 lignes de .proto à la main.

Valider un .proto généré par un outil de code-gen

Les générateurs (par ex. JSON Schema → Protobuf, OpenAPI → Protobuf) produisent parfois des schémas avec des erreurs de bord — numéros de champ en double, collisions avec la plage réservée. Faites passer la sortie dans le validateur avant de lui faire confiance.

Questions fréquentes

Mon schéma .proto est-il envoyé sur un serveur ?

Non. Le parser et les contrôles de lint tournent entièrement dans votre navigateur en JavaScript. Ouvrez les DevTools et regardez l’onglet Network pendant que vous collez — zéro requête. Pratique pour des schémas qui incluent des noms de types internes, des chemins de package ou tout ce que vous ne voudriez pas envoyer à un validateur tiers.

Qu’est-ce que la passe de lint vérifie réellement ?

Les numéros de champ doivent être dans 1..536870911 (en excluant la plage 19000..19999 réservée par Google), chaque numéro de champ d’un message doit être unique, et chaque nom de champ d’un message doit être unique. Tout ce qui échoue à l’une de ces règles est rapporté avec le chemin exact message.field. L’étape de parsing échoue aussi sur les points-virgules manquants, les accolades non appariées, les tokens inattendus, etc.

Est-ce que ça valide contre la spec proto3 ou proto2 ?

Ça accepte les deux syntaxes (default-zero proto3, qualificateurs required/optional proto2, etc.). Les contrôles de lint sont définis par la spec et s’appliquent aux deux. Les contrôles les plus stricts comme « pas de required en proto3 » ne sont pas appliqués ici — protoc lui-même les attrapera.

Pourquoi mon numéro de champ 19000 est-il signalé ?

La plage 19000..19999 est réservée par Google en interne pour l’implémentation de Protocol Buffers. Si vous attribuez un numéro de champ dans cette plage, le vrai protoc refusera le schéma. Le validateur l’attrape tôt pour que vous l’appreniez par cet outil plutôt que par une erreur de build confuse.

Suit-il les imports ?

Non. Les import sont reconnus et ignorés — les types de message multi-fichiers se résolvent en « inconnu » et ne sont pas validés. Si vous avez besoin de valider un message qui dépend de types importés, collez les messages importés dans la même entrée.

Quelle taille de schéma peut-il gérer ?

Des dizaines de milliers de lignes sans problème. La validation est locale, pas d’upload, pas de rate limit, pas d’aller-retour réseau — collez le repo entier si vous voulez, la limite c’est la mémoire de votre navigateur.

Outils associés

Si vous travaillez avec Protobuf et JSON, ces outils s’associent bien :

Validateur Protobuf