diff --git a/docs/src/user-guide/configuring/configuration-files.md b/docs/src/user-guide/configuring/configuration-files.md index 24a92bb1483a..458ef827402a 100644 --- a/docs/src/user-guide/configuring/configuration-files.md +++ b/docs/src/user-guide/configuring/configuration-files.md @@ -7,26 +7,17 @@ eleventyNavigation: parent: configuring title: Configuration Files order: 1 - --- -* [Configuration File Formats](#configuration-file-formats) -* [Using Configuration Files](#using-configuration-files) -* [Adding Shared Settings](#adding-shared-settings) -* [Cascading and Hierarchy](#cascading-and-hierarchy) -* [Extending Configuration Files](#extending-configuration-files) -* [Configuration Based on Glob Patterns](#configuration-based-on-glob-patterns) -* [Personal Configuration Files](#personal-configuration-files-deprecated) - ## Configuration File Formats ESLint supports configuration files in several formats: -* **JavaScript** - use `.eslintrc.js` and export an object containing your configuration. -* **JavaScript (ESM)** - use `.eslintrc.cjs` when running ESLint in JavaScript packages that specify `"type":"module"` in their `package.json`. Note that ESLint does not support ESM configuration at this time. -* **YAML** - use `.eslintrc.yaml` or `.eslintrc.yml` to define the configuration structure. -* **JSON** - use `.eslintrc.json` to define the configuration structure. ESLint's JSON files also allow JavaScript-style comments. -* **package.json** - create an `eslintConfig` property in your `package.json` file and define your configuration there. +* **JavaScript** - use `.eslintrc.js` and export an object containing your configuration. +* **JavaScript (ESM)** - use `.eslintrc.cjs` when running ESLint in JavaScript packages that specify `"type":"module"` in their `package.json`. Note that ESLint does not support ESM configuration at this time. +* **YAML** - use `.eslintrc.yaml` or `.eslintrc.yml` to define the configuration structure. +* **JSON** - use `.eslintrc.json` to define the configuration structure. ESLint's JSON files also allow JavaScript-style comments. +* **package.json** - create an `eslintConfig` property in your `package.json` file and define your configuration there. If there are multiple configuration files in the same directory, ESLint will only use one. The priority order is as follows: @@ -54,21 +45,16 @@ Here's an example JSON configuration file that uses the `typescript-eslint` pars ```json { "root": true, - "extends": [ - "eslint:recommended", - "plugin:@typescript-eslint/recommended" - ], + "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"], "parser": "@typescript-eslint/parser", "parserOptions": { "project": ["./tsconfig.json"] }, - "plugins": [ - "@typescript-eslint" - ], + "plugins": ["@typescript-eslint"], "rules": { "@typescript-eslint/strict-boolean-expressions": [ 2, { - "allowString" : false, - "allowNumber" : false + "allowString": false, + "allowNumber": false } ] }, @@ -124,7 +110,7 @@ And in YAML: ```yaml --- - settings: +settings: sharedData: "Hello" ``` @@ -170,10 +156,10 @@ And in YAML: ```yaml --- - root: true +root: true ``` -For example, consider `projectA` which has `"root": true` set in the `.eslintrc` file in the `lib/` directory. In this case, while linting `main.js`, the configurations within `lib/` will be used, but the `.eslintrc` file in `projectA/` will not. +For example, consider `projectA` which has `"root": true` set in the `.eslintrc` file in the `lib/` directory. In this case, while linting `main.js`, the configurations within `lib/` will be used, but the `.eslintrc` file in `projectA/` will not. ```text home @@ -207,14 +193,14 @@ Please note that the [home directory of the current user on your preferred opera A configuration file, once extended, can inherit all the traits of another configuration file (including rules, plugins, and language options) and modify all the options. As a result, there are three configurations, as defined below: -* Base config: the configuration that is extended. -* Derived config: the configuration that extends the base configuration. -* Resulting actual config: the result of merging the derived configuration into the base configuration. +* Base config: the configuration that is extended. +* Derived config: the configuration that extends the base configuration. +* Resulting actual config: the result of merging the derived configuration into the base configuration. The `extends` property value is either: -* a string that specifies a configuration (either a path to a config file, the name of a shareable config, `eslint:recommended`, or `eslint:all`) -* an array of strings where each additional configuration extends the preceding configurations +* a string that specifies a configuration (either a path to a config file, the name of a shareable config, `eslint:recommended`, or `eslint:all`) +* an array of strings where each additional configuration extends the preceding configurations ESLint extends configurations recursively, so a base configuration can also have an `extends` property. Relative paths and shareable config names in an `extends` property are resolved from the location of the config file where they appear. @@ -222,19 +208,19 @@ The `eslint-config-` prefix can be omitted from the configuration name. For exam The `rules` property can do any of the following to extend (or override) the set of rules: -* enable additional rules -* change an inherited rule's severity without changing its options: - * Base config: `"eqeqeq": ["error", "allow-null"]` - * Derived config: `"eqeqeq": "warn"` - * Resulting actual config: `"eqeqeq": ["warn", "allow-null"]` -* override options for rules from base configurations: - * Base config: `"quotes": ["error", "single", "avoid-escape"]` - * Derived config: `"quotes": ["error", "single"]` - * Resulting actual config: `"quotes": ["error", "single"]` -* override options for rules given as object from base configurations: - * Base config: `"max-lines": ["error", { "max": 200, "skipBlankLines": true, "skipComments": true }]` - * Derived config: `"max-lines": ["error", { "max": 100 }]` - * Resulting actual config: `"max-lines": ["error", { "max": 100 }]` where `skipBlankLines` and `skipComments` default to `false` +* enable additional rules +* change an inherited rule's severity without changing its options: + * Base config: `"eqeqeq": ["error", "allow-null"]` + * Derived config: `"eqeqeq": "warn"` + * Resulting actual config: `"eqeqeq": ["warn", "allow-null"]` +* override options for rules from base configurations: + * Base config: `"quotes": ["error", "single", "avoid-escape"]` + * Derived config: `"quotes": ["error", "single"]` + * Resulting actual config: `"quotes": ["error", "single"]` +* override options for rules given as object from base configurations: + * Base config: `"max-lines": ["error", { "max": 200, "skipBlankLines": true, "skipComments": true }]` + * Derived config: `"max-lines": ["error", { "max": 100 }]` + * Resulting actual config: `"max-lines": ["error", { "max": 100 }]` where `skipBlankLines` and `skipComments` default to `false` ### Using a shareable configuration package @@ -249,10 +235,10 @@ Example of a configuration file in YAML format: ```yaml extends: standard rules: - comma-dangle: - - error - - always - no-empty: warn + comma-dangle: + - error + - always + no-empty: warn ``` ### Using `eslint:recommended` @@ -265,22 +251,22 @@ Example of a configuration file in JavaScript format: ```js module.exports = { - "extends": "eslint:recommended", - "rules": { + extends: "eslint:recommended", + rules: { // enable additional rules - "indent": ["error", 4], + indent: ["error", 4], "linebreak-style": ["error", "unix"], - "quotes": ["error", "double"], - "semi": ["error", "always"], + quotes: ["error", "double"], + semi: ["error", "always"], // override configuration set by extending "eslint:recommended" "no-empty": "warn", "no-cond-assign": ["error", "always"], // disable rules from base configurations - "for-direction": "off", - } -} + "for-direction": "off", + }, +}; ``` ### Using a configuration from a plugin @@ -291,24 +277,19 @@ The `plugins` [property value](./plugins#configuring-plugins) can omit the `esli The `extends` property value can consist of: -* `plugin:` -* the package name (from which you can omit the prefix, for example, `react` is short for `eslint-plugin-react`) -* `/` -* the configuration name (for example, `recommended`) +* `plugin:` +* the package name (from which you can omit the prefix, for example, `react` is short for `eslint-plugin-react`) +* `/` +* the configuration name (for example, `recommended`) Example of a configuration file in JSON format: ```json { - "plugins": [ - "react" - ], - "extends": [ - "eslint:recommended", - "plugin:react/recommended" - ], + "plugins": ["react"], + "extends": ["eslint:recommended", "plugin:react/recommended"], "rules": { - "react/no-set-state": "off" + "react/no-set-state": "off" } } ``` @@ -346,11 +327,11 @@ Example of a configuration file in JavaScript format: ```js module.exports = { - "extends": "eslint:all", - "rules": { + extends: "eslint:all", + rules: { // override default options "comma-dangle": ["error", "always"], - "indent": ["error", 2], + indent: ["error", 2], "no-cond-assign": ["error", "always"], // disable now, but enable in the future @@ -360,8 +341,8 @@ module.exports = { "init-declarations": "off", "no-console": "off", "no-inline-comments": "off", - } -} + }, +}; ``` ## Configuration Based on Glob Patterns @@ -378,31 +359,31 @@ In your `.eslintrc.json`: ```json { - "rules": { - "quotes": ["error", "double"] - }, - - "overrides": [ - { - "files": ["bin/*.js", "lib/*.js"], - "excludedFiles": "*.test.js", - "rules": { - "quotes": ["error", "single"] - } - } - ] + "rules": { + "quotes": ["error", "double"] + }, + + "overrides": [ + { + "files": ["bin/*.js", "lib/*.js"], + "excludedFiles": "*.test.js", + "rules": { + "quotes": ["error", "single"] + } + } + ] } ``` Here is how overrides work in a configuration file: -* The patterns are applied against the file path relative to the directory of the config file. For example, if your config file has the path `/Users/john/workspace/any-project/.eslintrc.js` and the file you want to lint has the path `/Users/john/workspace/any-project/lib/util.js`, then the pattern provided in `.eslintrc.js` will be executed against the relative path `lib/util.js`. -* Glob pattern overrides have higher precedence than the regular configuration in the same config file. Multiple overrides within the same config are applied in order. That is, the last override block in a config file always has the highest precedence. -* A glob specific configuration works almost the same as any other ESLint config. Override blocks can contain any configuration options that are valid in a regular config, with the exception of `root` and `ignorePatterns`. - * A glob specific configuration can have an `extends` setting, but the `root` property in the extended configs is ignored. The `ignorePatterns` property in the extended configs is used only for the files the glob specific configuration matched. - * Nested `overrides` setting will be applied only if the glob patterns of both of the parent config and the child config matched. This is the same when the extended configs have an `overrides` setting. -* Multiple glob patterns can be provided within a single override block. A file must match at least one of the supplied patterns for the configuration to apply. -* Override blocks can also specify patterns to exclude from matches. If a file matches any of the excluded patterns, the configuration won't apply. +* The patterns are applied against the file path relative to the directory of the config file. For example, if your config file has the path `/Users/john/workspace/any-project/.eslintrc.js` and the file you want to lint has the path `/Users/john/workspace/any-project/lib/util.js`, then the pattern provided in `.eslintrc.js` will be executed against the relative path `lib/util.js`. +* Glob pattern overrides have higher precedence than the regular configuration in the same config file. Multiple overrides within the same config are applied in order. That is, the last override block in a config file always has the highest precedence. +* A glob specific configuration works almost the same as any other ESLint config. Override blocks can contain any configuration options that are valid in a regular config, with the exception of `root` and `ignorePatterns`. + * A glob specific configuration can have an `extends` setting, but the `root` property in the extended configs is ignored. The `ignorePatterns` property in the extended configs is used only for the files the glob specific configuration matched. + * Nested `overrides` setting will be applied only if the glob patterns of both of the parent config and the child config matched. This is the same when the extended configs have an `overrides` setting. +* Multiple glob patterns can be provided within a single override block. A file must match at least one of the supplied patterns for the configuration to apply. +* Override blocks can also specify patterns to exclude from matches. If a file matches any of the excluded patterns, the configuration won't apply. ### Relative glob patterns diff --git a/docs/src/user-guide/configuring/ignoring-code.md b/docs/src/user-guide/configuring/ignoring-code.md index db988459d5dd..2d10e6312090 100644 --- a/docs/src/user-guide/configuring/ignoring-code.md +++ b/docs/src/user-guide/configuring/ignoring-code.md @@ -7,15 +7,8 @@ eleventyNavigation: parent: configuring title: Ignoring Code order: 5 - --- -* [`ignorePatterns` in Config Files](#ignorepatterns-in-config-files) -* [The `.eslintignore` File](#the-eslintignore-file) -* [Using an Alternate File](#using-an-alternate-file) -* [Using eslintIgnore in package.json](#using-eslintignore-in-packagejson) -* [Ignored File Warnings](#ignored-file-warnings) - ## `ignorePatterns` in Config Files You can tell ESLint to ignore specific files and directories using `ignorePatterns` in your config files. `ignorePatterns` patterns follow the same rules as `.eslintignore`. Please see the [the `.eslintignore` file documentation](./ignoring-code#the-eslintignore-file) to learn more. @@ -29,9 +22,9 @@ You can tell ESLint to ignore specific files and directories using `ignorePatter } ``` -* Glob patterns in `ignorePatterns` are relative to the directory that the config file is placed in. -* You cannot write `ignorePatterns` property under `overrides` property. -* Patterns defined in `.eslintignore` take precedence over the `ignorePatterns` property of config files. +* Glob patterns in `ignorePatterns` are relative to the directory that the config file is placed in. +* You cannot write `ignorePatterns` property under `overrides` property. +* Patterns defined in `.eslintignore` take precedence over the `ignorePatterns` property of config files. If a glob pattern starts with `/`, the pattern is relative to the base directory of the config file. For example, `/foo.js` in `lib/.eslintrc.json` matches to `lib/foo.js` but not `lib/subdir/foo.js`. @@ -49,10 +42,10 @@ When ESLint is run, it looks in the current working directory to find an `.eslin Globs are matched using [node-ignore](https://github.com/kaelzhang/node-ignore), so a number of features are available: -* Lines beginning with `#` are treated as comments and do not affect the ignore patterns. -* Paths are relative to the current working directory. This is also true of paths passed in via the `--ignore-pattern` [command](../command-line-interface#--ignore-pattern). -* Lines preceded by `!` are negated patterns that re-include a pattern that was ignored by an earlier pattern. -* Ignore patterns behave according to the `.gitignore` [specification](https://git-scm.com/docs/gitignore). +* Lines beginning with `#` are treated as comments and do not affect the ignore patterns. +* Paths are relative to the current working directory. This is also true of paths passed in via the `--ignore-pattern` [command](../command-line-interface#--ignore-pattern). +* Lines preceded by `!` are negated patterns that re-include a pattern that was ignored by an earlier pattern. +* Ignore patterns behave according to the `.gitignore` [specification](https://git-scm.com/docs/gitignore). Of particular note is that like `.gitignore` files, all paths used as patterns for both `.eslintignore` and `--ignore-pattern` must use forward slashes as their path separators. @@ -68,34 +61,34 @@ Please see [`.gitignore`](https://git-scm.com/docs/gitignore)'s specification fo In addition to any patterns in the `.eslintignore` file, ESLint always follows a couple of implicit ignore rules even if the `--no-ignore` flag is passed. The implicit rules are as follows: -* `node_modules/` is ignored. -* dot-files (except for `.eslintrc.*`), as well as dot-folders and their contents, are ignored. +* `node_modules/` is ignored. +* dot-files (except for `.eslintrc.*`), as well as dot-folders and their contents, are ignored. There are also some exceptions to these rules: -* If the path to lint is a glob pattern or directory path and contains a dot-folder, all dot-files and dot-folders will be linted. This includes dot-files and dot-folders that are buried deeper in the directory structure. +* If the path to lint is a glob pattern or directory path and contains a dot-folder, all dot-files and dot-folders will be linted. This includes dot-files and dot-folders that are buried deeper in the directory structure. - For example, `eslint .config/` will lint all dot-folders and dot-files in the `.config` directory, including immediate children as well as children that are deeper in the directory structure. + For example, `eslint .config/` will lint all dot-folders and dot-files in the `.config` directory, including immediate children as well as children that are deeper in the directory structure. -* If the path to lint is a specific file path and the `--no-ignore` flag has been passed, ESLint will lint the file regardless of the implicit ignore rules. +* If the path to lint is a specific file path and the `--no-ignore` flag has been passed, ESLint will lint the file regardless of the implicit ignore rules. - For example, `eslint .config/my-config-file.js --no-ignore` will cause `my-config-file.js` to be linted. It should be noted that the same command without the `--no-ignore` line will not lint the `my-config-file.js` file. + For example, `eslint .config/my-config-file.js --no-ignore` will cause `my-config-file.js` to be linted. It should be noted that the same command without the `--no-ignore` line will not lint the `my-config-file.js` file. -* Allowlist and denylist rules specified via `--ignore-pattern` or `.eslintignore` are prioritized above implicit ignore rules. +* Allowlist and denylist rules specified via `--ignore-pattern` or `.eslintignore` are prioritized above implicit ignore rules. - For example, in this scenario, `.build/test.js` is the desired file to allowlist. Because all dot-folders and their children are ignored by default, `.build` must first be allowlisted so that eslint becomes aware of its children. Then, `.build/test.js` must be explicitly allowlisted, while the rest of the content is denylisted. This is done with the following `.eslintignore` file: + For example, in this scenario, `.build/test.js` is the desired file to allowlist. Because all dot-folders and their children are ignored by default, `.build` must first be allowlisted so that eslint becomes aware of its children. Then, `.build/test.js` must be explicitly allowlisted, while the rest of the content is denylisted. This is done with the following `.eslintignore` file: - ```text - # Allowlist 'test.js' in the '.build' folder - # But do not allow anything else in the '.build' folder to be linted - !.build - .build/* - !.build/test.js - ``` + ```text + # Allowlist 'test.js' in the '.build' folder + # But do not allow anything else in the '.build' folder to be linted + !.build + .build/* + !.build/test.js + ``` - The following `--ignore-pattern` is also equivalent: + The following `--ignore-pattern` is also equivalent: - eslint --ignore-pattern '!.build' --ignore-pattern '.build/*' --ignore-pattern '!.build/test.js' parent-folder/ + eslint --ignore-pattern '!.build' --ignore-pattern '.build/*' --ignore-pattern '!.build/test.js' parent-folder/ ## Using an Alternate File diff --git a/docs/src/user-guide/configuring/language-options.md b/docs/src/user-guide/configuring/language-options.md index 5397d8395e4f..29f465162880 100644 --- a/docs/src/user-guide/configuring/language-options.md +++ b/docs/src/user-guide/configuring/language-options.md @@ -7,49 +7,44 @@ eleventyNavigation: parent: configuring title: Configuring Language Options order: 2 - --- -* [Specifying Environments](#specifying-environments) -* [Specifying Globals](#specifying-globals) -* [Specifying Parser Options](#specifying-parser-options) - ## Specifying Environments An environment provides predefined global variables. The available environments are: -* `browser` - browser global variables. -* `node` - Node.js global variables and Node.js scoping. -* `commonjs` - CommonJS global variables and CommonJS scoping (use this for browser-only code that uses Browserify/WebPack). -* `shared-node-browser` - Globals common to both Node.js and Browser. -* `es6` - enable all ECMAScript 6 features except for modules (this automatically sets the `ecmaVersion` parser option to 6). -* `es2016` - adds all ECMAScript 2016 globals and automatically sets the `ecmaVersion` parser option to 7. -* `es2017` - adds all ECMAScript 2017 globals and automatically sets the `ecmaVersion` parser option to 8. -* `es2018` - adds all ECMAScript 2018 globals and automatically sets the `ecmaVersion` parser option to 9. -* `es2019` - adds all ECMAScript 2019 globals and automatically sets the `ecmaVersion` parser option to 10. -* `es2020` - adds all ECMAScript 2020 globals and automatically sets the `ecmaVersion` parser option to 11. -* `es2021` - adds all ECMAScript 2021 globals and automatically sets the `ecmaVersion` parser option to 12. -* `es2022` - adds all ECMAScript 2022 globals and automatically sets the `ecmaVersion` parser option to 13. -* `worker` - web workers global variables. -* `amd` - defines `require()` and `define()` as global variables as per the [amd](https://github.com/amdjs/amdjs-api/wiki/AMD) spec. -* `mocha` - adds all of the Mocha testing global variables. -* `jasmine` - adds all of the Jasmine testing global variables for version 1.3 and 2.0. -* `jest` - Jest global variables. -* `phantomjs` - PhantomJS global variables. -* `protractor` - Protractor global variables. -* `qunit` - QUnit global variables. -* `jquery` - jQuery global variables. -* `prototypejs` - Prototype.js global variables. -* `shelljs` - ShellJS global variables. -* `meteor` - Meteor global variables. -* `mongo` - MongoDB global variables. -* `applescript` - AppleScript global variables. -* `nashorn` - Java 8 Nashorn global variables. -* `serviceworker` - Service Worker global variables. -* `atomtest` - Atom test helper globals. -* `embertest` - Ember test helper globals. -* `webextensions` - WebExtensions globals. -* `greasemonkey` - GreaseMonkey globals. +* `browser` - browser global variables. +* `node` - Node.js global variables and Node.js scoping. +* `commonjs` - CommonJS global variables and CommonJS scoping (use this for browser-only code that uses Browserify/WebPack). +* `shared-node-browser` - Globals common to both Node.js and Browser. +* `es6` - enable all ECMAScript 6 features except for modules (this automatically sets the `ecmaVersion` parser option to 6). +* `es2016` - adds all ECMAScript 2016 globals and automatically sets the `ecmaVersion` parser option to 7. +* `es2017` - adds all ECMAScript 2017 globals and automatically sets the `ecmaVersion` parser option to 8. +* `es2018` - adds all ECMAScript 2018 globals and automatically sets the `ecmaVersion` parser option to 9. +* `es2019` - adds all ECMAScript 2019 globals and automatically sets the `ecmaVersion` parser option to 10. +* `es2020` - adds all ECMAScript 2020 globals and automatically sets the `ecmaVersion` parser option to 11. +* `es2021` - adds all ECMAScript 2021 globals and automatically sets the `ecmaVersion` parser option to 12. +* `es2022` - adds all ECMAScript 2022 globals and automatically sets the `ecmaVersion` parser option to 13. +* `worker` - web workers global variables. +* `amd` - defines `require()` and `define()` as global variables as per the [amd](https://github.com/amdjs/amdjs-api/wiki/AMD) spec. +* `mocha` - adds all of the Mocha testing global variables. +* `jasmine` - adds all of the Jasmine testing global variables for version 1.3 and 2.0. +* `jest` - Jest global variables. +* `phantomjs` - PhantomJS global variables. +* `protractor` - Protractor global variables. +* `qunit` - QUnit global variables. +* `jquery` - jQuery global variables. +* `prototypejs` - Prototype.js global variables. +* `shelljs` - ShellJS global variables. +* `meteor` - Meteor global variables. +* `mongo` - MongoDB global variables. +* `applescript` - AppleScript global variables. +* `nashorn` - Java 8 Nashorn global variables. +* `serviceworker` - Service Worker global variables. +* `atomtest` - Atom test helper globals. +* `embertest` - Ember test helper globals. +* `webextensions` - WebExtensions globals. +* `greasemonkey` - GreaseMonkey globals. These environments are not mutually exclusive, so you can define more than one at a time. @@ -97,7 +92,7 @@ And in YAML: ```yaml --- - env: +env: browser: true node: true ``` @@ -165,7 +160,7 @@ And in YAML: ```yaml --- - globals: +globals: var1: writable var2: readonly ``` @@ -194,18 +189,17 @@ ESLint allows you to specify the JavaScript language options you want to support Please note that supporting JSX syntax is not the same as supporting React. React applies specific semantics to JSX syntax that ESLint doesn't recognize. We recommend using [eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react) if you are using React and want React semantics. By the same token, supporting ES6 syntax is not the same as supporting new ES6 globals (e.g., new types such as `Set`). -For ES6 syntax, use `{ "parserOptions": { "ecmaVersion": 6 } }`; for new ES6 global variables, use `{ "env": -{ "es6": true } }`. `{ "env": { "es6": true } }` enables ES6 syntax automatically, but `{ "parserOptions": { "ecmaVersion": 6 } }` does not enable ES6 globals automatically. +For ES6 syntax, use `{ "parserOptions": { "ecmaVersion": 6 } }`; for new ES6 global variables, use `{ "env": { "es6": true } }`. `{ "env": { "es6": true } }` enables ES6 syntax automatically, but `{ "parserOptions": { "ecmaVersion": 6 } }` does not enable ES6 globals automatically. Parser options are set in your `.eslintrc.*` file by using the `parserOptions` property. The available options are: -* `ecmaVersion` - set to 3, 5 (default), 6, 7, 8, 9, 10, 11, 12, or 13 to specify the version of ECMAScript syntax you want to use. You can also set to 2015 (same as 6), 2016 (same as 7), 2017 (same as 8), 2018 (same as 9), 2019 (same as 10), 2020 (same as 11), 2021 (same as 12), or 2022 (same as 13) to use the year-based naming. You can also set "latest" to use the most recently supported version. -* `sourceType` - set to `"script"` (default) or `"module"` if your code is in ECMAScript modules. -* `allowReserved` - allow the use of reserved words as identifiers (if `ecmaVersion` is 3). -* `ecmaFeatures` - an object indicating which additional language features you'd like to use: - * `globalReturn` - allow `return` statements in the global scope - * `impliedStrict` - enable global [strict mode](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode) (if `ecmaVersion` is 5 or greater) - * `jsx` - enable [JSX](https://facebook.github.io/jsx/) +* `ecmaVersion` - set to 3, 5 (default), 6, 7, 8, 9, 10, 11, 12, or 13 to specify the version of ECMAScript syntax you want to use. You can also set to 2015 (same as 6), 2016 (same as 7), 2017 (same as 8), 2018 (same as 9), 2019 (same as 10), 2020 (same as 11), 2021 (same as 12), or 2022 (same as 13) to use the year-based naming. You can also set "latest" to use the most recently supported version. +* `sourceType` - set to `"script"` (default) or `"module"` if your code is in ECMAScript modules. +* `allowReserved` - allow the use of reserved words as identifiers (if `ecmaVersion` is 3). +* `ecmaFeatures` - an object indicating which additional language features you'd like to use: + * `globalReturn` - allow `return` statements in the global scope + * `impliedStrict` - enable global [strict mode](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode) (if `ecmaVersion` is 5 or greater) + * `jsx` - enable [JSX](https://facebook.github.io/jsx/) Here's an example `.eslintrc.json` file: diff --git a/docs/src/user-guide/configuring/plugins.md b/docs/src/user-guide/configuring/plugins.md index 6b0bb9b85926..4b68dce12d5d 100644 --- a/docs/src/user-guide/configuring/plugins.md +++ b/docs/src/user-guide/configuring/plugins.md @@ -7,13 +7,8 @@ eleventyNavigation: parent: configuring title: Configuring Plugins order: 4 - --- -* [Specifying Parser](#specifying-parser) -* [Specifying Processor](#specifying-processor) -* [Configuring Plugins](#configuring-plugins) - ## Specifying Parser By default, ESLint uses [Espree](https://github.com/eslint/espree) as its parser. You can optionally specify that a different parser should be used in your configuration file so long as the parser meets the following requirements: @@ -36,9 +31,9 @@ To indicate the npm module to use as your parser, specify it using the `parser` The following parsers are compatible with ESLint: -* [Esprima](https://www.npmjs.com/package/esprima) -* [@babel/eslint-parser](https://www.npmjs.com/package/@babel/eslint-parser) - A wrapper around the [Babel](https://babeljs.io) parser that makes it compatible with ESLint. -* [@typescript-eslint/parser](https://www.npmjs.com/package/@typescript-eslint/parser) - A parser that converts TypeScript into an ESTree-compatible form so it can be used in ESLint. +* [Esprima](https://www.npmjs.com/package/esprima) +* [@babel/eslint-parser](https://www.npmjs.com/package/@babel/eslint-parser) - A wrapper around the [Babel](https://babeljs.io) parser that makes it compatible with ESLint. +* [@typescript-eslint/parser](https://www.npmjs.com/package/@typescript-eslint/parser) - A parser that converts TypeScript into an ESTree-compatible form so it can be used in ESLint. Note when using a custom parser, the `parserOptions` configuration property is still required for ESLint to work properly with features not in ECMAScript 5 by default. Parsers are all passed `parserOptions` and may or may not use them to determine which features to enable. @@ -99,10 +94,7 @@ To configure plugins inside of a configuration file, use the `plugins` key, whic ```json { - "plugins": [ - "plugin1", - "eslint-plugin-plugin2" - ] + "plugins": ["plugin1", "eslint-plugin-plugin2"] } ``` @@ -110,7 +102,7 @@ And in YAML: ```yaml --- - plugins: +plugins: - plugin1 - eslint-plugin-plugin2 ``` @@ -153,9 +145,9 @@ The same rule does apply to scoped packages: When using rules, environments or configs defined by plugins, they must be referenced following the convention: -* `eslint-plugin-foo` → `foo/a-rule` -* `@foo/eslint-plugin` → `@foo/a-config` -* `@foo/eslint-plugin-bar` → `@foo/bar/a-environment` +* `eslint-plugin-foo` → `foo/a-rule` +* `@foo/eslint-plugin` → `@foo/a-config` +* `@foo/eslint-plugin-bar` → `@foo/bar/a-environment` For example: