Match config conventional with new spec [WIP]

[byCedric]

Description

Fixes #658

Motivation and Context

Usage examples

How Has This Been Tested?

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.

[bcoe]

@byCedric we're starting to roll out commit linting more internally, so I'm excited for this work 😄

a couple things we should make sure we capture:

1. I think commit lint is a bit stricter about type than we suggest on conventionalcommits.org, any type is fine (we're not as strict as angular).
2. I really love the new feat!: syntax, as a short hand for indicating a breaking change; would love to make sure we support this.

[byCedric]

Awesome! 🎉 And thanks for helping focussing on the important parts!

1. I had the same idea about the types. Like I outlined here, the spec describing feat and fix is more directed at the developers rather than Commitlint right? 😁

2. I think I saw the implementation for the shorthand in the conventional-changelog-conventionalcommits parser right? So switching the parser to this one should do the trick, right? Like outputting a parsed commit with breaking change notes, or do you think we still need to add something to make it work?

Right now I'm in Thailand, celebrating the engagement of a good friend of me. Maybe @marionebl or @escapedcat can lend a hand? When I get back I'll prioritize this a bit more 😁

[byCedric]

One thing I thought of that we should properly "inform" developers using Commitlint when we open up the types. Maybe also provide a short upgrade guide to keep Commitlint as is for them (with the stricter types). But I think we can cover this fairly easy in the final stage, just before releasing 😁

[bcoe]

@byCedric we do have the new parser conventional-changelog-conventionalcommits, I think if you use this it will capture the ! syntax 👍

As for being strict regarding types, I think I agree, we should just make sure it's well documented how a developer provides their own set of types, or turns off type enforcement as the case might be 👍

Have fun in Thailand, appreciate your hard work on this project. FYI, here's the bot I've been building in action:

https://github.com/googleapis/release-please/pull/222/checks?check_run_id=189188026

deployed from a framework we're working on here:

https://github.com/googleapis/repo-automation-bots/blob/master/packages/conventional-commit-lint/src/conventional-commit-lint.ts

[byCedric]

Let's keep this PR open for now. The type-enum should is removed (the spec doesn't forbid other types). Because of that, we need to consider this a breaking change. I suggest opening a new PR with only the updated parser preset, which should work with backward compatibility, to merge it without breaking change 😄

[marionebl]

Discussed this between @byCedric @escapedcat and me. The current plan is to relax @commitlint/config-conventional as per spec.

That being said we will move the current, stricter set to @commitlint/config-conventional-strict and show that as config to use in the installation guides.

[escapedcat]

After #821 did the most part of this I believe we're good here for now. Happy to re-open this if anyones has further feedback.