Create custom conventional commit specification

[MFarabi619]

Can be marketed as stack-builder commit conventions flavor/framework. Could be a mini open-source project of its own.

Currently there's no way to tell if a feature commit is visible to the user or not. A newly created component would be a feature commit, but may not be displayed yet.

• Need to be able to tell the difference between the following:
  • Frontend
    • Main web app
    • Docs site
    • Storybook
    • Eslint config inspector
    • GitHub README
    • Blog?
  • Back-end
    • Docs search functionality
    • Content management system

Work could consist of creating a component like a button, helper functions, scripts, api endpoints, schema changes, etc.

Proposal:

Ditch the capital letters. At this point they're hurting readability. Go back to full lowercase.

For any change that creates a difference in what the user sees, use the UI scope followed by the platform.
feat(ui/web), feat(ui/docs), fix(ui/storybook). These commits can contain both front-end and back-end changes, and probably will most of the time as the back-end API's need to be in place before the frontend changes can be rendered as intended. Due to trunk-based development, no broken/incomplete features should ever be visible by the user.

For any change that creates/modifies the APIs serving information to the frontend/microservices
feat(api/web), feat(api/docs)...

ui, api, web, docs, storybook, eslint, etc. are now reserved scopes. They can be used to filter commit history and debug fast.

The type can be only feat/fix, first level scope can only be ui/api, and last level scope can only be web/docs/storybook/eslint..

For package installs, use chore(deps), and chore(devdeps) or chore(deps-dev).

Resources:

https://trunkbaseddevelopment.com/