每个团队、每个人都有自己的规范。

规范的可以让整个项目的编码风格更统一。

项目的规范涉及许多方面：

在没有工具检测的情况下，统一多人项目的编码风格是一件比较困难的事情，每次提交都需要详细的 review 每一行，因为这些规范点都非常细。

好在目前的前端生态有许多工具帮我们这个问题。

是否符合规范，就是要对进行检查。
对 JavaScript 的检查，目前使用最多最广的是 ESLint。

可组装的JavaScript和JSX检查工具

ESLint 的主要作用就是检查，许多不符合规范的还可以通过 ESLint 直接修复。

ESLint 可以直接使用 npm 安装。

首先在空目录创建项目，然后安装 ESLint。

npm init -y

npm i eslint -D

安装后 package.json 的 scripts 配置项。

{
  "scripts": {
    "lint": "eslint ./src/**/*.*"
  }
}

eslint 命令就可以执行 eslint，./src/**/*.* 表示检查 src 目录开始的所有。

接下来创建：

在项目根目录下创建 .eslintrc.js 的，.eslintrc 是 eslint 会去认找的名。

eslint 可以用多种格式的配置，如 JSON、YAML，通常会选则 .js ，因为可以方便书写一些环境相关的逻辑、写注释等。

// .eslintrc.js
module.exports = {
  'rules': { // 椒盐规则
    'indent': [ // 锁进为2个一锁 不然报错
      'error',
      ,
    ],
    'quotes': [ // 引号必须使用单引号 不然报错
      'error',
      'single',
    ],
    'semi': [ // 语句结束必须要分号 不然报错
      'error',
      'always',
    ],
  },
};

创建后可以在项目下创建 src 目录，并且写不符合规则的 .js 。

// ./src/index.js
var number = 

if (number < ) {
    console.log("咕咕？");
}

完成后，就可以执行 npm run lint 命令了。

可以看到其炸了三个 error 级别的，因为在配置的时候提供的级别就是 error。

第 Missing semicolon，就是表示没有分号。
第二个 Expected indentation of 2 spaces but found 4，表示应该需要2个锁进，但其实有4个。
第三个 Strings must use singlequote，表示字符串应使用单引号包裹。

eslint 通过提供的配置规则来检查，发现不符合规则的部分就会告诉你。

如果把他提供的都修好，检测就会正常通过。

// ./src/index.js
var number = ;

if (number < ) {
  console.log('咕咕？');
}

如果放心把修复的权利交给 eslint，可以使用 eslint ./src/**/*.* --fix 命令，来修复这些报错。

// package.json
{
  "scripts": {
    "fix": "eslint ./src/**/*.* --fix"
  }
}

fix 命令 npm run fix，就会根据配置修复报错。

eslint --init 命令会 eslint 并以交互问答方式来创建。

ESLint 的有许多，还有很多大厂使用的预设规范，ESLint 也采用了配置项的方式可以配置。

对团队规范的检查其实就是将团队内的规则映射到 ESLint 的规则上。

许多编辑器和 IDE 都有对 eslint 规则的分析，从而对进行静态检查，在推送前就可以处理掉很多问题，通常情况下的规范检查发生在 git commit 的时候，git 提供了对应阶段的钩子。

如果需要对样式进行检查，可以考虑使用 stylelint， 使用方式和 eslint 大同小异。