Automatic Changelog and Coding Style?

[jhechtf]

A previous employer got me into the habit of using a modified version of the Angular commit style. The modification we made was that after the type+scope we would include a reference to a ticket. This, for us, was a JIRA board but it can be easily updated to reference issues in the Github repository.

e.g. feat(UserSearch): #3 Adds loading indicator to User Search Page

I personally do not like having the ticket number in the "title" so personally I tend to use the long form, e.g.

feat(UserSearch): Adds loading indicator to User Search Page

Closes #3 

This works well, as there is a tool called Standard Version which (in other projects) I have setup to auto-bump versions and generate a changelog for every commit that goes to main. In my actual setup, this bumping also creates a git tag, which then triggers a deployment.

As I'm sure this project has more contributors than you imagined it would, I think choosing a code style and sticking with it would be a good idea. If we use the Angular commit style, I also happened to make an extension for VSCode some time back with this in mind.

[Wolven531]

Can you elaborate a bit on "code style"? In my mind, there are a few pieces that belong to that conversation -

a.) Code formatting
b.) Commit message conventions
c.) PR conventions
d.) Code linting

We've got a.) covered w/ Prettier (there's a config file in repo). We can establish b.) and add it to the README - I think that's a fantastic idea. I think c.) is sufficiently covered via the PR template (provided contributors fill it out, 😂). Finally, for d.), we can add a pre-commit hook that runs a linter, or even a GHA that updates the changes on the feature branch w/ a linter using autofix.

Do you have further considerations that contribute to "code style"?

[jhechtf]

I mistyped; I meant "git commit style" instead of "coding style"

[jhechtf]

@Wolven531 would we also want for people to reference a ticket number in their commits. My job soft requires this in order to keep track of work based on tickets.

An example would be something like I've already denoted, but how my team implements it currently is

<type>(<scope>): <ticket#> <subject>

Which ends up looking like

fix(Search): #12 resolves the thing