We use Commitlint to maintain a consistent commit message format across the project. This ensures a clear and meaningful commit history. Please adhere to the following guidelines:
-
Type: Defines the type of change being made. Valid types include:
fix: A bug fixfeat: A new featuredocs: Documentation updatesstyle: Code style changes (formatting, missing semi-colons, etc.)refactor: Code changes that neither fix a bug nor add a featuretest: Adding or updating testschore: Changes to the build process or auxiliary tools and libraries
-
Subject: A brief summary of the change, ideally less than 100 characters. It should be descriptive but concise.
- Good:
feat: add user profile page - Good:
fix: resolve issue with login form validation - Bad:
update files(too vague) - Bad:
fix bug(missing details)
Note: The commit message must include a type and a non-empty subject. Avoid using capital letters or punctuation (e.g., ! or ?) in the type.
- Write your commit message according to the format above.
- Commit your changes. If your commit message does not conform to the rules, the commit will be rejected, and you’ll need to correct it.
ESLint is used to ensure code quality and enforce coding standards across the project. Here’s what you need to know:
-
File Types: ESLint is configured to lint
.jsand.jsxfiles located in thesrcdirectory. -
Ignored Files: ESLint will ignore files and directories specified in the configuration:
dist/directorycommitlint.config.js(since it is not part of the source code)
- To Check Code: Run
npx eslint 'src/**/*.{js,jsx}'to analyze the code for issues. - To Fix Issues: Run
npx eslint 'src/**/*.{js,jsx}' --fixto automatically fix linting issues where possible.