eslint 配置项
eslint检查代码风格是好的,不过 有些换行报错 空格报错 还有在代码中有 console也是报错 这有些烦人
为了把这些烦人的报错给禁止掉
我们可以在package.json文件中 找到(或者在.eslintrc.js中找到rules)
“warn” or 1 - 将规则视为一个警告(并不会导致检查不通过)
“error” or 2 - 将规则视为一个错误 (退出码为1,检查不通过)
.常用规则
类别 描述
Possible Errors 可能的错误或逻辑错误
no-cond-assign 禁止条件表达式中出现模棱两可的赋值操作符
no-console 禁用console
no-constant-condition 禁止在条件中使用常量表达式
no-debugger 禁用 debugger
no-dupe-args 禁止 function 定义中出现重名参数
no-dupe-keys 禁止对象字面量中出现重复的 key
no-duplicate-case 禁止出现重复的 case 标签
no-empty 禁止出现空语句块
no-ex-assign 禁止对 catch 子句的参数重新赋值
no-extra-boolean-cast 禁止不必要的布尔转换
no-extra-parens 禁止不必要的括号
no-extra-semi 禁止不必要的分号
no-func-assign 禁止对 function 声明重新赋值
no-inner-declarations 禁止在嵌套的块中出现变量声明或 function 声明
no-irregular-whitespace 禁止在字符串和注释之外不规则的空白
no-obj-calls 禁止把全局对象作为函数调用
no-sparse-arrays 禁用稀疏数组
no-prototype-builtins 禁止直接使用Object.prototypes 的内置属性
no-unexpected-multiline 禁止出现令人困惑的多行表达式
no-unreachable 禁止在return、throw、continue 和 break语句之后出现不可达代码
use-isnan 要求使用 isNaN() 检查 NaN
valid-typeof 强制 typeof 表达式与有效的字符串进行比较
—– —–
Best Practices 最佳实践
array-callback-return 强制数组方法的回调函数中有 return 语句
block-scoped-var 强制把变量的使用限制在其定义的作用域范围内
complexity 指定程序中允许的最大环路复杂度
consistent-return 要求 return 语句要么总是指定返回的值,要么不指定
curly 强制所有控制语句使用一致的括号风格
default-case 要求 switch 语句中有 default 分支
dot-location 强制在点号之前和之后一致的换行
dot-notation 强制在任何允许的时候使用点号
eqeqeq 要求使用 === 和 !==
guard-for-in 要求 for-in 循环中有一个 if 语句
no-alert 禁用 alert、confirm 和 prompt
no-case-declarations 不允许在 case 子句中使用词法声明
no-else-return 禁止 if 语句中有 return 之后有 else
no-empty-function 禁止出现空函数
no-eq-null 禁止在没有类型检查操作符的情况下与 null 进行比较
no-eval 禁用 eval()
no-extra-bind 禁止不必要的 .bind() 调用
no-fallthrough 禁止 case 语句落空
no-floating-decimal 禁止数字字面量中使用前导和末尾小数点
no-implicit-coercion 禁止使用短符号进行类型转换
no-implicit-globals 禁止在全局范围内使用 var 和命名的 function 声明
no-invalid-this: 禁止 this 关键字出现在类和类对象之外
no-lone-blocks 禁用不必要的嵌套块
no-loop-func 禁止在循环中出现 function 声明和表达式
no-magic-numbers 禁用魔术数字
no-multi-spaces 禁止使用多个空格
no-multi-str 禁止使用多行字符串
no-new 禁止在非赋值或条件语句中使用 new 操作符
no-new-func 禁止对 Function 对象使用 new 操作符
no-new-wrappers 禁止对 String,Number 和 Boolean 使用 new 操作符
no-param-reassign 不允许对 function 的参数进行重新赋值
no-redeclare 禁止使用 var 多次声明同一变量
no-return-assign 禁止在 return 语句中使用赋值语句
no-script-url 禁止使用 javascript: url
no-self-assign 禁止自我赋值
no-self-compare 禁止自身比较
no-sequences 禁用逗号操作符
no-unmodified-loop-condition 禁用一成不变的循环条件
no-unused-expressions 禁止出现未使用过的表达式
no-useless-call 禁止不必要的 .call() 和 .apply()
no-useless-concat 禁止不必要的字符串字面量或模板字面量的连接
vars-on-top 要求所有的 var 声明出现在它们所在的作用域顶部
—– —–
Strict Mode 使用严格模式和严格模式指
strict 要求或禁止使用严格模式指令
—– —–
Variables 变量声明
init-declarations 要求或禁止 var 声明中的初始化
no-catch-shadow 不允许 catch 子句的参数与外层作用域中的变量同名
no-restricted-globals 禁用特定的全局变量
no-shadow 禁止 var 声明 与外层作用域的变量同名
no-undef 禁用未声明的变量,除非它们在 /global / 注释中被提到
no-undef-init 禁止将变量初始化为 undefined
no-unused-vars 禁止出现未使用过的变量
no-use-before-define 不允许在变量定义之前使用它们
—– —–
Nodejs and CommonJS Node.js,CommonJS
global-require 要求 require() 出现在顶层模块作用域中
handle-callback-err 要求回调函数中有容错处理
no-mixed-requires 禁止混合常规 var 声明和 require 调用
no-new-require 禁止调用 require 时使用 new 操作符
no-path-concat 禁止对 dirname 和 filename进行字符串连接
no-restricted-modules 禁用指定的通过 require 加载的模块
—– —–
Stylistic Issues 风格指南
array-bracket-spacing 强制数组方括号中使用一致的空格
block-spacing 强制在单行代码块中使用一致的空格
brace-style 强制在代码块中使用一致的大括号风格
camelcase 强制使用骆驼拼写法命名约定
comma-spacing 强制在逗号前后使用一致的空格
comma-style 强制使用一致的逗号风格
computed-property-spacing 强制在计算的属性的方括号中使用一致的空格
eol-last 强制文件末尾至少保留一行空行
func-names 强制使用命名的 function 表达式
func-style 强制一致地使用函数声明或函数表达式
indent 强制使用一致的缩进
jsx-quotes 强制在 JSX 属性中一致地使用双引号或单引号
key-spacing 强制在对象字面量的属性中键和值之间使用一致的间距
keyword-spacing 强制在关键字前后使用一致的空格
linebreak-style 强制使用一致的换行风格
lines-around-comment 要求在注释周围有空行
max-depth 强制可嵌套的块的最大深度
max-len 强制一行的最大长度
max-lines 强制最大行数
max-nested-callbacks 强制回调函数最大嵌套深度
max-params 强制 function 定义中最多允许的参数数量
max-statements 强制 function 块最多允许的的语句数量
max-statements-per-line 强制每一行中所允许的最大语句数量
new-cap 要求构造函数首字母大写
new-parens 要求调用无参构造函数时有圆括号
newline-after-var 要求或禁止 var 声明语句后有一行空行
newline-before-return 要求 return 语句之前有一空行
newline-per-chained-call 要求方法链中每个调用都有一个换行符
no-array-constructor 禁止使用 Array 构造函数
no-continue 禁用 continue 语句
no-inline-comments 禁止在代码行后使用内联注释
no-lonely-if 禁止 if 作为唯一的语句出现在 else 语句中
no-mixed-spaces-and-tabs 不允许空格和 tab 混合缩进
no-multiple-empty-lines 不允许多个空行
no-negated-condition 不允许否定的表达式
no-plusplus 禁止使用一元操作符 ++ 和 –
no-spaced-func 禁止 function 标识符和括号之间出现空格
no-ternary 不允许使用三元操作符
no-trailing-spaces 禁用行尾空格
no-whitespace-before-property 禁止属性前有空白
object-curly-newline 强制花括号内换行符的一致性
object-curly-spacing 强制在花括号中使用一致的空格
object-property-newline 强制将对象的属性放在不同的行上
one-var 强制函数中的变量要么一起声明要么分开声明
one-var-declaration-per-line 要求或禁止在 var 声明周围换行
operator-assignment 要求或禁止在可能的情况下要求使用简化的赋值操作符
operator-linebreak 强制操作符使用一致的换行符
quote-props 要求对象字面量属性名称用引号括起来
quotes 强制使用一致的反勾号、双引号或单引号
require-jsdoc 要求使用 JSDoc 注释
semi 要求或禁止使用分号而不是 ASI
semi-spacing 强制分号之前和之后使用一致的空格
sort-vars 要求同一个声明块中的变量按顺序排列
space-before-blocks 强制在块之前使用一致的空格
space-before-function-paren 强制在 function的左括号之前使用一致的空格
space-in-parens 强制在圆括号内使用一致的空格
space-infix-ops 要求操作符周围有空格
space-unary-ops 强制在一元操作符前后使用一致的空格
spaced-comment 强制在注释中 // 或 /* 使用一致的空格
转载于https://github.com/zsqk/zsqk/issues/120
在 TypeScript 之前, 学习 JavaScript/ECMAScript(简称 JS) 最好的老师就是 ESLint.
是 ESLint 让我学习 JS, 并使用 JS 到现在的.
大多数情况下我都是不建议自己完善规则的, 因为 Airbnb 的规则已经足够好用了, React 也有自己的规则建议. 并且 TypeScript 能做的更多.
最近在整理微信小程序的项目, 在为这个项目完善 ESLint 规则的时候, 顺便也整理一份文字出来, 讲讲我这样设置的原因.
我的简短文字更像是笔记, 希望大家对照着 ESLint 自带的规则 来看.
被推荐的规则, 建议大家遵循, 同时建议没看过的同学在有空时翻看一下.
针对没有添加到 eslint:recommended
的, 下面逐一说:
避免错误
no-await-in-loop
不允许在循环中嵌套 await.
🟡 没有使用该规则.
我的原因很简单, 就是当想避免同时并发时, 在循环里 await wait('100ms');fetch('something');
还是有意义的.
no-console
不允许控制台输出
🟢使用该规则: error
.
如果真是希望长期留存输出, 建议大家通过一个函数进行包裹, 然后仅在该函数中使用, 然后通过注释 disable-eslint
来避免报错.
no-extra-parens
不使用没必要的括号.
🟢使用该规则: error
.
这里有一些小知识点, 比如算术运算符是遵循数学的, 乘除号优先级一样, 但逻辑运算符可不是. 推荐大家看看MDN 关于运算符优先级的相关文档, 比如 &&
是优先于 ||
的.
no-template-curly-in-string
普通字符串中不使用参数占位符
🟢 使用该规则: error
.
为了避免本来使用重音符但使用了引号的情况, 要求普通字符串中不能出现参数占位符. 是一点限制, 但基本不会有人故意在普通字符串中非要使用参数占位符, 如果非要, 那就用编码吧, 比如 '\u0024{}'
.
[7.0] no-useless-backreference
🟡 没有使用该规则.
这是最近才添加的新规则, 关于字符串正则的, 我们很少写正则.
因为 7.0 版本还在测试, 直接进入 404, 可以通过这里看文档.
require-atomic-updates
涉及异步时, 优先执行异步
🟢 使用该规则: error
.
虽然我们尽量写纯函数, 避免这种用法是可能的. 之所以会出现这样的问题, 也算是因为 JavaScript 的糟粕吧, 没有指针.
最佳实践
accessor-pairs
要求 Get 和 Set 同时出现
🟢 使用该规则: error
.
如果只 Set, 没有 Get, 那么使用 Set 就是毫无意义的. 不过反之则可能是真实需求, 所以使用默认规则只限制前者即可.
array-callback-return
数组某些方法的回调函数要求一定有返回值
🟢 使用该规则: error
.
我们遇到过本该使用 for 却使用 map 的代码. 该规则能一定程度上避免问题, 但无法检测出有人随便返回了一个值的情况. 所以还是要大家统一思想啊, 尽量写明确, 简洁, 清晰的代码.
block-scoped-var
无视 var 的作用域 hoisting
🟡 没有使用该规则.
在没有 let/const 时, 这个功能有用. 在 ES6 之后, 使用 no-var
就可避免这种语言问题.
class-methods-use-this
类的方法必须使用 this
🟢 使用该规则: error
.
如果一个类的方法没有使用到 this, 那么写成静态方法或者纯函数更好.
complexity
嵌套复杂度
🟢 使用该规则: ["error", 10]
尽量将每个函数写小一点, 增加代码可读性. 但考虑到整体团队和项目具体的情况, 需要选择一个合适的值.
consistent-return
一致性的返回
🟢 使用该规则: error
.
帮助我们思考, 这个函数为什么要这样用, 该不该这样用, 同时避免一些低级错误如 map 的特殊情况忘了返回默认值.
curly
要求写大括号
🟢 使用该规则: error
.
主要算是代码风格上的要求. 但也是因为 JS 的大括号省略规则可读性差, 还是写个大括号吧.
default-case
要求 switch 必须有 default
🟢 使用该规则: error
.
主要是为了避免手误.
[7.0] default-case-last
要求 switch 的 default 必须在末尾
🟢 使用该规则: error
.
从语义上理解, 将兜底方案放在末尾是可读性最佳的. 可以通过这里看文档.
default-param-last
函数有默认值的参数必须在最后
🟢 使用该规则: error
.
在 JS 中函数可以有多个参数, 一般前面的必填, 后面的选填. 否则就会造成使用不便, 每次请求的时候都要传个无效值, 如 foo(undefined, 1)
. 有默认值的参数都是可选, 所以放在最好方面函数的使用.
另外, 如果有多个可选参数, 建议使用 foo(need, options = {})
的方式定义函数, 将可选参数都放入 options
内.
dot-location
属性点号的位置
🟢 使用该规则: ["error", "property"]
.
这是关于风格一致性的约束. 不过实际中我们很少针对对象属性换行, 因为需要换行的时候, 一定是比较长了, 但我们需要避免这么长的命名出现. 如果真的需要, 我们希望在行首能知道, 同时要有缩进.
dot-notation
必须使用点号来访问属性
🟢 使用该规则: error
.
如果我们使用驼峰式命名, 那么这个一般是必要的. 但特殊情况下我们要处理后端直接返回的下划线风格命名时, 比如 SQL 列名, 就会出现问题, 建议遇到实际情况并且需要, 再使用 allowPattern
选项来允许特殊情况.
eqeqeq
必须使用全等
🟢 使用该规则: error
.
首先, 非全等并不会更快, 因为非全等是做了隐性的类型转换. 其次, 所有隐性的类型转换都是不建议的, 只会让错误更容易发生(哪怕只提升了 0.00001% 的错误概率), 并不能提高开发效率.
在一些情况下, 有人希望使用 == null
来同时判断 null 与 undefined. 但我不建议这样做, 如果需要这样的判断, 单独做一个函数, 在函数内进行 disable rule 就行了.
grouped-accessor-pairs
要求 Get/Set 相邻
🟢 使用该规则: error
.
这是一个代码可读性的问题, 一个属性的 Get/Set 要相邻. 这个大家应该都同意吧.
guard-for-in
谨慎使用 for in
🟢 使用该规则: error
.
在大多数业务代码中, 都不需要使用 for in
, 建议大家使用 for of
替代. for in
会遍历原型链, 一是没必要的慢, 二是很多时候我们不知道原型链中有什么.
现实情况可能是大家不知道这些个 for 循环都有什么区别, 尤其是被网上的一些代码带偏了. ☹️
max-classes-per-file
强制规定一个文件里面类的数量
🟢 使用该规则: error
.
以前 React 没有 Hooks 时经常写类, 现在前端很少写类了. 后端 Node.js 在数据操作上, 还是有类的. 每种数据一个类, 一个文件, 管理起来很方便.
no-alert
禁止使用 alert 等直接涉及 UI 的函数
🟡 没有使用该规则.
虽然历史原因是全局的, 但实际这些应该是 Window 的方法. 平时基本不会这些函数. 微信小程序等也是没有这些 Web API 的. 虽然会与 UI 界面不符, 但我真的希望浏览器能把这个功能做好, 我想用. 🌞
no-caller
禁止匿名函数内部自调用
🟢 使用该规则: error
.
出于性能考虑, 在 ES6 之后, arguments 就是不被推荐的了. 解决方法就是给函数命名.
no-constructor-return
禁止构造函数的返回
🟢 使用该规则: error
.
在构造函数中设置 return 是没有意义的. 如果出现, 一般都是写错了.
no-div-regex
避免可能与除法混淆的正则写法
🟢 使用该规则: error
.
使用引号来表示字符串, 使用 /
来表示正则. /
同时也可以表示除号, 这种一个符号两种用法在特定情况下会让人不容易理解. 可能出现歧义时, 我也建议使用 new RegExp
来表示正则.
no-else-return
不使用没必要的 else
🟢 使用该规则: error
.
梳理一下逻辑, 使用最简单有效并且可读的做法. 这个例子在我初学时对我影响很大. 初学时, 最大的疑问就是, 什么才算好代码?
no-empty-function
避免空函数
🟢 使用该规则: error
.
一般只有在未完成的时候才会保留空函数, 这个规则考虑到了该情况, 如果函数内有一些注释, 则不会报错.
no-eq-null
禁止与 null 进行非全等比较
🟡 没有使用该规则.
不是说这个规则没用, 是因为 eqeqeq
规则已经做了限定.
no-eval
禁止将字符串当作代码执行
🟢 使用该规则: error
.
函数如其名. 这样做是非常不安全的.
no-extend-native
禁止扩展原生对象
🟢 使用该规则: error
.
对于大多数业务代码来说, 不要修改标准库, 任何情况下都可以找到替代方案.
no-extra-bind
禁止不必要的绑定
🟢 使用该规则: error
.
fn.bind()
的目的是用来在函数运行时指定 this 而不是使用当前 this, 如果函数内没有用到 this, 就没有任何意义.
no-extra-label
禁止使用不必要的标签
🟡 没有使用该规则.
我们会通过 no-labels
来禁用标签, 所以这条规则没有使用.
no-floating-decimal
禁止浮点数省略 0
🟢 使用该规则: error
.
怎么说呢, 我认为这也是 JS 的语法糟粕. 不过还好, 在项目中我暂时没有遇到有人这么写代码.
no-implicit-coercion
禁止隐晦的类型转换
🟢 使用该规则: error
.
依然是 JS 的语法糟粕. 但类似 '' + something
的写法我还是见过的.
no-implicit-globals
禁止隐晦的全局声明
🟡 没有使用该规则.
在 no-var
规则开启的时候, 这条规则失去了原有的意义. 而且现在项目都是模块化的代码, 所以没必要使用这条规则.
no-implied-eval
禁止使用隐性 eval
🟢 使用该规则: error
.
类似 no-eval
规则.
no-invalid-this
禁止无效的 this 引用
🟢 使用该规则: error
.
很多时候, 无效的 this 引用并不是说 this 是 undefined, 而是没必要这样去引用 this. 比如浏览器中, 全局使用 this 等同于 window, 使用 window 就好, 没必要使用 this. 还是让 this 只出现的类中吧.
no-iterator
禁止使用 __iterator__
属性
🔵 可选使用该规则.
在 ES6 以后, 使用迭代器来替代 __iterator__
的功能. 禁用主要因为 __iterator__
并不是一个标准.
no-labels
禁用标签
🟢 使用该规则: error
.
我从来没有见过有人使用 label 语法, 这语法本身的含义也让我困惑. 不过还好, 我知道, 它没用, 完全可以被更简单清晰的语法替代.
no-lone-blocks
禁用不必要的大括号
🟢 使用该规则: error
.
大多数情况下, 应该是手误提醒. 但在我开发的经验中, 没有遇到这种情况. 不过需要注意的是, 任何大括号都会创建一个作用域, 虽然这点在特殊情况下可能会有用, 但一般都可以使用另一种写法而没必要特意创建一个作用域.
no-loop-func
禁止在循环中声明函数
🟢 使用该规则: error
.
在循环中声明函数一般是为了将循环中的变量传入到函数中执行. 但我们不应该滥用闭包, 纯函数就能避免潜在的问题. 比如除了避免使用 var 的方法外, 我们还可以在使用 var 时这样做:
let funcs = [];
let t = v => (() => v);
for (var i = 0; i < 10; i++) {
funcs[i] = t(i);
}
我不是在鼓励大家使用 var, 而是在鼓励大家写纯函数并且善用闭包而不是滥用闭包.
no-magic-numbers
禁止使用魔术标识符
🟢 使用该规则: error
.
在这里, "魔术" 的意思是不知道是怎么回事儿, 但就是起作用了. 该规则主要是希望使用更良好命名的常量来规范代码. 触发该规则的大多数情况是在开发初期, 为了方便快捷而为之, 但无论如何, 良好的命名对整体工作都是有利而无害的.
no-multi-spaces
禁止多个空格
🟢 使用该规则: error
.
主要是代码风格上的规范. 让代码整体上可读性更好. 如果经常触发该规则, 可能是键盘的空格键坏了. 😛
no-multi-str
禁止多行字符串
🟢使用该规则: error
.
普通字符串的多行一般都是出错了. 如果在字符串中手动添加了换行符, 现在一般使用模板字符串来做字符串的多行, 这是一个比换行符更简单直观的办法.
no-new
禁止单独使用 new
🟢 使用该规则: error
.
如果不为赋值, 没必要使用 new. 如果构造函数中有什么想要做的, 写成纯函数更好.
no-new-func
禁止使用 Function
🔵 可选使用该规则.
没必要把一个简单的事情做复杂, 尤其是 Function 的参数还有 eval 的味道.
no-new-wrappers
禁止在原生类型上使用 new
🟢 使用该规则: error
.
在做类型转换的时候 Number 等还是比较常用的, 但需要注意的时候, 这些时候都不能在前面加 new. 为了防止意外, 这条规则还是有意义的.
no-octal-escape
禁止出现八进制字符转义
🟢 使用该规则: error
.
在一些特殊情况下, 我们会使用字符转义. 现在基本所有编程语言都不支持八进制字符了, 均为 Unicode 或十六进制. 虽然 Unicode 会使用十六进制来表示, 但建议统一使用 Unicode, 即 /u
开头.
no-param-reassign
禁止修改函数的参数
🟢 使用该规则: error
.
在我看到的代码中, 这条规则非常不容易被遵守. 有些时候从性能考虑, 我们想直接修改函数外的变量. 但其中很多时候, 我们都在冒潜在的风险, 因为我们不知道将来谁还会使用这个函数.
我建议还是将此规则打开, 如果需要, 在函数处写好注释然后临时关闭该规则.
no-proto
禁止使用 __proto__
🟢 使用该规则: error
.
这是已被标准丢弃的用法, 但我曾多次看到互联网上有古老的代码使用了这一特性. 目前这一功能仅应该在兼容库中看到, 而我们使用的东西早已不支持 IE6, IE8 了.
图例:
🟢 使用该规则. 🟡 没有使用该规则. 🔵 业务代码基本不会触发该规则, 选择性使用.