为什么以及如何在你的项目中使用 ESLint

2021-09-15 10:13:46 浏览数 (59)

Npmjs.org 有数十万个包，但它们的质量不尽相同。检查直接依赖项的管理情况很重要。如果功能是正确的，那么任何一个缺失的管理实践都不应该从您的考虑中排除一个包，但是当你可以选择包时，选择管理良好的包或者准备好自己维护包！

我用来评估项目的一种做法是 JavaScript linting。

为什么要对 JavaScript 进行 lint？

运行良好的项目具有清晰、一致的编码约定，并具有自动执行功能。当我审查一个项目时，它的代码看起来像一个孩子用斧头和房子的图片建造的房子，它并没有激发代码功能的信心。

没有编码约定也是吸引贡献的障碍。依赖于一个不欢迎贡献的项目本身就是一种风险。

除了检查样式之外，linter 也是查找某些类型错误（例如与变量范围相关的错误）的绝佳工具。分配给未声明的变量（这些会泄漏到全局范围，污染它并可能导致很难找到错误）和使用未定义的变量是在 lint 时可检测到的错误示例。

如何配置 ESLint

ESLint 是用于 linting Node.js 包的主要工具，可以配置为强制执行多种编码风格。可以定义自己的样式定义，但在这里我将展示如何使用 StrongLoop 样式。还有其他的，但是StrongLoop的风格平淡无奇（好东西，编码风格不应该引起注意），和很多开源Node.js项目中使用的类似。

  1. 安装并保存软件包依赖项：​npm install --save-dev eslint eslint-config-strongloop​.
  2. 通过运行设置 ESLint 以使用 StrongLoop 配置​echo '{"extends": "strongloop"}' > .eslintrc.json​。
  3. 确保你有一个.gitignore文件（因此派生文件不会被 linted，只有原始源文件）。如果你没有，你可以用最少的努力创建一个：​echo node_modules/ >> .gitignore​.请注意，也可以使用特定于 ESLint 的.eslintignore文件，该文件与 .gitignore 具有相同的语法，并且可能具有相同的内容。为了避免这种维护负担，大多数项目只使用 .gitignore。
  4. 使用此设置，通过将 package.json 更改为pretest脚本，将 ESLint 配置为在测试之前自动运行。它应该类似于： 
    5. { ... 
    "scripts": 
    { 
        "pretest": "eslint --ignore-path .gitignore ." 
    } ... 
}

    package.json 的确切内容取决于您的项目。你必须添加预测试脚本以使 ESLint 在你的单元测试之前运行。当你使用 npm 运行测试脚本时，它还会运行 pretest 和 posttest 脚本（如果存在）。我更喜欢这个，因为 eslint 通常比我的测试运行得快得多，而且 lint 错误很容易修复，但有些人更喜欢在 linter 之前运行整个测试套件，在这种情况下，使用 posttest。

  5. 提交 ESLint 自动化支持：
    6. git add package.json .gitignore .eslintrc.json 
git commit -m 'Add eslint automation
  6. 完成后，运行 
    7. linter： npm run pretest

如果你的控制台充斥着大量错误，请不要气馁！

如何让现有代码清理干净

人们避免使用 ESLint 的一个原因是清理从未被 lint 的代码感觉就像清理Augean 马厩。我建议像 Hercules 那样做：从工具中获取帮助。

  1. ESLint 可以自动修复许多语法问题。这应该是你用来清理源代码的第一个工具：​./node_modules/.bin/eslint --fix --ignore-path .gitignore .​
  2. 如果你有 ESLint 预测试脚本，你还可以执行以下操作：​npm run pretest -- --fix​
  3. 有一些类的问题，ESLint不会解决，然而，在这种情况下，你可以用做一次性清理prettier。prettier 最常用作 ESLint 和 auto-formats 源在提交之前的替代品。它在引导 ESLint 时也非常有用。像这样运行它： 
    4. npm i prettier ./node_modules/.bin/prettier --single-quote --trailing-comma es5 --print-width 80 --write --no-bracket-spacing **/*.js

    运行​eslint --fixand​ 后prettier，你应该只有很少的剩余警告需要手动清理。虽然 prettier 不像 ESLint 那样常用，但如果需要，它可以用作 ESLint 的补充（prettier 用于自动格式化，ESLint 用于格式强制和错误检查）。如果由于某种原因您现在没有时间修复这些问题，请禁用 ESLint 规则。自动强制执行某些样式子集比完全不强制要好得多。您可以为特定项目覆盖一些 StrongLoop 样式，然后有时间回来清理代码。

  4. 这是放宽​max-len​规则以允许最多 120 个字符宽的连续行的示例：
    5.  { 
    "extends": "strongloop", 
    "rules": 
        { 
            "max-len": [2, 120, 8] 
        } 
}

    你可能会发现你的代码使用了一致的风格，但不是 StrongLoop 的风格。如果接近，你可以自定义StrongLoop样式并发布为你自己的。如果你的风格完全不同，那么编写和发布你自己的可重用配置可能是有意义的。

  5. 一旦您的代码干净利落（使用​ npm run pretest​ 检查），提交结果： 
    6. git commit -a -m 'Project lints clean

自动lint

有两个级别的自动化：项目范围的策略和您自己的个人设置。

就项目范围的策略而言，因为 ESLint 被配置为与您的测试一起运行，所以没有什么可做的。除非你没有为你的项目自动运行测试，在这种情况下是时候开始了！

就我自己的个人设置而言，我更喜欢在我的每个提交上运行 ESLint，因此我引入的任何问题都在我的机器上被 CI 捕获之前捕获。我用一个​ git pre-commithook​来做这个。

要进行设置，请使用示例钩子作为基础：

​cp .git/hooks/pre-commit.sample .git/hooks/pre-commi​t

文件的最后几行将如下所示：

# If there are whitespace errors, print the offending file names and fail.
exec git diff-index --check --cached $against --

将其更改为如下所示：

set -e
npm run pretest

# If there are whitespace errors, print the offending file names and fail.
exec git diff-index --check --cached $against --

就是这样，你现在是 eslint 的另一个用户。


JavaScript

0 人点赞