eslint · snitin315 · Apr 26, 2025 · Apr 26, 2025 · Apr 26, 2025
@@ -6,7 +6,7 @@
 
 #### Prerequisites checklist
 
--   [ ] I have read the [contributing guidelines](https://github.com/eslint/eslint/blob/HEAD/CONTRIBUTING.md).
+- [ ] I have read the [contributing guidelines](https://github.com/eslint/eslint/blob/HEAD/CONTRIBUTING.md).
 
 #### What is the purpose of this pull request? (put an "X" next to an item)
 

@@ -10,10 +10,10 @@ This project adheres to the [OpenJS Foundation Code of Conduct](https://eslint.o
 
 Before filing an issue, please be sure to read the guidelines for what you're reporting:
 
--   [Report Bugs](https://eslint.org/docs/latest/contribute/report-bugs)
--   [Propose a New Rule](https://eslint.org/docs/latest/contribute/propose-new-rule)
--   [Propose a Rule Change](https://eslint.org/docs/latest/contribute/propose-rule-change)
--   [Request a Change](https://eslint.org/docs/latest/contribute/request-change)
+- [Report Bugs](https://eslint.org/docs/latest/contribute/report-bugs)
+- [Propose a New Rule](https://eslint.org/docs/latest/contribute/propose-new-rule)
+- [Propose a Rule Change](https://eslint.org/docs/latest/contribute/propose-rule-change)
+- [Request a Change](https://eslint.org/docs/latest/contribute/request-change)
 
 To report a security vulnerability in ESLint, please use our [create an advisory form](https://github.com/eslint/eslint/security/advisories/new) on GitHub.
 

@@ -20,9 +20,9 @@
 
 ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code. In many ways, it is similar to JSLint and JSHint with a few exceptions:
 
--   ESLint uses [Espree](https://github.com/eslint/js/tree/main/packages/espree) for JavaScript parsing.
--   ESLint uses an AST to evaluate patterns in code.
--   ESLint is completely pluggable, every single rule is a plugin and you can add more at runtime.
+- ESLint uses [Espree](https://github.com/eslint/js/tree/main/packages/espree) for JavaScript parsing.
+- ESLint uses an AST to evaluate patterns in code.
+- ESLint is completely pluggable, every single rule is a plugin and you can add more at runtime.
 
 ## Table of Contents
 
@@ -87,9 +87,9 @@ export default defineConfig([
 
 The names `"prefer-const"` and `"no-constant-binary-expression"` are the names of [rules](https://eslint.org/docs/rules) in ESLint. The first value is the error level of the rule and can be one of these values:
 
--   `"off"` or `0` - turn the rule off
--   `"warn"` or `1` - turn the rule on as a warning (doesn't affect exit code)
--   `"error"` or `2` - turn the rule on as an error (exit code will be 1)
+- `"off"` or `0` - turn the rule off
+- `"warn"` or `1` - turn the rule on as a warning (doesn't affect exit code)
+- `"error"` or `2` - turn the rule on as an error (exit code will be 1)
 
 The three error levels allow you fine-grained control over how ESLint applies rules (for more configuration options and details, see the [configuration docs](https://eslint.org/docs/latest/use/configure)).
 
@@ -109,10 +109,10 @@ ESLint adheres to the [OpenJS Foundation Code of Conduct](https://eslint.org/con
 
 Before filing an issue, please be sure to read the guidelines for what you're reporting:
 
--   [Bug Report](https://eslint.org/docs/latest/contribute/report-bugs)
--   [Propose a New Rule](https://eslint.org/docs/latest/contribute/propose-new-rule)
--   [Proposing a Rule Change](https://eslint.org/docs/latest/contribute/propose-rule-change)
--   [Request a Change](https://eslint.org/docs/latest/contribute/request-change)
+- [Bug Report](https://eslint.org/docs/latest/contribute/report-bugs)
+- [Propose a New Rule](https://eslint.org/docs/latest/contribute/propose-new-rule)
+- [Proposing a Rule Change](https://eslint.org/docs/latest/contribute/propose-rule-change)
+- [Request a Change](https://eslint.org/docs/latest/contribute/request-change)
 
 ## Frequently Asked Questions
 
@@ -174,32 +174,32 @@ ESLint takes security seriously. We work hard to ensure that ESLint is safe for
 
 ESLint follows [semantic versioning](https://semver.org). However, due to the nature of ESLint as a code quality tool, it's not always clear when a minor or major version bump occurs. To help clarify this for everyone, we've defined the following semantic versioning policy for ESLint:
 
--   Patch release (intended to not break your lint build)
-    -   A bug fix in a rule that results in ESLint reporting fewer linting errors.
-    -   A bug fix to the CLI or core (including formatters).
-    -   Improvements to documentation.
-    -   Non-user-facing changes such as refactoring code, adding, deleting, or modifying tests, and increasing test coverage.
-    -   Re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone).
--   Minor release (might break your lint build)
-    -   A bug fix in a rule that results in ESLint reporting more linting errors.
-    -   A new rule is created.
-    -   A new option to an existing rule that does not result in ESLint reporting more linting errors by default.
-    -   A new addition to an existing rule to support a newly-added language feature (within the last 12 months) that will result in ESLint reporting more linting errors by default.
-    -   An existing rule is deprecated.
-    -   A new CLI capability is created.
-    -   New capabilities to the public API are added (new classes, new methods, new arguments to existing methods, etc.).
-    -   A new formatter is created.
-    -   `eslint:recommended` is updated and will result in strictly fewer linting errors (e.g., rule removals).
--   Major release (likely to break your lint build)
-    -   `eslint:recommended` is updated and may result in new linting errors (e.g., rule additions, most rule option updates).
-    -   A new option to an existing rule that results in ESLint reporting more linting errors by default.
-    -   An existing formatter is removed.
-    -   Part of the public API is removed or changed in an incompatible way. The public API includes:
-        -   Rule schemas
-        -   Configuration schema
-        -   Command-line options
-        -   Node.js API
-        -   Rule, formatter, parser, plugin APIs
+- Patch release (intended to not break your lint build)
+    - A bug fix in a rule that results in ESLint reporting fewer linting errors.
+    - A bug fix to the CLI or core (including formatters).
+    - Improvements to documentation.
+    - Non-user-facing changes such as refactoring code, adding, deleting, or modifying tests, and increasing test coverage.
+    - Re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone).
+- Minor release (might break your lint build)
+    - A bug fix in a rule that results in ESLint reporting more linting errors.
+    - A new rule is created.
+    - A new option to an existing rule that does not result in ESLint reporting more linting errors by default.
+    - A new addition to an existing rule to support a newly-added language feature (within the last 12 months) that will result in ESLint reporting more linting errors by default.
+    - An existing rule is deprecated.
+    - A new CLI capability is created.
+    - New capabilities to the public API are added (new classes, new methods, new arguments to existing methods, etc.).
+    - A new formatter is created.
+    - `eslint:recommended` is updated and will result in strictly fewer linting errors (e.g., rule removals).
+- Major release (likely to break your lint build)
+    - `eslint:recommended` is updated and may result in new linting errors (e.g., rule additions, most rule option updates).
+    - A new option to an existing rule that results in ESLint reporting more linting errors by default.
+    - An existing formatter is removed.
+    - Part of the public API is removed or changed in an incompatible way. The public API includes:
+        - Rule schemas
+        - Configuration schema
+        - Command-line options
+        - Node.js API
+        - Rule, formatter, parser, plugin APIs
 
 According to our policy, any minor update may report more linting errors than the previous release (ex: from a bug fix). As such, we recommend using the tilde (`~`) in `package.json` e.g. `"eslint": "~3.1.0"` to guarantee the results of your builds.
 

@@ -17,24 +17,24 @@ ESLint is written using Node.js to provide a fast runtime environment and easy i
 
 Everything is pluggable:
 
--   Rule API is used both by bundled and custom rules.
--   Formatter API is used both by bundled and custom formatters.
--   Additional rules and formatters can be specified at runtime.
--   Rules and formatters don't have to be bundled to be used.
+- Rule API is used both by bundled and custom rules.
+- Formatter API is used both by bundled and custom formatters.
+- Additional rules and formatters can be specified at runtime.
+- Rules and formatters don't have to be bundled to be used.
 
 Every rule:
 
--   Is standalone.
--   Can be turned off or on (nothing can be deemed "too important to turn off").
--   Can be set to a warning or error individually.
+- Is standalone.
+- Can be turned off or on (nothing can be deemed "too important to turn off").
+- Can be set to a warning or error individually.
 
 Additionally:
 
--   Rules are "agenda free" - ESLint does not promote any particular coding style.
--   Any bundled rules are generalizable.
+- Rules are "agenda free" - ESLint does not promote any particular coding style.
+- Any bundled rules are generalizable.
 
 The project:
 
--   Values documentation and clear communication.
--   Is as transparent as possible.
--   Believes in the importance of testing.
+- Values documentation and clear communication.
+- Is as transparent as possible.
+- Believes in the importance of testing.
@@ -13,14 +13,14 @@ eleventyNavigation:
 
 At a high level, there are a few key parts to ESLint:
 
--   `bin/eslint.js` - this is the file that actually gets executed with the command line utility. It's a dumb wrapper that does nothing more than bootstrap ESLint, passing the command line arguments to `cli`. This is intentionally small so as not to require heavy testing.
--   `lib/api.js` - this is the entry point of `require("eslint")`. This file exposes an object that contains public classes `Linter`, `ESLint`, `RuleTester`, and `SourceCode`.
--   `lib/cli.js` - this is the heart of the ESLint CLI. It takes an array of arguments and then uses `eslint` to execute the commands. By keeping this as a separate utility, it allows others to effectively call ESLint from within another Node.js program as if it were done on the command line. The main call is `cli.execute()`. This is also the part that does all the file reading, directory traversing, input, and output.
--   `lib/cli-engine/` - this module is `CLIEngine` class that finds source code files and configuration files then does code verifying with the `Linter` class. This includes the loading logic of configuration files, parsers, plugins, and formatters.
--   `lib/linter/` - this module is the core `Linter` class that does code verifying based on configuration options. This file does no file I/O and does not interact with the `console` at all. For other Node.js programs that have JavaScript text to verify, they would be able to use this interface directly.
--   `lib/rule-tester/` - this module is `RuleTester` class that is a wrapper around Mocha so that rules can be unit tested. This class lets us write consistently formatted tests for each rule that is implemented and be confident that each of the rules work. The RuleTester interface was modeled after Mocha and works with Mocha's global testing methods. RuleTester can also be modified to work with other testing frameworks.
--   `lib/source-code/` - this module is `SourceCode` class that is used to represent the parsed source code. It takes in source code and the Program node of the AST representing the code.
--   `lib/rules/` - this contains built-in rules that verify source code.
+- `bin/eslint.js` - this is the file that actually gets executed with the command line utility. It's a dumb wrapper that does nothing more than bootstrap ESLint, passing the command line arguments to `cli`. This is intentionally small so as not to require heavy testing.
+- `lib/api.js` - this is the entry point of `require("eslint")`. This file exposes an object that contains public classes `Linter`, `ESLint`, `RuleTester`, and `SourceCode`.
+- `lib/cli.js` - this is the heart of the ESLint CLI. It takes an array of arguments and then uses `eslint` to execute the commands. By keeping this as a separate utility, it allows others to effectively call ESLint from within another Node.js program as if it were done on the command line. The main call is `cli.execute()`. This is also the part that does all the file reading, directory traversing, input, and output.
+- `lib/cli-engine/` - this module is `CLIEngine` class that finds source code files and configuration files then does code verifying with the `Linter` class. This includes the loading logic of configuration files, parsers, plugins, and formatters.
+- `lib/linter/` - this module is the core `Linter` class that does code verifying based on configuration options. This file does no file I/O and does not interact with the `console` at all. For other Node.js programs that have JavaScript text to verify, they would be able to use this interface directly.
+- `lib/rule-tester/` - this module is `RuleTester` class that is a wrapper around Mocha so that rules can be unit tested. This class lets us write consistently formatted tests for each rule that is implemented and be confident that each of the rules work. The RuleTester interface was modeled after Mocha and works with Mocha's global testing methods. RuleTester can also be modified to work with other testing frameworks.
+- `lib/source-code/` - this module is `SourceCode` class that is used to represent the parsed source code. It takes in source code and the Program node of the AST representing the code.
+- `lib/rules/` - this contains built-in rules that verify source code.
 
 ## The `cli` object
 
@@ -30,17 +30,17 @@ The main method is `cli.execute()`, which accepts an array of strings that repre
 
 This object's responsibilities include:
 
--   Interpreting command line arguments.
--   Reading from the file system.
--   Outputting to the console.
--   Outputting to the filesystem.
--   Use a formatter.
--   Returning the correct exit code.
+- Interpreting command line arguments.
+- Reading from the file system.
+- Outputting to the console.
+- Outputting to the filesystem.
+- Use a formatter.
+- Returning the correct exit code.
 
 This object may not:
 
--   Call `process.exit()` directly.
--   Perform any asynchronous operations.
+- Call `process.exit()` directly.
+- Perform any asynchronous operations.
 
 ## The `CLIEngine` object
 
@@ -50,16 +50,16 @@ The main method of the `CLIEngine` is `executeOnFiles()`, which accepts an array
 
 This object's responsibilities include:
 
--   Managing the execution environment for `Linter`.
--   Reading from the file system.
--   Reading configuration information from config files (including `.eslintrc` and `package.json`).
+- Managing the execution environment for `Linter`.
+- Reading from the file system.
+- Reading configuration information from config files (including `.eslintrc` and `package.json`).
 
 This object may not:
 
--   Call `process.exit()` directly.
--   Perform any asynchronous operations.
--   Output to the console.
--   Use formatters.
+- Call `process.exit()` directly.
+- Perform any asynchronous operations.
+- Output to the console.
+- Use formatters.
 
 ## The `Linter` object
 
@@ -69,32 +69,32 @@ Once the AST is available, `estraverse` is used to traverse the AST from top to
 
 This object's responsibilities include:
 
--   Inspecting JavaScript code strings.
--   Creating an AST for the code.
--   Executing rules on the AST.
--   Reporting back the results of the execution.
+- Inspecting JavaScript code strings.
+- Creating an AST for the code.
+- Executing rules on the AST.
+- Reporting back the results of the execution.
 
 This object may not:
 
--   Call `process.exit()` directly.
--   Perform any asynchronous operations.
--   Use Node.js-specific features.
--   Access the file system.
--   Call `console.log()` or any other similar method.
+- Call `process.exit()` directly.
+- Perform any asynchronous operations.
+- Use Node.js-specific features.
+- Access the file system.
+- Call `console.log()` or any other similar method.
 
 ## Rules
 
 Individual rules are the most specialized part of the ESLint architecture. Rules can do very little, they are simply a set of instructions executed against an AST that is provided. They do get some context information passed in, but the primary responsibility of a rule is to inspect the AST and report warnings.
 
 These objects' responsibilities are:
 
--   Inspect the AST for specific patterns.
--   Reporting warnings when certain patterns are found.
+- Inspect the AST for specific patterns.
+- Reporting warnings when certain patterns are found.
 
 These objects may not:
 
--   Call `process.exit()` directly.
--   Perform any asynchronous operations.
--   Use Node.js-specific features.
--   Access the file system.
--   Call `console.log()` or any other similar method.
+- Call `process.exit()` directly.
+- Perform any asynchronous operations.
+- Use Node.js-specific features.
+- Access the file system.
+- Call `console.log()` or any other similar method.
@@ -20,9 +20,9 @@ For full reference information on writing rules, refer to [Custom Rules](../exte
 
 Each core rule in ESLint has three files named with its identifier (for example, `no-extra-semi`).
 
--   in the `lib/rules` directory: a source file (for example, `no-extra-semi.js`).
--   in the `tests/lib/rules` directory: a test file (for example, `no-extra-semi.js`).
--   in the `docs/src/rules` directory: a Markdown documentation file (for example, `no-extra-semi.md`).
+- in the `lib/rules` directory: a source file (for example, `no-extra-semi.js`).
+- in the `tests/lib/rules` directory: a test file (for example, `no-extra-semi.js`).
+- in the `docs/src/rules` directory: a Markdown documentation file (for example, `no-extra-semi.md`).
 
 **Important:** If you submit a core rule to the ESLint repository, you **must** follow the conventions explained below.
 
@@ -105,18 +105,18 @@ Performance budget ok:  1443.736547ms (limit: 3409.090909090909ms)
 
 The rule naming conventions for ESLint are as follows:
 
--   Use dashes between words.
--   If your rule only disallows something, prefix it with `no-` such as `no-eval` for disallowing `eval()` and `no-debugger` for disallowing `debugger`.
--   If your rule is enforcing the inclusion of something, use a short name without a special prefix.
+- Use dashes between words.
+- If your rule only disallows something, prefix it with `no-` such as `no-eval` for disallowing `eval()` and `no-debugger` for disallowing `debugger`.
+- If your rule is enforcing the inclusion of something, use a short name without a special prefix.
 
 ## Frozen Rules
 
 When rules are feature complete, they are marked as frozen (indicated with ❄️ in the documentation). Rules are considered feature complete when the intended purpose of the rule has been fully implemented such that it catches 80% or more of expected violations and covers the majority of common exceptions. After that point, we expect users to use [disable comments](../use/configure/rules#using-configuration-comments-1) when they find an edge case that isn't covered.
 
 When a rule is frozen, it means:
 
--   **Bug fixes**: We will still fix confirmed bugs.
--   **New ECMAScript features**: We will ensure compatibility with new ECMAScript features, meaning the rule will not break on new syntax.
--   **New options**: We will **not** add any new options unless an option is the only way to fix a bug or support a newly-added ECMAScript feature.
+- **Bug fixes**: We will still fix confirmed bugs.
+- **New ECMAScript features**: We will ensure compatibility with new ECMAScript features, meaning the rule will not break on new syntax.
+- **New options**: We will **not** add any new options unless an option is the only way to fix a bug or support a newly-added ECMAScript feature.
 
 If you find that a frozen rule would work better for you with a change, we recommend copying the rule source code and modifying it to fit your needs.