Validateur et analyseur de messages Conventional Commits

Il reconnaît les types courants liés au build, à la maintenance, à la CI, à la documentation, aux fonctionnalités, aux corrections, aux performances, à la refactorisation, aux annulations, au style et aux tests. Utilisez-le pour repérer les en-têtes mal formés ou les types inconnus avant leur entrée dans l’historique partagé, un processus de publication ou un journal des modifications automatisé. Son résultat compact est directement exploitable par vos scripts.

Contrôlez l’en-tête et extrayez les champs utiles

Envoyez le message de commit complet dans le champ de texte. Le validateur normalise les fins de ligne et examine la première ligne comme en-tête Conventional Commits. Le message peut donc conserver ensuite une ligne vide, des paragraphes de corps et des pieds. Un en-tête valide commence par un type reconnu en minuscules. Il peut se poursuivre par une portée entre parenthèses, recevoir un point d’exclamation pour signaler une rupture de compatibilité, puis doit contenir deux-points, exactement une espace de séparation et une description non vide. Par exemple, <code>feat(parser): support escaped delimiters</code> produit le type <code>feat</code>, la portée <code>parser</code> et la description <code>support escaped delimiters</code>. Le résultat normal contient également <code>valid: true</code> et un champ booléen de rupture. En l’absence de portée, cette propriété est omise plutôt que remplie par une valeur vide ou nulle trompeuse. Les erreurs de syntaxe et types inconnus génèrent une erreur d’entrée non valide accompagnée d’une explication directe. Un hook d’éditeur ou un pipeline peut ainsi proposer une correction utile sans devoir interpréter un résultat partiellement analysé.

Comprenez la convention reconnue

Conventional Commits définit la forme d’un en-tête tout en laissant chaque projet établir son vocabulaire de types. Cette capacité utilise volontairement un ensemble fixe et pratique afin de produire des résultats prévisibles entre dépôts : build, chore, ci, docs, feat, fix, perf, refactor, revert, style et test. Un en-tête correctement formé avec un autre mot échoue tout de même, car accepter n’importe quel terme supprimerait la validation de type recherchée. Les types doivent être en minuscules. Les portées sont facultatives et peuvent contenir des lettres minuscules, des chiffres, des points, des traits de soulignement, des barres obliques ou des traits d’union ; elles commencent obligatoirement par une lettre ou un chiffre. Des portées courantes comme <code>api</code>, <code>web-client</code> et <code>packages/core</code> sont donc admises, contrairement aux espaces ambigus et aux parenthèses non appariées. La description conserve sa ponctuation et ses majuscules d’origine, mais ne peut commencer ni finir par une espace. Un point d’exclamation placé juste avant les deux-points signale une rupture et est renvoyé séparément. Un pied <code>BREAKING CHANGE</code> peut rester dans le corps, mais le booléen actuel dépend uniquement du marqueur de l’en-tête et n’interprète pas les pieds.

Intégrez une validation déterministe au développement

Utilisez le validateur dès qu’un message proposé est disponible : dans un hook d’édition du commit, un contrôle de pull request, une file de fusion ou un service qui prépare les métadonnées d’une publication. Un hook local fournit le retour le plus rapide, tandis qu’un contrôle côté serveur garantit que les commits créés par une automatisation ou un autre client respectent la même politique. L’analyseur est déterministe et effectue un parcours borné de la chaîne. Il ne contacte aucun hébergeur de dépôt, n’inspecte aucun objet Git, ne déduit pas l’intention d’un diff, ne réécrit pas la description et n’utilise aucun service externe. La même entrée produit donc les mêmes champs ou la même erreur dans le navigateur et via l’API. Considérez le type, la portée et la description renvoyés comme des données de classement pour regrouper un journal des modifications, appliquer des règles de publication ou alimenter des tableaux de bord, mais gardez séparés les contrôles sémantiques propres au projet. Le validateur peut confirmer que <code>fix(auth): reject expired tokens</code> est structurellement correct, sans prouver que le changement corrige un défaut ni que <code>auth</code> est un paquet autorisé. Associez-le à la politique du dépôt pour imposer des portées ou références de ticket plus strictes.