直到最近，在前端的所有项目中，Dodo Pizza Engineering的开发人员都使用tslint –一个有用的工具，它可以告诉您何时
弄乱了代码，出现了不准确之处，有助于以相同的样式维护代码并纠正许多注释。 但后来茨林特死了。 在切口下方，我将告诉您它发生的原因，如何停止在死者身上流下眼泪，并切换到eslint工具，并展示一些非常亲密的内容。
实际上，这一切都是在很久以前开始的：tslint内核的最新版本已经在2016年。 现在是时候该开始说“最后”了，如果有人仍然说“最后一个”，因为该版本确实是最后一个。 2019年2月19日，发布了
正式职位以停止tslint的开发。 开发公司（顺便说一下，它甚至不是Microsoft）在其中强烈建议每个人都转而使用eslint，因为他们现在的努力将旨在改善对此Linter的TypeScript支持。
一种语言，一种堆栈，一种社区
Microsoft将TypeScript视为主要的Web开发语言，该语言应取代Java / ECMA Script。 显然，这样一个雄心勃勃的目标意味着整个前端开发只有一个工具栈。 这将大大简化大型JS社区到TypeScript的迁移。 除了保证Microsoft的信任之外，eslint还具有比tslint更好的体系结构。 例如，您可以连接解析器，并且有更多选择的连接规则。
如果只是想要，Microsoft不会自己。 无论我们怎么说他们的软件质量，他们都会提供出色的开发工具（顺便说一下，输入设备）。 因此，这次他们不是空手而归，而是写
了一份迁移计划 。 根据该计划，tslint规则的开发已于2019年8月1日终止，tslint本身的开发将于2019年11月1日停止。 虽然，老实说，开发很久以前就已经停止了（请参阅上面的最新版本）。
在这里，对于读者来说应该显而易见的是，该切换到eslint了，没有其他选择。 要使药丸变甜，值得一提：
- tslint专注于TypeScript，更侧重于类型和语法检查的正确使用，而eslint涵盖了可能出现在前面的所有内容，包括React组件的语法；
- eslint有很多预定义的规则；
- 有一些规则（和插件）在块级别检查代码（代码重复，感知的复杂性等）；
- 有些插件根本不检查代码，而是例如正则表达式。
总的来说，向作为主流产品的新棉短绒的过渡看起来将为我们打开一个前所未有的机遇世界。 好吧，让我们尝试！
将eslint添加到项目
我将在下面讨论规则的迁移。 同时，建立一个与eslint合作的项目。
如果您已经有一个使用tslint的项目，请首先从中删除与tslint相关的所有软件包：tslint本身，tslint-react，tslint-config-prettier等。
现在将eslint包添加到项目中（将所有内容设置为devDependencies）：
- 陪伴自己；
- @ typescript-eslint /解析器-解析TypeScript的引擎；
- @ typescript-eslint / eslint-plugin-TypeScript的规则集
Eslint最小设置
创建.eslintrc.json配置文件。 Eslint支持许多文件格式进行配置，但JSON似乎最方便。 最小工作选项如下所示：
{ // "env": { // "browser": true, // ES6 "es6": true, // ES2017 "es2017": true }, // "extends": [ // eslint "eslint:recommended", // "plugin:@typescript-eslint/eslint-recommended", // TypeScript "plugin:@typescript-eslint/recommended", // TS, "plugin:@typescript-eslint/recommended-requiring-type-checking" ], // "parser": "@typescript-eslint/parser", "parserOptions": { // TS "project": "tsconfig.json", "tsconfigRootDir": ".", }, // TypeScript "plugins": ["@typescript-eslint"], "rules": {} }
env部分告诉eslint您的项目选项。 在我的示例中，这是浏览器的项目（即代码将在浏览器中运行）。 为Node.JS编写-设置节点：true。 以下两个选项指示要测试的JS的方言。 通常，我们将检查TypeScript的代码，但是如果您的项目中也包含JS的代码，请不要忘记收紧它们。 对于我们自己，我们决定将这些参数设置为与tsconfig.json中的目标相同的值。
关于标准eslint规则集，没有争议，例如在表达式或空格/制表符末尾所需的分号。 所有规则都是唯一有用的。 您可以
在此处查看包括哪些规则和级别。
下一行需要
禁用一半规则。 这是必需的，因为它们不能与TypeScript一起使用，并且如果不能正常工作，它们会抛出很多错误。
然后，您应该将来自TypeScript的建议规则连接到一个单独的袋子中。 在这里，您需要记住，
常规语法规则 （例如禁止var）将像这样工作。
但是对于
使用TS类型的规则（例如@ typescript-eslint / no-不必要的类型断言），需要TypeScript引擎。 引擎将需要tsconfig.json文件，必须指定其路径。
在tsconfig.json中，Dodo Pizza Engineering的我们通常指定排除并抛出测试，以使它们不随项目一起构建。 但是要使eslint起作用，必须指定并包含。 也就是说，所有需要整理的文件必须明确包含在项目中。 没有这个，eslint会对发现的每个文件发誓：“该文件不在项目中，我什么也不会做，我会抛出很多错误。” 有一个选项没有明确指定项目文件-设置
createDefaultProgram: true参数。 从本质上讲，这意味着：“您找到的只是Parsi。” 但是开发人员强烈建议不要这样做，因为性能会大大下降。
如果使用ForkTsCheckerWebpackPlugin处理TypeScript文件，则将
tslint: true替换为
tslint: true （在webpack.config.ts中）。
还值得从命令行设置linter启动。 在此之前，将此值添加到
package.json的scripts部分：
"eslint": "eslint --cache --ext .js,.jsx,.ts,.tsx src", "eslint:dump": "eslint --print-config ./.eslintrc.json",
第一行只是在不构建项目的情况下启动eslint检查。 第二个显示当前的eslint设置，使您可以查看规则参数的设置。
在此版本中，eslint将已在项目中运行，甚至可能引起一些麻烦：重新定义全局变量，未使用的变量等。
设置Visual Studio代码
完成所有步骤后，您就可以从命令行启动lint。 在构建项目时，它也会隐式启动。 但是在Visual Studio Code中，我们将看不到棉绒的注释。 怎么这样？！
该工作室有一个eslint插件（dbaeumer.vscode-eslint），需要安装。 此后，无论如何都无济于事，也不会强调和纠正任何东西。 怎么了 因为该插件具有配置，所以您只需要在JavaScript文件中工作即可。
界面中未进行此隐秘设置，因此您需要进入Studio设置文件，然后将所需的语言手动添加到eslint.validate参数中。 完整的语言列表可以在Studio文档的正文中找到。 这是我们的设置：
"eslint.validate": [ "javascript", "javascriptreact", "typescriptreact", "typescript", ],
之后，重新启动Studio，一切都将终于开始工作。
现在仍然需要配置规则
项目成立。 现在介绍规则，因为在上面的示例中，规则列表为空。
我必须说tslint并没有阻止我们搞乱形式正确的代码。 例如，忘记等待。 Eslint知道如何找到这种语义错误并向他们发誓：报告返回值是Promise，但是由于某种原因，没有编写等待。 这也包括中等复杂性的风格问题：使用Lambda或函数等，这是Prettier不再能做的。
关于简单规则：方括号，制表符与 空格等，我们认为应该将它们提供给Prettier或类似的软件包。 但是无论如何，他们还是应该离开他们：这是最后一个领域，它仍然能够阻止堕落的项目组装商的疏忽开发商。 而且，该行可以自动执行：例如
husky ，您可以为每次提交自动启动linter。
我们决定
不迁移任何现有的tslint规则集。 并从头开始创建自己的集合。
eslint有预定义的规则集：
- ESLint推荐的是一套中立的规则，以不产生衍生物为目的。 仅包括明显必要的检查：未使用的变量等。 随后的所有集合都扩展了这一集合。
- Google-已经有选择的理由了：缩进中严格存在空格，需要使用分号。
- AirBnB-也有严格的样式规则，包括强制性的分号。
- 标准格式-此处禁止使用分号，但也禁止结尾逗号。
我们不喜欢任何现成的软件包。 这听起来可能很奇怪，但是对于我们来说，换用新的短绒棉很重要，避免出现风格上的战争。 如果我们到处都这样写（制表符，没有分号，则必须用逗号结尾），那么就让它保持不变-主要是在所有项目中都一样。
应许的性行为：自己的一套规则
坦白地说，向您展示eslint规则集就像一个显示胸部的女孩：没有其他秘密了。 我思考了很长时间是否值得这样做。 但是，在与女孩们协商之后，我认为这是值得的。
我将从我们使用的插件开始：
- react-检查反应组件代码。 基本规则集加上我们的规则。 重要的是：我们淹没了纯功能组件；
- react-hooks-React开发人员关于使用钩子的规则；
- promise-使用Promise时检查常见错误。 它与TypeScript代码有点奇怪。 重要的是：由于代码的可读性更好，我们尝试在各处使用Promise而不使用回调，然后使用/ catch；
- optimize-regex是一个有趣的插件，它提供了一些改进正则表达式的技巧。 不是很有用，因为regexp我们有一点。 但是，远非所有人都拥有正则表达式魔术。 因此它很有用，但是问得很少。
- sonarjs是一个强大的插件，可以检查代码的复杂性和典型的重构错误。 首先是一件有趣的事情：该插件评估代码的感知复杂度，并在值得简化代码的时候提供建议。 寻找重构错误通常还可以简化代码，或者至少可以提高可读性。
- @ typescript-eslint-用于检查TypeScript代码的eslint规则。 还有一个用于禁用与TS不兼容的基本规则的集合。
我们的整个规则文件在
这里 。 我注意到这不是教条，并且会随着项目的发展而更新。