diff --git a/docs/src/developer-guide/code-conventions.md b/docs/src/developer-guide/code-conventions.md index e5f5a448281..089e1247abf 100644 --- a/docs/src/developer-guide/code-conventions.md +++ b/docs/src/developer-guide/code-conventions.md @@ -7,7 +7,7 @@ Code conventions for ESLint are determined by The rationales for the specific rules in use can be found by looking to the project documentation for any given rule. If the rule is one of our own, see -our own [rule documentation](https://eslint.org/docs/rules/) and otherwise, see +our own [rule documentation](../rules/) and otherwise, see the documentation of the plugin in which the rule can be found. If you need to make changes to a `package.json` file, please see the diff --git a/docs/src/developer-guide/contributing/new-rules.md b/docs/src/developer-guide/contributing/new-rules.md index 0b4cd1bb95a..28514e85c75 100644 --- a/docs/src/developer-guide/contributing/new-rules.md +++ b/docs/src/developer-guide/contributing/new-rules.md @@ -22,7 +22,7 @@ Even though these are the formal criteria for inclusion, each rule is evaluated ## Proposing a Rule -If you want to propose a new rule, please see how to [create a pull request](/docs/developer-guide/contributing/pull-requests) or submit an issue by filling out a [new rule template](https://github.com/eslint/eslint/issues/new/choose). +If you want to propose a new rule, please see how to [create a pull request](pull-requests) or submit an issue by filling out a [new rule template](https://github.com/eslint/eslint/issues/new/choose). We need all of this information in order to determine whether or not the rule is a good core rule candidate. diff --git a/docs/src/developer-guide/contributing/reporting-bugs.md b/docs/src/developer-guide/contributing/reporting-bugs.md index f0ec2fe54e4..09a60ccd83a 100644 --- a/docs/src/developer-guide/contributing/reporting-bugs.md +++ b/docs/src/developer-guide/contributing/reporting-bugs.md @@ -3,7 +3,7 @@ title: Reporting Bugs --- -If you think you've found a bug in ESLint, please [create a new issue](https://github.com/eslint/eslint/issues/new/choose) or a [pull request](/docs/developer-guide/contributing/pull-requests) on GitHub. +If you think you've found a bug in ESLint, please [create a new issue](https://github.com/eslint/eslint/issues/new/choose) or a [pull request](pull-requests) on GitHub. Please include as much detail as possible to help us properly address your issue. If we need to triage issues and constantly ask people for more detail, that's time taken away from actually fixing issues. Help us be as efficient as possible by including a lot of detail in your issues. diff --git a/docs/src/developer-guide/contributing/rule-changes.md b/docs/src/developer-guide/contributing/rule-changes.md index 7a880e0caca..14de4495df3 100644 --- a/docs/src/developer-guide/contributing/rule-changes.md +++ b/docs/src/developer-guide/contributing/rule-changes.md @@ -7,7 +7,7 @@ Occasionally, a core ESLint rule needs to be changed. This is not necessarily a ## Proposing a Rule Change -To propose a change to an existing rule, [create a pull request](/docs/developer-guide/contributing/pull-requests) or [new issue](https://github.com/eslint/eslint/issues/new/choose) and fill out the template. +To propose a change to an existing rule, [create a pull request](pull-requests) or [new issue](https://github.com/eslint/eslint/issues/new/choose) and fill out the template. We need all of this information in order to determine whether or not the change is a good candidate for inclusion. diff --git a/docs/src/developer-guide/contributing/working-on-issues.md b/docs/src/developer-guide/contributing/working-on-issues.md index fabb9b1881d..5c929844843 100644 --- a/docs/src/developer-guide/contributing/working-on-issues.md +++ b/docs/src/developer-guide/contributing/working-on-issues.md @@ -7,10 +7,10 @@ Our public [issues tracker](https://github.com/eslint/eslint/issues) lists all o ## Issue Labels -We use labels to indicate the status of issues. The most complete documentation on the labels is found in the [Maintainer Guide](https://eslint.org/docs/maintainer-guide/issues.html#when-an-issue-is-opened), but most contributors should find the information on this page sufficient. The most important questions that labels can help you, as a contributor, answer are: +We use labels to indicate the status of issues. The most complete documentation on the labels is found in the [Maintainer Guide](../../maintainer-guide/issues#when-an-issue-is-opened), but most contributors should find the information on this page sufficient. The most important questions that labels can help you, as a contributor, answer are: 1. Is this issue available for me to work on? If you have little or no experience contributing to ESLint, the [`good first issue`](https://github.com/eslint/eslint/labels/good%20first%20issue) label marks appropriate issues. Otherwise, the [`help wanted`](https://github.com/eslint/eslint/labels/help%20wanted) label is an invitation to work on the issue. If you have more experience, you can try working on other issues labeled [`accepted`](https://github.com/eslint/eslint/labels/accepted). Conversely, issues not yet ready to work on are labeled `triage`, `evaluating`, and/or `needs bikeshedding`, and issues that cannot currently be worked on because of something else, such as a bug in a dependency, are labeled `blocked`. -1. What is this issue about? Labels describing the nature of issues include `bug`, `enhancement`, `feature`, `question`, `rule`, `documentation`, `core`, `build`, `cli`, `infrastructure`, `breaking`, and `chore`. These are documented in the [Maintainer Guide](https://eslint.org/docs/maintainer-guide/issues.html#types-of-issues). +1. What is this issue about? Labels describing the nature of issues include `bug`, `enhancement`, `feature`, `question`, `rule`, `documentation`, `core`, `build`, `cli`, `infrastructure`, `breaking`, and `chore`. These are documented in the [Maintainer Guide](../../maintainer-guide/issues#types-of-issues). 1. What is the priority of this issue? Because we have a lot of issues, we prioritize certain issues above others. The following is the list of priorities, from highest to lowest: 1. **Bugs** - problems with the project are actively affecting users. We want to get these resolved as quickly as possible. diff --git a/docs/src/developer-guide/nodejs-api.md b/docs/src/developer-guide/nodejs-api.md index 30b75ccecd9..833a678d722 100644 --- a/docs/src/developer-guide/nodejs-api.md +++ b/docs/src/developer-guide/nodejs-api.md @@ -489,8 +489,8 @@ The most important method on `Linter` is `verify()`, which initiates linting of * **Note**: If you want to lint text and have your configuration be read and processed, use [`ESLint#lintFiles()`][eslint-lintfiles] or [`ESLint#lintText()`][eslint-linttext] instead. * `options` - (optional) Additional options for this run. * `filename` - (optional) the filename to associate with the source code. - * `preprocess` - (optional) A function that [Processors in Plugins](/docs/developer-guide/working-with-plugins#processors-in-plugins) documentation describes as the `preprocess` method. - * `postprocess` - (optional) A function that [Processors in Plugins](/docs/developer-guide/working-with-plugins#processors-in-plugins) documentation describes as the `postprocess` method. + * `preprocess` - (optional) A function that [Processors in Plugins](working-with-plugins#processors-in-plugins) documentation describes as the `preprocess` method. + * `postprocess` - (optional) A function that [Processors in Plugins](working-with-plugins#processors-in-plugins) documentation describes as the `postprocess` method. * `filterCodeBlock` - (optional) A function that decides which code blocks the linter should adopt. The function receives two arguments. The first argument is the virtual filename of a code block. The second argument is the text of the code block. If the function returned `true` then the linter adopts the code block. If the function was omitted, the linter adopts only `*.js` code blocks. If you provided a `filterCodeBlock` function, it overrides this default behavior, so the linter doesn't adopt `*.js` code blocks automatically. * `disableFixes` - (optional) when set to `true`, the linter doesn't make either the `fix` or `suggestions` property of the lint result. * `allowInlineConfig` - (optional) set to `false` to disable inline comments from changing ESLint rules. @@ -686,7 +686,7 @@ Map { ### Linter#defineParser Each instance of `Linter` holds a map of custom parsers. If you want to define a parser programmatically, you can add this function -with the name of the parser as first argument and the [parser object](/docs/developer-guide/working-with-custom-parsers) as second argument. The default `"espree"` parser will already be loaded for every `Linter` instance. +with the name of the parser as first argument and the [parser object](working-with-custom-parsers) as second argument. The default `"espree"` parser will already be loaded for every `Linter` instance. ```js const Linter = require("eslint").Linter; @@ -918,7 +918,7 @@ ruleTester.run("my-rule", myRule, { --- [configuration object]: ../user-guide/configuring/ -[builtin-formatters]: https://eslint.org/docs/user-guide/formatters/ +[builtin-formatters]: ../user-guide/formatters/ [third-party-formatters]: https://www.npmjs.com/search?q=eslintformatter [eslint-lintfiles]: #-eslintlintfilespatterns [eslint-linttext]: #-eslintlinttextcode-options diff --git a/docs/src/developer-guide/selectors.md b/docs/src/developer-guide/selectors.md index 4be7795d287..5ea700dead1 100644 --- a/docs/src/developer-guide/selectors.md +++ b/docs/src/developer-guide/selectors.md @@ -93,7 +93,7 @@ If multiple selectors have equal specificity, their listeners will be called in ### Restricting syntax with selectors -With the [no-restricted-syntax](/docs/rules/no-restricted-syntax) rule, you can restrict the usage of particular syntax in your code. For example, you can use the following configuration to disallow using `if` statements that do not have block statements as their body: +With the [no-restricted-syntax](../rules/no-restricted-syntax) rule, you can restrict the usage of particular syntax in your code. For example, you can use the following configuration to disallow using `if` statements that do not have block statements as their body: ```json { diff --git a/docs/src/developer-guide/working-with-custom-formatters.md b/docs/src/developer-guide/working-with-custom-formatters.md index c52d373829d..78bcb67abb8 100644 --- a/docs/src/developer-guide/working-with-custom-formatters.md +++ b/docs/src/developer-guide/working-with-custom-formatters.md @@ -376,7 +376,7 @@ error semi ### Complex Argument Passing -If you find the custom formatter pattern doesn't provide enough options for the way you'd like to format ESLint results, the best option is to use ESLint's built-in [JSON formatter](https://eslint.org/docs/user-guide/formatters/) and pipe the output to a second program. For example: +If you find the custom formatter pattern doesn't provide enough options for the way you'd like to format ESLint results, the best option is to use ESLint's built-in [JSON formatter](../user-guide/formatters/) and pipe the output to a second program. For example: ```bash eslint -f json src/ | your-program-that-reads-JSON --option diff --git a/docs/src/developer-guide/working-with-plugins.md b/docs/src/developer-guide/working-with-plugins.md index 4ce91b22520..dc032922eb3 100644 --- a/docs/src/developer-guide/working-with-plugins.md +++ b/docs/src/developer-guide/working-with-plugins.md @@ -222,7 +222,7 @@ The plugin support was introduced in ESLint version `0.8.0`. Ensure the `peerDep ### Testing -ESLint provides the [`RuleTester`](/docs/developer-guide/nodejs-api#ruletester) utility to make it easy to test the rules of your plugin. +ESLint provides the [`RuleTester`](nodejs-api#ruletester) utility to make it easy to test the rules of your plugin. ### Linting diff --git a/docs/src/developer-guide/working-with-rules.md b/docs/src/developer-guide/working-with-rules.md index a11617239ac..0e92ccfe748 100644 --- a/docs/src/developer-guide/working-with-rules.md +++ b/docs/src/developer-guide/working-with-rules.md @@ -129,8 +129,8 @@ The `context` object contains additional functionality that is helpful for rules * `parserOptions` - the parser options configured for this run (more details [here](../user-guide/configuring/language-options#specifying-parser-options)). * `id` - the rule ID. -* `options` - an array of the [configured options](/docs/user-guide/configuring/rules#configuring-rules) for this rule. This array does not include the rule severity. For more information, see [here](#contextoptions). -* `settings` - the [shared settings](/docs/user-guide/configuring/configuration-files#adding-shared-settings) from configuration. +* `options` - an array of the [configured options](../user-guide/configuring/rules#configuring-rules) for this rule. This array does not include the rule severity. For more information, see [here](#contextoptions). +* `settings` - the [shared settings](../user-guide/configuring/configuration-files#adding-shared-settings) from configuration. * `parserPath` - the name of the `parser` from configuration. * `parserServices` - an object containing parser-provided services for rules. The default parser does not provide any services. However, if a rule is intended to be used with a custom parser, it could use `parserServices` to access anything provided by that parser. (For example, a TypeScript parser could provide the ability to get the computed type of a given node.) @@ -373,7 +373,7 @@ Best practices for fixes: ({ "foo": 1 }) ``` - * This fixer can just select a quote type arbitrarily. If it guesses wrong, the resulting code will be automatically reported and fixed by the [`quotes`](/docs/rules/quotes) rule. + * This fixer can just select a quote type arbitrarily. If it guesses wrong, the resulting code will be automatically reported and fixed by the [`quotes`](../rules/quotes) rule. Note: Making fixes as small as possible is a best practice, but in some cases it may be correct to extend the range of the fix in order to intentionally prevent other rules from making fixes in a surrounding range in the same pass. For instance, if replacement text declares a new variable, it can be useful to prevent other changes in the scope of the variable as they might cause name collisions. @@ -714,7 +714,7 @@ You can access that code path objects with five events related to code paths. Each bundled rule for ESLint core must have a set of unit tests submitted with it to be accepted. The test file is named the same as the source file but lives in `tests/lib/`. For example, if the rule source file is `lib/rules/foo.js` then the test file should be `tests/lib/rules/foo.js`. -ESLint provides the [`RuleTester`](/docs/developer-guide/nodejs-api#ruletester) utility to make it easy to write tests for rules. +ESLint provides the [`RuleTester`](nodejs-api#ruletester) utility to make it easy to write tests for rules. ## Performance Testing diff --git a/docs/src/library/rule-categories.md b/docs/src/library/rule-categories.md index 9f6688f8a73..8934fe7ecac 100644 --- a/docs/src/library/rule-categories.md +++ b/docs/src/library/rule-categories.md @@ -4,7 +4,7 @@ title: Rule categories ## Rule categories -The rule categories—namely “recommended”, “fixable”, and “hasSuggestions”—are shown in the [rules page](/rules/). They are rendered using the `ruleCategories` macro (imported from `/components/rule-categories.macro.html`). There is also an individual macro for each category type. +The rule categories—namely “recommended”, “fixable”, and “hasSuggestions”—are shown in the [rules page](../rules/). They are rendered using the `ruleCategories` macro (imported from `/components/rule-categories.macro.html`). There is also an individual macro for each category type. ```html { % from 'components/rule-categories.macro.html' import ruleCategories % } diff --git a/docs/src/maintainer-guide/governance.md b/docs/src/maintainer-guide/governance.md index 5bbe24c1f08..6b77d9f8952 100644 --- a/docs/src/maintainer-guide/governance.md +++ b/docs/src/maintainer-guide/governance.md @@ -36,8 +36,8 @@ Website Team Members are community members who have shown that they are committe * Are expected to delete their public branches when they are no longer necessary. * Must submit pull requests for all changes. * Have their work reviewed by Reviewers and TSC members before acceptance into the repository. -* May label and close website-related issues (see [Managing Issues](issues.html)) -* May merge some pull requests (see [Managing Pull Requests](pullrequests.html)) +* May label and close website-related issues (see [Managing Issues](issues)) +* May merge some pull requests (see [Managing Pull Requests](pullrequests)) To become a Website Team Member: @@ -59,8 +59,8 @@ Committers: * Are expected to delete their public branches when they are no longer necessary. * Must submit pull requests for all changes. * Have their work reviewed by TSC members before acceptance into the repository. -* May label and close issues (see [Managing Issues](issues.html)) -* May merge some pull requests (see [Managing Pull Requests](pullrequests.html)) +* May label and close issues (see [Managing Issues](issues)) +* May merge some pull requests (see [Managing Pull Requests](pullrequests)) To become a Committer: diff --git a/docs/src/rules/id-denylist.md b/docs/src/rules/id-denylist.md index 49a84ce19d4..d841f37d2dd 100644 --- a/docs/src/rules/id-denylist.md +++ b/docs/src/rules/id-denylist.md @@ -37,7 +37,7 @@ For example, to restrict the use of common generic identifiers: } ``` -**Note:** The first element of the array is for the rule severity (see [configuring rules](/docs/latest/user-guide/configuring/rules). The other elements in the array are the identifiers that you want to disallow. +**Note:** The first element of the array is for the rule severity (see [configuring rules](../user-guide/configuring/rules). The other elements in the array are the identifiers that you want to disallow. Examples of **incorrect** code for this rule with sample `"data", "callback"` restricted identifiers: diff --git a/docs/src/rules/indent-legacy.md b/docs/src/rules/indent-legacy.md index 051a4c1485a..97372ebc8ff 100644 --- a/docs/src/rules/indent-legacy.md +++ b/docs/src/rules/indent-legacy.md @@ -7,7 +7,7 @@ rule_type: layout This rule was **deprecated** in ESLint v4.0.0. -ESLint 4.0.0 introduced a rewrite of the [`indent`](/docs/rules/indent) rule, which now reports more errors than it did in previous versions. To ease the process of migrating to 4.0.0, the `indent-legacy` rule was introduced as a snapshot of the `indent` rule from ESLint 3.x. If your build is failing after the upgrade to 4.0.0, you can disable `indent` and enable `indent-legacy` as a quick fix. Eventually, you should switch back to the `indent` rule to get bugfixes and improvements in future versions. +ESLint 4.0.0 introduced a rewrite of the [`indent`](indent) rule, which now reports more errors than it did in previous versions. To ease the process of migrating to 4.0.0, the `indent-legacy` rule was introduced as a snapshot of the `indent` rule from ESLint 3.x. If your build is failing after the upgrade to 4.0.0, you can disable `indent` and enable `indent-legacy` as a quick fix. Eventually, you should switch back to the `indent` rule to get bugfixes and improvements in future versions. --- diff --git a/docs/src/rules/indent.md b/docs/src/rules/indent.md index 08d10277a37..d783bf179bd 100644 --- a/docs/src/rules/indent.md +++ b/docs/src/rules/indent.md @@ -81,7 +81,7 @@ if (a) { This rule has an object option: -* `"ignoredNodes"` can be used to disable indentation checking for any AST node. This accepts an array of [selectors](/docs/developer-guide/selectors). If an AST node is matched by any of the selectors, the indentation of tokens which are direct children of that node will be ignored. This can be used as an escape hatch to relax the rule if you disagree with the indentation that it enforces for a particular syntactic pattern. +* `"ignoredNodes"` can be used to disable indentation checking for any AST node. This accepts an array of [selectors](../developer-guide/selectors). If an AST node is matched by any of the selectors, the indentation of tokens which are direct children of that node will be ignored. This can be used as an escape hatch to relax the rule if you disagree with the indentation that it enforces for a particular syntactic pattern. * `"SwitchCase"` (default: 0) enforces indentation level for `case` clauses in `switch` statements * `"VariableDeclarator"` (default: 1) enforces indentation level for `var` declarators; can also take an object to define separate rules for `var`, `let` and `const` declarations. It can also be `"first"`, indicating all the declarators should be aligned with the first declarator. * `"outerIIFEBody"` (default: 1) enforces indentation level for file-level IIFEs. This can also be set to `"off"` to disable checking for file-level IIFEs. diff --git a/docs/src/rules/nonblock-statement-body-position.md b/docs/src/rules/nonblock-statement-body-position.md index 3fec9fff077..78d332026e7 100644 --- a/docs/src/rules/nonblock-statement-body-position.md +++ b/docs/src/rules/nonblock-statement-body-position.md @@ -34,7 +34,7 @@ if (foo) bar(); This rule aims to enforce a consistent location for single-line statements. -Note that this rule does not enforce the usage of single-line statements in general. If you would like to disallow single-line statements, use the [`curly`](/docs/rules/curly) rule instead. +Note that this rule does not enforce the usage of single-line statements in general. If you would like to disallow single-line statements, use the [`curly`](curly) rule instead. ### Options @@ -182,4 +182,4 @@ while (foo) ## When Not To Use It -If you're not concerned about consistent locations of single-line statements, you should not turn on this rule. You can also disable this rule if you're using the `"all"` option for the [`curly`](/docs/rules/curly) rule, because this will disallow single-line statements entirely. +If you're not concerned about consistent locations of single-line statements, you should not turn on this rule. You can also disable this rule if you're using the `"all"` option for the [`curly`](curly) rule, because this will disallow single-line statements entirely. diff --git a/docs/src/rules/rest-spread-spacing.md b/docs/src/rules/rest-spread-spacing.md index c661de171dd..d17c81189fc 100644 --- a/docs/src/rules/rest-spread-spacing.md +++ b/docs/src/rules/rest-spread-spacing.md @@ -58,7 +58,7 @@ This rule aims to enforce consistent spacing between rest and spread operators a } ``` -Please read the user guide's section on [configuring parser options](/docs/user-guide/configuring#specifying-parser-options) to learn more. +Please read the user guide's section on [configuring parser options](../user-guide/configuring#specifying-parser-options) to learn more. ## Options diff --git a/docs/src/rules/strict.md b/docs/src/rules/strict.md index 7c50c303411..5a8b1899e6b 100644 --- a/docs/src/rules/strict.md +++ b/docs/src/rules/strict.md @@ -47,7 +47,7 @@ In **ECMAScript** modules, which always have strict mode semantics, the directiv This rule requires or disallows strict mode directives. -This rule disallows strict mode directives, no matter which option is specified, if ESLint configuration specifies either of the following as [parser options](/docs/user-guide/configuring/language-options#specifying-parser-options): +This rule disallows strict mode directives, no matter which option is specified, if ESLint configuration specifies either of the following as [parser options](../user-guide/configuring/language-options#specifying-parser-options): * `"sourceType": "module"` that is, files are **ECMAScript** modules * `"impliedStrict": true` property in the `ecmaFeatures` object @@ -73,8 +73,8 @@ This rule has a string option: The `"safe"` option corresponds to the `"global"` option if ESLint considers a file to be a **Node.js** or **CommonJS** module because the configuration specifies either of the following: -* `node` or `commonjs` [environments](/docs/user-guide/configuring/language-options#specifying-environments) -* `"globalReturn": true` property in the `ecmaFeatures` object of [parser options](/docs/user-guide/configuring/language-options#specifying-parser-options) +* `node` or `commonjs` [environments](../user-guide/configuring/language-options#specifying-environments) +* `"globalReturn": true` property in the `ecmaFeatures` object of [parser options](../user-guide/configuring/language-options#specifying-parser-options) Otherwise the `"safe"` option corresponds to the `"function"` option. Note that if `"globalReturn": false` is explicitly specified in the configuration, the `"safe"` option will correspond to the `"function"` option regardless of the specified environment. @@ -340,4 +340,4 @@ function foo() { ## When Not To Use It -In a codebase that has both strict and non-strict code, either turn this rule off, or [selectively disable it](/docs/user-guide/configuring/rules#disabling-rules) where necessary. For example, functions referencing `arguments.callee` are invalid in strict mode. A [full list of strict mode differences](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode/Transitioning_to_strict_mode#Differences_from_non-strict_to_strict) is available on MDN. +In a codebase that has both strict and non-strict code, either turn this rule off, or [selectively disable it](../user-guide/configuring/rules#disabling-rules) where necessary. For example, functions referencing `arguments.callee` are invalid in strict mode. A [full list of strict mode differences](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode/Transitioning_to_strict_mode#Differences_from_non-strict_to_strict) is available on MDN. diff --git a/docs/src/user-guide/configuring/configuration-files-new.md b/docs/src/user-guide/configuring/configuration-files-new.md index 72ddc97d405..50737884c1e 100644 --- a/docs/src/user-guide/configuring/configuration-files-new.md +++ b/docs/src/user-guide/configuring/configuration-files-new.md @@ -486,7 +486,7 @@ export default [ ]; ``` -This configuration object specifies that the [`semi`](/docs/latest/rules/semi) rule should be enabled with a severity of `"error"`. You can also provide options to a rule by specifying an array where the first item is the severity and each item after that is an option for the rule. For example, you can switch the `semi` rule to disallow semicolons by passing `"never"` as an option: +This configuration object specifies that the [`semi`](../../rules/semi) rule should be enabled with a severity of `"error"`. You can also provide options to a rule by specifying an array where the first item is the severity and each item after that is an option for the rule. For example, you can switch the `semi` rule to disallow semicolons by passing `"never"` as an option: ```js export default [ diff --git a/docs/src/user-guide/configuring/configuration-files.md b/docs/src/user-guide/configuring/configuration-files.md index 8c4f0b19b9e..7c4110db593 100644 --- a/docs/src/user-guide/configuring/configuration-files.md +++ b/docs/src/user-guide/configuring/configuration-files.md @@ -41,7 +41,7 @@ The second way to use configuration files is to save the file wherever you would eslint -c myconfig.json myfiletotest.js ``` -If you are using one configuration file and want ESLint to ignore any `.eslintrc.*` files, make sure to use [`--no-eslintrc`](https://eslint.org/docs/user-guide/command-line-interface#--no-eslintrc) along with the [`--config`](https://eslint.org/docs/user-guide/command-line-interface#-c---config) flag. +If you are using one configuration file and want ESLint to ignore any `.eslintrc.*` files, make sure to use [`--no-eslintrc`](../command-line-interface#--no-eslintrc) along with the [`--config`](../../user-guide/command-line-interface#-c---config) flag. Here's an example JSON configuration file that uses the `typescript-eslint` parser to support TypeScript syntax: @@ -195,7 +195,7 @@ The complete configuration hierarchy, from highest to lowest precedence, is as f 1. `.eslintrc.*` or `package.json` file in the same directory as the linted file 1. Continue searching for `.eslintrc.*` and `package.json` files in ancestor directories up to and including the root directory or until a config with `"root": true` is found. -Please note that the [home directory of the current user on your preferred operating system](https://nodejs.org/api/os.html#os_os_homedir) (`~/`) is also considered a root directory in this context and searching for configuration files stops there as well. And with the [removal of support for Personal Configuration Files](https://eslint.org/docs/user-guide/configuring/configuration-files#personal-configuration-files-deprecated) from the 8.0.0 release forward, configuration files present in that directory are ignored. +Please note that the [home directory of the current user on your preferred operating system](https://nodejs.org/api/os.html#os_os_homedir) (`~/`) is also considered a root directory in this context and searching for configuration files stops there as well. And with the [removal of support for Personal Configuration Files](configuration-files#personal-configuration-files-deprecated) from the 8.0.0 release forward, configuration files present in that directory are ignored. ## Extending Configuration Files @@ -232,7 +232,7 @@ The `rules` property can do any of the following to extend (or override) the set ### Using a shareable configuration package -A [sharable configuration](https://eslint.org/docs/developer-guide/shareable-configs) is an npm package that exports a configuration object. Make sure that you have installed the package in your project root directory, so that ESLint can require it. +A [sharable configuration](../../developer-guide/shareable-configs) is an npm package that exports a configuration object. Make sure that you have installed the package in your project root directory, so that ESLint can require it. The `extends` property value can omit the `eslint-config-` prefix of the package name. @@ -251,7 +251,7 @@ rules: ### Using `eslint:recommended` -Using `"eslint:recommended"` in the `extends` property enables a subset of core rules that report common problems (these rules are identified with a checkmark (recommended) on the [rules page](https://eslint.org/docs/rules/)). +Using `"eslint:recommended"` in the `extends` property enables a subset of core rules that report common problems (these rules are identified with a checkmark (recommended) on the [rules page](../../rules/)). Here's an example of extending `eslint:recommended` and overriding some of the set configuration options: @@ -279,7 +279,7 @@ module.exports = { ### Using a configuration from a plugin -A [plugin](https://eslint.org/docs/developer-guide/working-with-plugins) is an npm package that can add various extensions to ESLint. A plugin can perform numerous functions, including but not limited to adding new rules and exporting [shareable configurations](https://eslint.org/docs/developer-guide/working-with-plugins#configs-in-plugins). Make sure the package has been installed in a directory where ESLint can require it. +A [plugin](../../developer-guide/working-with-plugins) is an npm package that can add various extensions to ESLint. A plugin can perform numerous functions, including but not limited to adding new rules and exporting [shareable configurations](../../developer-guide/working-with-plugins#configs-in-plugins). Make sure the package has been installed in a directory where ESLint can require it. The `plugins` [property value](./plugins#configure-plugins) can omit the `eslint-plugin-` prefix of the package name. @@ -332,9 +332,9 @@ The `extends` property value can be `"eslint:all"` to enable all core rules in t **Important:** This configuration is **not recommended for production use** because it changes with every minor and major version of ESLint. Use it at your own risk. -You might enable all core rules as a shortcut to explore rules and options while you decide on the configuration for a project, especially if you rarely override options or disable rules. The default options for rules are not endorsements by ESLint (for example, the default option for the [`quotes`](https://eslint.org/docs/rules/quotes) rule does not mean double quotes are better than single quotes). +You might enable all core rules as a shortcut to explore rules and options while you decide on the configuration for a project, especially if you rarely override options or disable rules. The default options for rules are not endorsements by ESLint (for example, the default option for the [`quotes`](../../rules/quotes) rule does not mean double quotes are better than single quotes). -If your configuration extends `eslint:all`, after you upgrade to a newer major or minor version of ESLint, review the reported problems before you use the `--fix` option on the [command line](https://eslint.org/docs/user-guide/command-line-interface#--fix), so you know if a new fixable rule will make changes to the code. +If your configuration extends `eslint:all`, after you upgrade to a newer major or minor version of ESLint, review the reported problems before you use the `--fix` option on the [command line](../command-line-interface#--fix), so you know if a new fixable rule will make changes to the code. Example of a configuration file in JavaScript format: @@ -428,7 +428,7 @@ If you specified the [`--ext`](../command-line-interface#--ext) command line opt ## Personal Configuration Files (deprecated) -⚠️ **This feature has been deprecated**. This feature was removed in the 8.0.0 release. If you want to continue to use personal configuration files, please use the [`--config` CLI option](https://eslint.org/docs/user-guide/command-line-interface#-c---config). For more information regarding this decision, please see [RFC 28](https://github.com/eslint/rfcs/pull/28) and [RFC 32](https://github.com/eslint/rfcs/pull/32). +⚠️ **This feature has been deprecated**. This feature was removed in the 8.0.0 release. If you want to continue to use personal configuration files, please use the [`--config` CLI option](../command-line-interface#-c---config). For more information regarding this decision, please see [RFC 28](https://github.com/eslint/rfcs/pull/28) and [RFC 32](https://github.com/eslint/rfcs/pull/32). `~/` refers to [the home directory of the current user on your preferred operating system](https://nodejs.org/api/os.html#os_os_homedir). The personal configuration file being referred to here is `~/.eslintrc.*` file, which is currently handled differently than other configuration files. @@ -444,4 +444,4 @@ If `eslint` could find configuration files in the project, `eslint` ignores `~/. `~/.eslintrc.*` files load shareable configs and custom parsers from `~/node_modules/` – similarly to `require()` – in the user's home directory. Please note that it doesn't load global-installed packages. -`~/.eslintrc.*` files load plugins from `$CWD/node_modules` by default in order to identify plugins uniquely. If you want to use plugins with `~/.eslintrc.*` files, plugins must be installed locally per project. Alternatively, you can use the [`--resolve-plugins-relative-to` CLI option](https://eslint.org/docs/user-guide/command-line-interface#--resolve-plugins-relative-to) to change the location from which ESLint loads plugins. +`~/.eslintrc.*` files load plugins from `$CWD/node_modules` by default in order to identify plugins uniquely. If you want to use plugins with `~/.eslintrc.*` files, plugins must be installed locally per project. Alternatively, you can use the [`--resolve-plugins-relative-to` CLI option](../command-line-interface#--resolve-plugins-relative-to) to change the location from which ESLint loads plugins. diff --git a/docs/src/user-guide/getting-started.md b/docs/src/user-guide/getting-started.md index 0496a156e7b..655c170bd33 100644 --- a/docs/src/user-guide/getting-started.md +++ b/docs/src/user-guide/getting-started.md @@ -75,7 +75,7 @@ After running `npm init @eslint/config`, you'll have a `.eslintrc.{js,yml,json}` } ``` -The names `"semi"` and `"quotes"` are the names of [rules](/docs/rules) in ESLint. The first value is the error level of the rule and can be one of these values: +The names `"semi"` and `"quotes"` are the names of [rules](../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) @@ -91,7 +91,7 @@ Your `.eslintrc.{js,yml,json}` configuration file will also include the line: } ``` -Because of this line, all of the rules marked "(recommended)" on the [rules page](/docs/rules) will be turned on. Alternatively, you can use configurations that others have created by searching for "eslint-config" on [npmjs.com](https://www.npmjs.com/search?q=eslint-config). ESLint will not lint your code unless you extend from a shared configuration or explicitly turn rules on in your configuration. +Because of this line, all of the rules marked "(recommended)" on the [rules page](../rules) will be turned on. Alternatively, you can use configurations that others have created by searching for "eslint-config" on [npmjs.com](https://www.npmjs.com/search?q=eslint-config). ESLint will not lint your code unless you extend from a shared configuration or explicitly turn rules on in your configuration. --- @@ -100,5 +100,5 @@ Because of this line, all of the rules marked "(recommended)" on the [rules page * Learn about [advanced configuration](configuring/) of ESLint. * Get familiar with the [command line options](command-line-interface). * Explore [ESLint integrations](integrations) into other tools like editors, build systems, and more. -* Can't find just the right rule? Make your own [custom rule](/docs/developer-guide/working-with-rules). -* Make ESLint even better by [contributing](/docs/developer-guide/contributing/). +* Can't find just the right rule? Make your own [custom rule](../developer-guide/working-with-rules). +* Make ESLint even better by [contributing](../developer-guide/contributing/). diff --git a/docs/src/user-guide/migrating-from-jscs.md b/docs/src/user-guide/migrating-from-jscs.md index ec2fdb01962..938daf8e230 100644 --- a/docs/src/user-guide/migrating-from-jscs.md +++ b/docs/src/user-guide/migrating-from-jscs.md @@ -10,7 +10,7 @@ In April 2016, we [announced](https://eslint.org/blog/2016/04/welcoming-jscs-to- Before beginning the process of migrating to ESLint, it's helpful to understand some of the terminology that ESLint uses and how it relates to terminology that JSCS uses. * **Configuration File** - In JSCS, the configuration file is `.jscsrc`, `.jscsrc.json`, `.jscsrc.yaml`, or `.jscsrs.js`. In ESLint, the configuration file can be `.eslintrc.json`, `.eslintrc.yml`, `.eslintrc.yaml`, or `.eslintrc.js` (there is also a deprecated `.eslintrc` file format). -* **Presets** - In JSCS, there were numerous predefined configurations shipped directly within JSCS. ESLint ships with just one predefined configuration (`eslint:recommended`) that has no style rules enabled. However, ESLint does support [shareable configs](https://eslint.org/docs/developer-guide/shareable-configs). Shareable configs are configurations that are published on their own to npm and there are shareable configs available for almost all of the JSCS presets (see [the "Converting Presets" section](#converting-presets) below). Additionally, the `preset` option in a configuration file is the equivalent of the ESLint `extends` option. +* **Presets** - In JSCS, there were numerous predefined configurations shipped directly within JSCS. ESLint ships with just one predefined configuration (`eslint:recommended`) that has no style rules enabled. However, ESLint does support [shareable configs](../developer-guide/shareable-configs). Shareable configs are configurations that are published on their own to npm and there are shareable configs available for almost all of the JSCS presets (see [the "Converting Presets" section](#converting-presets) below). Additionally, the `preset` option in a configuration file is the equivalent of the ESLint `extends` option. ## Convert Configuration Files Using Polyjuice diff --git a/docs/src/user-guide/migrating-to-1.0.0.md b/docs/src/user-guide/migrating-to-1.0.0.md index 8c4628089c3..1ed8496359e 100644 --- a/docs/src/user-guide/migrating-to-1.0.0.md +++ b/docs/src/user-guide/migrating-to-1.0.0.md @@ -23,62 +23,62 @@ This setting mimics some of the default behavior from 0.x, but not all. If you d The `"eslint:recommended"` configuration contains many of the same default rule settings from 0.x, but not all. These rules are no longer on by default, so you should review your settings to ensure they are still as you expect: -* [no-alert](https://eslint.org/docs/rules/no-alert) -* [no-array-constructor](https://eslint.org/docs/rules/no-array-constructor) -* [no-caller](https://eslint.org/docs/rules/no-caller) -* [no-catch-shadow](https://eslint.org/docs/rules/no-catch-shadow) -* [no-empty-label](https://eslint.org/docs/rules/no-empty-label) -* [no-eval](https://eslint.org/docs/rules/no-eval) -* [no-extend-native](https://eslint.org/docs/rules/no-extend-native) -* [no-extra-bind](https://eslint.org/docs/rules/no-extra-bind) -* [no-extra-strict](https://eslint.org/docs/rules/no-extra-strict) -* [no-implied-eval](https://eslint.org/docs/rules/no-implied-eval) -* [no-iterator](https://eslint.org/docs/rules/no-iterator) -* [no-label-var](https://eslint.org/docs/rules/no-label-var) -* [no-labels](https://eslint.org/docs/rules/no-labels) -* [no-lone-blocks](https://eslint.org/docs/rules/no-lone-blocks) -* [no-loop-func](https://eslint.org/docs/rules/no-loop-func) -* [no-multi-spaces](https://eslint.org/docs/rules/no-multi-spaces) -* [no-multi-str](https://eslint.org/docs/rules/no-multi-str) -* [no-native-reassign](https://eslint.org/docs/rules/no-native-reassign) -* [no-new](https://eslint.org/docs/rules/no-new) -* [no-new-func](https://eslint.org/docs/rules/no-new-func) -* [no-new-object](https://eslint.org/docs/rules/no-new-object) -* [no-new-wrappers](https://eslint.org/docs/rules/no-new-wrappers) -* [no-octal-escape](https://eslint.org/docs/rules/no-octal-escape) -* [no-process-exit](https://eslint.org/docs/rules/no-process-exit) -* [no-proto](https://eslint.org/docs/rules/no-proto) -* [no-return-assign](https://eslint.org/docs/rules/no-return-assign) -* [no-script-url](https://eslint.org/docs/rules/no-script-url) -* [no-sequences](https://eslint.org/docs/rules/no-sequences) -* [no-shadow](https://eslint.org/docs/rules/no-shadow) -* [no-shadow-restricted-names](https://eslint.org/docs/rules/no-shadow-restricted-names) -* [no-spaced-func](https://eslint.org/docs/rules/no-spaced-func) -* [no-trailing-spaces](https://eslint.org/docs/rules/no-trailing-spaces) -* [no-undef-init](https://eslint.org/docs/rules/no-undef-init) -* [no-underscore-dangle](https://eslint.org/docs/rules/no-underscore-dangle) -* [no-unused-expressions](https://eslint.org/docs/rules/no-unused-expressions) -* [no-use-before-define](https://eslint.org/docs/rules/no-use-before-define) -* [no-with](https://eslint.org/docs/rules/no-with) -* [no-wrap-func](https://eslint.org/docs/rules/no-wrap-func) -* [camelcase](https://eslint.org/docs/rules/camelcase) -* [comma-spacing](https://eslint.org/docs/rules/comma-spacing) -* [consistent-return](https://eslint.org/docs/rules/consistent-return) -* [curly](https://eslint.org/docs/rules/curly) -* [dot-notation](https://eslint.org/docs/rules/dot-notation) -* [eol-last](https://eslint.org/docs/rules/eol-last) -* [eqeqeq](https://eslint.org/docs/rules/eqeqeq) -* [key-spacing](https://eslint.org/docs/rules/key-spacing) -* [new-cap](https://eslint.org/docs/rules/new-cap) -* [new-parens](https://eslint.org/docs/rules/new-parens) -* [quotes](https://eslint.org/docs/rules/quotes) -* [semi](https://eslint.org/docs/rules/semi) -* [semi-spacing](https://eslint.org/docs/rules/semi-spacing) -* [space-infix-ops](https://eslint.org/docs/rules/space-infix-ops) -* [space-return-throw-case](https://eslint.org/docs/rules/space-return-throw-case) -* [space-unary-ops](https://eslint.org/docs/rules/space-unary-ops) -* [strict](https://eslint.org/docs/rules/strict) -* [yoda](https://eslint.org/docs/rules/yoda) +* [no-alert](../rules/no-alert) +* [no-array-constructor](../rules/no-array-constructor) +* [no-caller](../rules/no-caller) +* [no-catch-shadow](../rules/no-catch-shadow) +* [no-empty-label](../rules/no-empty-label) +* [no-eval](../rules/no-eval) +* [no-extend-native](../rules/no-extend-native) +* [no-extra-bind](../rules/no-extra-bind) +* [no-extra-strict](../rules/no-extra-strict) +* [no-implied-eval](../rules/no-implied-eval) +* [no-iterator](../rules/no-iterator) +* [no-label-var](../rules/no-label-var) +* [no-labels](../rules/no-labels) +* [no-lone-blocks](../rules/no-lone-blocks) +* [no-loop-func](../rules/no-loop-func) +* [no-multi-spaces](../rules/no-multi-spaces) +* [no-multi-str](../rules/no-multi-str) +* [no-native-reassign](../rules/no-native-reassign) +* [no-new](../rules/no-new) +* [no-new-func](../rules/no-new-func) +* [no-new-object](../rules/no-new-object) +* [no-new-wrappers](../rules/no-new-wrappers) +* [no-octal-escape](../rules/no-octal-escape) +* [no-process-exit](../rules/no-process-exit) +* [no-proto](../rules/no-proto) +* [no-return-assign](../rules/no-return-assign) +* [no-script-url](../rules/no-script-url) +* [no-sequences](../rules/no-sequences) +* [no-shadow](../rules/no-shadow) +* [no-shadow-restricted-names](../rules/no-shadow-restricted-names) +* [no-spaced-func](../rules/no-spaced-func) +* [no-trailing-spaces](../rules/no-trailing-spaces) +* [no-undef-init](../rules/no-undef-init) +* [no-underscore-dangle](../rules/no-underscore-dangle) +* [no-unused-expressions](../rules/no-unused-expressions) +* [no-use-before-define](../rules/no-use-before-define) +* [no-with](../rules/no-with) +* [no-wrap-func](../rules/no-wrap-func) +* [camelcase](../rules/camelcase) +* [comma-spacing](../rules/comma-spacing) +* [consistent-return](../rules/consistent-return) +* [curly](../rules/curly) +* [dot-notation](../rules/dot-notation) +* [eol-last](../rules/eol-last) +* [eqeqeq](../rules/eqeqeq) +* [key-spacing](../rules/key-spacing) +* [new-cap](../rules/new-cap) +* [new-parens](../rules/new-parens) +* [quotes](../rules/quotes) +* [semi](../rules/semi) +* [semi-spacing](../rules/semi-spacing) +* [space-infix-ops](../rules/space-infix-ops) +* [space-return-throw-case](../rules/space-return-throw-case) +* [space-unary-ops](../rules/space-unary-ops) +* [strict](../rules/strict) +* [yoda](../rules/yoda) See also: the [full diff](https://github.com/eslint/eslint/commit/e3e9dbd9876daf4bdeb4e15f8a76a9d5e6e03e39#diff-b01a5cfd9361ca9280a460fd6bb8edbbL1) where the defaults were changed. @@ -151,19 +151,19 @@ Here's a configuration file with the closest equivalent of the old defaults: Over the past several releases, we have been deprecating rules and introducing new rules to take their place. The following is a list of the removed rules and their replacements: -* [generator-star](https://eslint.org/docs/rules/generator-star) is replaced by [generator-star-spacing](https://eslint.org/docs/rules/generator-star-spacing) -* [global-strict](https://eslint.org/docs/rules/global-strict) is replaced by [strict](https://eslint.org/docs/rules/strict) -* [no-comma-dangle](https://eslint.org/docs/rules/no-comma-dangle) is replaced by [comma-dangle](https://eslint.org/docs/rules/comma-dangle) -* [no-empty-class](https://eslint.org/docs/rules/no-empty-class) is replaced by [no-empty-character-class](https://eslint.org/docs/rules/no-empty-character-class) -* [no-extra-strict](https://eslint.org/docs/rules/no-extra-strict) is replaced by [strict](https://eslint.org/docs/rules/strict) -* [no-reserved-keys](https://eslint.org/docs/rules/no-reserved-keys) is replaced by [quote-props](https://eslint.org/docs/rules/quote-props) -* [no-space-before-semi](https://eslint.org/docs/rules/no-space-before-semi) is replaced by [semi-spacing](https://eslint.org/docs/rules/semi-spacing) -* [no-wrap-func](https://eslint.org/docs/rules/no-wrap-func) is replaced by [no-extra-parens](https://eslint.org/docs/rules/no-extra-parens) -* [space-after-function-name](https://eslint.org/docs/rules/space-after-function-name) is replaced by [space-before-function-paren](https://eslint.org/docs/rules/space-before-function-paren) -* [space-before-function-parentheses](https://eslint.org/docs/rules/space-before-function-parentheses) is replaced by [space-before-function-paren](https://eslint.org/docs/rules/space-before-function-paren) -* [space-in-brackets](https://eslint.org/docs/rules/space-in-brackets) is replaced by[object-curly-spacing](https://eslint.org/docs/rules/object-curly-spacing) and [array-bracket-spacing](https://eslint.org/docs/rules/array-bracket-spacing) -* [space-unary-word-ops](https://eslint.org/docs/rules/space-unary-word-ops) is replaced by [space-unary-ops](https://eslint.org/docs/rules/space-unary-ops) -* [spaced-line-comment](https://eslint.org/docs/rules/spaced-line-comment) is replaced by [spaced-comment](https://eslint.org/docs/rules/spaced-comment) +* [generator-star](../rules/generator-star) is replaced by [generator-star-spacing](../rules/generator-star-spacing) +* [global-strict](../rules/global-strict) is replaced by [strict](../rules/strict) +* [no-comma-dangle](../rules/no-comma-dangle) is replaced by [comma-dangle](../rules/comma-dangle) +* [no-empty-class](../rules/no-empty-class) is replaced by [no-empty-character-class](../rules/no-empty-character-class) +* [no-extra-strict](../rules/no-extra-strict) is replaced by [strict](../rules/strict) +* [no-reserved-keys](../rules/no-reserved-keys) is replaced by [quote-props](../rules/quote-props) +* [no-space-before-semi](../rules/no-space-before-semi) is replaced by [semi-spacing](../rules/semi-spacing) +* [no-wrap-func](../rules/no-wrap-func) is replaced by [no-extra-parens](../rules/no-extra-parens) +* [space-after-function-name](../rules/space-after-function-name) is replaced by [space-before-function-paren](../rules/space-before-function-paren) +* [space-before-function-parentheses](../rules/space-before-function-parentheses) is replaced by [space-before-function-paren](../rules/space-before-function-paren) +* [space-in-brackets](../rules/space-in-brackets) is replaced by[object-curly-spacing](../rules/object-curly-spacing) and [array-bracket-spacing](../rules/array-bracket-spacing) +* [space-unary-word-ops](../rules/space-unary-word-ops) is replaced by [space-unary-ops](../rules/space-unary-ops) +* [spaced-line-comment](../rules/spaced-line-comment) is replaced by [spaced-comment](../rules/spaced-comment) **To address:** You'll need to update your rule configurations to use the new rules. ESLint v1.0.0 will also warn you when you're using a rule that has been removed and will suggest the replacement rules. Hopefully, this will result in few surprises during the upgrade process. diff --git a/docs/src/user-guide/migrating-to-2.0.0.md b/docs/src/user-guide/migrating-to-2.0.0.md index 6b9ded1f6d1..753fed743a7 100644 --- a/docs/src/user-guide/migrating-to-2.0.0.md +++ b/docs/src/user-guide/migrating-to-2.0.0.md @@ -54,11 +54,11 @@ module.exports = { The following rules have been deprecated with new rules created to take their place. The following is a list of the removed rules and their replacements: -* [no-arrow-condition](https://eslint.org/docs/rules/no-arrow-condition) is replaced by a combination of [no-confusing-arrow](https://eslint.org/docs/rules/no-confusing-arrow) and [no-constant-condition](https://eslint.org/docs/rules/no-constant-condition). Turn on both of these rules to get the same functionality as `no-arrow-condition`. -* [no-empty-label](https://eslint.org/docs/rules/no-empty-label) is replaced by [no-labels](https://eslint.org/docs/rules/no-labels) with `{"allowLoop": true, "allowSwitch": true}` option. -* [space-after-keywords](https://eslint.org/docs/rules/space-after-keywords) is replaced by [keyword-spacing](https://eslint.org/docs/rules/keyword-spacing). -* [space-before-keywords](https://eslint.org/docs/rules/space-before-keywords) is replaced by [keyword-spacing](https://eslint.org/docs/rules/keyword-spacing). -* [space-return-throw-case](https://eslint.org/docs/rules/space-return-throw-case) is replaced by [keyword-spacing](https://eslint.org/docs/rules/keyword-spacing). +* [no-arrow-condition](../rules/no-arrow-condition) is replaced by a combination of [no-confusing-arrow](../rules/no-confusing-arrow) and [no-constant-condition](../rules/no-constant-condition). Turn on both of these rules to get the same functionality as `no-arrow-condition`. +* [no-empty-label](../rules/no-empty-label) is replaced by [no-labels](../rules/no-labels) with `{"allowLoop": true, "allowSwitch": true}` option. +* [space-after-keywords](../rules/space-after-keywords) is replaced by [keyword-spacing](../rules/keyword-spacing). +* [space-before-keywords](../rules/space-before-keywords) is replaced by [keyword-spacing](../rules/keyword-spacing). +* [space-return-throw-case](../rules/space-return-throw-case) is replaced by [keyword-spacing](../rules/keyword-spacing). **To address:** You'll need to update your rule configurations to use the new rules. ESLint v2.0.0 will also warn you when you're using a rule that has been removed and will suggest the replacement rules. Hopefully, this will result in few surprises during the upgrade process. @@ -210,17 +210,17 @@ If you're not using `ecmaFeatures` in your configuration or your custom/plugin r In 2.0.0, the following 11 rules were added to `"eslint:recommended"`. -* [constructor-super](https://eslint.org/docs/rules/constructor-super) -* [no-case-declarations](https://eslint.org/docs/rules/no-case-declarations) -* [no-class-assign](https://eslint.org/docs/rules/no-class-assign) -* [no-const-assign](https://eslint.org/docs/rules/no-const-assign) -* [no-dupe-class-members](https://eslint.org/docs/rules/no-dupe-class-members) -* [no-empty-pattern](https://eslint.org/docs/rules/no-empty-pattern) -* [no-new-symbol](https://eslint.org/docs/rules/no-new-symbol) -* [no-self-assign](https://eslint.org/docs/rules/no-self-assign) -* [no-this-before-super](https://eslint.org/docs/rules/no-this-before-super) -* [no-unexpected-multiline](https://eslint.org/docs/rules/no-unexpected-multiline) -* [no-unused-labels](https://eslint.org/docs/rules/no-unused-labels) +* [constructor-super](../rules/constructor-super) +* [no-case-declarations](../rules/no-case-declarations) +* [no-class-assign](../rules/no-class-assign) +* [no-const-assign](../rules/no-const-assign) +* [no-dupe-class-members](../rules/no-dupe-class-members) +* [no-empty-pattern](../rules/no-empty-pattern) +* [no-new-symbol](../rules/no-new-symbol) +* [no-self-assign](../rules/no-self-assign) +* [no-this-before-super](../rules/no-this-before-super) +* [no-unexpected-multiline](../rules/no-unexpected-multiline) +* [no-unused-labels](../rules/no-unused-labels) **To address:** If you don't want to be notified by those rules, you can simply disable those rules. diff --git a/docs/src/user-guide/migrating-to-3.0.0.md b/docs/src/user-guide/migrating-to-3.0.0.md index fa93927212d..b4aa4580e79 100644 --- a/docs/src/user-guide/migrating-to-3.0.0.md +++ b/docs/src/user-guide/migrating-to-3.0.0.md @@ -38,17 +38,17 @@ To create a new configuration, use `eslint --init`. In 3.0.0, the following rules were added to `"eslint:recommended"`: -* [`no-unsafe-finally`](https://eslint.org/docs/rules/no-unsafe-finally) helps catch `finally` clauses that may not behave as you think. -* [`no-native-reassign`](https://eslint.org/docs/rules/no-native-reassign) was previously part of `no-undef`, but was split out because it didn't make sense as part of another rule. The `no-native-reassign` rule warns whenever you try to overwrite a read-only global variable. -* [`require-yield`](https://eslint.org/docs/rules/require-yield) helps to identify generator functions that do not have the `yield` keyword. +* [`no-unsafe-finally`](../rules/no-unsafe-finally) helps catch `finally` clauses that may not behave as you think. +* [`no-native-reassign`](../rules/no-native-reassign) was previously part of `no-undef`, but was split out because it didn't make sense as part of another rule. The `no-native-reassign` rule warns whenever you try to overwrite a read-only global variable. +* [`require-yield`](../rules/require-yield) helps to identify generator functions that do not have the `yield` keyword. The following rules were removed from `"eslint:recommended"`: -* [`comma-dangle`](https://eslint.org/docs/rules/comma-dangle) used to be recommended because Internet Explorer 8 and earlier threw a syntax error when it found a dangling comma on object literal properties. However, [Internet Explorer 8 was end-of-lifed](https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support) in January 2016 and all other active browsers allow dangling commas. As such, we consider dangling commas to now be a stylistic issue instead of a possible error. +* [`comma-dangle`](../rules/comma-dangle) used to be recommended because Internet Explorer 8 and earlier threw a syntax error when it found a dangling comma on object literal properties. However, [Internet Explorer 8 was end-of-lifed](https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support) in January 2016 and all other active browsers allow dangling commas. As such, we consider dangling commas to now be a stylistic issue instead of a possible error. The following rules were modified: -* [`complexity`](https://eslint.org/docs/rules/complexity) used to have a hardcoded default of 11 in `eslint:recommended` that would be used if you turned the rule on without specifying a maximum. The default is now 20. The rule actually always had a default of 20, but `eslint:recommended` was overriding it by mistake. +* [`complexity`](../rules/complexity) used to have a hardcoded default of 11 in `eslint:recommended` that would be used if you turned the rule on without specifying a maximum. The default is now 20. The rule actually always had a default of 20, but `eslint:recommended` was overriding it by mistake. **To address:** If you want to mimic how `eslint:recommended` worked in v2.x, you can use the following: diff --git a/docs/src/user-guide/migrating-to-4.0.0.md b/docs/src/user-guide/migrating-to-4.0.0.md index e7630a1dc90..d1267270d43 100644 --- a/docs/src/user-guide/migrating-to-4.0.0.md +++ b/docs/src/user-guide/migrating-to-4.0.0.md @@ -35,10 +35,10 @@ The lists below are ordered roughly by the number of users each change is expect ## `eslint:recommended` changes -Two new rules have been added to the [`eslint:recommended`](https://eslint.org/docs/user-guide/configuring#using-eslintrecommended) config: +Two new rules have been added to the [`eslint:recommended`](configuring#using-eslintrecommended) config: -* [`no-compare-neg-zero`](/docs/rules/no-compare-neg-zero) disallows comparisons to `-0` -* [`no-useless-escape`](/docs/rules/no-useless-escape) disallows uselessly-escaped characters in strings and regular expressions +* [`no-compare-neg-zero`](../rules/no-compare-neg-zero) disallows comparisons to `-0` +* [`no-useless-escape`](../rules/no-useless-escape) disallows uselessly-escaped characters in strings and regular expressions **To address:** To mimic the `eslint:recommended` behavior from 3.x, you can disable these rules in a config file: @@ -55,11 +55,11 @@ Two new rules have been added to the [`eslint:recommended`](https://eslint.org/d ## The `indent` rule is more strict -Previously, the [`indent`](/docs/rules/indent) rule was fairly lenient about checking indentation; there were many code patterns where indentation was not validated by the rule. This caused confusion for users, because they were accidentally writing code with incorrect indentation, and they expected ESLint to catch the issues. +Previously, the [`indent`](../rules/indent) rule was fairly lenient about checking indentation; there were many code patterns where indentation was not validated by the rule. This caused confusion for users, because they were accidentally writing code with incorrect indentation, and they expected ESLint to catch the issues. In 4.0.0, the `indent` rule has been rewritten. The new version of the rule will report some indentation errors that the old version of the rule did not catch. Additionally, the indentation of `MemberExpression` nodes, function parameters, and function arguments will now be checked by default (it was previously ignored by default for backwards compatibility). -To make the upgrade process easier, we've introduced the [`indent-legacy`](/docs/rules/indent-legacy) rule as a snapshot of the `indent` rule from 3.x. If you run into issues from the `indent` rule when you upgrade, you should be able to use the `indent-legacy` rule to replicate the 3.x behavior. However, the `indent-legacy` rule is deprecated and will not receive bugfixes or improvements in the future, so you should eventually switch back to the `indent` rule. +To make the upgrade process easier, we've introduced the [`indent-legacy`](../rules/indent-legacy) rule as a snapshot of the `indent` rule from 3.x. If you run into issues from the `indent` rule when you upgrade, you should be able to use the `indent-legacy` rule to replicate the 3.x behavior. However, the `indent-legacy` rule is deprecated and will not receive bugfixes or improvements in the future, so you should eventually switch back to the `indent` rule. **To address:** We recommend upgrading without changing your `indent` configuration, and fixing any new indentation errors that appear in your codebase. However, if you want to mimic how the `indent` rule worked in 3.x, you can update your configuration: @@ -86,13 +86,13 @@ Due to a bug, glob patterns in an `.eslintignore` file were previously resolved ## The `padded-blocks` rule is more strict by default -By default, the [`padded-blocks`](/docs/rules/padded-blocks) rule will now enforce padding in class bodies and switch statements. Previously, the rule would ignore these cases unless the user opted into enforcing them. +By default, the [`padded-blocks`](../rules/padded-blocks) rule will now enforce padding in class bodies and switch statements. Previously, the rule would ignore these cases unless the user opted into enforcing them. **To address:** If this change results in more linting errors in your codebase, you should fix them or reconfigure the rule. ## The `space-before-function-paren` rule is more strict by default -By default, the [`space-before-function-paren`](/docs/rules/space-before-function-paren) rule will now enforce spacing for async arrow functions. Previously, the rule would ignore these cases unless the user opted into enforcing them. +By default, the [`space-before-function-paren`](../rules/space-before-function-paren) rule will now enforce spacing for async arrow functions. Previously, the rule would ignore these cases unless the user opted into enforcing them. **To address:** To mimic the default config from 3.x, you can use: @@ -110,7 +110,7 @@ By default, the [`space-before-function-paren`](/docs/rules/space-before-functio ## The `no-multi-spaces` rule is more strict by default -By default, the [`no-multi-spaces`](/docs/rules/no-multi-spaces) rule will now disallow multiple spaces before comments at the end of a line. Previously, the rule did not check this case. +By default, the [`no-multi-spaces`](../rules/no-multi-spaces) rule will now disallow multiple spaces before comments at the end of a line. Previously, the rule did not check this case. **To address:** To mimic the default config from 3.x, you can use: diff --git a/docs/src/user-guide/migrating-to-5.0.0.md b/docs/src/user-guide/migrating-to-5.0.0.md index 87d19df8dae..13898eb3268 100644 --- a/docs/src/user-guide/migrating-to-5.0.0.md +++ b/docs/src/user-guide/migrating-to-5.0.0.md @@ -50,10 +50,10 @@ As of April 30th, 2018, Node.js 4 will be at EOL and will no longer be receiving ## `eslint:recommended` changes -Two new rules have been added to the [`eslint:recommended`](https://eslint.org/docs/user-guide/configuring#using-eslintrecommended) config: +Two new rules have been added to the [`eslint:recommended`](configuring#using-eslintrecommended) config: -* [`for-direction`](/docs/rules/for-direction) enforces that a `for` loop update clause moves the counter in the right direction. -* [`getter-return`](/docs/rules/getter-return) enforces that a `return` statement is present in property getters. +* [`for-direction`](../rules/for-direction) enforces that a `for` loop update clause moves the counter in the right direction. +* [`getter-return`](../rules/getter-return) enforces that a `return` statement is present in property getters. **To address:** To mimic the `eslint:recommended` behavior from 4.x, you can disable these rules in a config file: @@ -96,7 +96,7 @@ Note that this also enables parsing for other features from ES2018, such as [asy For compatibility, ESLint v5 will treat `ecmaFeatures: { experimentalObjectRestSpread: true }` as an alias for `ecmaVersion: 2018` when the former is found in a config file. As a result, if you use object rest/spread, your code should still parse successfully with ESLint v5. However, note that this alias will be removed in ESLint v6. -**To address:** If you use the `experimentalObjectRestSpread` option, you should be able to upgrade to ESLint v5 without any changes, but you will encounter a deprecation warning. To avoid the warning, use `ecmaVersion: 2018` in your config file rather than `ecmaFeatures: { experimentalObjectRestSpread: true }`. If you would like to disallow the use of other ES2018 features, consider using rules such as [`no-restricted-syntax`](/docs/rules/no-restricted-syntax). +**To address:** If you use the `experimentalObjectRestSpread` option, you should be able to upgrade to ESLint v5 without any changes, but you will encounter a deprecation warning. To avoid the warning, use `ecmaVersion: 2018` in your config file rather than `ecmaFeatures: { experimentalObjectRestSpread: true }`. If you would like to disallow the use of other ES2018 features, consider using rules such as [`no-restricted-syntax`](../rules/no-restricted-syntax). ## Linting nonexistent files from the command line is now a fatal error @@ -113,7 +113,7 @@ ESLint v5 will report a fatal error when either of the following conditions is m * A file provided on the command line does not exist * A glob or folder provided on the command line does not match any lintable files -Note that this also affects the [`CLIEngine.executeOnFiles()`](https://eslint.org/docs/developer-guide/nodejs-api#cliengineexecuteonfiles) API. +Note that this also affects the [`CLIEngine.executeOnFiles()`](../developer-guide/nodejs-api#cliengineexecuteonfiles) API. **To address:** If you encounter an error about missing files after upgrading to ESLint v5, you may want to double-check that there are no typos in the paths you provide to ESLint. To make the error go away, you can simply remove the given files or globs from the list of arguments provided to ESLint on the command line. @@ -121,8 +121,8 @@ If you use a boilerplate generator that relies on this behavior (e.g. to generat ## The default options for some rules have changed -* The default options for the [`object-curly-newline`](/docs/rules/object-curly-newline) rule have changed from `{ multiline: true }` to `{ consistent: true }`. -* The default options object for the [`no-self-assign`](/docs/rules/no-self-assign) rule has changed from `{ props: false }` to `{ props: true }`. +* The default options for the [`object-curly-newline`](../rules/object-curly-newline) rule have changed from `{ multiline: true }` to `{ consistent: true }`. +* The default options object for the [`no-self-assign`](../rules/no-self-assign) rule has changed from `{ props: false }` to `{ props: true }`. **To address:** To restore the rule behavior from ESLint v4, you can update your config file to include the previous options: @@ -137,7 +137,7 @@ If you use a boilerplate generator that relies on this behavior (e.g. to generat ## Deprecated globals have been removed from the `node`, `browser`, and `jest` environments -Some global variables have been deprecated or removed for code running in Node.js, browsers, and Jest. (For example, browsers used to expose an `SVGAltGlyphElement` global variable to JavaScript code, but this global has been removed from web standards and is no longer present in browsers.) As a result, we have removed these globals from the corresponding `eslint` environments, so use of these globals will trigger an error when using rules such as [`no-undef`](/docs/rules/no-undef). +Some global variables have been deprecated or removed for code running in Node.js, browsers, and Jest. (For example, browsers used to expose an `SVGAltGlyphElement` global variable to JavaScript code, but this global has been removed from web standards and is no longer present in browsers.) As a result, we have removed these globals from the corresponding `eslint` environments, so use of these globals will trigger an error when using rules such as [`no-undef`](../rules/no-undef). **To address:** If you use deprecated globals in the `node`, `browser`, or `jest` environments, you can add a `globals` section to your configuration to re-enable any globals you need. For example: @@ -158,7 +158,7 @@ ESLint v4 had a special behavior when linting files that only contain whitespace ESLint v5 treats whitespace-only files the same way as all other files: it parses them and runs enabled rules on them as appropriate. This could lead to additional linting problems if you use a custom rule that reports errors on empty files. -**To address:** If you have an empty file in your project and you don't want it to be linted, consider adding it to an [`.eslintignore` file](/docs/user-guide/configuring#ignoring-files-and-directories). +**To address:** If you have an empty file in your project and you don't want it to be linted, consider adding it to an [`.eslintignore` file](configuring#ignoring-files-and-directories). If you have a custom rule, you should make sure it handles empty files appropriately. (In most cases, no changes should be necessary.) @@ -229,7 +229,7 @@ In ESLint v5, the `context.getScope()` method has the same behavior regardless o Previously, rule context objects had an undocumented `_linter` property, which was used internally within ESLint to process reports from rules. Some rules used this property to achieve functionality that was not intended to be possible for rules. For example, several plugins used the `_linter` property in a rule to monitor reports from other rules, for the purpose of checking for unused `/* eslint-disable */` directive comments. Although this functionality was useful for users, it could also cause stability problems for projects using ESLint. For example, an upgrade to a rule in one plugin could unexpectedly cause a rule in another plugin to start reporting errors. -The `_linter` property has been removed in ESLint v5.0, so it is no longer possible to implement rules with this functionality. However, the [`--report-unused-disable-directives`](/docs/user-guide/command-line-interface#--report-unused-disable-directives) CLI flag can be used to flag unused directive comments. +The `_linter` property has been removed in ESLint v5.0, so it is no longer possible to implement rules with this functionality. However, the [`--report-unused-disable-directives`](command-line-interface#--report-unused-disable-directives) CLI flag can be used to flag unused directive comments. ## `RuleTester` now uses strict equality checks in its assertions @@ -268,6 +268,6 @@ In ESLint v5, an unsuccessful linting run due to a fatal error will result in an ## The `eslint.linter` property is now non-enumerable -When using ESLint's Node.js API, the [`linter`](/docs/developer-guide/nodejs-api#linter-1) property is now non-enumerable. Note that the `linter` property was deprecated in ESLint v4 in favor of the [`Linter`](/docs/developer-guide/nodejs-api#linter) property. +When using ESLint's Node.js API, the [`linter`](../developer-guide/nodejs-api#linter-1) property is now non-enumerable. Note that the `linter` property was deprecated in ESLint v4 in favor of the [`Linter`](../developer-guide/nodejs-api#linter) property. **To address:** If you rely on enumerating all the properties of the `eslint` object, use something like `Object.getOwnPropertyNames` to ensure that non-enumerable keys are captured. diff --git a/docs/src/user-guide/migrating-to-6.0.0.md b/docs/src/user-guide/migrating-to-6.0.0.md index 4173e7deda7..36f67f16a07 100644 --- a/docs/src/user-guide/migrating-to-6.0.0.md +++ b/docs/src/user-guide/migrating-to-6.0.0.md @@ -51,19 +51,19 @@ As of April 2019, Node.js 6 will be at EOL and will no longer be receiving secur ## `eslint:recommended` has been updated -The following rules have been added to the [`eslint:recommended`](https://eslint.org/docs/user-guide/configuring#using-eslintrecommended) config: +The following rules have been added to the [`eslint:recommended`](../user-guide/configuring#using-eslintrecommended) config: -* [`no-async-promise-executor`](https://eslint.org/docs/rules/no-async-promise-executor) disallows using an `async` function as the argument to the `Promise` constructor, which is usually a bug. -* [`no-misleading-character-class`](https://eslint.org/docs/rules/no-misleading-character-class) reports character classes in regular expressions that might not behave as expected. -* [`no-prototype-builtins`](https://eslint.org/docs/rules/no-prototype-builtins) reports method calls like `foo.hasOwnProperty("bar")` (which are a frequent source of bugs), and suggests that they be replaced with `Object.prototype.hasOwnProperty.call(foo, "bar")` instead. -* [`no-shadow-restricted-names`](https://eslint.org/docs/rules/no-shadow-restricted-names) disallows shadowing variables like `undefined` (e.g. with code like `let undefined = 5;`), since is likely to confuse readers. -* [`no-useless-catch`](https://eslint.org/docs/rules/no-useless-catch) reports `catch` clauses that are redundant and can be removed from the code without changing its behavior. -* [`no-with`](https://eslint.org/docs/rules/no-with) disallows use of the [`with` statement](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with), which can make code difficult to understand and cause compatibility problems. -* [`require-atomic-updates`](https://eslint.org/docs/rules/require-atomic-updates) reports race condition bugs that can occur when reassigning variables in async functions. +* [`no-async-promise-executor`](../rules/no-async-promise-executor) disallows using an `async` function as the argument to the `Promise` constructor, which is usually a bug. +* [`no-misleading-character-class`](../rules/no-misleading-character-class) reports character classes in regular expressions that might not behave as expected. +* [`no-prototype-builtins`](../rules/no-prototype-builtins) reports method calls like `foo.hasOwnProperty("bar")` (which are a frequent source of bugs), and suggests that they be replaced with `Object.prototype.hasOwnProperty.call(foo, "bar")` instead. +* [`no-shadow-restricted-names`](../rules/no-shadow-restricted-names) disallows shadowing variables like `undefined` (e.g. with code like `let undefined = 5;`), since is likely to confuse readers. +* [`no-useless-catch`](../rules/no-useless-catch) reports `catch` clauses that are redundant and can be removed from the code without changing its behavior. +* [`no-with`](../rules/no-with) disallows use of the [`with` statement](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with), which can make code difficult to understand and cause compatibility problems. +* [`require-atomic-updates`](../rules/require-atomic-updates) reports race condition bugs that can occur when reassigning variables in async functions. Additionally, the following rule has been *removed* from `eslint:recommended`: -* [`no-console`](https://eslint.org/docs/rules/no-console) disallows calling functions like `console.log`. While this rule is useful in many cases (e.g. to avoid inadvertently leaving debugging statements in production code), it is not as broadly applicable as the other rules in `eslint:recommended`, and it was a source of false positives in cases where `console.log` is acceptable (e.g. in CLI applications). +* [`no-console`](../rules/no-console) disallows calling functions like `console.log`. While this rule is useful in many cases (e.g. to avoid inadvertently leaving debugging statements in production code), it is not as broadly applicable as the other rules in `eslint:recommended`, and it was a source of false positives in cases where `console.log` is acceptable (e.g. in CLI applications). Finally, in ESLint v5 `eslint:recommended` would explicitly disable all core rules that were not considered "recommended". This could cause confusing behavior if `eslint:recommended` was loaded after another config, since `eslint:recommended` would have the effect of turning off some rules. In ESLint v6, `eslint:recommended` has no effect on non-recommended rules. @@ -133,7 +133,7 @@ config | ESLint v5 | ESLint v6 ## The `no-redeclare` rule is now more strict by default -The default options for the [`no-redeclare`](https://eslint.org/docs/rules/no-redeclare) rule have changed from `{ builtinGlobals: false }` to `{ builtinGlobals: true }`. Additionally, the `no-redeclare` rule will now report an error for globals enabled by comments like `/* global foo */` if those globals were already enabled through configuration anyway. +The default options for the [`no-redeclare`](../rules/no-redeclare) rule have changed from `{ builtinGlobals: false }` to `{ builtinGlobals: true }`. Additionally, the `no-redeclare` rule will now report an error for globals enabled by comments like `/* global foo */` if those globals were already enabled through configuration anyway. **To address:** @@ -153,7 +153,7 @@ Additionally, if you see new errors for `global` comments in your code, you shou ## The `comma-dangle` rule is now more strict by default -Previously, the [`comma-dangle`](https://eslint.org/docs/rules/comma-dangle) rule would ignore trailing function arguments and parameters, unless explicitly configured to check for function commas. In ESLint v6, function commas are treated the same way as other types of trailing commas. +Previously, the [`comma-dangle`](../rules/comma-dangle) rule would ignore trailing function arguments and parameters, unless explicitly configured to check for function commas. In ESLint v6, function commas are treated the same way as other types of trailing commas. **To address:** You can restore the previous default behavior of the rule with: @@ -177,7 +177,7 @@ To restore the previous behavior of a string option like `"always-multiline"`, r ## The `no-confusing-arrow` rule is now more lenient by default -The default options for the [`no-confusing-arrow`](https://eslint.org/docs/rules/no-confusing-arrow) rule have changed from `{ allowParens: false }` to `{ allowParens: true }`. +The default options for the [`no-confusing-arrow`](../rules/no-confusing-arrow) rule have changed from `{ allowParens: false }` to `{ allowParens: true }`. **To address:** You can restore the previous default behavior of the rule with: @@ -195,7 +195,7 @@ The default options for the [`no-confusing-arrow`](https://eslint.org/docs/rules Due to a bug, the glob patterns in a `files` list in an `overrides` section of a config file would never match dotfiles, making it impossible to have overrides apply to files starting with a dot. This bug has been fixed in ESLint v6. -**To address:** If you don't want dotfiles to be matched by an override, consider adding something like `excludedFiles: [".*"]` to that `overrides` section. See the [documentation](https://eslint.org/docs/user-guide/configuring#configuration-based-on-glob-patterns) for more details. +**To address:** If you don't want dotfiles to be matched by an override, consider adding something like `excludedFiles: [".*"]` to that `overrides` section. See the [documentation](../user-guide/configuring#configuration-based-on-glob-patterns) for more details. **Related issue(s):** [eslint/eslint#11201](https://github.com/eslint/eslint/issues/11201) @@ -282,7 +282,7 @@ If you're not sure which config file needs to be updated, it may be useful to ru ## User-provided regular expressions in rule options are parsed with the unicode flag -Rules like [`max-len`](/docs/rules/max-len) accept a string option which is interpreted as a regular expression. In ESLint v6.0.0, these regular expressions are interpreted with the [unicode flag](https://mathiasbynens.be/notes/es6-unicode-regex), which should exhibit more reasonable behavior when matching characters like astral symbols. Unicode regexes also validate escape sequences more strictly than non-unicode regexes. +Rules like [`max-len`](../rules/max-len) accept a string option which is interpreted as a regular expression. In ESLint v6.0.0, these regular expressions are interpreted with the [unicode flag](https://mathiasbynens.be/notes/es6-unicode-regex), which should exhibit more reasonable behavior when matching characters like astral symbols. Unicode regexes also validate escape sequences more strictly than non-unicode regexes. **To address:** If you get rule option validation errors after upgrading, ensure that any regular expressions in your rule options have no invalid escape sequences. @@ -328,6 +328,6 @@ Previously, when linting code with a parser that had not been previously defined In ESLint v6, `Linter` will no longer perform any filesystem operations, including loading parsers. -**To address:** If you're using `Linter` with a custom parser, use [`Linter#defineParser`](https://eslint.org/docs/developer-guide/nodejs-api#linterdefineparser) to explicitly define the parser before linting any code. +**To address:** If you're using `Linter` with a custom parser, use [`Linter#defineParser`](../developer-guide/nodejs-api#linterdefineparser) to explicitly define the parser before linting any code. **Related issue(s):** [eslint/rfcs#7](https://github.com/eslint/rfcs/pull/7) diff --git a/docs/src/user-guide/migrating-to-7.0.0.md b/docs/src/user-guide/migrating-to-7.0.0.md index f8c6d7969ff..ecb959bb587 100644 --- a/docs/src/user-guide/migrating-to-7.0.0.md +++ b/docs/src/user-guide/migrating-to-7.0.0.md @@ -147,20 +147,20 @@ To allow for the colocation of comments that provide context with the directive, The ten Node.js/CommonJS rules in core have been deprecated and moved to the [eslint-plugin-node](https://github.com/mysticatea/eslint-plugin-node) plugin. -**To address:** As per [our deprecation policy](https://eslint.org/docs/user-guide/rule-deprecation), the deprecated rules will remain in core for the foreseeable future and are still available for use. However, we will no longer be updating or fixing any bugs in those rules. To use a supported version of the rules, we recommend using the corresponding rules in the plugin instead. +**To address:** As per [our deprecation policy](../user-guide/rule-deprecation), the deprecated rules will remain in core for the foreseeable future and are still available for use. However, we will no longer be updating or fixing any bugs in those rules. To use a supported version of the rules, we recommend using the corresponding rules in the plugin instead. | Deprecated Rules | Replacement | | :--------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------ | -| [callback-return](https://eslint.org/docs/rules/callback-return) | [node/callback-return](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/callback-return.md) | -| [global-require](https://eslint.org/docs/rules/global-require) | [node/global-require](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/global-require.md) | -| [handle-callback-err](https://eslint.org/docs/rules/handle-callback-err) | [node/handle-callback-err](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/handle-callback-err.md) | -| [no-mixed-requires](https://eslint.org/docs/rules/no-mixed-requires) | [node/no-mixed-requires](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-mixed-requires.md) | -| [no-new-require](https://eslint.org/docs/rules/no-new-require) | [node/no-new-require](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-new-require.md) | -| [no-path-concat](https://eslint.org/docs/rules/no-path-concat) | [node/no-path-concat](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-path-concat.md) | -| [no-process-env](https://eslint.org/docs/rules/no-process-env) | [node/no-process-env](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-process-env.md) | -| [no-process-exit](https://eslint.org/docs/rules/no-process-exit) | [node/no-process-exit](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-process-exit.md) | -| [no-restricted-modules](https://eslint.org/docs/rules/no-restricted-modules) | [node/no-restricted-require](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-restricted-require.md) | -| [no-sync](https://eslint.org/docs/rules/no-sync) | [node/no-sync](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-sync.md) | +| [callback-return](../rules/callback-return) | [node/callback-return](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/callback-return.md) | +| [global-require](../rules/global-require) | [node/global-require](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/global-require.md) | +| [handle-callback-err](../rules/handle-callback-err) | [node/handle-callback-err](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/handle-callback-err.md) | +| [no-mixed-requires](../rules/no-mixed-requires) | [node/no-mixed-requires](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-mixed-requires.md) | +| [no-new-require](../rules/no-new-require) | [node/no-new-require](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-new-require.md) | +| [no-path-concat](../rules/no-path-concat) | [node/no-path-concat](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-path-concat.md) | +| [no-process-env](../rules/no-process-env) | [node/no-process-env](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-process-env.md) | +| [no-process-exit](../rules/no-process-exit) | [node/no-process-exit](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-process-exit.md) | +| [no-restricted-modules](../rules/no-restricted-modules) | [node/no-restricted-require](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-restricted-require.md) | +| [no-sync](../rules/no-sync) | [node/no-sync](https://github.com/mysticatea/eslint-plugin-node/blob/v11.1.0/docs/rules/no-sync.md) | **Related issue(s):** [#12898](https://github.com/eslint/eslint/pull/12898) @@ -168,16 +168,16 @@ The ten Node.js/CommonJS rules in core have been deprecated and moved to the [es Several rules have been enhanced and now report additional errors: -* [accessor-pairs](https://eslint.org/docs/rules/accessor-pairs) rule now recognizes class members by default. -* [array-callback-return](https://eslint.org/docs/rules/array-callback-return) rule now recognizes `flatMap` method. -* [computed-property-spacing](https://eslint.org/docs/rules/computed-property-spacing) rule now recognizes class members by default. -* [func-names](https://eslint.org/docs/rules/func-names) rule now recognizes function declarations in default exports. -* [no-extra-parens](https://eslint.org/docs/rules/no-extra-parens) rule now recognizes parentheses in assignment targets. -* [no-dupe-class-members](https://eslint.org/docs/rules/no-dupe-class-members) rule now recognizes computed keys for static class members. -* [no-magic-numbers](https://eslint.org/docs/rules/no-magic-numbers) rule now recognizes bigint literals. -* [radix](https://eslint.org/docs/rules/radix) rule now recognizes invalid numbers for the second parameter of `parseInt()`. -* [use-isnan](https://eslint.org/docs/rules/use-isnan) rule now recognizes class members by default. -* [yoda](https://eslint.org/docs/rules/yoda) rule now recognizes bigint literals. +* [accessor-pairs](../rules/accessor-pairs) rule now recognizes class members by default. +* [array-callback-return](../rules/array-callback-return) rule now recognizes `flatMap` method. +* [computed-property-spacing](../rules/computed-property-spacing) rule now recognizes class members by default. +* [func-names](../rules/func-names) rule now recognizes function declarations in default exports. +* [no-extra-parens](../rules/no-extra-parens) rule now recognizes parentheses in assignment targets. +* [no-dupe-class-members](../rules/no-dupe-class-members) rule now recognizes computed keys for static class members. +* [no-magic-numbers](../rules/no-magic-numbers) rule now recognizes bigint literals. +* [radix](../rules/radix) rule now recognizes invalid numbers for the second parameter of `parseInt()`. +* [use-isnan](../rules/use-isnan) rule now recognizes class members by default. +* [yoda](../rules/yoda) rule now recognizes bigint literals. **To address:** Fix errors or disable these rules. @@ -187,9 +187,9 @@ Several rules have been enhanced and now report additional errors: Three new rules have been enabled in the `eslint:recommended` preset. -* [no-dupe-else-if](https://eslint.org/docs/rules/no-dupe-else-if) -* [no-import-assign](https://eslint.org/docs/rules/no-import-assign) -* [no-setter-return](https://eslint.org/docs/rules/no-setter-return) +* [no-dupe-else-if](../rules/no-dupe-else-if) +* [no-import-assign](../rules/no-import-assign) +* [no-setter-return](../rules/no-setter-return) **To address:** Fix errors or disable these rules. @@ -209,7 +209,7 @@ The `RuleTester` now validates the following: ## The `CLIEngine` class has been deprecated -The [`CLIEngine` class](https://eslint.org/docs/developer-guide/nodejs-api#cliengine) has been deprecated and replaced by the new [`ESLint` class](https://eslint.org/docs/developer-guide/nodejs-api#eslint-class). +The [`CLIEngine` class](../developer-guide/nodejs-api#cliengine) has been deprecated and replaced by the new [`ESLint` class](../developer-guide/nodejs-api#eslint-class). The `CLIEngine` class provides a synchronous API that is blocking the implementation of features such as parallel linting, supporting ES modules in shareable configs/parsers/plugins/formatters, and adding the ability to visually display the progress of linting runs. The new `ESLint` class provides an asynchronous API that ESLint core will now using going forward. `CLIEngine` will remain in core for the foreseeable future but may be removed in a future major version. diff --git a/docs/src/user-guide/migrating-to-8.0.0.md b/docs/src/user-guide/migrating-to-8.0.0.md index 43f54b4b027..f28f15ccbd1 100644 --- a/docs/src/user-guide/migrating-to-8.0.0.md +++ b/docs/src/user-guide/migrating-to-8.0.0.md @@ -109,10 +109,10 @@ In ESLint v7.0.0, using both `--report-unused-disable-directives` and `--fix` on Four new rules have been enabled in the `eslint:recommended` preset. -* [`no-loss-of-precision`](https://eslint.org/docs/rules/no-loss-of-precision) -* [`no-nonoctal-decimal-escape`](https://eslint.org/docs/rules/no-nonoctal-decimal-escape) -* [`no-unsafe-optional-chaining`](https://eslint.org/docs/rules/no-unsafe-optional-chaining) -* [`no-useless-backreference`](https://eslint.org/docs/rules/no-useless-backreference) +* [`no-loss-of-precision`](../rules/no-loss-of-precision) +* [`no-nonoctal-decimal-escape`](../rules/no-nonoctal-decimal-escape) +* [`no-unsafe-optional-chaining`](../rules/no-unsafe-optional-chaining) +* [`no-useless-backreference`](../rules/no-useless-backreference) **To address:** Fix errors or disable these rules. @@ -120,7 +120,7 @@ Four new rules have been enabled in the `eslint:recommended` preset. ## Rules require `meta.hasSuggestions` to provide suggestions -In ESLint v7.0.0, rules that [provided suggestions](https://eslint.org/docs/developer-guide/working-with-rules#providing-suggestions) did not need to let ESLint know. In v8.0.0, rules providing suggestions need to set their `meta.hasSuggestions` to `true`. This informs ESLint that the rule intends to provide suggestions. Without this property, any attempt to provide a suggestion will result in an error. +In ESLint v7.0.0, rules that [provided suggestions](../developer-guide/working-with-rules#providing-suggestions) did not need to let ESLint know. In v8.0.0, rules providing suggestions need to set their `meta.hasSuggestions` to `true`. This informs ESLint that the rule intends to provide suggestions. Without this property, any attempt to provide a suggestion will result in an error. **To address:** If your rule provides suggestions, add `meta.hasSuggestions` to the object, such as: @@ -168,7 +168,7 @@ The [eslint-plugin/require-meta-fixable](https://github.com/not-an-aardvark/esli The [eslint-plugin/prefer-object-rule](https://github.com/not-an-aardvark/eslint-plugin-eslint-plugin/blob/master/docs/rules/prefer-object-rule.md) rule can automatically fix and enforce that your rules are written with the object format instead of the deprecated function format. -See the [rule documentation](https://eslint.org/docs/developer-guide/working-with-rules) for more information on writing rules. +See the [rule documentation](../developer-guide/working-with-rules) for more information on writing rules. **Related issue(s):** [#13349](https://github.com/eslint/eslint/issues/13349) @@ -178,7 +178,7 @@ Back in ESLint v4.0.0, we deprecated `SourceCode#getComments()`, but we neglecte The `SourceCode#getComments()` method will be removed in v9.0.0. -**To address:** If your rule uses `SourceCode#getComments()`, please use [`SourceCode#getCommentsBefore()`, `SourceCode#getCommentsAfter()`, or `SourceCode#getCommentsInside()`](https://eslint.org/docs/developer-guide/working-with-rules#sourcecodegetcommentsbefore-sourcecodegetcommentsafter-and-sourcecodegetcommentsinside). +**To address:** If your rule uses `SourceCode#getComments()`, please use [`SourceCode#getCommentsBefore()`, `SourceCode#getCommentsAfter()`, or `SourceCode#getCommentsInside()`](../developer-guide/working-with-rules#sourcecodegetcommentsbefore-sourcecodegetcommentsafter-and-sourcecodegetcommentsinside). **Related issue(s):** [#14744](https://github.com/eslint/eslint/issues/14744) @@ -233,7 +233,7 @@ In ESLint v8.0.0 (via Acorn v8.0.0), the key and value are now separate objects ## The `CLIEngine` class has been removed -The `CLIEngine` class has been removed and replaced by the [`ESLint` class](https://eslint.org/docs/developer-guide/nodejs-api#eslint-class). +The `CLIEngine` class has been removed and replaced by the [`ESLint` class](../developer-guide/nodejs-api#eslint-class). **To address:** Update your code to use the new `ESLint` class if you are currently using `CLIEngine`. The following table maps the existing `CLIEngine` methods to their `ESLint` counterparts: