feat: parsable output format

[mibli]

Expected Behavior

Commitlint prints line and column numbers where the issue was found, to allow parsing the output for IDE integration (for example vim with neomake), like all major linters do. This should be the default behaviour TBH.

Current Behavior

Commitlint cat-s the message and writes issues found without any context. Formatter doesn't support line and column fields.

Affected packages

• [x] cli
• [ ] core
• [ ] prompt
• [ ] config-angular

Possible Solution

At least line and column fields should be available in the formatter API.

Context

No response

[escapedcat]

Duplicates #633
Please reopen if you think it's different

[mibli]

It is different, and should be easier to implement. While #633 gives a perfect example of the format in a different tool, this is a separate feature that won't be fulfiled by adding a squigly line.

@escapedcat Unfortunately I can't reopen the issue myself :(

[mibli]

Required Rule changes.

So if I understand this correctly. Each of the rule in @commitlint/rules currently returns [ boolean, message ]. For this to work, we would need to extend RuleOutcome to consist of [ boolean, message, Context{ row: int, column: int, matched: <FoundIn> } ] where <FoundIn> is either an enum value describing commit section or a matched line.

This requires changes to:

• @commitlint/types/src/rules/RuleOutcome
• @commitlint/rules/src/*

Tests required:

• Test col position (beggining, middle, end of the line)
• Test row position (first, last, single line)
• Rule not applicable (empty body)

Considerations:

• Wide unicode characters handling – imo should be delegated to Rule user, as it's not desirable to overcomplicate each rule implementation. This could be considered as a separate feature if we don't want to overcomplicate the first iteration.

Followup Questions:

• Where RuleOutcome is consumed?
• What changes to configuration would be required? (if any)
• Can this be implemented without API/config changes? (delegate to separate issues)
• What API changes would be required?
• Should the current default output behavior be preserved?
• What should be the exact format?