0-1 配置eslint + prettier

前言：为什么需要项目规范

我们学习编程的方式不同，对知识的理解也不同。经过日复一日的编程，每个人都养成了自己的编码习惯和理解。

编码习惯和理解的差异导致团队中出现各种“标准”代码。当你看你的代码时，你可能会觉得你的代码看起来比较标准，只是有点乱。但当团队成员看你的代码时，他可能会想：卧槽，他写的代码为什么是这样的？这种风格的代码就像公司律师使用 Excel 规范自动格式化的沙拉食谱。看起来一点也不可靠。

图像

这种差异导致团队协作效率低下，也影响了项目的健壮性和可维护性。因此，我们需要规范编码风格。这种规范不仅可以保持统一的代码风格，而且可以在代码运行之前检测到一些错误和Bug，提高协同开发的效率。

前端开发者最常用的语言，最初是为了解决一些简单的网页交互而设计的。它是一种弱类型、基于原型的语言。

它具有其他语言所不具备的灵活性。这种灵活性带来了代码效率的提升，但也让代码编写变得非常随意。另外，隐式类型转换规则比较混乱，并且允许重复定义同名函数，增加了代码中存在隐患的可能性。

烂笑话：权威指南与语言本质的区别。

图像

如果能够在代码提交测试之前发现这些潜在的错误，可以大大减轻测试人员的压力，降低软件项目的调试成本。然而，作为一种解释型语言，解释器是嵌入在相应的客户端中的，对此无能为力。这个任务只能通过专用的代码检查工具来完成。

接下来我就讲一下上面的问题，首先介绍解决这些问题的工具，然后介绍使用这个工具解决团队规范和错误预检问题的步骤，最后使用一行命令来整合这些复杂的步骤最大限度地减少使用障碍。

和棉绒

Lint 是最著名的 C 语言工具之一。它是贝尔实验室于1979年基于PCC（）开发的静态代码分析，一般由UNIX系统提供。

lint 用于检查 C 程序中的潜在错误，包括（但不限于）可疑类型组合、未使用的变量、无法访问的代码和不可移植的代码。 lint 产生一系列诊断消息，程序员必须从头到尾阅读这些消息。使用 lint 的好处是：

它可以检测编译器遗漏的错误；

它可以关联多个文件进行错误检查和代码分析，具有很强的灵活性。

Lint应该算是lint世界的始祖。

一个叫C.Zakas的人在2013年推出了一个lint工具，也叫（简称ES），所以这个工具就这么叫了。

图像

是一个用于识别和报告 /code 中模式匹配的工具，目的是确保代码一致性并避免错误。

一些语法错误和潜在的bug可以在代码运行之前就被发现，大大减轻了测试人员的压力，降低了软件项目的调试成本。同时它允许开发者通过规则来定义自己的代码规范，因此非常适合制定团队代码规范。

图像

它是一个代码格式化工具，用于检测代码中的格式问题，例如单行代码长度、制表符长度、空格、逗号表达式等。在功能职责上，他们倾向于控制项目的代码质量，并且更倾向于统一项目的编码风格。

在引入--fix参数之前，没有自动格式化代码的功能。对于一些格式化问题的批量格式化，就只能使用这样的工具了。而且它在编码风格检测方面更加全面，因此两者通常一起使用。

通用标准和规范

在介绍规范之前，可以先使用 npm i \-g 命令进行全局安装安装。这两个全局包会在后续教程中用到。

推荐规格

默认情况下，不启用自定义规则验证，仅检测不正确的 ES5 语法和标准语法错误，例如 const、ES6 语法和莫名其妙的分号（如下所示）。

图像

当我们在项目目录下添加一个.js文件并写入以下内容后，就会启用推荐规范：

module.exports = {
  root: true,
  extends: 'eslint:recommended'
};
复制代码

在推荐的规范中，有一些内置的规则。例如，定义后未使用的变量会抛出错误，使用常量作为循环条件也会抛出错误（如下所示）。

图像

推荐的规格可以避免一些错误。例如上面的两个错误，可以在运行前检查并解决。请参阅更详细的规格。

它是基于从中衍生出的更严格的规范。该规范与标准之间大约有88处差异，主要是其中很多是关闭和错误的，例如在单行代码块两侧添加空格以及禁止在末尾使用分号。

下面的代码在规范下不会报错，但在规范内会报错。

规格

图像

规格

图像

首先使用 npm i -- -- \-D 命令安装插件，然后在 .js 文件中写入以下内容，规范就会启用：

module.exports = {
  root: true,
  extends: ['standard']
};
复制代码

它会比之前的版本更加严格，并且会对编码风格进行一些限制。不过它有一个比较大的用户群体，其中有一些是大家都熟悉的。 （如下图）

图像

请参阅详细规格。

该规范是最严格的规范。以下是比较明显的区别：

默认需要分号，默认不加

您不能使用 for 循环。建议使用数组自带的API来完成遍历工作。

当必须使用函数表达式（或传递匿名函数）时，请使用箭头函数表示法。

除此之外，还有更严格的规则，请查看规格。

在项目中配置+

由于存在一些相同的规则，当相同的规则设置不同时，就会出现一个很奇怪的现象：格式化后的代码无法通过验证。

下面，我们以前端代码规范为例，为一个项目配置一套完整的+规范。

配置..js

我们创建一个新的 .js 文件并写入以下内容作为我们的初始配置。 （如下）

module.exports = {
  root: true // 表示该文件为根配置文件
};
复制代码

在上一章的示例代码中，我们发现默认只能识别es5语法，所以我们首先配置env属性来支持es6语法，并将环境设置为（浏览器）或node（如下图）。

module.exports = {
  root: true,
  env: {
    browser: true,
    node: true,
    es6: true,
  },
  extends: 'eslint:recommended'
};
复制代码

如果您使用标准，则无需额外设置并且支持最新功能。对于实验性功能，您需要添加 babel-。

因此，这里我们直接配置和babel-，加上一些自定义规则，最终配置的规则如下：

module.exports = {
  root: true,
  parserOptions: {
    parser: 'babel-eslint', // 解析一些最新的 es 语法
    sourceType: 'module'  // 模块为 ECMAScript 模块
  },
  extends: ['standard'], // 使用 standard 标准
  rules: {
    'no-debugger': 'error', // 禁止在代码中使用 debugger
    quotes: ['error', 'single'], // 单引号
    semi: ['error', 'always'] // 代码需要以分号结尾
  }
};
复制代码

规范文件配置完成后，我们添加配置文件，新建一个..js文件，添加以下内容：

module.exports = {
  printWidth: 800, // 单行宽度限制
  tabWidth: 2, // tab 使用两个空格
  useTabs: false, // 不使用制表符缩进，使用空格缩进
  semi: true, // 代码需要分号结尾
  singleQuote: true, // 单引号
  bracketSpacing: true, // 对象左右两侧需要空格
  jsxBracketSameLine: false, // html 关闭标签换行
  arrowParens: 'avoid', // 单参数的箭头函数参数不需要括号
  proseWrap: 'never', // 参考 https://prettier.io/docs/en/options.html#prose-wrap
  trailingComma: 'none' // 参考 https://prettier.io/docs/en/options.html#trailing-commas
};
复制代码

配置完成后，我们新建一个文件，测试一下效果。在src目录下新建文件test.js，填写以下内容：

使用自动格式化的图像

从上面可以看出，该文件不符合我们设定的规范。下面我们将使用格式化和格式化函数来尝试纠正它。

首先我们在命令行输入\--fix src/test.js，然后看效果（如下图）

图像

我们可以看到多余的空格被删除了，双引号被替换为双引号，并且赋值运算符的左右两侧都添加了空格。

接下来，我们首先恢复文件，然后使用 \-w src/test.js 命令对其进行格式化。效果如下：

图像

从上图可以看出，由于我们设置的规则是一致的，所以格式化的文件也高度相似。

这样我们就完成了代码规范格式的统一。

插件

从上面的示例代码可以看出，编写不标准的代码会直接在编辑器中报错。这是因为上面的示例代码使用了，并且安装了一些插件来辅助开发。

下面，我们就来介绍一下这些插件。

我们首先安装插件（如下图）

图像

插件安装后，插件会读取目录下的配置文件，然后检查代码是否有错误并提示（如下图）。

图像

如果我们在 中设置以下属性，则保存文件时代码将自动格式化。 （如下图）

图像

接下来我们就可以安装插件了（如下图）。

图像

安装插件后，使用键盘组合键shift+/ctrl+p调出设置，然后输入With...，回车，从选项中选择（如下图）。

图像

设置完成后，使用组合键shift+/alt+f即可完成文件的格式化。

这两个插件的功能比较多，大家可以自行探索。

关于插件的一些事情

如果您熟悉该插件，可以跳过本章。

