Skip to content

PLAT-2173 #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .husky/commit-msg
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx --no -- commitlint --edit "$1"
99 changes: 99 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
# Contributing

As a contributor, here are the guidelines we would like you to follow:

- [Coding Rules](#markdown-header-coding-rules)
- [Working with branches](#markdown-header-working-with-branches)
- [Commit Message Guidelines](#markdown-header-commit=message-format)

## Coding Rules

TODO

## Working with branches

Remote branches must follow the following format:

- fix/my-fix-name: for bugfixes/hotfixes
- feature/my-feature-name: for features, refactoring, etc

Branches name **must be in kebab-case and lower caps**.

Please **keep the commit history of your branch clean**, with proper commit messages (see below).
Use `git log` to review it, and if necessary `git rebase` to clean it.

> See the [git docs](https://git-scm.com/docs/git-rebase#_interactive_mode) for more details.

## Commit Message Format

_This specification is inspired by [Angular commit message format](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format)._

We have very precise rules over how our Git commit messages must be formatted.
This format leads to **easier to read commit history**.

Each commit message consists of a **header** and a **body**

```
<header>
<BLANK LINE>
<body>
```

The `header` is mandatory and must conform to the [Commit Message Header](#markdown-header-commit-message-header) format.

The `body` is mandatory for all commits except for those of type "docs".
When the body is present it must be at least 20 characters long and must conform to the [Commit Message Body](#markdown-header-commit-message-body) format.

Any line of the commit message cannot be longer than 100 characters.

### Commit Message Header

```
<type>(<scope>): <short summary>
│ | │
│ | └─⫸ Summary in present tense. Not capitalized. No period at the end.
| |
| └─⫸ Commit Scope: domain-challenge|domain-resource|lib-logger|lib-common|lib-secrets
|
└─⫸ Commit Type: feat|fix|docs|chore|refactor|ci|test|perf|revert
```

Both `<type>` and `<summary>` fields are mandatory.

#### Type

Must be one of the following:

- **feat**: A new feature
- **fix**: A bug fix
- **docs**: Documentation (README, CONTRIBUTING and code documentation)
- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **ci**: Changes to our CI/CD configuration files and scripts
- **test**: Adding missing tests or correcting existing tests
- **perf**: A code change that improves performance
- **revert**: Reverts a previous commit

#### Summary

Use the summary field to provide a succinct description of the change:

- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize the first letter
- no dot (.) at the end

### Commit Message Body

Just as in the summary, use the imperative, present tense: "fix" not "fixed" nor "fixes".

Explain the motivation for the change in the commit message body. This commit message should explain _why_ you are making the change.
You can include a comparison of the previous behavior with the new behavior in order to illustrate the impact of the change.

### Revert commits

If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit.

The content of the commit message body should contain:

- information about the SHA of the commit being reverted in the following format: `This reverts commit <SHA>`,
- a clear description of the reason for reverting the commit message.
22 changes: 22 additions & 0 deletions commitlint.config.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
module.exports = {
extends: [
"@commitlint/config-conventional"
],
rules: {
"type-enum": [
2,
"always",
[
"feat",
"fix",
"docs",
"chore",
"refactor",
"ci",
"test",
"perf",
"revert",
],
],
},
};
11 changes: 8 additions & 3 deletions package.json
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,8 @@
"build:proto": "node bin/proto",
"build:app": "rimraf dist && tsc -b",
"build": "npm run build:proto && npm run build:app",
"start": "ts-node-dev --respawn --transpile-only src/app.ts"
"start": "ts-node-dev --respawn --transpile-only src/app.ts",
"prepare": "husky install"
},
"keywords": [],
"author": "Rakib Ansary",
Expand All @@ -30,6 +31,10 @@
"@types/node": "^18.11.17",
"ts-node-dev": "^2.0.0",
"ts-proto": "^1.126.1",
"typescript": "^4.9.4"
"typescript": "^4.9.4",
"@commitlint/config-conventional": "^17.4.0",
"commitlint": "^17.4.0",
"husky": "^8.0.3",
"lint-staged": "^13.1.0"
}
}
}
Loading