Project Name

• Contents
  • Getting Started
    • Run the development server
    • Run the production server
    • Run linter
    • Run type checking
  • Contribution Guidelines
  • Commit Message Guidelines
  • Pull Request Guidelines

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

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

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.