fix: stop truncating the body in presence of dashes

[tehraninasab]

Fixes #3428

Description

In the current version of commitlint the body is truncated unexpectedly when there is a pattern like '- Something between dashes -' in the commit message body. I investigated this issue #3428 and noticed that the reason for this behavior is that in the commit parser package the commitlint uses (conventional-commit-parser), this pattern '- something -' is a special pattern for any arbitrary filed. For example, if you put '-myNote-' in the commit message body, everything that comes after this field will be saved in an arbitrary field called myNote (Or whatever is written between dashes) and you can use it like other fields (header, body, etc.), but I believe we should disable this functionality because, in the commit messages like the one I mentioned in #3428 issue, the user might put stack trace in the commit message body and this way it will be truncated unexpectedly.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[escapedcat]

@realmarv awesome!
I was just searching if this has ever been mentioned and found this: #3
So I assume we're good here, right?

[gilmoreorless]

Hi, this was technically a breaking change that wasn't marked as such. Any time a commit says "we should disable this functionality", it's a very strong indicator that it's a breaking change.

We were adding extra commit information (such as author name and email) in -fieldNames- format so a custom rule plugin could ignore bot authors. That functionality has now broken after upgrading to 17.4.0.

I can see that #3 says explicitly providing these fields is out of scope: "Additional fields will be business of plugins when the API for them arrives." However, #2455 shows that the promised API for additional fields still doesn't exist. Adding extra detail via --git-log-args was the only way I found to get this working simply.
This removal would be ok if it was possible to override in parserOpts. But fieldPattern: null is set last in the options object, so no custom options will override it.

I get that the bug that was fixed wasn't desirable behaviour. But can I request that this nulling out of fieldPattern at least be able to be overridden if required?

[escapedcat]

@gilmoreorless thanks for the heads up.
How about reverting this for now and releasing a patch version?
Not exactly sure how to continue with this tbh. Would you be able to provide a PR that solves your use case?

@realmarv wdyt?

[knocte]

Reverting @realmarv's commit would now cause another breaking change, plus her PR included a unit test. However, the behaviour that is claimed to be supported by @gilmoreorless didn't have a unit test to back it up. If this is a wanted behaviour please write a unit test first.

[gilmoreorless]

That's fair. 👍

The implicit behaviour of relying on conventional-commit-parser's defaults wasn't documented. But if anyone is setting fieldPattern in parserOpts in their config, that will currently be broken.

I'm happy to put up a PR to keep the current default null value, but allow overriding via config.

[escapedcat]

Thanks people! Happy for any help here.