[FEAT] Add character length indicator for commit message summary and description inputs
YourAKShaw opened this issue · 17 comments
Is your feature request related to a problem? Please describe
Yes. Most developers suggest that the commit message summary be no longer than 50 characters, and the description be limited to 72, even though the nature of git commits is 72 max for the commit title and inf for the description.
Describe the solution you'd like
While typing each of the message summary and description, if the live character count, like x/50 in the case of summary and x/72 in the case of description, is visible in the input box and gives a soft warning when someone exceeds the limit, still allowing the user to commit exceeding length message when required will be great. Adding a flair of redness, like how @twitter handles it for tweets will be pretty dope!
Describe alternatives you've considered
Sometimes when I need to be strict about the lengths, I type the text in an editor of choice, while keeping track of the character length, and copy paste it into the input box.
I prefer sticking to these conventions, the reason for conventional commits since it aids in better communication and DevX.
Additional context
N/A
TBH, I'm really hyped by this gloriously awesome extension! I just can't live without it now! @vivaxy, I'm super eager to contribute to the project. I'd like to work on this issue if assigned. 😸
👋 @Ak-Shaw, I am a collaborator on this project, and very glad that you like this extension, your proposal is very good, and I have assigned you for this issue, and looking forward to your PR. 😁
Thanks a ton @yi-Xu-0100! Will be sending in a PR soon! 👍🏻
Hello guys, I came here to see if anyone else missed this feature in the extension! because I felt
Making some tests here i can solve this it and I would like your opinion for make a PR
Maybe you think another location for show this message more assertive for the users or maybe better way to do this code
(it's my first time with vscode extensions)
End result is this
👋 @gabolera, thanks for your nice PR, I have been build the beta extension of your PR in GitHub workflow. See and try: vscode-conventional-commits-e8d25c4.vsix.
For about 1 week testing, if there is no any more feedback, it will be merged into next new version and be released! 😊
@gabolera Also I have a little issue about it. We know that this word limit applies to commit messages not the title of it, does the "type" and "optional scope" also be considered in GitHub? If it should calculate the words of "type" and "optional scope", The PR may need to be updated for this situation. 🤔
yes really, i think to happen in this situation.
I didn't consider because in my tests i see that git accept 70 characters before break line and only 50 is recommended in for a margin safety.
but you are right, maybe has interesting calculate the type , emoji and scope with subject for user has more accuracy of commit size.
for this fix, @yi-Xu-0100 think so is better change the limit for 70 on subject summing the last characters of the steps?
@gabolera For fast fix, have a configuration option for this number may better.
I think I've come to a good solution now #310 has edits
Now has crated a settings
{
"conventionalCommits.commitMaxLength.subject": 70,
"conventionalCommits.commitMaxLength.body": 140
}###What has been considering a now
- Size complete of a
type - Gitmoji only one caractere +
spaceif selected by user - Size of scope + 3 character with spaces and formats to complete the
()space
Examples
refactor(myScope): :ambulance: My first commit with new version this has a 63 characters but in app has just considering 53 because gitmoji has ocupe only character in github (:ambulance: change for 🚑 )
@gabolera I update the PR for adding multi-language support, your code is very nice for me! 😁
@vivaxy I think it has been tested by me and can be release it on next Friday. What do you think? 😊
@yi-Xu-0100 Nice update in PR, thanks for help.
I'm testing still and not found more nothing bug. I believe can join in next release
@gabolera @yi-Xu-0100 Nice PR!
But I've got a question.
The config conventionalCommits.commitMaxLength.subject and conventionalCommits.commitMaxLength.body seems to have the same effect as [Commitlint Rules](https://commitlint.js.org/#/reference-rules) subject-max-length and body-max-length. Is it possible to read max length config from CommitLint rules and remove those VSCode configs?
@vivaxy I don't know, but maybe there's a way to improve, because not all people who use this extension have a commitlint configured correctly, an example is me! In the company I work for, the default language is PHP and it doesn't have this commitlint configuration by default, I use this extension just to help with the commit but it's not mandatory to follow conventional commit rules here.
But it might be interesting, if you find these commitlint settings use them, otherwise use a vscode configuration.
if you find these commitlint settings use them, otherwise use a vscode configuration.
👍🏻That's a better way.
Nice, i can work soon in this changes and I have a new question about a similar feature, I don't know how commitlint works correctly, but if it has a value set with maximum length, the commit can never exceed the length, right?
If it's right it might be interesting to have a configuration in the visual code for restricted-commit with true or false, for the extension if it's false show only values for information and if true don't accept more lenth than defined in configuration, block by UI before commit
@vivaxy what you think about this?
Now he is default get data of commitlint, but if not found configuration, is used a value parameter has defined by user in conventionalCommits.commitMaxLength.subject and conventionalCommits.commitMaxLength.body
#310 is PR
Sorry for the delay in continuing the change 😉
@vivaxy @yi-Xu-0100