Fix angular allowed commit types

[satazor]

Motivation and Context

Allowed types were wrong according to https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits

Usage examples

Does not apply.

How Has This Been Tested?

Tested manually.

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.

Couldn't run tests.. npm i && npm t fails with missing dependencies.

[e-cloud]

your reference is angular.js not angular. see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#type

[marionebl]

Thanks for contributing!

Seems I pulled the trigger on changing to the Angular (vs Angular.js) conventions too early.

You PR reverts the breaking change introduced with the version 4.3.0to 5.0.0 update, see the BREAKING CHANGE section here:

https://github.com/marionebl/commitlint/releases/tag/v5.0.0

The reference commitlint now uses is here
https://github.com/angular/angular/blob/master/CONTRIBUTING.md#type

If you want to continue using the previous commit types you can install @commitlint/config-angular@4 for now.

We probably should make the transition smoother by

• republishing @commitlint/config-angular@4 as @commitlint/config-angular-legacy
• Backporting the subject-tense change to legacy

What do you think?

Related

• WIP: fix: update to latest angular commit conventions conventional-changelog#249
• WIP: fix: update to latest angular commit conventions commitizen/conventional-commit-types#7

[marionebl]

Follow up with Angular project angular/angular#20537

[satazor]

Yes probably the transition was too early, the conventional-changelog projects also need to adapt (suggested version, changelog generation, etc). Perhaps we should create an umbrella issue there to track progress to what needs to change.

Regarding the drop of chore, we kind of lost the type for maintenance operations which is unfortunate. I wonder what the reasoning was and what to use now.

About creating the legacy + backporting, I absolutely agree! Note that standard-version commits with the subject equal to the version so we must not break those use-cases.

[marionebl]

I created this issue here to keep track of our progress:
https://github.com/marionebl/commitlint/issues/146