Using a regex for issuePrefixes

[erquhart]

For enterprise projects using Jira/Bitbucket Server, the # symbol doesn't really apply the way it does in Github. A regex would allow developers to use something like /[A-Z]+\-[0-9]+/, which would capture any Jira issue key. Is there already some way of doing this, or would this approach fit with your plans for the library?

My current solution is providing an array of Jira project names, and using the raw value in the commit template, but the static list approach might get unwieldy.

[stevemao]

It's already fixed by https://github.com/stevemao/conventional-commits-parser/commit/5342f45d3aa6382e612cead26348c5d1ce9a6703

[erquhart]

Not the same issue - can you reread?

[stevemao]

Jira/Bitbucket Server is already supported.

[stevemao]

Also please read https://github.com/stevemao/conventional-commits-parser#issueprefixes

[erquhart]

You have to prefix the Jira issue key with a hash.

[stevemao]

What do you mean exactly? The tests passed https://github.com/stevemao/conventional-commits-parser/blob/master/test/regex.spec.js#L98-L115 https://github.com/stevemao/conventional-commits-parser/blob/master/test/regex.spec.js#L158-L164

[erquhart]

It only works if the Jira issue key is prefixed with a # symbol.

Works:
Closes #MYJIRAPROJECT-123

Doesn't work:
Closes MYJIRAPROJECT-123

Prefixing a Github issue key with a hash symbol is standard. Prefixing a Jira issue key with a hash symbol is not ever done, for any reason. I'm suggesting that this not be a requirement for non-github users.

[stevemao]

what about using MYJIRAPROJECT- as a prefix?

[erquhart]

That's what I'm currently doing. From my original post:

My current solution is providing an array of Jira project names, and using the raw value in the commit template, but the static list approach might get unwieldy.

A repo can be referenced by multiple projects, and that list becomes one more thing to keep fresh (there are hundreds of Jira projects in my current context). The simplest fix would be to allow issuePrefix to accept a regex, and to provide a boolean option for including the prefix in the issue key itself, both for display and for the url.

[stevemao]

The simplest fix would be to allow issuePrefix to accept a regex, and to provide a boolean option for including the prefix in the issue key itself, both for display and for the url.

Does it fit the current API paradigm?

Is there any side effect of making issuePrefix optional?

[erquhart]

It wouldn't be optional, just optionally included in the issue key. The API changes would include:

• issuePrefix can now be a regex or string (or an array of both)
• includeIssuePrefix is added for configuring the issuePrefix to be included in the issue key. Defaults to false (to match current behavior).

No breaking changes, just a feature addition.

[stevemao]

I don't 100% understand you.

I was thinking if issuePrefix is null, no issue prefix is needed (Closes MYJIRAPROJECT-123 would work without # or gh-). But I don't know if there's any downside of this change.

Anyways, PR welcome. For a quick demo purpose you could create a test first.

[erquhart]

I forgot that you're only searching for references in the footer - yes, your way is much more straightforward.

[stevemao]

I forgot that you're only searching for references in the footer

this is not true. It searches everywhere in the commit message.

[erquhart]

Then I would expect to see a lot of false positives with this approach - any number in the commit message would match the regex, right?

[stevemao]

any number in the commit message would match the regex, right?

no, it must have an action (eg: closes) and an issue prefix atm (eg: #)

Then I would expect to see a lot of false positives with this approach

I'm not sure about this.

[erquhart]

Hmm...makes me wonder if it's better to just call out the dichotomy and allow developers to choose an issue key type - numeric or alphanumeric. Numeric would use the current defaults, but with the regex as it was prior to the commit you referenced earlier. Alphanumeric would default to no prefix or action, and would use the updated regex (but without searching for pure digit strings). These changes, together with making issuePrefix and referenceActions optional, would do the trick, and I wouldn't expect any breaks.

[erquhart]

So the api changes would include:

• issueType accepts 'numeric' or 'alphanumeric'. Defaults to 'numeric'.
• issuePrefix is now optional.
• referenceActions is now optional.

What do you think?

[stevemao]

I really don't want to add another option for this.

I'm probably going for the original proposal I made. an edge case might be

I closed the door

fixes 123

the is misparsed as an issue. I don't know if this is a good idea?

On top of this we could make referenceActions optional. In this scenario, It only searches for the pattern made by issuePrefix.

JIRA-123 blocks the code

I don't see any problem with this.

If they both issuePrefix and referenceActions are null, you can't reference.

[erquhart]

Yep, the extra option is definitely syntactic sugar - but it's in the spirit of the conventional-changelog api, which is, to quote Andrew Joslin (source):

I need to be able to find this repo and get started as quickly as possible, with as little reading and weighing of choices as possible.

The direction you're heading will require developers to think through, and possibly Google their way through, setting up the commit parser to work for Jira, which is a very common use case. Making the api flexible enough to allow for this, as you're describing, is great, but I could have moved on to other things many hours ago if I could have simply indicated that my issue keys are alphanumeric and left it that.

But yes, either way works.

[stevemao]

I don't think referencing an issue without a prefix is realistic. Looks like there might be many edge cases. Please send a PR if you have a good idea.