Glossary

This glossary defines the common linting terms as used by Flint.

Note

Other linters refer to some definitions using different terms. See Terminology Comparison for a table of equivalents.

Linting Terms

Abstract Syntax Tree (AST)

A representation of the contents of a source file. Lint rules and other forms of static analysis receive an AST to describe the code they analyze.

ASTs are “trees” in that each node, or area of file, may have child nodes. For example, the CallExpression console.log("Hello, world!") has two children: a MemberExpression for console.log and a Literal for "Hello, world!".

Tip

The typescript-eslint playground provides a handy AST viewer for exploring the AST nodes generated for source code.

Change

A modification to code, as suggested by the linter or a rule. Changes can either be:

• Fixes: can be automatically applied, such as with a --fix command-line
• Suggestions: may not be safe to apply, and are typically surfaced as editor suggestions

Comment Directive

An inline comment that changes how a linter should behave for a file.

Comment directives are most often used to disable some or all of a linter’s rules. For example, a directive might disable a particular rule for a specific file or block of code.

Configuration

The set of options that control the behavior of a linter.

Each project that adds a linter typically will include customizations in its configuration file specific to the project and its maintainers. Those customizations are generally stored in a configuration file in the root of a repository.

Fix

A change that is safe to apply automatically.

Fixes are generally created by rules as a part of a report when there is a single known best way to resolve a detected code defect. Running a linter with --fix enabled will apply all reported fixes to code.

Formatter

A tool that applies standard formatting to source code.

Common formatters include:

• Biome’s formatter
• dprint
• Prettier

Formatters are generally very fast, as they only have to parse code and apply changes in a single pass.

Linter

A tool that runs a set of rules on code in order to detect potential issues.

Plugin

A standalone package that adds rules, presets, or other functionality for use with a linter. Plugins are generally single-purpose: they often add rules for a one area of technology, such as a specific framework.

Preset

A set of predefined rules and configuration options that may be used in a configuration.

Presenter

Logic that takes in the results of linting and outputs it to the user.

Note

This is typically called a “formatter” by other linters, such as ESLint. Flint refers to it as a “presenter” to disambiguate from standalone formatters.

Processor

A hook that parses out additional information from files for linting.

Processors are most commonly used to extract nested files from existing source files. For example, a Markdown processor might parse ``` code blocks from files and create corresponding virtual files to be linted.

Report

A description of a potential issue in code.

Reports are generally created by rules when they detect a problem in a file. They may also be created by the running linter, such as when an invalid comment directive is detected.

Rule

A check for a specific pattern in code that may indicate a problem.

When a rule finds that problem in code, it will issue a report.

Stylistic

An overloaded term generally used to describe lint rules that don’t directly deal with logical bugs. These rules are generally split into two categories:

• Formatting: rules that only change whitespace or other non-semantic aspects of code, such as indentation or line length
• Non-formatting: rules around consistency, such as naming conventions or whether to use one syntax over another equivalent one

Linters such as ESLint used to provide stylistic rules alongside logical ones. Most linters now generally only include logical rules instead. See:

• ESLint: Changes to Rules Policies (May 2020)
• ESLint: Deprecation of formatting rules (October 2023)

ESLint Stylistic

ESLint Stylistic is an ESLint plugin that provides stylistic rules. It mostly contains formatting rules, as well as a small number of non-formatting stylistic rules that are not eligible for inclusion in ESLint core. See: ESLint Stylistic > Why?.

typescript-eslint Stylistic Config

The typescript-eslint project includes several preset configs under the label “stylistic”. Those configs contain only non-formatting stylistic rules that are recommended for most TypeScript projects. See: typescript-eslint > Shared Configs > stylistic.

Suggestion

A change that is not safe to apply automatically.

Suggestions are generally created by rules as a part of a report when resolving the suggestion would change the meaning of code, and/or there are multiple potential changes that could be applied. Users typically apply suggestions manually through an interface in their editor.

Type-Aware Linting

The ability for rules to use information provided by a type checker.

Type-aware linting allows rules to make more informed decisions about code. For example, a lint rule that prevents looping over arrays with for...in statements can use type information to determine whether a variable is actually an array or some other type.

Type Checker

A program that determines the possible types of values in source code, then makes sure the ways those values are used are consistent with their types.

The most common type checker in the web ecosystem is TypeScript. TypeScript provides APIs that are used to inform type-aware linting.

Terminology Comparison

Most concepts are referred to by the same terms by most linters. However, some linters use different terms for other concepts. This table shows how each linter refers to concepts whose terminology is not standardized.

Flint Term	Biome	Deno Lint	ESLint	Oxlint
Comment Directive	Suppression Comments	n/a	Inline Configuration Comments	Inline Configuration Comments
Preset	n/a	n/a	Config	n/a
Presenter	Formatter	Formatter	Formatter	Formatter