---
title: Glossary
eleventyNavigation:
    key: glossary
    title: Glossary
    parent: core concepts
---

This page serves as a reference for common terms associated with ESLint.

## A

### Abstract Syntax Tree (AST)

A structured representation of code syntax.

Each section of source code in an AST is referred to as a [node](#node).
Each node may have any number of properties, including properties that store child nodes.

The AST format used by ESLint is the [ESTree](#estree) format.

ESLint [rules](#rule) are given an AST and may produce [violations](#violation) on parts of the AST when they detect a [violation](#violation).

## C

### Config File (Configuration File)

A file containing preferences for how ESLint should parse files and run [rules](#rule).

ESLint config files are named like `eslint.config.(c|m)js`.
Each config file exports a [config array](#config-array) containing [config objects](#config-object).

For example, this `eslint.config.js` file enables the `prefer-const` [rule](#rule) at the _error_ [severity](#severity):

```js
import { defineConfig } from "eslint/config";

export default defineConfig([
	{
		rules: {
			"prefer-const": "error",
		},
	},
]);
```

See [Configuration Files](../configure/configuration-files) for more details.

### Config Array

An array of [config objects](#config-object) within a [config file](#config-file-configuration-file).

Each config file exports an array of config objects.
The objects in the array are evaluated in order: later objects may override settings specified in earlier objects.

See [Configuration Files](../configure/configuration-files) for more details.

### Config Object

A [config file](#config-file-configuration-file) entry specifying all of the information ESLint needs to execute on a set of files.

Each configuration object may include properties describing which files to run on, how to handle different file types, which [plugins](#plugin) to include, and how to run [rules](#rule).

See [Configuration Files > Configuration Objects](../configure/configuration-files#configuration-objects) for more details.

## E

### ESQuery

The library used by ESLint to parse [selector](#selector) syntax for querying [nodes](#node) in an [AST](#abstract-syntax-tree-ast).

ESQuery interprets CSS syntax for AST node properties.
Examples of ESQuery selectors include:

- `BinaryExpression`: selects all nodes of type _BinaryExpression_
- `BinaryExpression[operator='+']`: selects all _BinaryExpression_ nodes whose _operator_ is `+`
- `BinaryExpression > Literal[value=1]`: selects all _Literal_ nodes with _value_ `1` whose direct parent is a _BinaryExpression_

See [github.com/estools/esquery](https://github.com/estools/esquery) for more information on the ESQuery format.

### ESTree

The format used by ESLint for how to represent JavaScript syntax as an [AST](#abstract-syntax-tree-ast).

For example, the ESTree representation of the code `1 + 2;` would be an object roughly like:

```json
{
	"type": "ExpressionStatement",
	"expression": {
		"type": "BinaryExpression",
		"left": {
			"type": "Literal",
			"value": 1,
			"raw": "1"
		},
		"operator": "+",
		"right": {
			"type": "Literal",
			"value": 2,
			"raw": "2"
		}
	}
}
```

[Static analysis](#static-analysis) tools such as ESLint typically operate by converting syntax into an AST in the ESTree format.

See [github.com/estree/estree](https://github.com/estree/estree) for more information on the ESTree specification.

## F

### Fix

An optional augmentation to a [rule](#rule) [violation](#violation) that describes how to automatically correct the violation.

Fixes are generally "safe" to apply automatically: they shouldn't cause code behavior changes.
ESLint attempts to apply as many fixes as possible in a [report](#report) when run with the `--fix` flag, though there is no guarantee that all fixes will be applied.
Fixes may also be applied by common editor extensions.

Rule violations may also include file changes that are unsafe and not automatically applied in the form of [suggestions](#suggestion).

### Flat Config

The current configuration file format for ESLint.

Flat config files are named in the format `eslint.config.(c|m)?js`.
"Flat" config files are named as such because all nesting must be done in one configuration file.
In contrast, the ["Legacy" config format](#legacy-config) allowed nesting configuration files in sub-directories within a project.

You can read more about the motivations behind flat configurations in [ESLint's new config system, Part 2: Introduction to flat config](https://eslint.org/blog/2022/08/new-config-system-part-2).

### Formatter (Linting)

A package that presents the [report](#report) generated by ESLint.

ESLint ships with several built-in reporters, including `stylish` (default), `json`, and `html`.

For more information, see [Formatters](../formatters).

### Formatter (Tool)

A [static analysis](#static-analysis) tool that quickly reformats code without changing its logic or names.

Formatters generally only modify the "trivia" of code, such as semicolons, spacing, newlines, and whitespace in general.
Trivia changes generally don't modify the [AST](#abstract-syntax-tree-ast) of code.

Common formatters in the ecosystem include [Prettier](https://prettier.io) and [dprint](https://dprint.dev).

Note that although ESLint is a [linter](#linter) rather than a formatter, ESLint rules can also apply formatting changes to source code.
See [Formatting (Rule)](#formatting-rule) for more information on formatting rules.

### Formatting (Rule)

A rule that solely targets [formatting](#formatter-tool) concerns, such as semicolons and whitespace.
These rules don't change application logic and are a subset of [Stylistic rules](#stylistic-rule).

ESLint no longer recommends formatting rules and previously deprecated its built-in formatting rules.
ESLint recommends instead using a dedicated formatter such as [Prettier](https://prettier.io) or [dprint](https://dprint.dev).
Alternately, the [ESLint Stylistic project](https://eslint.style) provides formatting-related lint rules.

For more information, see [Deprecation of formatting rules](https://eslint.org/blog/2023/10/deprecating-formatting-rules).

## G

### Global Declaration

A description to ESLint of a JavaScript [global variable](#global-variable) that should exist at runtime.

Global declarations inform lint rules that check for proper uses of global variables.
For example, the [`no-undef` rule](../../rules/no-undef) will create a violation for references to global variables not defined in the configured list of globals.

[Config files](#config-file-configuration-file) have globals defined as JavaScript objects.

For information about configuring globals, see [Configure Language Options > Specifying Globals](../configure/language-options#specifying-globals).

### Global Variable

A runtime variable that exists in the global scope, meaning all modules and scripts have access to it.

Global variables in JavaScript are declared on the `globalThis` object (generally aliased as `global` in Node.js and `window` in browsers).

You can let ESLint know which global variables your code uses with [global declarations](#global-declaration).

## I

### Inline Config (Configuration Comment)

A source code comment that configures a rule to a different severity and/or set of options.

Inline configs use similar syntax as [config files](#config-file-configuration-file) to specify any number of rules by name, their new severity, and optionally new options for the rules.
For example, the following inline config comment simultaneously disables the [`eqeqeq`](../../rules/eqeqeq) rule and sets the [`curly`](../../rules/curly) rule to `"error"`:

```js
/* eslint eqeqeq: "off", curly: "error" */
```

For documentation on inline config comments, see [Rules > Using configuration comments](../configure/rules#using-configuration-comments).

## L

### Legacy Config

The previous configuration file format for ESLint, now superseded by ["Flat" config](#flat-config).

Legacy ESLint configurations are named in the format `.eslintrc.*` and allowed to be nested across files within sub-directories in a project.

You can read more about the lifetime of legacy configurations in [ESLint's new config system, Part 1: Background](https://eslint.org/blog/2022/08/new-config-system-part-1).

### Linter

A [static analysis](#static-analysis) tool that can [report](#report) the results from running a set of [rules](#rule) on source code.
Each rule may report any number of [violations](#violation) in the source code.

ESLint is a commonly used linter for JavaScript and other web technologies.

Note that a _linter_ is separate from [formatters](#formatter-tool) and [type checkers](#type-checker).

### Logical Rule

A [rule](#rule) that inspects how code operates to find problems.

Many logical rules look for likely crashes (e.g. [`no-undef`](../../rules/no-undef)), unintended behavior (e.g. [`no-sparse-arrays`](../../rules/no-sparse-arrays)), and unused code (e.g [`no-unused-vars`](../../rules/no-unused-vars)).

You can see the full list of logical rules that ship with ESLint under [Rules > Possible Problems](../../rules/#possible-problems)

## N

### Node

A section of code within an [AST](#abstract-syntax-tree-ast).

Each node represents a type of syntax found in source code.
For example, the `1 + 2` in the AST for `1 + 2;` is a _BinaryExpression_.

See [#esquery](#esquery) for the library ESLint uses to parse [selectors](#selector) that allow [rules](#rule) to search for nodes.

## O

### Override

When a [config object](#config-object) or [inline config](#inline-config-configuration-comment) sets a new severity and/or rule options that supersede previously set severity and/or options.

The following [config file](#config-file-configuration-file) overrides `no-unused-expressions` from `"error"` to `"off"` in `*.test.js` files:

```js
import { defineConfig } from "eslint/config";

export default defineConfig([
	{
		rules: {
			"no-unused-expressions": "error",
		},
	},
	{
		files: ["*.test.js"],
		rules: {
			"no-unused-expressions": "off",
		},
	},
]);
```

The following [inline config](#inline-config-configuration-comment) sets `no-unused-expressions` to `"error"`:

```js
/* eslint no-unused-expressions: "error" */
```

For more information on overrides in legacy configs, see [Configuration Files (Deprecated) > How do overrides work?](../configure/configuration-files-deprecated#how-do-overrides-work).

## P

### Parser

An object containing a method that reads in a string and converts it to a standardized format.

ESLint uses parsers to convert source code strings into an [AST](#abstract-syntax-tree-ast) shape.
By default, ESLint uses the [Espree](https://github.com/eslint/js/tree/main/packages/espree) parser, which generates an AST compatible with standard JavaScript runtimes and versions.

Custom parsers let ESLint parse non-standard JavaScript syntax.
Often custom parsers are included as part of shareable configurations or plugins, so you don’t have to use them directly.
For example, [@typescript-eslint/parser](https://www.npmjs.com/package/@typescript-eslint/parser) is a custom parser included in the [typescript-eslint](https://typescript-eslint.io) project that lets ESLint parse TypeScript code.

For more information on using parsers with ESLint, see [Configure a Parser](../configure/parser).

### Plugin

A package that can contain a set of [configurations](#shareable-config-configuration), [processors](#processor), and/or [rules](#rule).

A popular use case for plugins is to enforce best practices for a framework.
For example, [@angular-eslint/eslint-plugin](https://www.npmjs.com/package/@angular-eslint/eslint-plugin) contains best practices for using the Angular framework.

For more information, refer to [Configure Plugins](../configure/plugins).

### Processor

A part of a plugin that extracts JavaScript code from other kinds of files, then lets ESLint lint the JavaScript code.

For example, [`@eslint/markdown`](https://github.com/eslint/markdown) includes a processor that converts the text of <code>```</code> code blocks in Markdown files into code that can be linted.

For more information on configuring processor, see [Plugins > Specify a Processor](../configure/plugins#specify-a-processor).

## R

### Report

A collection of [violations](#violation) from a single ESLint run.

When ESLint runs on source files, it will pass an [AST](#abstract-syntax-tree-ast) for each source file to each configured [rule](#rule).
The collection of violations from each of the rules will be packaged together and passed to a [formatter](#formatter-linting) to be presented to the user.

### Rule

Code that checks an [AST](#abstract-syntax-tree-ast) for expected patterns. When a rule's expectation is not met, it creates a [violation](#violation).

ESLint provides a large collection of rules that check for common JavaScript code issues.
Many more rules may be loaded in by [plugins](#plugin).

For an overview of rules provided, see [Core Concepts > Rules](../core-concepts/#rules).

## S

### Selector

Syntax describing how to search for [nodes](#node) within an [AST](#abstract-syntax-tree-ast).

ESLint [rules](#rule) use [ESQuery](#esquery) selectors to find nodes that should be checked.

### Severity

What level of reporting a rule is configured to run, if at all.

ESLint supports three levels of severity:

- `"off"` (`0`): Do not run the rule.
- `"warn"` (`1`): Run the rule, but don't exit with a non-zero status code based on its violations (excluding the [`--max-warnings` flag](../command-line-interface#--max-warnings))
- `"error"` (`2`): Run the rule, and exit with a non-zero status code if it produces any violations

For documentation on configuring rules, see [Configure Rules](../configure/rules).

### Shareable Config (Configuration)

A module that provides a predefined [config file](#config-file-configuration-file) configurations.

Shareable configs can configure all the same information from config files, including [plugins](#plugin) and [rules](#rule).

Shareable configs are often provided alongside [plugins](#plugin).
Many plugins provide configs with names like _"recommended"_ that enable their suggested starting set of rules.
For example, [`eslint-plugin-solid`](https://github.com/solidjs-community/eslint-plugin-solid) provides a shareable recommended config:

```js
import { defineConfig } from "eslint/config";
import js from "@eslint/js";
import solid from "eslint-plugin-solid/configs/recommended";

export default defineConfig([js.configs.recommended, solid]);
```

For information on shareable configs, see [Share Configurations](../../extend/shareable-configs).

### Static Analysis

The process of analyzing source code without building or running it.

[Linters](#linter) such as ESLint, [formatters](#formatter-tool), and [type checkers](#type-checker) are examples of static analysis tools.

Static analysis is different from _dynamic_ analysis, which is the process of evaluating source code after it is built and executed.
Unit, integration, and end-to-end tests are common examples of dynamic analysis.

### Stylistic (Rule)

A rule that enforces a preference rather than a logical issue.
Stylistic areas include [Formatting rules](#formatting-rule), naming conventions, and consistent choices between equivalent syntaxes.

ESLint's built-in stylistic rules are feature frozen: except for supporting new ECMAScript versions, they won't receive new features.

For more information, see [Changes to our rules policies](https://eslint.org/blog/2020/05/changes-to-rules-policies) and [Deprecation of formatting rules](https://eslint.org/blog/2023/10/deprecating-formatting-rules).

### Suggestion

An optional augmentation to a [rule](#rule) [violation](#violation) that describes how one may manually adjust the code to address the violation.

Suggestions are not generally safe to apply automatically because they cause code behavior changes.
ESLint does not apply suggestions directly but does provide suggestion to integrations that may choose to apply suggestions (such as an editor extension).

Rule violations may also include file changes that are safe and may be automatically applied in the form of [fixes](#fix).

## T

### Type Checker

A [static analysis](#static-analysis) tool that builds a full understanding of a project's code constructs and data shapes.

Type checkers are generally slower and more comprehensive than linters.
Whereas linters traditionally operate only on a single file's or snippet's [AST](#abstract-syntax-tree-ast) at a time, type checkers understand cross-file dependencies and types.

[TypeScript](https://typescriptlang.org) is the most common type checker for JavaScript.
The [typescript-eslint](https://typescript-eslint.io) project provides integrations that allow using type checker in lint rules.

## V

### Violation

An indication from a [rule](#rule) that an area of code doesn't meet the expectation of the rule.

Rule violations indicate a range in source code and error message explaining the violation.
Violations may also optionally include a [fix](#fix) and/or [suggestions](#suggestion) that indicate how to improve the violating code.