Presets / Eslint
DX - Code Style
Enforce a strict, project-wide code style for JS and TS with a stylistic formatting baseline plus focused groups of core ESLint rules.
Read article44 docs tagged with "code-style"
View all tagsRules / Eslint / Patterns
No Assign Then Return
Disallow assigning to a const variable and immediately returning it when the value can be returned directly without the intermediate binding.
Read articleRules / Eslint / Patterns
No Await In Loop
Disallow await inside loops so sequential async calls that could be parallelized with Promise.all are caught early during linting.
Read articleRules / Eslint / Patterns
No Boolean Var For If
Disallow extracting a multi-condition boolean into a single-use variable when the condition can be inlined in the next if-statement.
Read articleRules / Eslint / Patterns
No Bracket Assignment
Disallow bracket notation assignment on objects and encourage Reflect.set for dynamic property writes to keep mutation sites explicit.
Read articleRules / Eslint / Patterns
No Bracket Method Call
Disallow calling methods via bracket notation with a static string key when standard dot notation is available and more readable.
Read articleRules / Eslint / Typescript
No Catch Unknown Annotation
Disallow redundant unknown type annotations on catch clause variables because TypeScript already defaults the binding to unknown.
Read articleRules / Eslint / Formatting
No Complex Arrow Concise
Require arrow functions with complex concise bodies to use an explicit block body so the return value is always visually distinct.
Read articleRules / Eslint / Syntax
No Destructuring
Disallow destructuring patterns in callbacks, for-of loops, function parameters, variable declarations, and assignment expressions.
Read articleRules / Eslint / Typescript
No Explicit Any
Disallow usage of the any type and require unknown with type guards or a specific named type to maintain full type-level safety.
Read articleRules / Eslint / Conventions
No Implicit Boolean
Require explicit boolean comparisons instead of relying on truthy/falsy coercion in conditions for unambiguous control flow intent.
Read articleRules / Eslint / Typescript
No Inline Type Annotation
Disallow inline type annotations in code files and require named type aliases imported from dedicated definition files instead.
Read articleRules / Eslint / Formatting
No Multiline Strings
Disallow multiline string content including backslash continuation, visual newlines in template literals, and internal escape sequences.
Read articleRules / Eslint / Syntax
No Numeric Literals
Disallow binary, octal, and hexadecimal numeric literal forms and require parseInt with an explicit radix argument for readable numbers.
Read articleRules / Eslint / Syntax
No Optional Chaining
Disallow the optional chaining operator so null and undefined checks are explicit and the intended handling of absent values is visible.
Read articleRules / Eslint / Regex
No Regex Literal Flags
Disallow flags on regex literals so shared patterns stay reusable and callers add flags at the call site via new RegExp.
Read articleRules / Eslint / Regex
No Regex Literals
Disallow inline regex literal expressions so patterns are centralized in a shared patterns file and reusable across the codebase.
Read articleRules / Eslint / Syntax
No Rest Params
Disallow rest parameters in function signatures so every parameter is listed explicitly and callers can see the full expected argument list.
Read articleRules / Eslint / Typescript
No Shared Type Import
Disallow importing shared type files in code files to enforce type layering where shared types flow through domain type files.
Read articleRules / Eslint / Patterns
No Template Curly in String
Disallow template literal placeholder syntax in regular strings so missing backticks are caught before the expression appears literally in output.
Read articleRules / Eslint / Formatting
No Ternary in Template Literal
Disallow ternary expressions inside template literals to keep template strings readable and encourage extracting logic into variables.
Read articleRules / Eslint / Patterns
No Use Before Define
Disallow use of variables, constants, functions, classes, and types before they are defined to enforce top-down declaration order.
Read articleRules / Eslint / Typescript
Require Bracket Property Access
Require bracket notation instead of dot notation for property access on project-defined plain objects to keep access patterns consistent.
Read articleRules / Eslint / Conventions
Require Explicit Return
Require an explicit return statement at the end of void function bodies so every function signals its exit point for consistent flow.
Read articleRules / Eslint / Conventions
Require Hash Private
Require #hash notation for private class members instead of the private keyword so privacy is enforced at the runtime language level.
Read articleRules / Eslint / Formatting
Require Import Order
Require 6-group import ordering with regular imports first (Node built-ins, third-party, local) then type imports (Node built-ins, third-party, local).
Read articleRules / Eslint / Jsdoc
Require JSDoc Body
Require a body paragraph in JSDoc blocks that explains why the declaration exists rather than restating the function or class name.
Read articleRules / Eslint / Jsdoc
Require JSDoc Hierarchy
Require JSDoc summary lines to follow the hierarchy chain derived from the file path and method name for searchable documentation.
Read articleRules / Eslint / Jsdoc
Require JSDoc Param Alignment
Require vertical alignment of param types, names, and dashes in JSDoc blocks so multi-parameter signatures stay visually consistent.
Read articleRules / Eslint / Jsdoc
Require JSDoc Param Name
Require param descriptions in JSDoc blocks to match the parameter name with the first letter capitalized and a trailing period.
Read articleRules / Eslint / Jsdoc
Require JSDoc Presence
Require a leading JSDoc block on every documentable symbol so no class, function, method, or property ships undocumented.
Read articleRules / Eslint / Jsdoc
Require JSDoc Private
Require a private tag in JSDoc blocks for private class members to keep documentation consistent with TypeScript access modifiers.
Read articleRules / Eslint / Jsdoc
Require JSDoc Returns
Require every @returns tag in JSDoc blocks to contain only a type in braces, with no trailing description after the type annotation.
Read articleRules / Eslint / Jsdoc
Require JSDoc Since
Require a @since tag in every JSDoc block and validate its value as a semver version or UNRELEASED to track API introduction dates.
Read articleRules / Eslint / Jsdoc
Require JSDoc Tag Order
Require JSDoc tags to follow the canonical order with exactly one blank line between adjacent tag groups for consistent documentation.
Read articleRules / Eslint / Conventions
Require Kebab Case Filename
Require kebab-case file names for TypeScript source files so filenames stay consistent, URL-safe, and free of case-sensitivity issues.
Read articleRules / Eslint / Formatting
Require Multiline Condition Groups
Require expanded formatting for parenthesized groups in mixed-operator logical expressions so each condition group starts on its own line.
Read articleRules / Eslint / Formatting
Require Multiline Conditions
Require each operand to be on its own line when a logical expression exceeds the allowed inline count for readable condition chains.
Read articleRules / Eslint / Conventions
Require Node Protocol
Require the node: protocol when importing Node.js built-in modules so built-in imports are visually distinct from third-party packages.
Read articleRules / Eslint / Formatting
Require Padding Lines
Require blank lines between specific statement patterns for improved readability such as exit code before return and before loops.
Read articleRules / Eslint / Formatting
Require Ternary Parens
Require parenthesized condition in ternary expressions so the test clause is visually separated from the consequent and alternate branches.
Read articleRules / Eslint / Typescript
Require Type Naming
Require type alias names in definition files to start with the class name prefix derived from the file path for consistent naming.
Read articleRules / Eslint / Conventions
Require Undefined Init
Require explicit undefined initializer when declaring variables without a value so uninitialized state is always visible in the source.
Read articleRules / Eslint / Conventions
Switch Case Blocks
Require every non-empty switch case to wrap its body in a block so declarations stay scoped and branches stay independent.
Read article