在插件安装过程中，不少童鞋反映了问题。以下是一些常见问题的解决方案。

插件不工作

全局安装 npm i -g

安装插件后，重启

如果还是不行，请升级

插件未启用

新版本需要手动激活插件。查看右下角工作状态，点击启用。 （如下图）

启用后图像不起作用

查看右下角的工作状态。点击输出日志。 （如下图）

图像

根据输出日志进行修复。比如上图中，就缺少对应的插件。只需安装它即可。

修复了未遵循的保存规则

这可能是因为你的保存自动格式化（代码格式化）打开了。首先打开 > ，搜索on save，然后关闭这个选项（如下图）

图像正常工作

正常工作及插入状态如下图所示。

image 在提交时自动检测并格式化代码

在项目开发过程中，自动格式化并不总是让人放心，因为并非所有项目组成员都会使用插件进行自动格式化。

这种情况会导致一些不标准的代码被提交到服务器，仍然会造成团队规范的不一致。这时候就需要用到提交时自动检测并格式化代码的功能。

接下来我们将使用husky来进行提交代码时的自动检测。

首先使用 npm i husky \-D 安装依赖项。依赖完成后，我们需要使用以下命令来初始化husky（如下图）

npx husky install && npx husky set .husky/pre-commit "npm run pre-commit"
复制代码

上面的命令是初始化git hook，前置命令会在git之前执行。

因此，我们还需要在项目的.json中添加pre-来检测该命令何时运行（如下所示）。

"scripts": {
  "pre-commit": "eslint src"
}
复制代码

接下来，我们运行 git add 。和 git \-m 'test' 命令并尝试提交代码。我们会发现提交失败，命令行输出如下所示。

图像

如上图所示，提交时检测到代码不符合规范，提交失败。

如果我们想在检测错误的同时自动修复语法错误，我们需要使用 lint-。先使用 npm i lint-\-D 安装，然后修改 .json 中的 pre-，然后添加以下内容。

"scripts": {
  "pre-commit": "lint-staged"
},
"lint-staged": {
  "src/**": [
    "eslint --fix"
  ]
}
复制代码

接下来，我们运行 git add 。再次输入 git \-m 'test' 命令并尝试提交代码。输出如下所示。

图像

从上图可以看出，运行lint-命令后，不符合规范的代码会通过\--fix自动正确格式化。

这样就完成了提交代码时对代码的自动检测和格式化。

使用脚手架自动化手动配置的配置问题

完成上述配置后，看似大功告成，可以立即走上标准化编码的快乐之路，但事实并非如此。

如果我们仔细梳理一下，我们会发现，当我们需要在新项目中配置代码规范时，需要执行以下繁琐的步骤。

安装。

根据项目类型安装相应的规则配置npm包。

根据项目类型安装相关插件、解析器等。

配置。 。基于项目类型的文件。

安装代码提交检查+自动格式化工具。哈士奇+绒毛-

配置.json。

测试并修复问题。

这些繁琐的步骤会消耗大量的时间，并且可能会出现一些错误，需要额外的时间来排除故障。这个过程对于个人来说可能是一个很好的学习机会，但对于团队来说确实是一种低效的协作方式。

因此，我们可以利用一些工具来帮助完成上述工作。该工具可以根据配置选择生成相应的标准配置，并安装相互兼容的依赖包。

使用脚手架进行自动配置

我们首先使用 npm i --cli \-g 命令全局安装脚手架工具，然后在对应目录下运行 jgxl 命令。

这里我们以vue+命令为例。所选配置如下图所示。

图像

初始化完成后，对应的配置文件内容如下：

..js

图像

..js

图像

.json

图像

从上面可以看出，我们的规范配置会根据选择的配置生成对应的规范配置文件，并且已经安装了相关版本的依赖。

作为团队成员，你不需要关心这些规范的细枝末节，你只需要进行核心业务的开发。

TIPS：自动更正功能只能更正一些代码风格规范，不会自动更正一些可能造成隐患的代码问题（例如：定义了但没有使用的变量）。

概括

在关于编码风格规范的争论中，每个人都有自己的理解，从来没有正确的答案。与其花时间争论细节，不如更多地关注核心业务。

无论你如何争论，你总会选择一种风格。对此，需要在个人语义和普世价值之间取得平衡。

因此，选择一个前端规范标准（例如 ）并坚持使用。留出时间来解决其他有意义的问题！ (^___^)/

参考：

关于本文