Codes of Practice ESLint + Prettier

premise

This article does not alone explain ESLint Prettier and how to configure and run.

problem

I would like to pursue a certain code specification in the team, and to make non-compliant code detection and prompt.

Program

ESLint use code standards checking, but only a start ESLint tell you where the problem is detected, often the case is that a bunch of warning, to change it is very painful. Later ESLint provides $ ESLint filename --fixcommands can help you automatically fix some non-compliant code. Prettier is a code formatting tools that can help you put the code into a more readable format to format, the most typical is the problem line of code is too long.

Lint and Prettier difference

What difference ESLint and Prettier is it? The main function eslint (including lint other tools) comprising check code formats, code quality check. And Prettier check code format only (and formatting codes), quality of the code will not be verified. Code format question generally refers to: single line of code length, tab length, spaces, commas, expression and so on. The question refers to the code quality: unused variable number Third, global variable declaration and other issues.

Lint and Prettier used in conjunction with

Why use the combination of the two? Because, before the first launch --fix parameter in ESLint, ESLint did not feature automated format code, to make bulk format for some formatting issues can only use this tool Prettier. The second rule ESLint does not fully contain rules Prettier, both of whom not a simple alternative to whom. But after the introduction of --fix command line arguments in ESLint, if you feel formatting codes ESLint provided enough, you may not be used Prettier.

Prettier time ESLint and cooperate with each other there are some problems, for some of their regular intersection, inconsistent after ESLint and Prettier format code format. The problem is caused by: Prettier when you use the formatting code and then use ESLint to detect, there will be some warning as a result of formatting. This time there are two solutions:

  1. After running Prettier, then use a eslint --fix format, so the part of the conflict is to ESLint format standard overwritten, and the rest are warning on code quality problem.
  2. In the configuration validation rules ESLint when the conflict and rules Prettier disable swap, and then use the rule Prettier as validation rules. So after using Prettier format, use ESLint check warning will not appear on the former.

Why not be the first to use ESLint re-use Prettier. For Option 1, if Prettier after you, then submit the code formatting or others after checkout the next code pass lint check. For Option 2, it can actually be, but when I mentioned that in the practice, community programs eslint --fix and prettier mix in some cases there will be formatting issues. So be safe first, or perttier format, and then eslint command check, without eslint --fix command to format.

Option One practice

  1. Installation prettier-eslint (Tip: All programs, provided that you have installed eslint and prettier related packages):

    $ npm install --save-dev prettier-eslint prettier-eslint-cli
    
  2. run

    $ npm prettier-eslint "src/**/*.js"
    

    prettier-eslint will be the first performance prettier and eslint --fix command. The whole process is: Code ➡️ prettier ➡️ eslint --fix ➡️ Formatted Code. Various parameters prettier-eslint Refer to https://github.com/prettier/prettier-eslint-cli .

Option II practice

Scheme II is the main idea of ​​rule configuration file eslint fuss, install a specific plugin, to the end of the configured rules, to achieve coverage of eslint prettier rules rules.

  1. Install plugin:

    $ npm install --save-dev eslint-config-prettier
    
  2. . * Files inside the extends field Add .eslintrc:

    {
      "extends": [
        ...,
        "已经配置的规则",
    +   "prettier",
    +   "prettier/@typescript-eslint"
      ]
    }
    
    

    I am using a TypeScript, so the plugin name is prettier / @ typescript-eslint.

    If you want to disable out more rules may be as follows:

    {
      "extends": [
        ...,
        "已经配置的规则",
        "prettier",
        "prettier/@typescript-eslint",
        "prettier/babel",
        "prettier/flowtype",
        "prettier/react",
        "prettier/standard",
        "prettier/unicorn",
        "prettier/vue"
      ]
    }
    
    

    See the name should be able to guess what each corresponding rules disable it.

  3. The above two steps can be achieved is to run eslint command will do the checks in accordance with the rules prettier, but still need to run prettier and eslint command, respectively. A community program has integrated the above two steps, using eslint --fix time, instead of the actual prettier eslint of formatting functions.
    installation:

    $ npm install --save-dev eslint-plugin-prettier
    

    Modify .eslintrc. *

    {
      "extends": [
        ...,
        "已经配置的规则",
        "plugin:prettier/recommended"
      ]
    }
    
    

    This time you run eslint --fix is Prettier actually used to format the file. eslint-plugin-prettier specific configuration details, see: https://github.com/prettier/eslint-plugin-prettier

