pnpm dev

pnpm build
pnpm start

pnpm lint

pnpm tsc:check

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

<!--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.