feat: sync v8.32.0 (#95)

* docs: add options to check destructuring in no-underscore-dangle eslint/eslint#16006 * docs: check assignment patterns in no-underscore-dangle eslint/eslint#16693 * docs: use inline code for rule options name eslint/eslint#16768 * docs: ignore directives for no-fallthrough eslint/eslint#16757 * docs: IA Update page URL move eslint/eslint#16665 * update * feat: sync v8.31.0 (#94) * docs: User Guide Getting Started expansion * docs: add options to check destructuring in no-underscore-dangle eslint/eslint#16006 * docs: adjust some words * docs: Add function call example for no-undefined eslint/eslint#16712 * docs: check assignment patterns in no-underscore-dangle eslint/eslint#16693 * update formatters * Apply suggestions from code review Co-authored-by: Strek <ssharishkumar@gmail.com> --------- Co-authored-by: Strek <ssharishkumar@gmail.com> * docs: add options to check destructuring in no-underscore-dangle eslint/eslint#16006 * docs: IA Update page URL move eslint/eslint#16665 --------- Co-authored-by: Strek <ssharishkumar@gmail.com>
eslint · Feb 28, 2023 · db64486 · db64486
1 parent 00cb6f6
commit db64486
Show file tree

Hide file tree

Showing 73 changed files with 297 additions and 179 deletions.
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
@@ -12,7 +12,7 @@
 <!--
     Please ensure your pull request is ready:
 
-    - Read the pull request guide (https://eslint.org/docs/developer-guide/contributing/pull-requests)
+    - Read the pull request guide (https://eslint.org/docs/latest/contribute/pull-requests)
     - Update documentation for this change (if appropriate)
 -->
 

diff --git a/src/developer-guide/architecture/index.md → src/contribute/architecture/index.md b/src/developer-guide/architecture/index.md → src/contribute/architecture/index.md
diff --git a/src/developer-guide/code-conventions.md → src/contribute/code-conventions.md b/src/developer-guide/code-conventions.md → src/contribute/code-conventions.md
diff --git a/...eveloper-guide/development-environment.md → src/contribute/development-environment.md b/...eveloper-guide/development-environment.md → src/contribute/development-environment.md
@@ -71,7 +71,7 @@ npm test
 
 ### 工作流程
 
-在安装好开发环境后，你就可以对 ESLint 的源文件进行修改并提交。提交时需要认真遵守我们的 [pull-request 提交工作流程](contributing/pull-requests)。
+在安装好开发环境后，你就可以对 ESLint 的源文件进行修改并提交。提交时需要认真遵守我们的 [pull-request 提交工作流程](./pull-requests)。
 
 ### 构建脚本
 

diff --git a/src/maintainer-guide/governance.md → src/contribute/governance.md b/src/maintainer-guide/governance.md → src/contribute/governance.md
@@ -28,16 +28,16 @@ ESLint 是一个依赖于社区贡献者的开源项目。每个人都可以随
 
 ### 网站团队成员
 
-网站团队成员是社区成员，他们通过与社区的持续接触，表明他们致力于持续维护 [eslint.org](https://eslint.org/)。网站团队成员被赋予推送访问 GitHub `eslint.org` 仓库的权利，并且必须遵守项目的[贡献指南](../developer-guide/contributing/)。
+网站团队成员是社区成员，他们通过与社区的持续接触，表明他们致力于持续维护 [eslint.org](https://eslint.org/)。网站团队成员被赋予推送访问 GitHub `eslint.org` 仓库的权利，并且必须遵守项目的[贡献指南](../contribute/)。
 
  网站团队成员：
 
 * 在源码库的公开分支上工作，并从该分支向主分支提交拉取请求
 * 当不再需要时，应删除的公开分支
 * 必须为所有修改提交拉取请求。
 * 审查者和 TSC 成员会对他们的工作进行审查，然后才会接受到版本库中。
-* 可以标记和关闭与网站有关的议题（见[议题管理](issues)）。
-* 可以合并一些拉取请求（见[拉取请求管理](pullrequests)）。
+* 可以标记和关闭与网站有关的议题（见[议题管理](../maintain/manage-issues)）。
+* 可以合并一些拉取请求（见[拉取请求管理](../maintain/review-pull-requests)）。
 
 要成为网站团队成员：
 
@@ -51,16 +51,16 @@ ESLint 是一个依赖于社区贡献者的开源项目。每个人都可以随
 
 ### 提交者
 
-提交者是指那些通过持续参与社区活动，表明他们致力于项目的持续发展的社区成员。提交者被赋予推送访问项目的GitHub仓库的权限，并且必须遵守项目的[贡献指南](../developer-guide/contributing/)。
+提交者是指那些通过持续参与社区活动，表明他们致力于项目的持续发展的社区成员。提交者被赋予推送访问项目的GitHub仓库的权限，并且必须遵守项目的[贡献指南](../contribute/)。
 
 提交者：
 
 * 希望在源码库的公开分支上工作，并从该分支向主分支提交拉取请求。
 * 当他们不再需要时，应删除他们的公开分支
 * 必须为所有修改提交拉取请求
-* 在 TSC 成员审查他后，再合并仓库中
-* 可以标记和关闭议题（见[管理议题](issues)）
-* 可以合并一些拉取请求（见[管理拉取请求](pullrequests)）
+* 在 TSC 成员审查后，再合并仓库中
+* 可以标记和关闭议题（见[管理议题](../maintain/manage-issues)）
+* 可以合并一些拉取请求（见[管理拉取请求](../maintain/review-pull-requests)）
 
 要成为提交者：
 
@@ -102,7 +102,7 @@ ESLint 是一个依赖于社区贡献者的开源项目。每个人都可以随
 
 #### 新增审查者流程
 
-1. 将 GitHub用户 添加到 GitHub ESLint Reviewers 团队中。
+1. 将 GitHub 用户添加到 GitHub ESLint Reviewers 团队中。
 1. 用 ESLint Twitter 账户发推祝贺新的审查者
 
 ### 技术指导委员会（TSC）

diff --git a/src/developer-guide/contributing/index.md → src/contribute/index.md b/src/developer-guide/contributing/index.md → src/contribute/index.md
@@ -16,27 +16,27 @@ eleventyNavigation:
 
 ESLint 欢迎每个人的贡献，并遵守 [OpenJS 基金会的行为准则](https://eslint.org/conduct)。我们恳请您在投稿前仔细阅读我们的行为准则。
 
-## [错误报告](reporting-bugs)
+## [错误报告](report-bugs)
 
 你认为你发现了一个问题？我们很乐意听到这个问题。本节解释了如何提交一个 bug，我们需要什么样的信息来正确验证它，以及整个过程。
 
-## 提议[新规则](new-rules)
+## 提议[新规则](propose-new-rule)
 
 我们在 ESLint 中收到很多关于新规则的提议。本节解释了我们如何确定哪些规则被接受，以及你应该提供哪些信息来帮助我们评估你的建议。
 
-## 提议[规则修改](rule-changes)
+## 提议[规则修改](propose-rule-change)
 
 想对现有的规则进行修改？本节解释了这一过程以及我们如何评估此类提案。
 
-## 请求[修改](changes)
+## 请求[修改](request-change)
 
 如果你想请求一个除错误修复或新规则之外的变化，本节将解释这一过程。
 
 ## 报告安全漏洞
 
 要报告 ESLint 的安全漏洞，请使用我们的 [HackerOne 程序](https://hackerone.com/eslint)。
 
-## [专注议题](working-on-issues)
+## [专注议题](work-on-issue)
 
 有一些额外的时间并想做出贡献？本节讲述了在议题上工作的过程。
 

diff --git a/...veloper-guide/package-json-conventions.md → src/contribute/package-json-conventions.md b/...veloper-guide/package-json-conventions.md → src/contribute/package-json-conventions.md
@@ -1,6 +1,6 @@
 ---
 title: Package.json Conventions
-edit_link: https://github.com/eslint/eslint/edit/main/docs/src/developer-guide/package-json-conventions.md
+edit_link: https://github.com/eslint/eslint/edit/main/docs/src/contribute/package-json-conventions.md
 ---
 
 The following applies to the "scripts" section of `package.json` files.

diff --git a/...developer-guide/contributing/new-rules.md → src/contribute/propose-new-rule.md b/...developer-guide/contributing/new-rules.md → src/contribute/propose-new-rule.md
@@ -42,4 +42,4 @@ ESLint 团队不会实施用户建议的新规则，因为我们的人数有限
 
 ## 替代方案：创建你自己的规则
 
-请记住，ESLint 是完全可扩展，这意味着你可以创建你自己的规则并使用插件发布。我们这样做是有目的的，因为我们不想成为所有可能的规则的看门人。即使我们不接受一个规则进入核心，这也不意味着你不能拥有你想要的确切规则。更多信息请参见[创建规则](../working-with-rules)和[创建插件](../working-with-plugins)文档。
+请记住，ESLint 是完全可扩展，这意味着你可以创建你自己的规则并使用插件发布。我们这样做是有目的的，因为我们不想成为所有可能的规则的看门人。即使我们不接受一个规则进入核心，这也不意味着你不能拥有你想要的确切规则。更多信息请参见[创建规则](../extend/custom-rules)和[创建插件](../extend/plugins)文档。
diff --git a/...eloper-guide/contributing/rule-changes.md → src/contribute/propose-rule-change.md b/...eloper-guide/contributing/rule-changes.md → src/contribute/propose-rule-change.md
@@ -15,7 +15,7 @@ title: Rule Changes
 
 为了使规则变更被 ESLint 接受，它必须：
 
-1. 遵守 [核心规则指南](new-rules#core-rule-guidelines)
+1. 遵守[核心规则指南](propose-new-rule#核心规则指南)
 1. 有一名 ESLint 团队成员支持该更改。
 1. 足够重要，如果没有这个变化，规则被认为是不完整的。
 

diff --git a/...loper-guide/contributing/pull-requests.md → src/contribute/pull-requests.md b/...loper-guide/contributing/pull-requests.md → src/contribute/pull-requests.md
@@ -9,8 +9,8 @@ title: 拉取请求
 
 如果你想在拉动请求上工作，而你以前从未提交过代码，请遵循以下步骤：
 
-1. 建立[开发环境](../development-environment)。
-1. 如果你想实现破坏性改变或要对核心的改变，请确保要对当前所做事情进行描述，并且该问题已经被接受。你可以创建新议题，也可以表明你在[处理现有的议题](working-on-issues)。错误修复、文档修改和其他拉动请求则无需有对应议题。
+1. 建立[开发环境](./development-environment)。
+1. 如果你想实现破坏性改变或要对核心的改变，请确保要对当前所做事情进行描述，并且该问题已经被接受。你可以创建新议题，也可以表明你在[处理现有的议题](./work-on-issue)。错误修复、文档修改和其他拉动请求则无需有对应议题。
 
 在这之后，你就可以开始处理代码了。
 
@@ -42,7 +42,7 @@ git checkout -b issue1234
 
 ### 第二步：进行修改<a name="step2"></a>
 
-对代码和测试进行修改，在修改过程中遵循[代码约定](../code-conventions)。完成后，将修改提交到你的分支。
+对代码和测试进行修改，在修改过程中遵循[代码约定](./code-conventions)。完成后，将修改提交到你的分支。
 
 ```shell
 git add -A
@@ -75,7 +75,7 @@ Fixes #1234
 * `ci` - 对我们的 CI 配置文件和脚本的修改。
 * `perf` - 修改代码以提高性能。
 
-使用[你正在处理的问题的标签](working-on-issues#issue-labels)来确定最佳标签。
+使用[你正在处理的问题的标签](./work-on-issue#议题标签)来确定最佳标签。
 
 消息摘要应该是对修改的一句话描述，长度必须是 72 个字符或更短。如果拉动请求解决了一个问题，那么在提交信息的正文中应该提到问题编号，格式为 `Fixes #1234`。如果提交的内容没有完全解决该问题，那么就用 `Refs #1234` 代替 `Fixes #1234`。
 
@@ -119,7 +119,7 @@ npm test
 * 为不相关的改动提出单独的拉动请求。有多个不相关变化的大型拉动请求可能会被关闭而不被合并。
 * 所有的修改都必须有测试，即使你正在做的功能以前没有测试。
 * 所有面向用户的修改必须有适当的文档。
-* 遵循[代码约定](../code-conventions)。
+* 遵循[代码约定](./code-conventions)。
 
 ### 第六步：提交更改<a name="step6"></a>
 
@@ -179,7 +179,7 @@ git push origin issue1234
 
 ### 变基
 
-如果你的代码已经过期，我们可能会要求你重新发布。这意味着我们希望你在最新的上游代码基础上应用你的修改。请确保你已经配置好了[开发环境](../development-environment)，然后你就可以使用这些命令重新发布。
+如果你的代码已经过期，我们可能会要求你重新发布。这意味着我们希望你在最新的上游代码基础上应用你的修改。请确保你已经配置好了[开发环境](./development-environment)，然后你就可以使用这些命令重新发布。
 
 ```shell
 git fetch upstream

diff --git a/...oper-guide/contributing/reporting-bugs.md → src/contribute/report-bugs.md b/...oper-guide/contributing/reporting-bugs.md → src/contribute/report-bugs.md
diff --git a/src/developer-guide/contributing/changes.md → src/contribute/request-change.md b/src/developer-guide/contributing/changes.md → src/contribute/request-change.md
diff --git a/src/developer-guide/source-code.md → src/contribute/source-code.md b/src/developer-guide/source-code.md → src/contribute/source-code.md
diff --git a/src/developer-guide/unit-tests.md → src/contribute/tests.md b/src/developer-guide/unit-tests.md → src/contribute/tests.md
diff --git a/...r-guide/contributing/working-on-issues.md → src/contribute/work-on-issue.md b/...r-guide/contributing/working-on-issues.md → src/contribute/work-on-issue.md
@@ -7,10 +7,10 @@ title: 着手处理议题
 
 ## 议题标签
 
-我们给议题状态打上标签。[维护者指南](../../maintainer-guide/issues#当有新议题时)中有关于标签最完整的文档，但本页的信息对大多数贡献者足够了。作为贡献者，标签可以回答你最重要的问题有：
+我们给议题状态打上标签。[维护者指南](../maintain/manage-issues#当有新议题时)中有关于标签最完整的文档，但本页的信息对大多数贡献者足够了。作为贡献者，标签可以回答你最重要的问题有：
 
 1. 我可以就这个议题工作吗？如果你对向 ESLint 贡献没有或者经验不多，那么 [`good first issue`](https://github.com/eslint/eslint/labels/good%20first%20issue) 标签标记的议题就很适合你。否则，你可以选择来自 [`help wanted`](https://github.com/eslint/eslint/labels/help%20wanted) 标签的邀请。如果你有足够的经验，你可以尝试 [`accepted`](https://github.com/eslint/eslint/labels/accepted) 标签。此外，议题如果还没有准备好就会打上 `triage`、`evaluating` 或 `needs bikeshedding` 标签，而由于其他原因目前不能工作的问题，如依赖的错误，则被标记为 `blocked`。
-1. 这个问题是关于什么的？描述议题性质的标签包括 `bug`、`enhancement`、`feature`、`question`、`rule`、`documentation`、`core`、`build`、`cli`、`infrastructure`、`breaking` 和 `chore`。这些都在[维护者指南](../../maintainer-guide/issues#议题的类型)中有所记载。
+1. 这个问题是关于什么的？描述议题性质的标签包括 `bug`、`enhancement`、`feature`、`question`、`rule`、`documentation`、`core`、`build`、`cli`、`infrastructure`、`breaking` 和 `chore`。这些都在[维护者指南](../maintain/manage-issues#议题的类型)中有所记载。
 1. 先解决哪个议题？因为存在很多议题，因此对议题优先级进行了排序。以下是从高到低的优先级列表：
 
     1. **漏洞** - 项目的问题正在积极影响用户。我们希望尽可能快地解决这些问题。

diff --git a/src/developer-guide/code-path-analysis.md → src/extend/code-path-analysis.md b/src/developer-guide/code-path-analysis.md → src/extend/code-path-analysis.md
diff --git a/...r-guide/working-with-custom-formatters.md → src/extend/custom-formatters.md b/...r-guide/working-with-custom-formatters.md → src/extend/custom-formatters.md
@@ -129,9 +129,9 @@ eslint -f awesome src/
 
 formatter 函数的第二个实参应为对象。该对象有以下属性：
 
-* `cwd` ... 当前工作目录。这个值来自 [ESLint](nodejs-api#-new-eslintoptions) 类中的 `cwd` 构造器选项。
+* `cwd` ... 当前工作目录。这个值来自 [ESLint](../integrate/nodejs-api#-new-eslintoptions) 类中的 `cwd` 构造器选项。
 * `maxWarningsExceeded`（可选）：如果设置了 `--max-warnings` 且警告数量达到限制，则此对象将包括两个属性：值为 `--max-warnings` 选项的 `maxWarnings` 和值为检查出的警告数量的 `foundWarnings`。
-* `rulesMeta` ... 规则的 `meta` 属性值。关于规则的更多信息，请参见[使用规则](working-with-rules)页面。
+* `rulesMeta` ... 规则的 `meta` 属性值。关于规则的更多信息，请参见[使用规则](custom-rules)页面。
 
 例如，如果运行了 `no-extra-semi` 规则，对象会是这样的：
 
@@ -375,7 +375,7 @@ error semi
 
 ### 复杂的实参传递
 
-如果你发现自定义格式化模式没有为你想要格式化 ESLint 结果的方式提供足够的选项，最好的选择是使用 ESLint 内置的 [JSON 格式化工具](../user-guide/formatters/)，并将把输出传递到第二个程序。比如说：
+如果你发现自定义格式化模式没有为你想要格式化 ESLint 结果的方式提供足够的选项，最好的选择是使用 ESLint 内置的 [JSON 格式化工具](../use/formatters/)，并将把输出传递到第二个程序。比如说：
 
 ```bash
 eslint -f json src/ | your-program-that-reads-JSON --option

diff --git a/...oper-guide/working-with-custom-parsers.md → src/extend/custom-parsers.md b/...oper-guide/working-with-custom-parsers.md → src/extend/custom-parsers.md
diff --git a/...er-guide/working-with-rules-deprecated.md → src/extend/custom-rules-deprecated.md b/...er-guide/working-with-rules-deprecated.md → src/extend/custom-rules-deprecated.md
@@ -3,7 +3,7 @@ title: 创建规则（废弃）
 
 ---
 
-**注意**：本页面涵盖了 ESLint <= 2.13.1 中的已被废弃的规则格式。[这是最新的规则格式](./working-with-rules)。
+**注意**：本页面涵盖了 ESLint <= 2.13.1 中的已被废弃的规则格式。[这是最新的规则格式](./custom-rules)。
 
 ESLint 中的每个规则都有两个以其标识符命名的文件（如 `no-extra-semi`）。
 
@@ -37,7 +37,7 @@ module.exports.schema = []; // 无选项
 
 ## 规则基础
 
-`schema`（数组）指定[选项](#options-schemas)，这样 ESLint 可以防止无效的[规则配置](../user-guide/configuring/rules#configuring-rules)
+`schema`（数组）指定[选项](#选项模式)，这样 ESLint 可以防止无效的[规则配置](../use/configure/rules#规则配置)
 
 `create`（函数）返回对象，该对象包含 ESLint 调用的方法，在遍历 JavaScript 代码的抽象语法树 (AST，由 [ESTree](https://github.com/estree/estree) 定义）时 `"visit"` 节点。
 
@@ -47,7 +47,7 @@ module.exports.schema = []; // 无选项
 
 一个规则可以使用当前节点和它周围的树来报告或修复问题：
 
-下面是 [array-callback-return](./rules/array-callback-return) 规则的方法：
+下面是 [array-callback-return](../rules/array-callback-return) 规则的方法：
 
 ```js
 function checkLastSegment (node) {
@@ -77,7 +77,7 @@ module.exports = function(context) {
 
 `context` 对象包含额外的功能，有助于规则完成其工作。顾名思义，`context` 对象包含与规则的上下文相关的信息。`context` 对象有以下属性。
 
-* `parserOptions` - 为本次运行配置的解析器选项（[查看更多细节](../user-guide/configuring/language-options#specifying-parser-options)）。
+* `parserOptions` - 为本次运行配置的解析器选项（[查看更多细节](../use/configure/language-options#specifying-parser-options)）。
 * `id` - 规则 ID。
 * `options` - 规则选项的数组。
 * `settings` - 配置中的 `settings`。
@@ -481,7 +481,7 @@ valid: [
 ]
 ```
 
-`parserOptions` 的可用选项和预期语法与[配置](../user-guide/configuring/language-options#specifying-parser-options)中使用的相同。
+`parserOptions` 的可用选项和预期语法与[配置](../use/configure/language-options#specifying-parser-options)中使用的相同。
 
 ### 编写测试
 
@@ -576,5 +576,5 @@ ESLint 的规则命名约定是相当简单的。
 运行时规则的编写格式与所有其他规则相同。像其他规则一样创建你的规则，然后按照以下步骤进行。
 
 1. 把你所有的运行时规则放在同一个目录下（即`eslint_rules`）。
-2. 创建[配置文件](../user-guide/configuring/) 并在 `rules` 键下指定你的规则 ID 错误等级。你的规则将不会运行，除非它在配置文件中的值为 `1` 或 `2`。
-3. 运行[命令行界面](../user-guide/command-line-interface)，使用 `--rulesdir` 选项来指定你的运行规则的位置。
+2. 创建[配置文件](../use/configure/) 并在 `rules` 键下指定你的规则 ID 错误等级。你的规则将不会运行，除非它在配置文件中的值为 `1` 或 `2`。
+3. 运行[命令行界面](../use/command-line-interface)，使用 `--rulesdir` 选项来指定你的运行规则的位置。