docs: Revert all changes after the license change (#17227)

docs/src/extend/code-path-analysis.md

@@ -259,8 +259,7 @@ Please use a map of information instead.
 ```js
 function hasCb(node, context) {
     if (node.type.indexOf("Function") !== -1) {
-        const sourceCode = context.sourceCode;
-        return sourceCode.getDeclaredVariables(node).some(function(v) {
+        return context.getDeclaredVariables(node).some(function(v) {
             return v.type === "Parameter" && v.name === "cb";
         });
     }

docs/src/extend/custom-processors.md

@@ -59,19 +59,19 @@ Reported problems have the following location information in each lint message:
 type LintMessage = {
 
   /// The 1-based line number where the message occurs.
-  line?: number;
+  line: number;
 
    /// The 1-based column number where the message occurs.
-  column?: number;
+  column: number;
 
   /// The 1-based line number of the end location.
-  endLine?: number;
+  endLine: number;
 
   /// The 1-based column number of the end location.
-  endColumn?: number;
+  endColumn: number;
 
   /// If `true`, this is a fatal error.
-  fatal?: boolean;
+  fatal: boolean;
 
   /// Information for an autofix.
   fix: Fix;

docs/src/extend/plugins.md

@@ -18,34 +18,6 @@ Each plugin is an npm module with a name in the format of `eslint-plugin-<plugin
 
 The easiest way to start creating a plugin is to use the [Yeoman generator](https://www.npmjs.com/package/generator-eslint). The generator will guide you through setting up the skeleton of a plugin.
 
-### Metadata in Plugins
-
-For easier debugging and more effective caching of plugins, it's recommended to provide a name and version in a `meta` object at the root of your plugin, like this:
-
-```js
-// preferred location of name and version
-module.exports = {
-    meta: {
-        name: "eslint-plugin-custom",
-        version: "1.2.3"
-    }
-};
-```
-
-The `meta.name` property should match the npm package name for your plugin and the `meta.version` property should match the npm package version for your plugin. The easiest way to accomplish this is by reading this information from your `package.json`.
-
-As an alternative, you can also expose `name` and `version` properties at the root of your plugin, such as:
-
-```js
-// alternate location of name and version
-module.exports = {
-    name: "eslint-plugin-custom",
-    version: "1.2.3"
-};
-```
-
-While the `meta` object is the preferred way to provide the plugin name and version, this format is also acceptable and is provided for backward compatibility.
-
 ### Rules in Plugins
 
 Plugins can expose custom rules for use in ESLint. To do so, the plugin must export a `rules` object containing a key-value mapping of rule ID to rule. The rule ID does not have to follow any naming convention (so it can just be `dollar-sign`, for instance). To learn more about creating custom rules in plugins, refer to [Custom Rules](custom-rules).
@@ -183,7 +155,7 @@ ESLint plugins should be linted too! It's suggested to lint your plugin with the
 
 * [eslint](https://www.npmjs.com/package/eslint)
 * [eslint-plugin-eslint-plugin](https://www.npmjs.com/package/eslint-plugin-eslint-plugin)
-* [eslint-plugin-n](https://www.npmjs.com/package/eslint-plugin-n)
+* [eslint-plugin-node](https://www.npmjs.com/package/eslint-plugin-node)
 
 ## Share Plugins
 

docs/src/integrate/nodejs-api.md

@@ -510,7 +510,7 @@ The `Linter` object does the actual evaluation of the JavaScript code. It doesn'
 
 The `Linter` is a constructor, and you can create a new instance by passing in the options you want to use. The available options are:
 
-* `cwd` - Path to a directory that should be considered as the current working directory. It is accessible to rules from `context.cwd` or by calling `context.getCwd()` (see [The Context Object](../extend/custom-rules#the-context-object)). If `cwd` is `undefined`, it will be normalized to `process.cwd()` if the global `process` object is defined (for example, in the Node.js runtime) , or `undefined` otherwise.
+* `cwd` - Path to a directory that should be considered as the current working directory. It is accessible to rules by calling `context.getCwd()` (see [The Context Object](../extend/custom-rules#the-context-object)). If `cwd` is `undefined`, it will be normalized to `process.cwd()` if the global `process` object is defined (for example, in the Node.js runtime) , or `undefined` otherwise.
 
 For example:
 
@@ -520,7 +520,7 @@ const linter1 = new Linter({ cwd: 'path/to/project' });
 const linter2 = new Linter();
 ```
 
-In this example, rules run on `linter1` will get `path/to/project` from `context.cwd` or when calling `context.getCwd()`.
+In this example, rules run on `linter1` will get `path/to/project` when calling `context.getCwd()`.
 Those run on `linter2` will get `process.cwd()` if the global `process` object is defined or `undefined` otherwise (e.g. on the browser <https://eslint.org/demo>).
 
 ### Linter#verify

docs/src/maintain/manage-issues.md

@@ -30,7 +30,7 @@ The first goal when evaluating an issue is to determine which category the issue
 
 ## Triaging Process
 
-All of ESLint's issues, across all GitHub repositories, are managed on our [Triage Project](https://github.com/orgs/eslint/projects/3). Please use the Triage project instead of the issues list when reviewing issues to determine what to work on. The Triage project has several columns:
+All of ESLint's issues, across all GitHub repositories, are managed on our [Triage Project](https://github.com/orgs/eslint/projects/2). Please use the Triage project instead of the issues list when reviewing issues to determine what to work on. The Triage project has several columns:
 
 * **Needs Triage**: Issues that have not yet been reviewed by anyone
 * **Triaging**: Issues that someone has reviewed but has not been able to fully triage yet
@@ -41,7 +41,7 @@ All of ESLint's issues, across all GitHub repositories, are managed on our [Tria
 * **RFC Opened**: An RFC is opened to address these issues
 * **Blocked**: The issue can't move forward due to some dependency
 * **Ready to Implement**: These issues have all the details necessary to start implementation
-* **Implementing**: There is an open pull request for each of these issues
+* **PR Opened**: There is an open pull request for each of these issues
 * **Completed**: The issue has been closed (either via pull request merge or by the team manually closing the issue)
 
 We make every attempt to automate movement between as many columns as we can, but sometimes moving issues needs to be done manually.
@@ -64,24 +64,14 @@ The steps for triaging an issue are:
         * If the issue is actually a question (rather than something the dev team needs to change), please [convert it to a discussion](https://docs.github.com/en/free-pro-team@latest/discussions/managing-discussions-for-your-community/moderating-discussions#converting-an-issue-to-a-discussion). You can continue the conversation as a discussion.
         * If the issue is reporting a bug, try to reproduce the issue following the instructions in the issue. If you can reproduce the bug, please add the "repro:yes" label. (The bot will automatically remove the "repro:needed" label.) If you can't reproduce the bug, ask the author for more information about their environment or to clarify reproduction steps.
         * If the issue is reporting something that works as intended, please add the "works as intended" label and close the issue.
-        * Please add labels describing the part of ESLint affected:
+        * For all issues, please add labels describing the part of ESLint affected:
             * **3rd party plugin**: Related to third-party functionality (plugins, parsers, rules, etc.)
             * **build**: Related to commands run during a build (testing, linting, release scripts, etc.)
             * **cli**: Related to command line input or output, or to `CLIEngine`
             * **core**: Related to internal APIs
             * **documentation**: Related to content on eslint.org
             * **infrastructure**: Related to resources needed for builds or deployment (VMs, CI tools, bots, etc.)
             * **rule**: Related to core rules
-        * Please assign an initial priority based on the importance of the issue. If you're not sure, use your best judgment. We can always change the priority later.
-            * **P1**: Urgent and important, we need to address this immediately.
-            * **P2**: Important but not urgent. Should be handled by a TSC member or reviewer.
-            * **P3**: Nice to have but not important. Can be handled by any team member.
-            * **P4**: A good idea that we'd like to have but may take a while for the team to get to it.
-            * **P5**: A good idea that the core team can't commit to. Will likely need to be done by an outside contributor.
-        * Please assign an initial impact assessement (make your best guess):
-            * **Low**: Doesn't affect many users.
-            * **Medium**: Affects most users or has a noticeable effect on user experience.
-            * **High**: Affects a lot of users, is a breaking change, or otherwise will be very noticeable to users.
         * If you can't properly triage the issue, move the issue back to the "Needs Triage" column in the Triage project so someone else can triage it.
         * If you have triaged the issue, move the issue to the "Ready for Dev Team" column in the Triage project.
 
@@ -130,8 +120,8 @@ Consensus is reached on issues when there are at least three team members who be
 
 If consensus cannot be reached on an issue, or an issue's progress has been stalled and it's not clear if the issue should be closed, then you can refer the issue to the TSC for resolution. To do so, add the "tsc agenda" label to the issue and add a comment including the following information:
 
-1. A one-paragraph summary of the discussion to this point. This should begin with "TSC Summary:".
-2. The question you would like the TSC to answer. This should begin with "TSC Question:".
+1. A one-paragraph summary of the discussion to this point.
+2. The question you would like the TSC to answer.
 
 The issue will be discussed at the next TSC meeting and the resolution will be posted back to the issue.
 

docs/src/rules/callback-return.md

@@ -9,7 +9,7 @@ further_reading:
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 The callback pattern is at the heart of most I/O and event-driven programming
  in JavaScript.

docs/src/rules/global-require.md

@@ -4,7 +4,7 @@ rule_type: suggestion
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 In Node.js, module dependencies are included using the `require()` function, such as:
 

docs/src/rules/handle-callback-err.md

@@ -7,7 +7,7 @@ further_reading:
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 In Node.js, a common pattern for dealing with asynchronous behavior is called the callback pattern.
 This pattern expects an `Error` object or `null` as the first argument of the callback.

docs/src/rules/id-match.md

@@ -91,10 +91,10 @@ This rule has an object option:
 
 * `"properties": false` (default) does not check object properties
 * `"properties": true` requires object literal properties and member expression assignment properties to match the specified regular expression
-* `"classFields": false` (default) does not check class field names
+* `"classFields": false` (default) does not class field names
 * `"classFields": true` requires class field names to match the specified regular expression
 * `"onlyDeclarations": false` (default) requires all variable names to match the specified regular expression
-* `"onlyDeclarations": true` requires only `var`, `const`, `let`, `function`, and `class` declarations to match the specified regular expression
+* `"onlyDeclarations": true` requires only `var`, `function`, and `class` declarations to match the specified regular expression
 * `"ignoreDestructuring": false` (default) enforces `id-match` for destructured identifiers
 * `"ignoreDestructuring": true` does not check destructured identifiers
 

docs/src/rules/no-buffer-constructor.md

@@ -8,7 +8,7 @@ further_reading:
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 In Node.js, the behavior of the `Buffer` constructor is different depending on the type of its argument. Passing an argument from user input to `Buffer()` without validating its type can lead to security vulnerabilities such as remote memory disclosure and denial of service. As a result, the `Buffer` constructor has been deprecated and should not be used. Use the producer methods `Buffer.from`, `Buffer.alloc`, and `Buffer.allocUnsafe` instead.
 

docs/src/rules/no-div-regex.md

@@ -8,15 +8,15 @@ related_rules:
 
 
 
-Characters `/=` at the beginning of a regular expression literal can be confused with a division assignment operator.
+Require regex literals to escape division operators.
 
 ```js
 function bar() { return /=foo/; }
 ```
 
 ## Rule Details
 
-This rule forbids equal signs (`=`) after the slash (`/`) at the beginning of a regular expression literal, because the characters `/=` can be confused with a division assignment operator.
+This is used to disambiguate the division operator to not confuse users.
 
 Examples of **incorrect** code for this rule:
 

docs/src/rules/no-mixed-requires.md

@@ -4,7 +4,7 @@ rule_type: suggestion
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 In the Node.js community it is often customary to separate initializations with calls to `require` modules from other variable declarations, sometimes also grouping them by the type of module. This rule helps you enforce this convention.
 

docs/src/rules/no-new-require.md

@@ -4,7 +4,7 @@ rule_type: suggestion
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 The `require` function is used to include modules that exist in separate files, such as:
 

docs/src/rules/no-new.md

@@ -43,7 +43,7 @@ Examples of **correct** code for this rule:
 
 var thing = new Thing();
 
-Foo();
+Thing();
 ```
 
 :::

docs/src/rules/no-path-concat.md

@@ -4,7 +4,7 @@ rule_type: suggestion
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 In Node.js, the `__dirname` and `__filename` global variables contain the directory path and the file path of the currently executing script file, respectively. Sometimes, developers try to use these variables to create paths to other files, such as:
 

docs/src/rules/no-process-env.md

@@ -7,7 +7,7 @@ further_reading:
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 The `process.env` object in Node.js is used to store deployment/configuration parameters. Littering it through out a project could lead to maintenance issues as it's another kind of global dependency. As such, it could lead to merge conflicts in a multi-user setup and deployment issues in a multi-server setup. Instead, one of the best practices is to define all those parameters in a single configuration/settings file which could be accessed throughout the project.
 

docs/src/rules/no-process-exit.md

@@ -4,7 +4,7 @@ rule_type: suggestion
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 The `process.exit()` method in Node.js is used to immediately stop the Node.js process and exit. This is a dangerous operation because it can occur in any method at any point in time, potentially stopping a Node.js application completely when an error occurs. For example:
 

docs/src/rules/no-restricted-modules.md

@@ -4,7 +4,7 @@ rule_type: suggestion
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 A module in Node.js is a simple or complex functionality organized in a JavaScript file which can be reused throughout the Node.js
 application. The keyword `require` is used in Node.js/CommonJS to import modules into an application. This way you can have dynamic loading where the loaded module name isn't predefined /static, or where you conditionally load a module only if it's "truly required".

docs/src/rules/no-sync.md

@@ -4,7 +4,7 @@ rule_type: suggestion
 ---
 
 
-This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-n`](https://github.com/eslint-community/eslint-plugin-n).
+This rule was **deprecated** in ESLint v7.0.0. Please use the corresponding rule in [`eslint-plugin-node`](https://github.com/mysticatea/eslint-plugin-node).
 
 In Node.js, most I/O is done through asynchronous methods. However, there are often synchronous versions of the asynchronous methods. For example, `fs.exists()` and `fs.existsSync()`. In some contexts, using synchronous operations is okay (if, as with ESLint, you are writing a command line utility). However, in other contexts the use of synchronous operations is considered a bad practice that should be avoided. For example, if you are running a high-travel web server on Node.js, you should consider carefully if you want to allow any synchronous operations that could lock up the server.