docs: add Glossary page

docs/src/use/core-concepts/glossary.md

@@ -0,0 +1,396 @@
+---
+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
+export default [
+    {
+        rules: {
+            "prefer-const": "error",
+        },
+    },
+];
+```
+
+See [Configuration Files (New)](../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 (New)](../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 files.
+
+Each configuration object may include properties describing which files to run on, how to handle different files types, which [plugins](#plugin) to include, and how to run [rules](#rule).
+
+See [Configuration Files (New) > 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 environments.
+
+[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 is declared "globally", meaning all modules and scripts have access to it.
+
+JavaScript allows declaring global variables on the `globalThis` object (generally aliased as `global` in Node.js and `window` in browsers).
+
+ESLint can be informed of those global variables 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 same 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` rule and sets the `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 ELSint 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-expression` from `"error"` to `"off"` in `*.test.js` files:
+
+```js
+export default [
+  rules: {
+    "no-unused-expressions": "off"
+  },
+  {
+    files: ["*.test.js"],
+    rules: {
+        "no-unused-expressions": "off"
+    }
+  }
+];
+```
+
+The following [inline config](#inline-config-configuration-comment) sets
+
+For more information on overrides in legacy configs, see [Configuration Files (Deprecated) > How to 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/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-plugin-markdown`](https://github.com/eslint/eslint-plugin-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 solid from "eslint-plugin-solid/configs/recommended";
+
+export default [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.