And integrated use VSCode

All the content mentioned above are written in your code to check, using a command-line tool. If you are a novice, to regulate not very familiar with, then the problem encountered is finished code to run commands generated after massive warning line tool. This time change up really motivating. If you can allow editors tips when writing code that can be corrected in a timely manner. We naturally also offers many community programs, various mainstream editor Atom, Sublime, VSCode and other editors have the relevant plug. I will take VSCode example:

  1. Download ESLint Extension


    80789-c8d244fd9026f1a0.png
    vscode-eslint-extension.png
  2. Configuring .eslintrc. *

module.exports =  {
  parser:  '@typescript-eslint/parser',
  extends:  [
    'plugin:@typescript-eslint/recommended',
    'prettier/@typescript-eslint',
    'plugin:prettier/recommended'
  ],
  parserOptions:  {
    ecmaVersion:  2018,
    sourceType:  'module'
  },
  // 其他配置
};
  1. Because I used TypeScript so .eslintrc. * Values ​​and javascript configuration items is a bit different, but the principle is the same. If you do not use TypeScript then to the top step over. But VSCode of ESLint no natural support plug-ts files, so we must also establish a settings file itself. New .vscode / settings.json file in the root directory of the project, as follows:
    {
      "eslint.validate": [
        "javascript",
        "javascriptreact",
        { 
          "language": "typescript",
          "autoFix": true
        },
        { 
          "language": "typescriptreact",
          "autoFix": true
        }
      ]
    }
    

You can see real-time editor of the code suggests.

Forced validation and formatting

Talking about this with the use of two tools already speak well, but these steps are dependent on human consciousness, forced to do a little bit of function, we can use the husky lint-staged to force code formatting and code before git commit check.

  1. installation

    $npm install --save-dev husky lint-staged
    
  2. Modify package.json:

    {
      "name": "project-name",
      ...,
      + "husky": {
      +     "hooks": {
      +         "pre-commit": "lint-staged"
      +     }
      + },
      + "lint-staged": {
      +     "src/**/*.{js,jsx,ts,tsx,json,css,scss,md}": [
      +     "prettier --write",
      +     "eslint",
      +     "git add"
      +     ]
      + },
    }
    
  3. Then run git commit time, automatically will go to run prettier --write formatting code, and then run the code eslint check for compliance. These two steps are not committed by code. If any step fails, it stops submitted.

If you use a program, command lint-staged configuration:

{
  "name": "project-name",
  ...,
  +  "husky": {
  +    "hooks": {
  +      "pre-commit": "lint-staged"
  +    }
  +  },
  + "lint-staged": {
  +   "src/**/*.{js,jsx,ts,tsx,json,css,scss,md}": [
  +     "prettier-eslint",
  +     "git add"
  +   ]
  + },
}

If you use the program two eslint-plugin-prettier, lint-staged configuration command:

{
  "name": "project-name",
  ...,
  +  "husky": {
  +    "hooks": {
  +      "pre-commit": "lint-staged"
  +    }
  +  },
  + "lint-staged": {
  +   "src/**/*.{js,jsx,ts,tsx,json,css,scss,md}": [
  +     "eslint --fix",
  +     "git add"
  +   ]
  + },
}

references

  1. https://eslint.org/
  2. https://prettier.io/
  3. https://restishistory.net/blog/whats-the-difference-between-eslint-and-prettier.html

If you are using TypeScript:

  1. How to use the TS project ESLint
  2. How Prettier and used in conjunction with

Guess you like

Origin blog.csdn.net/weixin_34033624/article/details/91022348