A commit linter for projects of KazanExpress frontend division
Check if your current environment adheres to these specs:
NodeJSversion >= 8.0.0 installed in your bash environment.gitversion >= 2.9.- Your operating system can execute bash scripts.
To add the linter to your current project, just execute the following commands in your project's root directory:
npm i -D @kazanexpress/frontend-commitlintThis repository consists of two main things:
- A comprehensive description of rules for commit conventions at KazanExpress/Frontend Team.
- See the
Commit formattingsection for more info.
- See the
- Commit linter for NodeJS projects.
- See the
Linter installationsection for more info.
- See the
If there are any proposals or comments on the matter - feel free to create an issue! 😉
This section covers conventions for commit message formatting used at KazanExpress/FrontEnd.
We found several reasons for establishing commit conventions:
- Easier change tracking.
- Visually similar commit message format.
- Easier visual analysis of commit messages.
- Potential for automated changelog and semver updates generation.
- informativity
- Commits should tell WHY they were made in the first place.
- Commits should provide context for changes they bring.
Any commit message header (first line) must consist of following parts:
-
Type - the first word in the commit message.
- Possible types:
Fix- some bug or error is fixed (preferably with an issue number, see pt. 2).Feature- some new feature is introduced (preferably with an issue number, see pt. 2).Add- addition of new things in general.Add npm-package-name - v1.0.0- example of adding a new npm packageAdd modules/user - intial functionality- example of adding a new module in foldermodules
Update- updating of things in general (package versions, for example).Chore- routine maintenance, things that do not directly fall into any other type.- Choose this type if you do not want to include this change in the final changelog!
Refactor- code/structure refactoring. File renames go here too.Content- changes to static content that do not affect functionality.Revert- commits/changes reverts.Docs- updates to documentation.Remove- removal of things in general (files, functionality, etc.).Remove npm-package-name - deprecated- example for removal of an existing npm packageRemove [User.oldFunction] modules/user - I'm sick of it- example for removal of an existing function in moduleuser
- Possible types:
-
Related issue, optional. Should be placed whenever changes in commit resolve or affect an issue in a certain way. If many issues are affected, choose the most relevant one and place others in commit message [6].
-
Breaking change flag, optional. Shows if there was a breaking change in the commit.
-
Change scope - a semi-complete scope of the change in a subject. Optional.
-
Subject of the change - usually would be a file or a folder that is subject to change in this commit.
- Subject can be stated as
*(as inAdd * - initial commit) to specify that every possible subject is affected. - Note: scope ([4]) should be omitted instead of specifying it as
*.
- Subject can be stated as
-
Commit message written in a short informal way. Should precisely describe commit's change, giving context to it.
If a commit message has a body, it should start with a preceding blank line, like this:
Feature [toServer] modules/common - new method `toServer`
Convertable class can do reversed convertation from now on.
But only with a separate convert function with it's own map
If a commit message header (first line) is too long - informal message ([6]) can be omitted:
Feature [toServer] modules/common
Convertable class can do reversed convertation from now on.
But only with a separate convert function using it's own map.
Refactor rules - restructure & move to a separate folder
Fix [headerPattern] rules/pattern - spaces in commitlint headerPattern
Update * - finish initial setup
Add [LOGOUT] store/modules/user
Refactor [reset] store/modules/order
reset mutation now uses default object factory instead of hard-coding values
Remove parakeet-mapper - they fixed backend
Fix #132 [Product.constructor] types/models/product
object reference was being wrongly reassigned
Chore [tmpVer] store/plugins - bump store version
Chore [LOGOUT] store/module/* - make interconnected logouts work
Chore [rr-widget] pages/product - again updates for retail-rocket