Validatore di messaggi Conventional Commits

Riconosce i tipi comuni relativi a build, manutenzione, CI, documentazione, funzionalità, correzioni, prestazioni, refactoring, ripristini, stile e test. Lo usi per individuare intestazioni non valide o tipi sconosciuti prima che entrino nella cronologia condivisa, nel flusso di rilascio o in un changelog automatico. Il risultato compatto è subito utilizzabile dagli script senza ulteriore analisi testuale.

Controlli l’intestazione ed estragga i campi utili

Invii il messaggio di commit completo nel campo di testo. Il validatore normalizza le terminazioni di riga ed esamina la prima riga come intestazione Conventional Commits; il messaggio può quindi mantenere sotto una riga vuota, paragrafi del corpo e piè di pagina. Un’intestazione valida inizia con un tipo riconosciuto in minuscolo. Può proseguire con un ambito tra parentesi, aggiungere un punto esclamativo per segnalare una modifica incompatibile e deve poi contenere due punti, esattamente uno spazio separatore e una descrizione non vuota. Per esempio, <code>feat(parser): support escaped delimiters</code> restituisce il tipo <code>feat</code>, l’ambito <code>parser</code> e la descrizione <code>support escaped delimiters</code>. Il risultato normale include inoltre <code>valid: true</code> e un campo booleano di incompatibilità. Se manca l’ambito, la proprietà viene omessa anziché riempita con un valore vuoto o nullo fuorviante. Errori di sintassi e tipi sconosciuti generano un errore di input non valido con una spiegazione diretta, così un hook dell’editor o una pipeline può suggerire una correzione utile senza interpretare un risultato analizzato solo in parte.

Comprenda la convenzione riconosciuta

Conventional Commits definisce la forma dell’intestazione, lasciando ai progetti la possibilità di stabilire il proprio vocabolario di tipi. Questa capacità usa deliberatamente un insieme fisso e pratico per fornire risultati prevedibili tra repository: build, chore, ci, docs, feat, fix, perf, refactor, revert, style e test. Un’intestazione formalmente corretta con un’altra parola non viene accettata, perché ammettere qualsiasi termine annullerebbe la validazione del tipo richiesta. I tipi devono essere minuscoli. Gli ambiti sono facoltativi e possono contenere lettere minuscole, cifre, punti, trattini bassi, barre o trattini; devono iniziare con una lettera o una cifra. Sono quindi utilizzabili ambiti comuni come <code>api</code>, <code>web-client</code> e <code>packages/core</code>, mentre vengono respinti spazi ambigui e parentesi non abbinate. La descrizione conserva punteggiatura e maiuscole originali, ma non può iniziare o terminare con spazi. Un punto esclamativo immediatamente prima dei due punti indica una modifica incompatibile e viene restituito separatamente. Un piè di pagina <code>BREAKING CHANGE</code> può restare nel corpo, ma il valore booleano attuale deriva solo dal marcatore nell’intestazione e non interpreta la semantica del piè di pagina.

Inserisca una validazione deterministica nello sviluppo

Usi il validatore non appena è disponibile un messaggio proposto: in un hook dell’editor dei commit, in un controllo della pull request, in una coda di merge o in un servizio che prepara i metadati di rilascio. Un hook locale offre il riscontro più rapido, mentre la validazione sul server garantisce che i commit creati dall’automazione o da client alternativi rispettino la stessa politica. L’analizzatore è deterministico ed esegue una scansione limitata della stringa. Non contatta un host di repository, non ispeziona oggetti Git, non deduce l’intento da un diff, non riscrive la descrizione fornita e non usa servizi esterni. Lo stesso input genera pertanto gli stessi campi o lo stesso errore nel browser e tramite API. Consideri tipo, ambito e descrizione restituiti come dati di classificazione per raggruppare changelog, applicare regole di rilascio o alimentare dashboard, ma mantenga separati i controlli semantici specifici del progetto. Il validatore può confermare che <code>fix(auth): reject expired tokens</code> è strutturalmente valido, ma non può provare che la modifica corregga un errore o che <code>auth</code> sia un pacchetto consentito. Lo combini con la politica del repository se servono elenchi di ambiti o riferimenti ai ticket più rigorosi.