Skip to content

Commit

Permalink
docs: remove table of contents from markdown
Browse files Browse the repository at this point in the history
  • Loading branch information
snitin315 committed Jun 14, 2022
1 parent f070ea7 commit 99e2559
Show file tree
Hide file tree
Showing 4 changed files with 148 additions and 188 deletions.
167 changes: 74 additions & 93 deletions docs/src/user-guide/configuring/configuration-files.md
Expand Up @@ -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:

Expand Down Expand Up @@ -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
}
]
},
Expand Down Expand Up @@ -124,7 +110,7 @@ And in YAML:

```yaml
---
settings:
settings:
sharedData: "Hello"
```

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -207,34 +193,34 @@ 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.

The `eslint-config-` prefix can be omitted from the configuration name. For example, `airbnb` resolves as `eslint-config-airbnb`.

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

Expand All @@ -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`
Expand All @@ -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
Expand All @@ -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"
}
}
```
Expand Down Expand Up @@ -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
Expand All @@ -360,8 +341,8 @@ module.exports = {
"init-declarations": "off",
"no-console": "off",
"no-inline-comments": "off",
}
}
},
};
```

## Configuration Based on Glob Patterns
Expand All @@ -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

Expand Down

0 comments on commit 99e2559

Please sign in to comment.