Saber front-end framework uses ESlint to standardize unified project code style

I. Introduction

---

  Since the company's Saberfront-end framework does not ESlintconstrain the code specification, various code styles are very different during the development process, and specifications cannot be formed, resulting in difficulties in future maintenance. For this reason, our company decided to use ESlintthe standard to unify the project style.

2. Code style

---

• Overall style
  • javascriptgenerally follow ESlintthe norm
  • html, wxmlgenerally follow prettyhtmlthe norms
• javascriptdetail adjustment
  • no semicolon at the end
  • Wrap over 140 characters
  • use single quotes
  • no trailing comma
  • Arrow function single parameter without semicolon
  • Spaces before parentheses are prohibited in function declarations

3. Preliminary preparation

---

• Refer to VS Code to configure automatic formatting and unified code specification

4. Add itemsESlint

---

1. .eslintrc.jsWhen adding a function declaration to the project, it is forbidden to have a space rule before the parentheses

  When resolving Prettierformatting conflicts with ESlintthe specification, an error is reported. For conflict reasons, please refer to Prettier does not support spaces after functions? See what the community says

// 函数声明时禁止圆括号前有空格
'space-before-function-paren': 'off'

2. Add the root directory of the project .prettierrcand specify Prettierthe formatting rules

jsThe defined rules did not take effect when   resolving format files. Because .editorconfigthe formatting is higher than the formatting rules of the compiler, Prettierthe defined formatting does not take effect. If there is no effective reason, please refer to EditorConfig-Priority

{
  "semi": false,
  "printWidth": 140,
  "singleQuote": true,
  "trailingComma": "none",
  "arrowParens": "avoid"
}

3. Add itemsESlint

• vue add @vue/eslint
• choose StandardandLint on Save
  

4. Modify the error message

  There are two ways to modify the error message, one is to ignore the file check and hide the error message; the second is to modify according to the error message rules. There are two ways to choose one of the following

1. Ignore file checks, hide error messages

忽略整个文件检查，一般写在文件头部
/* eslint-disable */
忽略单行检查
/* eslint-disable-line */
忽略下一行检验
/* eslint-disable-next-line */
忽略多行检查
/* eslint-disable */
// js code
/* eslint-enable */
忽略具体错误类型 
/* eslint-disable-line [错误类型] */

2. Modify according to the error message

• no camelCase
• There is no such thing as strong ===or strong!==
• The framework code itself is wrong

解决方式：为了框架能正确运行，如果是框架本身的报错信息，用忽略文件或单行文件进行修改，自己写的代码严格遵循ESlint规范。