Question: suggested process for handling accidental leading or trailing whitespace in subject

[ddeepwell]

I find that I accidentally add trailing whitespace in the subject of commit messages. I am appreciative that commitlint catches this before the commit is made, but wish that commitlint could fix this simple case before completely rejecting the commit which is often annoying and disrupts my train of thought.

I understand that commitlint is largely designed to check and not adjust commit messages, but other linters often have a --fix option to solve the simplest of issues. While adding a fix option might not be on the roadmap, what are the suggested workarounds for this scenario? I'm curious to hear what other members of the community do about this.

Currently, in this scenario I copy the content of the rejected commit message from .git/COMMIT_EDITMSG and try again with a fix. But this adds an extra step that slows things down.

[escapedcat]

Does enabling this rule help?

For reference see: #3199

[ddeepwell]

The "header-trim" rule doesn't fix a message by removing trailing whitespace. It only throws an error when the whitespace exists.

I would like to use a configuration which removes the trailing or leading whitespace in the subject line rather than throw the error.

[escapedcat]

I guess #3199 was about the same issue and that was the result. Fixing messages seems out of scope of commitlint.

[ddeepwell]

Many linters provide the option to fix simple cases. This would be a nice feature, especially for this simple situation, but I understand if there isn't an appetite for such an addition.

[escapedcat]

You're right. A "fix option" would be nice. But so far commitlint isn't offering anything in that direction. Would need a bigger concept than "let's just add it for whitespace now" I guess :)

[iamyoki]

That's why I created a formatter for commitlint recently, 🤗meet committier

No one needs to memorize numerous rules anymore, now every commit will comply with commitlint validation (Well, almost. Such as max-length will still bypass to commitlint). Read more in deepwiki.

Also includes a built-in local AI commit generator (Beta).

flowchart TD
    A --> |husky git hook|F[commitlint]
    F --> G[FAIL❌]
    A[" FIX Some errors"] -->|husky git hook|B
    B[committier] --> |fix and format to|C
    C["fix: some errors"] --> D
    D[commitlint] --> E(PASS✅)

Loading

More Examples:

• Trim / Casing / Default Type: " Handle nullish" -> "fix: handle nullish"
• Scope: " feat app1,app2 add foo bar " -> "feat(app1,app2): add foo bar"
• Monorepo Auto Scope: feat foo bar -> feat(app1,app2,pkg1): foo bar
• Auto Emoji: "FEAT : Foo bar" -> "✨ feat: foo bar"
• Filename as Default Description: chore -> chore: package.json, tsconfig.json

I would really love to seek advice from the maintainer @escapedcat : Do you like it or what are your thoughts on this project? Do you have any suggestions on how to better integrate Committier with Commitlint? I am fully committed to aligning it with the Commitlint to achieve a better developer experience.