使用 NPM、ESLint 和 Prettier 标准化 TypeScript

无论在新项目还是旧项目中开始使用 TypeScript，为以后的代码设定标准都至关重要。因此，我通过 ESLint 和 Prettier 为 TypeScript 项目添加了 linting 和格式化支持。在本文中，我将向您展示如何实现这一点以及它的重要性。

等等，linting？我没有 TypeScript 可以做这个吗？

虽然 TypeScript 编译器会通过静态类型检查来强制执行代码的正确性，但它不会执行一些重要的事情。具体来说，它会检查你的代码是否能够编译。而 Linter 则会检查代码是否遵循 JavaScript 生态系统中的最佳实践。

把这两个想象成拼写检查器和语法检查器。下面的“句子”可以通过拼写检查器：

Frog cloud red molecule ambivalent forty two.

语法检查器会查看上述内容并认为我疯了（并且可能是正确的）。

类似地，TypeScript 编译器只是检查你的代码在语法上是否合理。而 Linter 会通过以下信息来增强它的有效性：

• 不要使用any关键字
• 不要声明标记（空）接口
• 使用驼峰命名法
• 使用一致的字符串格式
• 不要使用ts-ignore

本质上，linter 会质疑你代码中可能随着时间推移而添加的一些可疑内容，从而确保你的代码质量。在团队或项目中引入新开发人员时，这尤其有用。

Linter 本质上是固执己见的，但这些观点是可以改变的。通过使用配置文件（我们稍后会看到）并包含你选择的规则集，你可以精确控制 Linter 的挑剔程度。

ESLint 简介

ESLint 是一种非常流行的 JavaScript 和 TypeScript 代码检查器，它可以解析 JavaScript 和 TypeScript 代码，并根据违反的各种规则的严重程度输出警告和错误。

顺便提一下，如果 ESLint 遇到任何错误级别严重性规则违规，都会输出错误代码。例如，这可以作为构建管道的一部分，用于不接受包含规则违规的新提交。

过去，我曾推荐使用 TSLint 进行 TypeScript 代码检查，但在 2019 年初，Palantir 宣布弃用 TSLint，转而使用 ESLint。因此，我主张在现有项目中最终迁移到 TSLint，并在新项目中从一开始就使用 ESLint。

让我们将 ESLint 安装到当前不使用 linting 的现有 TypeScript 应用程序中，并查看该过程如何工作。

NPM 入门

我将从我之前迁移到 TypeScript 文章中的代码开始。这是一个简单的 TypeScript 应用程序，没有任何单页应用程序的复杂性。无需关注 Angular、React、Vue 甚至 JQuery，只需关注 TypeScript 及其生成的 JavaScript 代码。

此代码可在GitHub上获取，如果您想继续操作，我们将从migrationEnd 标签开始。

出于本文的目的，我将使用 Node 包管理器 (NPM) 来管理依赖项和构建步骤。本文假设您已在计算机上安装了它。如果没有，请继续安装 NPM 的最新 LTS 版本。

由于我的示例仓库中没有配置 NPM，我将npm init从命令行运行以创建一个新package.json文件。NPM init 会询问你一系列问题，所有问题都带有括号中列出的默认选项，你可以按 Enter 键接受这些选项。无论你选择什么，package.json都会创建一个文件。

我的看起来像这样：

请记住，只有当您想在线发布您的包时，这些才重要，而我们不会在本文中这样做。

请注意scripts本文档的 部分。此列表中的每个条目都可以通过 运行npm run [scriptname]。NPM 实际上拥有编写相当复杂的多步骤构建过程所需的所有工具。

让我们添加我们自己的脚本定义来支持将 TypeScript 转换为 JavaScript：

