ESLint 那么棒，不妨自己开发一个规则

ESLint 那么棒👍，不妨自己开发一个规则

本文章的目的是介绍如何编写一个自己的 eslint 规则并发布在项目中使用。

为什么要用❓

随着各个团队的人越来越多，开发的项目越来越多，项目中的代码也会变得风格迥异。
有些朋友喜欢第一种，有些朋友喜欢第二种

<Input onChange={
   (value)=>setValue(value)} />
<Input onChange={
   setValue} />

虽然这种不同的代码风格很难分个优劣，但是如果统一了，就能减少项目中代码风格的差异性，还可以提高代码的规范、减少 debug 成本、提高 review 效率。

什么场景需要自己开发规则💭

eslint 的自带规则有很多，而有时候也会出现已有的规则无法满足的情况。例如我所在团队的项目中，团队成员拥抱 css variable，并且诞生了 Dark Mode，此时如果允许 #fff、#3370ff，rgb(250,250,250)、var(--system-primary) 这些一起出现的话，就会极大地提高维护成本。那么我们就可以使用 eslint 编写一个 rule 禁止项目中使用：颜色名/十六进制/rgb(a)。
再比如，团队中已有开发好的 Input 组件，而 并不是每个团队成员（尤其对新同学来说）开发的时候就能知道：哦~原来在这个地方还有一个编写好的组件。挨个问是否有已有组件也不现实，所以开发者有时会新开发一个已有的类似组件。这个时候 eslint 插件就可以做一件事——当成员使用 Input 标签时，给予提示：在遥远的某处目录下，有一个写好的组件等你用呢，如果符合需求你就不用重复开发啦。
注：配合 vscode eslint 插件食用更佳，否则不会在编码阶段检测，只会在 commit 检测，这时候组件已经开发完了，影响初衷。

小任务✨

现在我们来定一个任务，如果 jsx style 出现 px 字面量则提示使用 number 类型替代 并且 style 的属性个数不超过 3（可定制就更棒了），再多的话，为何不用 className 呢？

//good
<div style={
   {
   width:10,height:10}} />

//bad
<div style={
   {
   width:'10px',height:'10px',display:'flex'}} />

虽然这样写并不会造成什么 bug 和风险，但是 过多的 style 属性会令人视觉疲劳。约束后，间接提高了我们的生产力。
试想一下，你现在正在 code review，面对一个文件里随处可见、动则数行、穿插了各种单双引号的style，一定会被打消积极性，或者想快速看完这个文件。（ “10px” 一定不如 10 来的简洁 ）。
我们完全可以把它放到 css 文件中， JSX 也完全 支持 px 值以 number 类型来书写。

着手开发🤙

创建项目并生成模板🔧

ESLint 官方为了方便开发者开发插件，提供了使用 Yeoman 模板 (generator-eslint) 。
Yeoman 是一个为 web 应用提供脚手架的工具，它提供了三种能力：

• yo——脚手架，自动生成工具
• Grunt、gulp——构建工具
• Bower、npm——包管理工具
  这里就用到了 Yeaman 脚手架插件市场中的 eslint 项目生成工具