Validador y analizador de mensajes Conventional Commits

Reconoce los tipos comunes de compilación, mantenimiento, CI, documentación, funcionalidad, corrección, rendimiento, refactorización, reversión, estilo y pruebas. Úselo para detectar cabeceras mal formadas o tipos desconocidos antes de incorporarlos al historial compartido, a un flujo de publicación o a un registro de cambios automático. El resultado compacto queda listo para scripts sin análisis de texto adicional.

Compruebe la cabecera y extraiga campos útiles

Envíe el mensaje de commit completo en el campo de texto. El validador normaliza los finales de línea y examina la primera línea como cabecera de Conventional Commits, por lo que el mensaje puede conservar debajo una línea en blanco, párrafos de cuerpo y pies. Una cabecera válida comienza con un tipo reconocido en minúsculas. Puede continuar con un ámbito entre paréntesis, añadir un signo de exclamación para señalar un cambio incompatible y, después, debe contener dos puntos, exactamente un espacio separador y una descripción no vacía. Por ejemplo, <code>feat(parser): support escaped delimiters</code> produce el tipo <code>feat</code>, el ámbito <code>parser</code> y la descripción <code>support escaped delimiters</code>. El resultado normal también incluye <code>valid: true</code> y un campo booleano de cambio incompatible. Si no existe ámbito, la propiedad se omite en vez de rellenarse con un valor vacío o nulo engañoso. Los errores de sintaxis y los tipos desconocidos generan un error de entrada no válida con una explicación directa, para que un hook del editor o una canalización muestre una corrección útil sin interpretar un resultado parcial.

Conozca la convención reconocida

Conventional Commits define la forma de una cabecera, pero permite que cada proyecto establezca su vocabulario de tipos. Esta capacidad utiliza deliberadamente un conjunto fijo y práctico para ofrecer resultados previsibles entre repositorios: build, chore, ci, docs, feat, fix, perf, refactor, revert, style y test. Una cabecera bien formada con otra palabra también falla, porque aceptar cualquier término impediría validar el tipo solicitado. Los tipos deben estar en minúsculas. Los ámbitos son opcionales y pueden contener letras minúsculas, dígitos, puntos, guiones bajos, barras o guiones; deben empezar por una letra o un dígito. Así se admiten ámbitos habituales como <code>api</code>, <code>web-client</code> y <code>packages/core</code>, mientras se rechazan espacios ambiguos y paréntesis sin pareja. La descripción conserva su puntuación y uso de mayúsculas originales, pero no puede empezar ni terminar con espacios. Un signo de exclamación justo antes de los dos puntos indica un cambio incompatible y se devuelve por separado. Un pie <code>BREAKING CHANGE</code> puede permanecer en el cuerpo, aunque el resultado actual calcula el booleano únicamente desde el signo de la cabecera y no interpreta la semántica de los pies.

Integre una validación determinista en el desarrollo

Utilice el validador en cuanto esté disponible el mensaje propuesto: en un hook del editor de commits, una comprobación de pull request, una cola de fusión o un servicio que prepare metadatos de publicación. Un hook local ofrece la respuesta más rápida, mientras que la validación del servidor garantiza que los commits creados mediante automatización o clientes alternativos sigan la misma política. El analizador es determinista y realiza un recorrido acotado de la cadena. No consulta un alojamiento de repositorios, inspecciona objetos Git, deduce intenciones a partir de un diff, reescribe la descripción ni contacta con servicios externos. Por ello, la misma entrada produce los mismos campos o el mismo error en el navegador y mediante la API. Use el tipo, ámbito y descripción devueltos como datos de clasificación para agrupar registros de cambios, aplicar reglas de publicación o alimentar paneles, pero mantenga aparte las comprobaciones semánticas propias del proyecto. Por ejemplo, puede confirmar que <code>fix(auth): reject expired tokens</code> es válido estructuralmente, pero no que el cambio corrija un defecto ni que <code>auth</code> sea un paquete permitido. Añada la política del repositorio si necesita listas de ámbitos o referencias a incidencias más estrictas.