Commitlint: header-full-stop?

[shreyasminocha]

Expected Behavior

To be able to control full stops on my type-less, scope-less commit messages.

Current Behavior

I'm using commitlint with:

type-empty: [2, always]
scope-empty: [2, always]

According to the parser, I have an empty subject and what would usually be the subject, is understood by the parser to be the header. The header does not, at the moment, have a full stop setting. I'd love either header-full-stop or the parser recognising my subject correctly.

Affected packages

• [ ] core
• [x] cli
• [ ] prompt
• [ ] config-angular

Steps to Reproduce (for bugs)

$ echo "Blah, blah, blah, blah, blah, blah." | commitlint

⧗   input: Blah, blah, blah, blah, blah, blah.
✔   found 0 problems, 0 warnings

.commitlintrc.yml

  rules:

      header-max-length: [2, always, 50]

      header-min-length: [2, always, 1]

      body-max-line-length: [2, always, 72]

      body-min-length: [2, never]

      footer-max-line-length: [2, always, 72]

      footer-min-length: [2, never]

      subject-max-length: [2, always, 50]

      subject-min-length: [2, always, 1]

      scope-empty: [2, always]

      type-empty: [2, always]

      signed-off-by: [2, never]

  

Your Environment

| Executable | Version |
| ---: | :--- |
| commitlint --version | 7.2.1 |
| git --version | 2.20.0 |
| node --version | 11.4.0 |

[escapedcat]

I think I have problems understanding this. Might be related to not being a native English speaker.
Would it be possible for you to add an expected commitlint output?
I think that could clear things up.
Thanks.

[shreyasminocha]

@escapedcat I want echo "Blah, blah, blah, blah, blah, blah." | commitlint to give me an error due to the presence of the trailing period. It doesn't, however, in spite of me setting subject-full-stop to never. Also, when I set scope-empty and type-empty to always, commitlint interprets my subject as a header.

[escapedcat]

Thx, I think this clears things up. We'll take a look when possible.

[ianwremmel]

I was looking at adding scopeless, typeless rules to a project and I was surprised that scope and type have case and full-stop rules, but header does not. Seems like all three should have the same set of rules and options (and should accept both always and never, not just one of always or never)

[byCedric]

Hi @ianwremmel! You are totally right. We actually discussed this in one of our meetup-calls. All rules related to types and subject should also be available for the header right? E.g. (scope|subject)-case, (scope|subject)-empty and subject-full-stop. Do you think there should be more available for the header? I'll put something in my calendar for tomorrow evening to get some of these rules available for headers asap!

[ianwremmel]

yea, i think those make sense. I was looking at the code to see if I could throw something together. looks like it should be pretty straightforward, but I don't think I'll have time today.

One thing that was a little unclear for some rules: does the absence (e.g. regarding "full stop") of "always" imply "never" or does it imply "optional"?

[ianwremmel]

oh, also, I wasn't sure where to look to register new rules were I to make them.

[byCedric]

Hi @ianwremmel, sorry for the delay. I've created both header-case and header-full-stop rules. They are under review and can be merged/released as soon as they are reviewed.

Regarding the always/never statement for rules; they are basically inverters of the rule itself. E.g., if you set header-full-stop to always, commitlint expects you always to define it. For never, it's basically !condition, that means that commitlint expects you to _not_-define it.

You can view the structure a bit more in the API documentation, if you would like.

This always/never thing might seem a bit weird, but for some rules this is useful. Take the scope-empty rule for example. When we (the company I work for) just started using Conventional Commits, there was an explosion of different kind of scopes. Literally every developer had his/her own set of scopes. Needless to say, the scopes were rendered useless, and it became harder actually to use CC. For us, the best thing to do is to force scope-empty to always. After some initial learning and finetuning, we soon realized scopes could be useful for modular projects that we had. So instead of creating a new rule, e.g., scope-not-empty, we could reuse the other rule scope-empty and force it to never. 😄

[ianwremmel]

thanks for the update!

yea, i think the current behavior of always/never is fine, it just seems like it's not entirely clear what the absence of a choice means (especially for rules that accept one but not the other). just something to think about should the docs go through revamp at some point :)

[shreyasminocha]

Thanks @byCedric!

[byCedric]

I'll create a release asap! Let me get to my computer first 😉

[byCedric]

This has been released in 7.4.0! 😄 Let me know if it works fine, or if you encounter some issues with the new rules. Good luck!