Before the development of the project, a good development specification can help us standardize the process and avoid problems such as difficult maintenance of the later project and difficult reading of the COMMIT log due to laziness and other factors. Taking advantage of the project opportunity, the formatting tool prettier was used to format the project, and commitlint bound git commit. For later maintenance, easy for others to read the code. Step on a lot of pits in the middle, I hope to bring help to you

Note: This project is created based on create-react-app

configurationprettierFormatting tool

Question and answer session

  1. React doesn’t provide for useslint?

Eslint can only do syntax checking and only check for syntax errors. Prettier is a code formatting tool that makes sure your code looks the same way even when someone else reads it.

  1. Why prettier?
    • When you press the Save key, the code is formatted
    • Code reviews don’t debate code styles
    • Save time and energy

If you followprettierFor installation use, there are several pits that need attention, please read below.

Simple configuration

  1. The installation

    npm install --save-dev --save-exact prettier

  2. echo {}> .prettierrc.json

    If you’re usingwindowsComputer and usevscodeTerminal, according to the official website in your project using the above command to create.prettierrc.jsonFile, the creation process will not occur any errors, but in your following operations, such as usingnpx prettier --write .Commands give errors and are hard to locate. And the reason is, when you create it, you create a format that’s notutd8The format ofjsonFiles, depending on your system and computer. Because the error information is not accurately positioned, it is difficult to troubleshoot. You can create the file manually or format the file toutf8

  3. Create a. Prettierignore file that ignores files or folders that do not need formatting

  4. Format NPX prettier –write

    Use this command to format a file or folder of your choice. As shown below, the comparison between before and after formatting.

    • Format the previous code snippet

Before formatting, the code does not have a new line, so it is beyond the visual studio code display area. Maybe many students will set the maximum visual studio code display length. But because everyone’s configuration is different, in order to make one set of code look the same in everyone’s editor. So prettier is used

  • Formatted snippets of code

  1. Every time you format, you have to typenpx prettier --writeThis command is a little cumbersome. We want to be smarter. Two options are provided, one is to useprettierSupported editor plug-ins, such asvscodethePrettier - Code formatter, just need to be invscodeAnd then you can use the shortcut keysCtrl + Shift + PTo format the file. However, we feel that this approach is not automated enough, so we highlight the following method, using automation tools to help us with formatting.

Configuring automation Tools

Pre-knowledge (don’t worry if you don’t know)
  1. Husky is a tool that adds hooks to Git clients. Once installed, it automatically adds hooks to the.git/ directory in your repository. For example, a pre-commit hook will trigger when you perform a Git commit. You can implement things like lint checking, unit testing, and code formatting in pre-commit.

  2. Lint-staged, a tool that simply filters out Git code staging files (files added by Git); If we do a review of the entire project code, it may take a long time, if it is an old project, to do a code specification review and modify the previous code, it may lead to a big change in the project.

    Lint-staged, a great tool for team projects and open source projects, is a specification and discipline for the code to be submitted by individuals.

configuration
  1. npx mrm lint-staged

    MRM is an automated tool that will install and configure Husky and Lint-staged from code quality tools in package.json dependencies, so be sure to install and configure all code quality tools, such as Prettier and Slint, before you do this

    Note: Installation may fail becausemrmNeed to install separately, please usenpm install mrm -D

  2. Configure the package.json file

    Example: create-react-app creates a project that, by default, provides ESLint for code checking to avoid colliding with Prettier. We use prettier to override part of an ESLint configuration. The following

    "eslintConfig": {
        "extends": [
          "react-app"."react-app/jest"."prettier"]}Copy the code

    Add the following configuration in package.json

      "husky": {
        "hooks": {
          "pre-commit": "lint-staged"
        }
      },
      "lint-staged": {
        "*.{js,css,md,ts,tsx}": "prettier --write"
      }
    Copy the code

    When git commit is used, hooks defined in Husky are called. This hook will go to Lint-staged formatting where the command prettier –write was used in the beginning of manual formatting. At this point, this set of automated tools will help us automatically format our COMMIT code.

commitlint

The tool checks that our Commit messages conform to the specification every time we commit. It provides us with a set of rules that we must follow to fill in Commit messages. The benefit of this is that our later Commit messages are very readable. By reading this, you can clearly know what changes or operations we made in this COMMIT.

Install the configuration

  1. install

    npm install -g @commitlint/cli @commitlint/config-conventional

  2. Configure

    echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

  3. The configuration rules will help verify that git commit messages conform to the specification when using commit.

    "husky": {
        "hooks": {
          "pre-commit": "lint-staged"."commit-msg": "commitlint -E HUSKY_GIT_PARAMS"}}Copy the code

Git commit format

git commit -m <type>[optional scope]: <description>
Copy the code
Common type categories

Type: Indicates the type of change we are committing this time

  • Build: The main purpose is to modify the commit of the project build system (e.g. glUP, Webpack, rollup configuration, etc.)

  • Ci: The main purpose is to modify the submission of the project to continue the integration process (e.g. Travis, Jenkins, GitLab CI, Circle, etc.)

  • Docs: Updates the document

  • Feat: Added function

  • Fix: Fixes bugs

  • Perf: Performance optimization

  • Refactor: Refactoring code (no new features, no bug fixes)

  • Style: Code changes that do not affect program logic (modify whitespace characters, complete missing semicolons, etc.)

  • Test: Add a test case or update an existing test

  • Revert: Rolls back an earlier submission

  • Chore: Any other type that is not one of the above (chore)

Optional Scope: An optional modification scope. Identifies which module in the code is primarily involved in this commit.

Description: Describes the submitted content

example

git commit -m "test: test commitlint"
Copy the code

Configuring Prettier to automate code formatting, automatic detection, and commitlint configuration for Git commit There are more advanced features to discover.