conventional-changelog/commitlint

input is not displayed correctly (non-existing blank lines added)

Open

#3 129 ouverte le 20 avr. 2022

Voir sur GitHub
 (9 commentaires) (1 réaction) (0 assignés)TypeScript (896 forks)batch import
bughelp wanted

Métriques du dépôt

Stars
 (15 497 stars)
Métriques de merge PR
 (Merge moyen 5j 19h) (65 PRs mergées en 30 j)

Description

Current Behavior

When there's no blank line between body and footer (and the line is recognised as footer due to existing issue reference), commitlint wrongly displays the input and adds that blank line between them, which makes the lint messages pretty confusing (please look at the example below).

Expected Behavior

Displayed input should be exactly the same as provided input.

Affected packages

  • cli
  • core
  • prompt
  • config-angular

Possible Solution

Display the initial input with no modification at all.

Steps to Reproduce (for bugs)

❯ echo "test(general): test

some body
related to #1

Issues: #2" | npx commitlint

⧗   input: test(general): test

some body

related to #1

Issues: #2
✖   footer must have leading blank line [footer-leading-blank]

(looking at what is displayed - the blank line is there, but it's actually missing)

Context

Your Environment

Executable Version
commitlint --version @commitlint/cli@16.2.3
git --version git version 2.32.0 (Apple Git-132)
node --version v17.9.0

Guide contributeur

Direction de recherche
Enquêtez sur le package @commitlint/cli pour trouver où l'entrée du message de commit est traitée et affichée. Le bogue se produit probablement dans la logique de formatage de l'entrée, peut être dans les fonctions de lecture ou de formatage. Cherchez où le message est divisé en lignes et réassemblé, car le problème montre qu'une ligne vide supplémentaire est insérée. Vérifiez des fichiers comme `cli/src/read.ts` ou similaires. Concentrez vous sur la préservation de la chaîne d'entrée originale sans modifications.
Stack technique
typescript
Domaine
cli
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
Git
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65