WIP: fix: update to latest Angular commit conventions

[marionebl]

Related:
conventional-changelog/conventional-changelog#249
#219

---

Work in Progress until angular/angular#20537 is resolved.

[coveralls]

Coverage remained the same at 99.679% when pulling a2b882e on marionebl:fix/update-angular-conventions into 709dae1 on conventional-changelog:master.

[stevemao]

@bcoe It's pretty hard to keep up-to-date with the angular convention without any help from the angular team. I was hoping to work with them on the specs. I think the specs should be centralised at https://conventionalcommits.org/ EG: they should probably hold discussions there, then change their docs. I tried to communicate with them multiple times but no luck. Any idea what would be the right channel to work with them?

[bcoe]

@stevemao I agree; I see no reason to move away from chore it would break the workflow I've convinced many folks at npm, and in communities elsewhere to take on. Instead I'd rather that we have a new conventional commit type that we use by default for standard-version, which would always track https://conventionalcommits.org/?

What do you think of this @marionebl, we could still continue to keep the angular format up-to-date in the corresponding repo, but standard-verison would officially be adhering to a different set of guidelines.

[bcoe]

... I could imagine landing this still to unblock folks ... but I would like to make an effort to diverge from the stricter angular guidelines.

[marionebl]

Edit: There is no immediate action required for unblocking from my point of view - I moved the latest tag back to the compatible 4.3.0 version of @commitlint/config-angular.

I track everything related to this here: https://github.com/marionebl/commitlint/issues/146

---

@bcoe I'd be fine with ways forward that remove the current uncertainty about the exact conventions to use when talking "Angular" conventions.

I can see the following ToDos:

1. Define the convention standard-version wants to track long-term.
2. Create @commitlint/config-standard
3. Create conventional-changelog/conventional-changelog-standard
4. Adapt conventional-commits.org accordingly
5. Reflect the breaking changes in all things *-angular via semver
6. Instruct commitlint users to switch to @commitlint/config-standard by default
7. Switch to conventional-changelog/conventional-changelog-standard by default
8. Long tail: Do lots of PRs to rename to standard commit convention if that is what is in use

Doing a "fork" and renaming seems to be the safest way forward. As I see it that actually happened silently when the Angular team did their changes in January.

[bcoe]

@marionebl this plan of action sounds wonderful (as always sorry for the slow reply, it's reached the point where I get dozens of issues opened on various open-source projects ever week; I'm trying to figure out a workflow that helps me keep up better).

Any interest in taking point on this project (getting us over to @commitlint/config-standard/conventional-changelog/conventional-changelog-standard)? I think this is a great future direction for this project.

A good place to reach me for coordinating work is this slack.

[marionebl]

@bcoe No worries/pressure it is your free time after all. :)

I'll drive the needed changes and ping you via Slack if needed:

• publish @commitlint/config-conventional
• agree on exact commit conventions (Slack)
• adapt @commitlint/config-conventional as needed
• rename/alias @commitlint/config-conventional to @commitlint/config-standard?
• publish conventional-changelog/conventional-changelog-standard and use as default preset
• adapt http://conventionalcommits.org/ to agreed commit conventions
• major release for conventional-changelog-angular, reflecting the chore removal

[stevemao]

@marionebl I made you an owner of this org so you can merge/close PRs/issues etc. Thanks!

[satazor]

Awesome plan.

I prefer config-conventional but I’m fine with standard too.

[marionebl]

@stevemao Thank you :)

[satazor]

@marionebl I've tried using @commitlint/config-conventional but it still fails to work with standard-version:

⧗ input: chore(release): 1.0.0
✖ subject must not be sentence-case, start-case, pascal-case, upper-case [subject-case]

I guess the issue is that the sentence starts with a number which is causing a validation error.
This works:

⧗ input: chore(release): v1.0.0
✔ found 0 problems, 0 warnings

How do you suggest to fix this? Should this be fixed in the config conventional?

[marionebl]

@satazor Please raise this issue at commitlint, seams to be a regression with ensure-case in core.

[satazor]

Done, see https://github.com/marionebl/commitlint/issues/198

[bcoe]

@marionebl awesome work creating config-conventional 👍

[bcoe]

@marionebl what would it take for us to dust this off and land it?

[bcoe]

cleaning up some old pull requests, please feel free to reopen this conversation if you're still interested in implementing this.

@marionebl I would still love to see us move to a conventional commits preset; so please feel free to dust this off at any time.