ramsey/conventional-commits

Configurable Preceding Symbol

lukaszgoworko opened this issue · 4 comments

lukaszgoworko commented

Configurable Preceding Symbol

Possibility to set the precending symbol in the configuration

Background/problem

When using e.g. Jira the Issue preceding symbol is depending on the Jira project and is something like MYPRO-. It would be nice to have the possibility to configure the preceding symbol to have the possibility to use the Jira Project Key instead of the #.

Proposal/solution

  • add precendingSymbol to configuration schema
  • add # as default value to Configuration
  • use precendingSymbol configuration value in IssueIdentifierQuestion

Alternatives

Additional context

Would love to help with that feature and contribute, but before just start coding I would like to ask if this is something you want to have as a feature. Also the naming of the configuration key should be discussed. Perhaps IssuePrefix or IssueKey is better.

ramsey commented

I had been thinking about this, too. Would it be better to remove the preceding/prefix symbol altogether and let the user type it in?

lukaszgoworko commented

I was thinking about using an other Question too. But when using the tool, I noticed that there are already quite a few questions until I get the message. I would be more in favour of configuring defaults per project and letting the user type as little as possible.

E.g. typing the Issue number on the numeric keypad is quickly done if everything else is default. What do you think?

ramsey commented

typing the Issue number on the numeric keypad is quickly done if everything else is default

I haven't had a numeric keypad in 20 years 😉 I usually copy/paste issue numbers.

I'm not opposed to the configuration, but I'm curious how others are using it.

Speaking of having quite a few questions, I'm also considering adding some configs to allow you to exclude some of the questions, if you don't use them (like the components question, for example).

  • 👍1
lukaszgoworko commented

"Default Questions Answers" 😁 that sounds great. Count me in! We can create a new ticket for that, would also put some effort in it. Do we need to think about a config structure and naming for the configuration keys and take the default questions already into consideration in this ticket? Renaming later would lead to a breaking change, right? Having "Default Question Answers" would perhaps also lead to have a question about the Ticket Key. As it would be then possible to add the Default answer. What about something like this:

Current Config Keys:

  • typeCase
  • types
  • scopeCase
  • scopeRequired
  • scopes
  • descriptionCase
  • descriptionEndMark
  • bodyRequired
  • bodyWrapWidth
  • requiredFooters

New:

  • defaultQuestionAnswers
    • issueKeyQuestion
      • String:
    • addFootersQuestion
      • String: yes/no

...

But there are some Questions it do not make sense to have a default answer like the Description or Body question, right?