Project Name

Contents

Getting Started

Run the development server

pnpm dev

Run the production server

pnpm build
pnpm start

Run linter

pnpm lint

Run type checking

pnpm tsc:check

Contribution Guidelines

Clone the Repository: After forking, clone the repository to your local machine.
Create a New Branch: Always create a new branch for your changes. This keeps the project history clean and easy to navigate.
Make Your Changes: Make your changes in the new branch. Please follow the coding standards and conventions used throughout the project.
Test Your Changes: Before submitting your changes, make sure to test them thoroughly.
Commit Your Changes: Commit your changes with a clear and concise commit message.
Push Your Changes: Push your changes to your forked repository.
Submit a Pull Request: Finally, submit a pull request to the main repository. Please provide a clear and detailed description of the changes you've made.

Commit Message Guidelines

We follow the Conventional Commits specification for our commit messages. This leads to more readable messages that are easy to follow when looking through the project history.

A commit message should be structured as follows:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

Where type must be one of the following:

feat : A new feature
fix: A bug fix
quickfix : Small bug fix that doesn't require a new version
docs : Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing tests or correcting existing tests
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

Pull Request Guidelines

Follow the same naming convention for your pull requests as you do for your commits. A pull request should be structured.

Reference Related Issues: If your pull request is related to an existing issue, please reference it in your PR description.
Describe Your Changes: Provide a clear and detailed description of what changes you've made.
Include Screenshots: If your changes include UI updates, please include screenshots in your PR description.
Wait for Review: After submitting your PR, please wait for it to be reviewed and approved before merging.

Raw

<!--toc:start-->
 
- [Contents](#ProjectName)
  - [Getting Started](#run-development)
    - [Run the development server](#run-the-development-server)
    - [Run the production server](#run-the-production-server)
    - [Run linter](#run-linter)
    - [Run type checking](#run-type-checking)
  - [Contribution Guidelines](#contribution-guidelines)
  - [Commit Message Guidelines](#commit-message-guidelines)
  - [Pull Request Guidelines](#pull-request-guidelines)
    <!--toc:end-->
 
## Getting Started
 
### Run the development server
 
````bash
pnpm dev
\```
 
### Run the production server
 
```bash
pnpm build
pnpm start
\```
 
### Run linter
 
```bash
pnpm lint
\```
 
### Run type checking
 
```bash
pnpm tsc:check
\```
 
## Contribution Guidelines
 
1. **Clone the Repository**: After forking, clone the repository to your local machine.
 
2. **Create a New Branch**: Always create a new branch for your changes. This keeps the project history clean and easy to navigate.
 
3. **Make Your Changes**: Make your changes in the new branch. Please follow the coding standards and conventions used throughout the project.
 
4. **Test Your Changes**: Before submitting your changes, make sure to test them thoroughly.
 
5. **Commit Your Changes**: Commit your changes with a clear and concise commit message.
 
6. **Push Your Changes**: Push your changes to your forked repository.
 
7. **Submit a Pull Request**: Finally, submit a pull request to the main repository. Please provide a clear and detailed description of the changes you've made.
 
## Commit Message Guidelines
 
We follow the [Conventional Commits](https://www.conventionalcommits.org/) specification for our commit messages. This leads to more readable messages that are easy to follow when looking through the project history.
 
A commit message should be structured as follows:
 
```gitcommit
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
\```
 
Where `type` must be one of the following:
 
- <span style='color: #162FD8'> feat</span> : A new feature
- <span style='color: #721820'> fix</span>: A bug fix
- <span style='color: #DB7379'> quickfix </span>: Small bug fix that doesn't require a new version
- <span style='color: #6A5E7C'>docs</span> : Documentation only changes
- <span style='color: #1F6FEB'>style</span>: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- <span style='color: #CC793B'>refactor</span>: A code change that neither fixes a bug nor adds a feature
- <span style='color: #81EF8E'>perf</span>: A code change that improves performance
- <span style='color: #196A87'>test</span>: Adding missing tests or correcting existing tests
- <span style='color: #32279D'>chore</span>: Changes to the build process or auxiliary tools and libraries such as documentation generation
 
## Pull Request Guidelines
 
Follow the same naming convention for your pull requests as you do for your commits. A pull request should be structured.
 
1. **Reference Related Issues**: If your pull request is related to an existing issue, please reference it in your PR description.
 
2. **Describe Your Changes**: Provide a clear and detailed description of what changes you've made.
 
3. **Include Screenshots**: If your changes include UI updates, please include screenshots in your PR description.
 
4. **Wait for Review**: After submitting your PR, please wait for it to be reviewed and approved before merging.

Custom Contribution Guidelines for Open Source Projects

A template for creating contribution guidelines for open source projects.