其实我们看到EditorConfig包含的内容比较少，主要是配置我们的编辑器，编译代码时的简单规则不足以满足项目的更多需求；
更漂亮
Prettier是一款专注于底层代码的工具，诞生于2016年并迅速流行起来。 出道就是巅峰-.-
Prettier只关注low case，不具备通过lint检测句型的能力。 它通过解析代码并根据自己的规则集进行匹配来强制执行一致的代码表示格式。
它在美化代码方面有很大的优势，配合ESLint，可以很好的补充ESLint的底层基础。
那么如何使用呢？
单独使用，配合编辑器IDE进行低级代码格式化；
与ESLint等配合使用； 下文ESLint中会详细讨论，这里不再赘述；
1.单独使用，配合编辑器IDE进行低级代码格式化
以VSCode为例，首先安装Prettier插件。
VSCode 的外部代码低格式工具可以指定由 Prettier 接管，右下角会显示 Prettier。 您可以自行配置低级触发机制：换行时低级、保存文件时低级、或者通过快捷键触发；
我的使用习惯是使用快捷键自动触发低格。
当低级格式在编辑器中不生效时，可以查看.settings.json中对应文件格式指定的低级程序并进行调整：
这样，在VSCode编辑器中，触发文件低格式时，可以根据配置手动美化格式代码；
配置项：
常规配置可以在VSCode首选项-设置-扩展或者.settings.json中修改；
其实也可以在具体项目的根目录下单独配置.prettierrc；
例如以下配置：
{
// 设置强制单引号
"singleQuote": true,
// 为多行数组的非末尾行添加逗号 es5的对象，数组等
"trailingComma": "es5",
// 每行最大宽度 100
"printWidth": 100,
// 设置语句末尾不加分号
"semi": false,
// jsx中使用单引号
"jsxSingleQuote": true,
}
复制代码
最后低格式的有效策略也是就近原则，逐步匹配目标文件最近的父目录的配置文件，越接近优先级越高。
ESLint
ESLint 是一个插件测量工具，用于通过 JavaScript 代码中的常规模式匹配来识别和报告代码。 其目的是保证代码规范的一致性，及时发现代码问题，提前预防错误。
ESLint的重点是代码质量，检测代码风格并提示不符合风格规范的代码。 另外ESLint还具有部分代码低格式功能。
我们按照ESLint官网的说明来了解ESLint。
Lint 发展历史
ESLint 最初是由 Nicholas C. Zakas（JavaScript 中级编程作者）于 2013 年 6 月创建的开源项目。 它的目标是提供一个插件式的javascript代码检查工具。
JavaScript开发中出现的Lint工具：JSLint->JSHint->ESLint/TSLint；
关于 TSLint（已停止维护）
使用过 TypeScript 的童鞋应该对 TSLint 很熟悉，它是由 TypeScript 团队推出并维护的。
但从 2019 年 1 月开始，根据 TSLint 官方的说法，TSLint 正在逐渐被放弃，并将逐渐迁移到 ESLint 作为代码检测工具。
至于停止维护的原因：一是ESLint社区更加活跃、更加成熟，社区对ESLint的支持度越来越高，而TSLint还不够成熟； 其次，在不断迭代和支持新特性的过程中发现TSLint基于规则的操作存在架构性能问题，而ESLint具有更高效的架构。
但不得不感叹：虽然官方已经表示已经停止更新很久了，但是你会发现，仍然有很多使用 TSLint 作为代码检测工具的 TypeScript 项目并没有迁移。
如果您的项目还在使用 TSLint，为了项目的常年维护和更好的 ts 代码检测体验，请尽快迁移到 ESLint；
右图为JSHint、TSLint、ESLint、Prettier的Npm包下载对比：
那么ESLint的出现有何意义呢？
ESLint官网说明：代码检测是一种静态分析，常用于发现有问题的模式或代码，并且不依赖于特定的编码风格。 对于大多数编程语言来说，都会有代码检查，并且通常编译器会有外部检查工具。
JavaScript是一种动态弱类型语言，在开发中比较容易出错。 由于没有编译好的程序，为了发现JavaScript代码错误，一般需要在执行过程中不断调试。 像 ESLint 这样的工具允许程序员在编码时而不是在执行期间发现问题。
与Java等编程语言不同，JavaScript是一种弱类型动态语言。 由于缺少编译阶段，一些本来可以在编译过程中发现的错误只能在运行时才能发现，这就减少了我们的调试和早期发现隐藏问题的机会。 有些困难，而Lint工具相当于减少了js的编译过程，在代码部署和运行之前进行静态分析，发现错误和不标准的代码。
这样看来，TypeScript 在编译阶段就已经能够检测到很多问题了，那为什么还需要 Lint 工具代码检测呢？
由于 TypeScript 的重点是类型检测，而不是代码风格。
总结一下ESLint的作用和优点：
例如：api语句错误、使用未定义的变量、修改const变量
例如：使用制表符或空格、使用单冒号或双冒号等。
例如： eslint-config-standard 配置包可用于扩充社区中流行的最佳实践的样式手册。
这样可以大大提高项目中多人协作开发的效率，代码的可读性和可维护性。
ESLint 特性 1. 所有 ESLint 规则都设计为可插拔的
每个校准规则都是独立的，可以单独打开或关闭（任何人都不能认为“太重要而不能关闭”），并且结果可以设置为警告或错误。
编写规则时，每个规则都是一个单独的文件和相应的低级技能。
2. ESLint是完全可配置的
ESlint 被设计为完全可配置的。 不仅规则可插拔，还可以编译自定义规则、引入社区规则配置集、插件等，让ESLint更好地满足各个项目的具体需求；
通过eslint-plugin-react配置包扩展对React句型的支持；
通过@typescript-eslint/parser解析器支持typeScript句型和校准；
3. ESLint使用Node.js编译
在后端项目中方便安装并有快速的运行环境；
降低了开发者编写自定义规则的门槛；
四、ESLint解析时先将源码转换为AST
ESLint 使用 Esprima 将源代码解析为 AST 来分析代码中的模式，然后通过匹配规则定义和报告收集到的代码信息。
虽然增加一层转换的效率略有提高，但有用之处在于它可以支持使用任意规则来衡量 AST 是否符合预期，这使得 ESLint 具有高度的可扩展性。
支持的配置文件格式
ESLint 支持多种格式的配置文件：
如果同一目录下有多个配置文件，ESLint 只会使用一个。 优先级顺序如下：
.eslintrc.js
.eslintrc.yaml
.eslintrc.yml
.eslintrc.json
.eslintrc
包.json
当项目中有多个级联配置时，仍以就近原则为优先；
配置文件描述规则-启用的规则及其各自的错误级别
ESLint 附带了大量规则。 您可以使用注释或配置文件来更改项目中使用的规则。 要更改规则设置，您必须将规则 ID 设置为以下值之一：
Globals - 配置额外的全局变量
启用 ESLint 规则后，no-undef 规则将在访问当前源文件中未定义的变量时发出警告。
而且有时候，我们需要访问其他文件中的一些全局变量，并保证能够正常获取值。 这时，你可以在ESLint中定义这样一个全局变量，这样ESLint就不会发出警告了。
/* global var1, var2 */
复制代码
这定义了两个全局变量，var1 和 var2。 如果您想有选择地指定哪些全局变量可以写入（而不是只能读取），那么您可以使用“可写”标志来设置它们：
/* global var1:writable, var2:writable */
复制代码
// .eslintrc.js
"globals": {
"var1": "writable",
"var2": "readonly"
}
复制代码
Environments-指定脚本的运行环境
每个环境都有一组特定的预定义全局变量。 比如brower、node环境变量、es6环境变量等。
'env': {
'browser': true,
'commonjs': true,
'es6': true
},
复制代码
Plugins-第三方插件
ESLint支持使用第三方插件，首先下载并安装项目中要导入的插件，并在配置文件中使用plugins关键字存储插件名称列表。 插件名称可以省略 eslint-plugin- 前缀。
plugins: ['react', 'babel'], // eslint-plugin-react eslint-plugin-babel
复制代码
扩展继承
配置文件可以由基本配置中启用的规则继承。
extends: ["eslint:recommended","plugin:prettier/recommended"],
复制代码
配置代码注释方法
有时，我们需要在代码中忽略ESLint的单独规则检测。 这时，我们可以通过添加代码注释来解决：可以指定整个文件、某一行、某一块来启用/禁用单个或全部规则检测；
/* eslint-disable */ --禁用全部规则 放在文件顶部则整个文件范围都不检查
/* eslint-disable no-alert, no-console */ --禁用某些规则
// eslint-disable-line --当前行上禁用规则
// eslint-disable-next-line --下一行上禁用规则
复制代码
具体参考：eslint.bootcss.com/docs/user-g...；
使用 ESLint 安装 ESLint
ESLint可以安装在当前项目中，也可以安装在全局环境中，但是由于项目之间的差异，我们通常安装在当前项目中。 安装：
yarn add --save-dev eslint
复制代码
安装插件和解析器
如果项目中使用了TypeScript和React，则安装：
// 我们需要安装 @typescript-eslint/parser，替代掉默认的Espree解析器。
yarn add --save-dev typescript @typescript-eslint/parser
// 安装eslint-plugin-react配置包扩展支持React语法；安装@typescript-eslint/eslint-plugin提供额外的ts 语法的规则
yarn add --save-dev eslint-plugin-react @typescript-eslint/eslint-plugin
复制代码
请根据实际项目需要安装其他插件和解析器。
创建配置文件
我们在项目根目录下创建一个.eslintrc.js，内容如下：
module.exports = {
parser: '@typescript-eslint/parser',
plugins: ['react','@typescript-eslint'],
rules: {
// 禁止使用 var
'no-var': "error",
// 优先使用 interface 而不是 type
'@typescript-eslint/consistent-type-definitions': [
"error",
"interface"
]
}
}
复制代码
站在巨人的右臂上使用
后端社区有很多好的规则集。 我们要做的就是站在巨人的右臂，在现有规则集的基础上构建适合自己和团队的规则配置。
通过学习别人优秀的规则集，逐步建立自己或公司的规则配置；
本文介绍的ESLint只是涉及到的一些重要概念和基本用法。 ESLint规则和配置包含很多内容。 如果你想用好它们，花精力自己研究一下是值得的。
问答1. 如何方便地开始使用ESLint，并且尽量不改变原来的代码？
如果你是使用GIt进行项目代码管理，那么你可以使用husky+lint-staged+Prettier在Git提交时手动强制校准和低级格式化以及修补代码，并且只处理自己这次提交的文件。
在预提交阶段使用这些增量校准模式，尽可能避免对旧代码的影响； 这些方法可以逐步稳定地建立老项目；
2、Prettier和ESLint配置冲突如何解决？
Perttier规则在代码低级时使用，我们的代码校准使用ESLint。 如果同一条规则的配置不一致，往往会发生冲突；
例如：字符串中单双冒号的配置，eslintfix后，字符串改为单冒号，再次编辑文件后，保存（Prettier）并手动低格式后，改为双冒号，导致异常代码校准。
解决方案一：要么更改eslintrc，要么更改prettierrc配置，使其配置保持一致；
方案二：禁用ESLint中与Prettier配置冲突的规则； 然后使用 Prettier 替换 ESLint 的底层函数；
安装 eslint-config-prettier 插件配置集并在 eslintrc 规则末尾进行配置。 执行 ESLint 命令将禁用这些与 Prettier 配置冲突的规则。
安装eslint-plugin-prettier插件，首先使用Prettier对代码进行低级处理，然后标记不一致的地方；
当这两个包一起使用时，在运行 eslint--fix 时可以使用 Prettier 的配置规则来降级文件。
具体配置和使用请自行查看探索；
总结
ESLint、Prettier、EditorConfig的引入需要牺牲部分开发人员的编码自由度来保证团队成员代码风格的一致性，从而增强代码的可读性和可维护性。 让项目管理更加完善，成员之间的合作更加顺畅。
即使不考虑团队发展，个人也可以从中逐步完善良好的发展规范，这对自己的成功来说是长远的。
事实上，我们也应该清醒地认识到该工具的局限性：
1、定位明确：
ESLint等解决了团队开发规范问题，但无法解决其他诸如编码能力、代码合理性等问题，仍然是工程上比较薄弱的环节。
有时团队会制定非常严格的校准规则，并在每次提交代码时收集检测结果作为代码质量评估的重要指标。 我个人觉得这些方法还是可以量化部分代码质量评估问题的，但是循序渐进太重了。 但这也是廖胜武的做法。
过于严格的规则限制了代码的灵活性。 每条规则都应该是可讨论的，是否启用取决于团队；
如果某种语言或框架的书写方式被禁止，那么就应该从源头上消除； 它之所以存在，必然有一定的意义；
ESLint 不是神药，最好的代码实践往往在于大量的探索和不断的更新；
2.技术创新日新月异，以前感觉的原则可能不适用于现在。 我们要保持不断调整、后续优化的态度；
3、不要做一个代码规范严格的强迫症患者。 它不是目的idea typescript 校验，而是一种方法idea typescript 校验，可以让我们更方便地管理项目，将自己从复杂的团队项目中解放出来。
更倾向于的做法是：不要完全依赖工具的规则校准，让它们帮助我们养成良好的编码习惯，培养代码质量意识，引导我们写出更好的代码，而不是依赖它
❤️爱心三连击 1.看到这里了就点个在看支持下吧，你的「点赞，在看」是我创作的动力。
2.关注公众号
程序员成长指北，回复「1」加入Node进阶交流群！「在这里有好多 Node 开发者，会讨论 Node 知识，互相学习」！3.也可添加微信【ikoala520】，一起成长。
“向前看”是最大的支持
发表评论