"scripts": {
    "transpile": "tsc",
    "build": "npm run transpile",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

这里我们新增了一个transpile可以通过 执行的步骤npm run transpile。这将依次执行tsc将 TypeScript 转换为 JavaScript 的操作。诚然，要达到同样的效果需要更多的按键操作，但这样做的好处是我们可以开始编写多部分构建。

我还定义了build步骤，我们将使用它在单个命令中运行多个步骤。在本例中，步骤build只是运行该transpile步骤，但我们将在下一节中看到它在 ESLint 中的扩展。

安装 ESLint

接下来，让我们设置 ESLint 和 linting 流程。我们将npm通过运行以下命令来安装 ESLint 的开发依赖项：

npm i -D typescript eslint eslint-config-typescript

这里i指的是安装命令，并-D指示 NPM 将依赖项保存package.json为仅开发依赖项。

这会将所需的依赖项下载到你的node_modules文件夹中，并根据拉取的依赖项版本将条目写入你的文件夹中package.json。就我而言，在撰写本文时，这些版本已被拉取：

"devDependencies": {
    "eslint": "^6.7.1",
    "eslint-config-typescript": "^3.0.0",
    "typescript": "^3.7.2"
  }

这实际上指示任何未来的npm i命令寻找这些依赖项或更新的内容（由^字符表示）。

为 TypeScript 配置 ESLint

现在 ESlint 已经安装完毕，让我们来配置它。要配置它，请运行eslint --init。

你应该会看到一个提示，询问你希望 ESLint 的行为方式。出于我们的目的，我们不希望它强制执行代码风格，因此请选择“检查语法并查找问题”。

接下来，ESLint 会询问你使用的 JavaScript 模块结构类型。为了简单起见，我在上一篇文章中没有使用模块，所以选择None of these。

之后，ESLint 会询问你是否使用单页应用程序框架。我的示例只是使用普通的 JavaScript 与 DOM 进行交互，所以我不会再选择这些了。

接下来，ESLint 会询问我们是否使用 TypeScript。天哪，我们用了！答案是肯定的。

接下来 ESLint 会询问我们的代码在什么环境中运行。在这种情况下，代码将在浏览器中运行，因此默认选择就可以了。

最后，ESLint 会询问我们如何存储设置。你可以选择任何你喜欢的选项，但就本文而言，我将使用JSON，因为对我来说，在使用 TypeScript 文件时，它是最自然的packages.json。

ESLint 可能会根据你的选择询问你是否要安装其他依赖项。请选择“是”。

这样，您的 ESLint 设置就配置好了，并存储在一个.eslintrc.json类似这样的文件中：

使用 ESLint 分析 TypeScript

太棒了！那么我们该如何使用它呢？

嗯，语法有点复杂，我不喜欢每次都输入它，但它看起来像eslint --ext .ts [pathtosource]。

这里我们说的是“仅在 TypeScript 文件上运行 ESLint，并查找指定的目录和子目录”。由于我的示例应用程序的 TypeScript 文件位于根目录中，因此我运行该命令eslint --ext .ts .来指定当前目录包含我的源代码。

在我的示例代码上运行此代码会产生一些违规行为：

太棒了！我们想找出潜在的可疑行为，所以我们知道 linting 确实发挥了作用。

让我们通过更新脚本来为下次节省一点时间package.json：

"lint": "eslint --ext .ts .",
"build": "npm run lint && npm run transpile",

这里我们定义了一个仅用于 linting 的新步骤，并通过操作符扩展我们的build步骤&&，让它调用 lint 步骤，等待结果，然后仅当 lint 步骤执行没有错误时才调用 transpile 步骤。

现在我们可以运行npm run buildlint 并将 TypeScript 转换为 JavaScript。

修复 ESLint 问题

但是我们的错误怎么办？我们肯定需要改正。

在这种情况下，我的错误是误报。也就是说，我依赖 HTML 中的点击处理程序来调用 JavaScript 中定义的函数，而我的 linter 并不知道我在做什么。

但是，当您考虑这一点时，JavaScript 函数和 HTML 文件之间的关系对于项目中从事其他工作的新开发人员来说并不明显，他们可能会轻易删除、重命名或移动函数，而不了解这种选择的全部影响。

为了防止这种情况 - 并解决我的 ESLint 警告 - 我将向您展示一个修复此问题的示例。

在我的 HTML 文件中，我删除了相关的onclick="addTestCase()"行，而是修改了后台代码以通过按钮的 ID 来获取按钮，然后onclick在代码中设置处理程序：

注意：如果上面代码片段中的缩进、引号和/或括号给您带来脑部创伤，我深表歉意，这是为了证明一个观点，稍后会得到解决。

这解决了我们的一个错误。我们可以按照同样的模式解决其他问题，或者我可以借此机会向大家展示如何忽略误报。

假设我不同意这条no-unused-vars规则。这条规则本身就很好，所以我不应该反对，但我可能想把它的严重程度降低到警告，或者完全禁用它。

我通过进入文件并通过将其标识符添加到文件中的集合中eslintrc.json来声明我对该规则的憎恨，如下所示：rules

"rules": {
    "no-unused-vars": "warn"
}

如果我不想出现错误或警告，可以将其设置为off。请不要这样做。这是一条好规则，应该将其设置为错误或警告，但这说明了如何禁用您不同意的规则。

既然我同意这条规则，我实际上并不想禁用它或让它变成非错误，所以我打算在代码中逐行禁用它。这对于单例误报的情况更有意义。

我通过以下语法来实现disable-next-line：

// eslint-disable-next-line no-unused-vars
function deleteTestCase(id: number) {
  // my logic here
}

无论您想以何种方式处理它，这都为我们提供了所需的工具，以将 ESLint 中的错误数降至 0，并传递npm run build命令。

使用 Prettier 进行风格化编码

所以，linter 能抓到代码问题，但它显然不在乎我选择了什么样的奇葩缩进样式。这在代码规范至关重要的生产应用中是个问题。

值得庆幸的是，一款名为 Prettier 的工具不仅能检测样式问题，还能自动修复。这套标准的格式规则让代码审查不再需要争论，让你专注于真正重要的事情——实际的代码。

当然，这些风格可能并不完全符合您自己的风格，但您很快就会学会阅读代码风格，甚至用它来思考。

安装和配置 Prettier

虽然 Prettier 可以作为独立工具运行，但直接集成到 ESLint 中会更加顺畅。这样，Prettier 会在每次 linting 时执行。

我们将首先通过以下命令安装 Prettier ESLint 插件的开发依赖项：

npm i -D prettier eslint-plugin-prettier eslint-config-prettier

一旦完成，我们需要修改我们的eslintrc.json文件，以便它了解 Prettier。

在该extends部分中，添加以下两个条目：

"prettier/@typescript-eslint",
"plugin:prettier/recommended"

现在，当我通过 运行我的lint或build任务时npm，我会遇到大量有关缩进、引号等方面的失败。现在强制执行一种样式并拒绝不符合该样式的文件。

嗯，这很烦人，而且在实际使用中也没什么用。如果 Prettier 能自动正确格式化我的文件就更好了。谢天谢地，它确实可以。

我们所要做的就是修改lint脚本以package.json添加--fix命令行参数，如下所示：

"lint": "eslint --fix --ext .ts ."

一旦我们重新运行该程序，我们的源文件就会自动修改为正确的格式。

这是可能的，因为一些 ESLint 规则定义了自动修复，如果您指定--fix标志，ESLint 可以自动应用这些修复。

这不仅限于格式 - 一些简单的 JavaScript 和 TypeScript 规则提供自动修复，这意味着检查代码中是否存在严重问题可以自动修复小问题，同时在整个代码库中强制执行一致的样式。

建议

尝试一下 NPM、ESLint 和 Prettier，看看您是否喜欢使用它们。

如果您对 ESLint 的规则或配置感到好奇，请查看TypeScript 推荐的规则集，了解有关各个规则、其默认设置以及如何自定义其行为的详细信息。

我发现，TypeScript 与 NPM、ESLint 和 Prettier 结合提供了适当程度的标准执行和一致性，可帮助团队扩展 JavaScript 开发，这才是真正想要使用 TypeScript 的意义所在。

使用 NPM、ESLint 和 Prettier 标准化 TypeScript一文最先出现在Kill All Defects上。