Validador de mensagens Conventional Commits

Ele reconhece os tipos comuns de build, manutenção, CI, documentação, recurso, correção, desempenho, refatoração, reversão, estilo e teste. Use-o para encontrar cabeçalhos malformados ou tipos desconhecidos antes que entrem no histórico compartilhado, no fluxo de lançamento ou no changelog automático. O resultado compacto fica pronto para scripts sem exigir outra análise de texto.

Verifique o cabeçalho e extraia campos úteis

Envie a mensagem de commit completa no campo de texto. O validador normaliza as quebras de linha e examina a primeira linha como cabeçalho de Conventional Commits; assim, a mensagem ainda pode conter abaixo uma linha vazia, parágrafos de corpo e rodapés. Um cabeçalho válido começa com um tipo reconhecido em letras minúsculas. Ele pode continuar com um escopo entre parênteses, receber um ponto de exclamação para indicar uma mudança incompatível e depois deve conter dois-pontos, exatamente um espaço separador e uma descrição não vazia. Por exemplo, <code>feat(parser): support escaped delimiters</code> devolve o tipo <code>feat</code>, o escopo <code>parser</code> e a descrição <code>support escaped delimiters</code>. O resultado normal também inclui <code>valid: true</code> e um campo booleano de incompatibilidade. Quando não há escopo, a propriedade é omitida em vez de receber um valor vazio ou nulo enganoso. Falhas de sintaxe e tipos desconhecidos produzem um erro de entrada inválida com explicação direta, permitindo que um hook do editor ou pipeline apresente uma correção útil sem interpretar um resultado analisado apenas em parte.

Entenda a convenção reconhecida

Conventional Commits define o formato do cabeçalho, mas permite que os projetos criem seu próprio vocabulário de tipos. Esta capacidade adota intencionalmente um conjunto fixo e prático para gerar resultados previsíveis entre repositórios: build, chore, ci, docs, feat, fix, perf, refactor, revert, style e test. Um cabeçalho com formato correto e outra palavra ainda falha, pois aceitar qualquer termo eliminaria a validação de tipo solicitada. Os tipos devem estar em minúsculas. Escopos são opcionais e podem conter letras minúsculas, dígitos, pontos, sublinhados, barras ou hífens; eles devem começar por letra ou dígito. Isso permite escopos comuns como <code>api</code>, <code>web-client</code> e <code>packages/core</code>, enquanto rejeita espaços ambíguos e parênteses sem correspondência. A descrição mantém pontuação e capitalização originais, mas não pode começar nem terminar com espaços. Um ponto de exclamação imediatamente antes dos dois-pontos indica mudança incompatível e é retornado separadamente. Um rodapé <code>BREAKING CHANGE</code> pode permanecer no corpo, porém o resultado atual obtém o booleano de incompatibilidade somente do marcador do cabeçalho e não interpreta a semântica dos rodapés.

Inclua validação determinística no desenvolvimento

Use o validador assim que uma mensagem proposta estiver disponível: em um hook do editor de commits, uma verificação de pull request, uma fila de merge ou um serviço que prepara metadados de lançamento. Um hook local oferece retorno mais rápido, enquanto a validação no servidor garante que commits criados por automação ou clientes alternativos sigam a mesma política. O analisador é determinístico e faz uma varredura limitada da string. Ele não acessa um provedor de repositório, inspeciona um objeto Git, deduz intenção a partir de um diff, reescreve a descrição fornecida nem contata serviços externos. Portanto, a mesma entrada gera os mesmos campos ou o mesmo erro no navegador e pela API. Trate tipo, escopo e descrição retornados como dados de classificação para agrupar changelogs, aplicar regras de lançamento ou alimentar painéis, mas mantenha separadas as verificações semânticas específicas do projeto. Por exemplo, o validador confirma que <code>fix(auth): reject expired tokens</code> é estruturalmente válido, mas não prova que a alteração corrige um defeito nem que <code>auth</code> seja um pacote permitido. Combine-o com a política do repositório quando precisar de listas de escopos ou referências a tickets mais rigorosas.