@ttsc/lint 0.13.1 → 0.14.0-dev.20260528

package/src/structures/rules/ITtscLintCoreRules.ts

@@ -0,0 +1,1406 @@
+import type { TtscLintRuleSetting } from "../TtscLintRuleSetting";
+
+/**
+ * Generic ESLint-compatible rules that apply to both JavaScript and
+ * TypeScript source.
+ *
+ * Every rule listed here corresponds 1-to-1 with an ESLint core rule of the
+ * same kebab-case id. TypeScript-only rules and `@typescript-eslint`
+ * extension rules do **not** live here — they belong to
+ * {@link ITtscLintTypeScriptRules}.
+ *
+ * Keeping the core family namespace-free means projects migrating from
+ * ESLint can paste their rule severities into a `ttsc.lint.config.ts` file
+ * without renaming anything.
+ *
+ * The fix availability noted in each rule's JSDoc applies when `ttsc fix`
+ * or the LSP code action is invoked; a rule marked *Autofixable* may still
+ * produce diagnostics that require human review for edge cases.
+ *
+ * @reference https://eslint.org/docs/latest/rules/
+ */
+export interface ITtscLintCoreRules {
+  /**
+   * Require block statements for every `if`, `else`, `while`, `for`, and `do` body — reject the single-statement shorthand.
+   *
+   * @reference https://eslint.org/docs/latest/rules/curly
+   */
+  "curly"?: TtscLintRuleSetting;
+
+  /**
+   * Require `switch` statements to include a `default` clause.
+   *
+   * A switch without `default` silently drops every discriminant value
+   * that no `case` label matched. The rule forces the catch-all branch
+   * to be written out so unhandled cases become an intentional decision
+   * instead of a hidden fall-through.
+   *
+   * @reference https://eslint.org/docs/latest/rules/default-case
+   */
+  "default-case"?: TtscLintRuleSetting;
+
+  /**
+   * Require the `default` clause of a `switch` statement to appear
+   * after every explicit `case` label.
+   *
+   * Placing `default` ahead of a `case` reverses the visual order of
+   * the labels and changes the fall-through path — running `default`
+   * and then falling into the next `case` is almost always a
+   * misordering rather than intent.
+   *
+   * @reference https://eslint.org/docs/latest/rules/default-case-last
+   */
+  "default-case-last"?: TtscLintRuleSetting;
+
+  /**
+   * Reject identifier declarations that aren't camelCase or PascalCase — snake_case bindings are flagged.
+   *
+   * @reference https://eslint.org/docs/latest/rules/camelcase
+   */
+  "camelcase"?: TtscLintRuleSetting;
+
+  /**
+   * Reject function bodies whose cyclomatic complexity exceeds twenty (default ESLint threshold).
+   *
+   * @reference https://eslint.org/docs/latest/rules/complexity
+   */
+  "complexity"?: TtscLintRuleSetting;
+
+  /**
+   * Reject functions where some `return` statements return a value and
+   * others (explicit bare `return;` or implicit fall-through) do not.
+   *
+   * @reference https://eslint.org/docs/latest/rules/consistent-return
+   */
+  "consistent-return"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `(req, opt = 1, req2)` and similar parameter lists where a
+   * required parameter follows an optional or default-valued one.
+   *
+   * The call site cannot omit the trailing required parameter, so the
+   * optional becomes positionally required too — almost always an
+   * accidental ordering.
+   *
+   * @reference https://eslint.org/docs/latest/rules/default-param-last
+   */
+  "default-param-last"?: TtscLintRuleSetting;
+
+  /**
+   * Prefer dot access (`obj.value`) over bracket access (`obj["value"]`)
+   * when the string key is a valid JavaScript identifier.
+   *
+   * Bracket access remains accepted for reserved words, dynamic keys, or
+   * keys containing characters that cannot appear in an identifier.
+   *
+   * @reference https://eslint.org/docs/latest/rules/dot-notation
+   */
+  "dot-notation"?: TtscLintRuleSetting;
+
+  /**
+   * Require strict equality operators `===` / `!==` over `==` / `!=`.
+   *
+   * Loose equality performs implicit type coercion that frequently hides
+   * bugs.
+   *
+   * @reference https://eslint.org/docs/latest/rules/eqeqeq
+   */
+  "eqeqeq"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `for` statements whose update clause moves the counter away
+   * from the termination condition, such as `for (let i = 0; i < 10;
+   * i--)`. Such loops either never run or never terminate.
+   *
+   * @reference https://eslint.org/docs/latest/rules/for-direction
+   */
+  "for-direction"?: TtscLintRuleSetting;
+
+  /**
+   * Require a `get` accessor's body to return a value on every
+   * reachable exit. A getter that falls through returns `undefined`
+   * to the caller, which is almost never the intent and turns into a
+   * silent bug that only surfaces when the property is finally read.
+   *
+   * @reference https://eslint.org/docs/latest/rules/getter-return
+   */
+  "getter-return"?: TtscLintRuleSetting;
+
+  /**
+   * Require the `get` and `set` accessors of a single property to be
+   * declared adjacent in the class body.
+   *
+   * When the read and write halves of a property are split apart by
+   * unrelated members, a reader scanning the class has to chase the
+   * pair across the body — and patches to one half are easy to make
+   * without noticing the other.
+   *
+   * @reference https://eslint.org/docs/latest/rules/grouped-accessor-pairs
+   */
+  "grouped-accessor-pairs"?: TtscLintRuleSetting;
+
+  /**
+   * Require the body of every `for (key in obj)` loop to begin with a
+   * guard against inherited keys: `Object.hasOwn(obj, key)` or the
+   * older `Object.prototype.hasOwnProperty.call(obj, key)`. The
+   * inverted-guard early-skip shape `if (!Object.hasOwn(...))
+   * continue;` is also accepted.
+   *
+   * Without the guard the loop processes every enumerable name on the
+   * prototype chain — including monkey-patches someone else attached
+   * to `Object.prototype` — so an unguarded body silently leaks work
+   * onto inherited entries.
+   *
+   * @reference https://eslint.org/docs/latest/rules/guard-for-in
+   */
+  "guard-for-in"?: TtscLintRuleSetting;
+
+  /**
+   * Reject identifier names shorter than two characters.
+   *
+   * @reference https://eslint.org/docs/latest/rules/id-length
+   */
+  "id-length"?: TtscLintRuleSetting;
+
+  /**
+   * Require every `var` / `let` declaration to be initialized at its declaration site.
+   *
+   * @reference https://eslint.org/docs/latest/rules/init-declarations
+   */
+  "init-declarations"?: TtscLintRuleSetting;
+
+  /**
+   * Reject a source file that declares more than one class.
+   *
+   * @reference https://eslint.org/docs/latest/rules/max-classes-per-file
+   */
+  "max-classes-per-file"?: TtscLintRuleSetting;
+
+  /**
+   * Reject block-statement nesting deeper than four levels inside a function.
+   *
+   * @reference https://eslint.org/docs/latest/rules/max-depth
+   */
+  "max-depth"?: TtscLintRuleSetting;
+
+  /**
+   * Reject a source file whose total line count exceeds three hundred.
+   *
+   * @reference https://eslint.org/docs/latest/rules/max-lines
+   */
+  "max-lines"?: TtscLintRuleSetting;
+
+  /**
+   * Reject a function whose body spans more than fifty lines.
+   *
+   * @reference https://eslint.org/docs/latest/rules/max-lines-per-function
+   */
+  "max-lines-per-function"?: TtscLintRuleSetting;
+
+  /**
+   * Reject callback nesting deeper than ten inside a single function.
+   *
+   * @reference https://eslint.org/docs/latest/rules/max-nested-callbacks
+   */
+  "max-nested-callbacks"?: TtscLintRuleSetting;
+
+  /**
+   * Reject function declarations whose parameter list grows beyond
+   * three. Long parameter lists are hard to read at the call site
+   * because positional arguments lose their names; folding them into
+   * an options object recovers the names and lets callers pass a
+   * subset.
+   *
+   * Every function-like declaration is checked: function declarations,
+   * function expressions, arrow functions, methods, accessors, and
+   * constructors. The threshold is fixed at three to match the ESLint
+   * default; rule options are deferred.
+   *
+   * @reference https://eslint.org/docs/latest/rules/max-params
+   */
+  "max-params"?: TtscLintRuleSetting;
+
+  /**
+   * Reject function bodies whose statement count exceeds ten.
+   *
+   * @reference https://eslint.org/docs/latest/rules/max-statements
+   */
+  "max-statements"?: TtscLintRuleSetting;
+
+  /**
+   * Reject calls to `alert`, `confirm`, and `prompt`.
+   *
+   * These browser dialogs block the main thread and are almost always
+   * debugging leftovers or placeholders for a proper UI component.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-alert
+   */
+  "no-alert"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `Array(...)` and `new Array(...)` constructor calls in favor
+   * of array literals.
+   *
+   * `Array(n)` and `[n]` behave differently for a single numeric
+   * argument, and the array literal is uniformly clearer.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-array-constructor
+   */
+  "no-array-constructor"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `new Promise(async (resolve, reject) => { ... })`.
+   *
+   * Promises thrown asynchronously inside the executor are dropped
+   * silently because the constructor has already returned the outer
+   * Promise. Use a regular function and call `reject` explicitly.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-async-promise-executor
+   */
+  "no-async-promise-executor"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `await` expressions evaluated inside a loop body. The loop
+   * runs strictly serially because each iteration blocks on the
+   * previous one's microtask hop; when the operations are independent
+   * the equivalent `Promise.all([…])` is dramatically faster. The rule
+   * intentionally exempts `for await … of` because the awaitable
+   * iterator is the loop's whole reason for existing.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-await-in-loop
+   */
+  "no-await-in-loop"?: TtscLintRuleSetting;
+
+  /**
+   * Reject bitwise operators (`&`, `|`, `^`, `~`, `<<`, `>>`, `>>>`).
+   *
+   * Bitwise operators are almost always typos for the logical operators
+   * (`&&`, `||`); enable when the codebase has no legitimate
+   * bit-twiddling.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-bitwise
+   */
+  "no-bitwise"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `arguments.caller` and `arguments.callee`, both deprecated
+   * properties forbidden in strict mode.
+   *
+   * They defeat engine optimizations and break under ES modules, where
+   * strict mode is implicit.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-caller
+   */
+  "no-caller"?: TtscLintRuleSetting;
+
+  /**
+   * Reject lexical declarations (`let`, `const`, `class`, `function`)
+   * inside `case` or `default` clauses without their own block, since
+   * the declaration shares the whole `switch` scope and leaks into
+   * sibling clauses.
+   *
+   * Wrap the case body in `{ ... }` to introduce a fresh block.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-case-declarations
+   */
+  "no-case-declarations"?: TtscLintRuleSetting;
+
+  /**
+   * Reject reassigning a class binding (`class C {}; C = ...`).
+   *
+   * The declaration name is effectively final; overwriting it silently
+   * leaves other call sites pointing at the original class.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-class-assign
+   */
+  "no-class-assign"?: TtscLintRuleSetting;
+
+  /**
+   * Reject comparisons against `-0` (`x === -0`, `x < -0`, etc.).
+   *
+   * `===` treats `+0` and `-0` as equal, so the comparison never
+   * distinguishes them; use `Object.is(x, -0)` when the sign of zero
+   * actually matters.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-compare-neg-zero
+   */
+  "no-compare-neg-zero"?: TtscLintRuleSetting;
+
+  /**
+   * Reject assignment expressions inside conditions, such as `if (x =
+   * y)` — almost always a typo for `==` / `===`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-cond-assign
+   */
+  "no-cond-assign"?: TtscLintRuleSetting;
+
+  /**
+   * Reject calls to `console.*`.
+   *
+   * Typically configured as `"warning"` so leftover logging stays visible
+   * without breaking the build.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-console
+   */
+  "no-console"?: TtscLintRuleSetting;
+
+  /**
+   * Reject conditions whose value can be determined statically, such
+   * as `while (true)` or `if (false)`, in `if`, `while`, `do/while`,
+   * `for`, and ternary expressions.
+   *
+   * The default `checkLoops` configuration still permits intentional
+   * infinite loops in a few forms; see upstream for the matrix.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-constant-condition
+   */
+  "no-constant-condition"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `continue` statements.
+   *
+   * Stylistic policy preferring early returns or restructured loops over
+   * `continue`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-continue
+   */
+  "no-continue"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `return X;` (with a value) inside a class constructor. The
+   * returned value is ignored when the constructor is invoked with
+   * `new` unless it happens to be an object; relying on that behavior
+   * is always a misunderstanding of the constructor protocol.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-constructor-return
+   */
+  "no-constructor-return"?: TtscLintRuleSetting;
+
+  /**
+   * Reject ASCII control characters (`\x00`–`\x1F`) inside regular
+   * expression literals and `RegExp` strings.
+   *
+   * They render invisibly in source and almost always indicate an
+   * accidental paste or a missed `\t` / `\n` escape.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-control-regex
+   */
+  "no-control-regex"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `debugger` statements.
+   *
+   * Typically configured as `"error"` so accidental debugger leftovers
+   * fail CI.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-debugger
+   */
+  "no-debugger"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `delete` applied to plain variable bindings (`delete x`).
+   *
+   * The operation is forbidden in strict mode (and therefore in ES
+   * modules) and never has the intended effect on `let` / `const` /
+   * `var` declarations.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-delete-var
+   */
+  "no-delete-var"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `function f(a, a)` and similar parameter lists that declare
+   * the same name twice.
+   *
+   * The function cannot bind both arguments and fails in strict mode.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-dupe-args
+   */
+  "no-dupe-args"?: TtscLintRuleSetting;
+
+  /**
+   * Reject two declarations of the same member on a single class. The
+   * later declaration silently overwrites the earlier one at runtime;
+   * the syntax permits it but the result is never what the author
+   * intended. A getter and a setter for the same property coexist; an
+   * instance member and a static member with the same name coexist.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-dupe-class-members
+   */
+  "no-dupe-class-members"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `if (a) {} else if (a) {}` — the second branch is
+   * unreachable because the first condition already handled it.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-dupe-else-if
+   */
+  "no-dupe-else-if"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `{ a: 1, a: 2 }` — duplicate property keys in an object
+   * literal silently overwrite earlier values.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-dupe-keys
+   */
+  "no-dupe-keys"?: TtscLintRuleSetting;
+
+  /**
+   * Reject the same `case` label appearing twice in a `switch` —
+   * later duplicates are unreachable.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-duplicate-case
+   */
+  "no-duplicate-case"?: TtscLintRuleSetting;
+
+  /**
+   * Reject two import declarations that resolve to the same module
+   * specifier. The runtime sees one module load either way; the
+   * duplicated declaration is purely noise at the head of the file
+   * and obscures the dependency graph.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-duplicate-imports
+   */
+  "no-duplicate-imports"?: TtscLintRuleSetting;
+
+  /**
+   * Reject an `else` block whose preceding `if` branch already
+   * terminates control flow with `return`, `throw`, `break`, or
+   * `continue` — flatten the body into the surrounding scope.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-else-return
+   */
+  "no-else-return"?: TtscLintRuleSetting;
+
+  /**
+   * Reject empty blocks (`if (x) {}`, `while (x) {}`, `try {} catch
+   * (e) {}` etc.) that almost always indicate forgotten code.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-empty
+   */
+  "no-empty"?: TtscLintRuleSetting;
+
+  /**
+   * Reject empty regex character classes (`[]`).
+   *
+   * An empty class never matches anything, so the entire pattern can
+   * never succeed; the negated form `[^]` (matches any character) is
+   * allowed.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-empty-character-class
+   */
+  "no-empty-character-class"?: TtscLintRuleSetting;
+
+  /**
+   * Reject empty function and method bodies (`function f() {}`, `()
+   * => {}`).
+   *
+   * Use `() => undefined` or a leading TODO comment when the empty
+   * body is intentional.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-empty-function
+   */
+  "no-empty-function"?: TtscLintRuleSetting;
+
+  /**
+   * Reject empty named import or export clauses — `import {} from "x"`,
+   * `import name, {} from "x"`, and `export {}` — which bind nothing.
+   *
+   * The empty-only import shape leaves just the side-effect load and is
+   * better written as `import "x"`; the default-plus-empty form should
+   * drop the empty clause; and a bare `export {}` either restates
+   * module-ness redundantly or marks an otherwise non-module file in
+   * a way that has cleaner alternatives. The stricter sibling rule
+   * `typescript/no-useless-empty-export` fires only when another
+   * module-syntax statement is already present.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-empty-named-blocks
+   */
+  "no-empty-named-blocks"?: TtscLintRuleSetting;
+
+  /**
+   * Reject empty destructuring patterns (`const {} = obj`, `function
+   * f([]) {}`), which bind nothing and are usually mid-edit typos.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-empty-pattern
+   */
+  "no-empty-pattern"?: TtscLintRuleSetting;
+
+  /**
+   * Reject empty `static {}` class initialization blocks.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-empty-static-block
+   */
+  "no-empty-static-block"?: TtscLintRuleSetting;
+
+  /**
+   * Reject loose null comparisons (`x == null`).
+   *
+   * Use `x === null` or the explicit `x === null || x === undefined`.
+   *
+   * Pairs with `eqeqeq` but kept separate so the loose null shortcut can
+   * be allowed under `"smart"`-style `eqeqeq` exceptions.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-eq-null
+   */
+  "no-eq-null"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `eval(...)` and indirect `eval` calls — almost always a
+   * security or correctness bug.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-eval
+   */
+  "no-eval"?: TtscLintRuleSetting;
+
+  /**
+   * Reject reassigning the parameter of a `catch` clause (`catch (e) {
+   * e = ... }`), which loses the original error reference.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-ex-assign
+   */
+  "no-ex-assign"?: TtscLintRuleSetting;
+
+  /**
+   * Reject assignments to a built-in prototype such as
+   * `Array.prototype.foo = bar`. Only `<Builtin>.prototype.<key> = …`
+   * is flagged; assigning to `Object.foo = …` (a static property) is
+   * left alone.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-extend-native
+   */
+  "no-extend-native"?: TtscLintRuleSetting;
+
+  /**
+   * Reject unnecessary `Function.prototype.bind()` calls — for
+   * example, binding without arguments or binding an arrow function
+   * (which ignores `this`).
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-extra-bind
+   */
+  "no-extra-bind"?: TtscLintRuleSetting;
+
+  /**
+   * Reject redundant boolean casts such as `!!Boolean(x)`, `if
+   * (Boolean(x))`, or `Boolean(!!x)`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-extra-boolean-cast
+   */
+  "no-extra-boolean-cast"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `switch` case fall-through unless preceded by an explicit
+   * `// falls through` comment.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-fallthrough
+   */
+  "no-fallthrough"?: TtscLintRuleSetting;
+
+  /**
+   * Reject reassignment of function declarations (`function f() {}; f
+   * = 0;`).
+   *
+   * The hoisted binding looks final to most readers; overwriting it
+   * makes the original implementation unreachable from other references.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-func-assign
+   */
+  "no-func-assign"?: TtscLintRuleSetting;
+
+  /**
+   * Reject common implicit-coercion idioms (`!!x`, `+x`, `"" + x`) in
+   * favor of the explicit `Boolean(x)` / `Number(x)` / `String(x)`
+   * conversions. The explicit forms are more readable and avoid
+   * surprise around primitive edge cases.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-implicit-coercion
+   */
+  "no-implicit-coercion"?: TtscLintRuleSetting;
+
+  /**
+   * Reject writes to a binding introduced by an `import` declaration —
+   * assignment (`x = …`), compound assignment, or increment/decrement
+   * of an imported name, plus property mutations of a namespace import
+   * (`ns.foo = …`). Imported bindings are read-only at runtime; mutating
+   * them either throws under strict mode or silently desynchronises the
+   * module's view of its own exports.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-import-assign
+   */
+  "no-import-assign"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `function` and `var` declarations nested in non-function
+   * blocks (loops, `if`, etc.) — they hoist in surprising ways.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-inner-declarations
+   */
+  "no-inner-declarations"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `this` references outside any function-like, class method, or class-static-block context.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-invalid-this
+   */
+  "no-invalid-this"?: TtscLintRuleSetting;
+
+  /**
+   * Reject irregular whitespace characters (zero-width space,
+   * non-breaking space, etc.) in source — typically copy-paste artifacts
+   * from rich-text editors.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-irregular-whitespace
+   */
+  "no-irregular-whitespace"?: TtscLintRuleSetting;
+
+  /**
+   * Reject the legacy `__iterator__` property — a SpiderMonkey-only
+   * extension predating ES2015 iterators.
+   *
+   * Use `Symbol.iterator` or a generator.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-iterator
+   */
+  "no-iterator"?: TtscLintRuleSetting;
+
+  /**
+   * Reject labeled statements (`outer: for (...) { break outer; }`).
+   *
+   * Labels obscure control flow; prefer extracting the inner loop into
+   * a function and using `return`, or refactoring with a flag variable.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-labels
+   */
+  "no-labels"?: TtscLintRuleSetting;
+
+  /**
+   * Reject standalone `{ ... }` blocks that introduce no lexical
+   * scope distinct from the surrounding block.
+   *
+   * Blocks that actually declare `let`, `const`, `class`, or `function`
+   * (in strict mode) are exempt, since those declarations need the
+   * inner scope.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-lone-blocks
+   */
+  "no-lone-blocks"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `if (cond) { if (...) { ... } }` where the inner `if` is
+   * the only statement in an `else` — prefer `else if`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-lonely-if
+   */
+  "no-lonely-if"?: TtscLintRuleSetting;
+
+  /**
+   * Reject function declarations defined inside the body of a loop.
+   * Each iteration of the loop allocates a fresh function whose
+   * closure captures the surrounding `let`/`var` binding — a class
+   * of bugs where every captured function reads the iteration's
+   * final value instead of its own.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-loop-func
+   */
+  "no-loop-func"?: TtscLintRuleSetting;
+
+  /**
+   * Reject numeric literals whose source text cannot round-trip
+   * through `Number` without losing digits, including overflow.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-loss-of-precision
+   */
+  "no-loss-of-precision"?: TtscLintRuleSetting;
+
+  /**
+   * Reject inline numeric literals outside `const` initializer position. `0`, `1`, `-1`, array indices, and enum values are exempt.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-magic-numbers
+   */
+  "no-magic-numbers"?: TtscLintRuleSetting;
+
+  /**
+   * Reject regex character classes that contain combined Unicode
+   * sequences (e.g. surrogate pairs) which most readers will not
+   * realize represent multiple code units.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-misleading-character-class
+   */
+  "no-misleading-character-class"?: TtscLintRuleSetting;
+
+  /**
+   * Reject mixing operators of different precedence families in the
+   * same expression without explicit parentheses around the inner
+   * sub-expression. The famous case is `a && b || c`: readers expect
+   * left-to-right grouping but the parser sees `(a && b) || c` because
+   * `&&` binds tighter than `||`.
+   *
+   * The conservative baseline only flags the highest-confusion mixes —
+   * logical mixed with a different logical (`&&` next to `||` / `??`),
+   * and bitwise (`&`, `|`, `^`) next to a comparison or logical.
+   * Wrapping the inner sub-expression in parens suppresses the report.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-mixed-operators
+   */
+  "no-mixed-operators"?: TtscLintRuleSetting;
+
+  /**
+   * Reject chained assignment such as `a = b = 0`, which obscures
+   * intent and surprises readers who expect comparison.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-multi-assign
+   */
+  "no-multi-assign"?: TtscLintRuleSetting;
+
+  /**
+   * Reject backslash-newline multiline string literals; use template
+   * literals instead.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-multi-str
+   */
+  "no-multi-str"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `if (!cond) { ... } else { ... }` — flip the branches so
+   * the positive condition reads first.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-negated-condition
+   */
+  "no-negated-condition"?: TtscLintRuleSetting;
+
+  /**
+   * Reject ternary expressions nested in other ternaries
+   * (`a ? b : c ? d : e`), which are hard to read at a glance.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-nested-ternary
+   */
+  "no-nested-ternary"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `new` expressions whose return value is not assigned or
+   * used — the object is created only for its constructor side effects.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-new
+   */
+  "no-new"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `new Function(...)` and `Function(...)` calls, which
+   * effectively evaluate a string and have the same risks as `eval`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-new-func
+   */
+  "no-new-func"?: TtscLintRuleSetting;
+
+  /**
+   * Reject primitive wrapper constructors `new String(...)`, `new
+   * Number(...)`, `new Boolean(...)`.
+   *
+   * The resulting objects compare unequal to their primitive counterparts.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-new-wrappers
+   */
+  "no-new-wrappers"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `new Symbol(...)`. `Symbol` is a function but not a
+   * constructor; calling it with `new` throws a TypeError at runtime.
+   * The upstream rule was renamed `no-new-native-nonconstructor`; the
+   * legacy name remains the more readable pointer for this specific
+   * Symbol check.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-new-symbol
+   */
+  "no-new-symbol"?: TtscLintRuleSetting;
+
+  /**
+   * Reject calling global non-callable objects as functions, such as
+   * `Math()` or `JSON()`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-obj-calls
+   */
+  "no-obj-calls"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `new Object()` and `Object()` constructor calls; use an
+   * object literal `{}` instead.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-object-constructor
+   */
+  "no-object-constructor"?: TtscLintRuleSetting;
+
+  /**
+   * Reject legacy octal literals (`0123`).
+   *
+   * Use the `0o123` prefix when an octal literal is actually intended.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-octal
+   */
+  "no-octal"?: TtscLintRuleSetting;
+
+  /**
+   * Reject octal escape sequences in string literals (`"\251"`,
+   * `"\07"`).
+   *
+   * Deprecated and forbidden in strict mode; use Unicode (`©`) or hex
+   * (`\xA9`) escapes.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-octal-escape
+   */
+  "no-octal-escape"?: TtscLintRuleSetting;
+
+  /**
+   * Reject reassigning a function parameter inside the body of the
+   * function it belongs to. The parameter name stops pointing at the
+   * caller's argument after the write. Property mutations
+   * (`param.foo = …`) are not flagged.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-param-reassign
+   */
+  "no-param-reassign"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `++` and `--` operators.
+   *
+   * Prefer `+= 1` / `-= 1` to keep statements expression-only and
+   * avoid ASI surprises.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-plusplus
+   */
+  "no-plusplus"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `return` inside the Promise executor function — the value
+   * is ignored.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-promise-executor-return
+   */
+  "no-promise-executor-return"?: TtscLintRuleSetting;
+
+  /**
+   * Reject access to `obj.__proto__`; use `Object.getPrototypeOf` /
+   * `Object.setPrototypeOf`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-proto
+   */
+  "no-proto"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `obj.hasOwnProperty(key)` and other direct
+   * `Object.prototype` builtins on user objects, since the property
+   * may be shadowed.
+   *
+   * Use `Object.prototype.hasOwnProperty.call(obj, key)` or
+   * `Object.hasOwn`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-prototype-builtins
+   */
+  "no-prototype-builtins"?: TtscLintRuleSetting;
+
+  /**
+   * Reject declaring the same binding more than once in the same scope
+   * (`var x = 1; var x = 2;`, two `function foo()` declarations side by
+   * side, or a parameter rebound by a later `var` in the body). The
+   * second declaration silently overwrites the first; shadowing the
+   * binding in a nested scope is left alone.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-redeclare
+   */
+  "no-redeclare"?: TtscLintRuleSetting;
+
+  /**
+   * Reject more than one consecutive literal space in a regex; use
+   * `{N}` quantifiers for clarity.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-regex-spaces
+   */
+  "no-regex-spaces"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `import` declarations targeting any module specifier in the project denylist.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-restricted-imports
+   */
+  "no-restricted-imports"?: TtscLintRuleSetting;
+
+  /**
+   * Reject AST node kinds listed in the project denylist.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-restricted-syntax
+   */
+  "no-restricted-syntax"?: TtscLintRuleSetting;
+
+  /**
+   * Reject assignment expressions used as the operand of `return`
+   * (`return x = 1`) — almost always a typo for `===`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-return-assign
+   */
+  "no-return-assign"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `javascript:` URLs in string literals — they execute their
+   * body as code on browser navigation, and security scanners treat them
+   * as an `eval` equivalent.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-script-url
+   */
+  "no-script-url"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `x = x` and destructuring forms that copy a value to
+   * itself — almost always a typo.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-self-assign
+   */
+  "no-self-assign"?: TtscLintRuleSetting;
+
+  /**
+   * Reject comparing a value to itself (`x === x`). Use
+   * `Number.isNaN(x)` to test for `NaN`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-self-compare
+   */
+  "no-self-compare"?: TtscLintRuleSetting;
+
+  /**
+   * Reject comma expressions (`a, b`) outside the heads of `for`
+   * statements.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-sequences
+   */
+  "no-sequences"?: TtscLintRuleSetting;
+
+  /**
+   * Reject explicit `return` from a setter — setters' return values
+   * are ignored.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-setter-return
+   */
+  "no-setter-return"?: TtscLintRuleSetting;
+
+  /**
+   * Reject a variable declaration that shadows a same-name binding in
+   * an enclosing scope.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-shadow
+   */
+  "no-shadow"?: TtscLintRuleSetting;
+
+  /**
+   * Reject redeclaring restricted globals (`NaN`, `Infinity`,
+   * `undefined`, etc.).
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-shadow-restricted-names
+   */
+  "no-shadow-restricted-names"?: TtscLintRuleSetting;
+
+  /**
+   * Reject array literals with elision (`[, 1, , 3]`), which read
+   * surprisingly and rarely express intent.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-sparse-arrays
+   */
+  "no-sparse-arrays"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `${expr}` inside ordinary single- or double-quoted
+   * strings — almost always a missing template-literal backtick.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-template-curly-in-string
+   */
+  "no-template-curly-in-string"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `this` (or `super.x`) references that precede the first
+   * `super()` call in a derived constructor. The runtime throws a
+   * ReferenceError on the first such access; catching it at lint time
+   * avoids a class of bugs that only surface after the constructor is
+   * actually called.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-this-before-super
+   */
+  "no-this-before-super"?: TtscLintRuleSetting;
+
+  /**
+   * Reject throwing non-Error operands (`throw "boom"`, `throw 1`).
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-throw-literal
+   */
+  "no-throw-literal"?: TtscLintRuleSetting;
+
+  /**
+   * Reject initializing a variable to the literal `undefined`
+   * (`let x = undefined`) — declaring without an initializer has the
+   * same effect.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-undef-init
+   */
+  "no-undef-init"?: TtscLintRuleSetting;
+
+  /**
+   * Reject use of the global `undefined` identifier; use the `void 0`
+   * expression or omit the value.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-undefined
+   */
+  "no-undefined"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `cond ? true : false` and similar ternaries that can be
+   * simplified to a boolean coercion or the condition itself.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-unneeded-ternary
+   */
+  "no-unneeded-ternary"?: TtscLintRuleSetting;
+
+  /**
+   * Reject statements that follow an unconditional `return`, `throw`,
+   * `break`, or `continue` in the same block — control flow has already
+   * left the block, so any later statement is dead code.
+   *
+   * The conservative baseline scans the immediate statement list of a
+   * block (or the top-level source / module body) only; hoistable
+   * function declarations following the terminator are exempt because
+   * they are hoisted above the unreachable point.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-unreachable
+   */
+  "no-unreachable"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `return` and `throw` inside a `finally` block, which
+   * override any earlier `return`/`throw` from the corresponding
+   * `try`/`catch`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-unsafe-finally
+   */
+  "no-unsafe-finally"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `!key in obj` and `!a instanceof B` where the `!` binds
+   * tighter than the relational operator and silently coerces the
+   * left operand to a boolean.
+   *
+   * Wrap in parens (`!(key in obj)`) when the negation is genuinely
+   * intended.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-unsafe-negation
+   */
+  "no-unsafe-negation"?: TtscLintRuleSetting;
+
+  /**
+   * Reject member access or call expressions that chain off an
+   * optional chain without continuing the chain. `(obj?.foo).bar`
+   * throws a TypeError if obj is null/undefined; the chain must
+   * continue with `?.` to remain safe.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-unsafe-optional-chaining
+   */
+  "no-unsafe-optional-chaining"?: TtscLintRuleSetting;
+
+  /**
+   * Reject expression statements with no observable effect, like a
+   * bare `x;` or `'use strict' && f();`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-unused-expressions
+   */
+  "no-unused-expressions"?: TtscLintRuleSetting;
+
+  /**
+   * Reject labels that no `break` or `continue` statement references.
+   *
+   * Usually the targeted statement was renamed or removed but the label
+   * was left behind.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-unused-labels
+   */
+  "no-unused-labels"?: TtscLintRuleSetting;
+
+  /**
+   * Reject an assignment whose value is immediately overwritten by the
+   * very next statement without an intervening read of the same
+   * identifier. The conservative baseline only fires on two
+   * syntactically adjacent `x = <expr>;` statements where the
+   * left-hand sides are the same bare identifier and the second
+   * statement's right-hand side does not reference `x` itself — almost
+   * always a leftover from refactoring.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-useless-assignment
+   */
+  "no-useless-assignment"?: TtscLintRuleSetting;
+
+  /**
+   * Reject unnecessary `.call()` / `.apply()` calls (such as
+   * `f.call(undefined, x)`).
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-useless-call
+   */
+  "no-useless-call"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `catch (e) { throw e }` patterns that only rethrow the
+   * caught error without adding context or handling.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-useless-catch
+   */
+  "no-useless-catch"?: TtscLintRuleSetting;
+
+  /**
+   * Reject computed property keys whose expression is a literal
+   * identifier (`{ ["foo"]: 1 }`).
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-useless-computed-key
+   */
+  "no-useless-computed-key"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `"a" + "b"` and similar concatenations where every operand
+   * is a literal string.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-useless-concat
+   */
+  "no-useless-concat"?: TtscLintRuleSetting;
+
+  /**
+   * Reject empty constructor bodies (`class X { constructor() {} }`)
+   * that add nothing over the implicit constructor.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-useless-constructor
+   */
+  "no-useless-constructor"?: TtscLintRuleSetting;
+
+  /**
+   * Reject unnecessary escape sequences in strings and regex
+   * literals, such as `"\."` or `/\,/`. Autofixable.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-useless-escape
+   */
+  "no-useless-escape"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `{ x: x }` destructuring renames that bind back to the
+   * same name. Autofixable.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-useless-rename
+   */
+  "no-useless-rename"?: TtscLintRuleSetting;
+
+  /**
+   * Reject a bare `return;` whose only effect is to end a function
+   * body that would have returned anyway. The conservative baseline
+   * only fires on the last statement of a function-like's immediate
+   * body — earlier `return;` inside a branch or loop may still be
+   * load-bearing.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-useless-return
+   */
+  "no-useless-return"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `var` declarations.
+   *
+   * Use `let` for mutable bindings and `const` for immutable ones.
+   * Autofixable to `let`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-var
+   */
+  "no-var"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `with (...)` statements.
+   *
+   * `with` is forbidden in strict mode (and therefore in modules),
+   * defeats lexical scoping, and blocks engine optimization.
+   *
+   * @reference https://eslint.org/docs/latest/rules/no-with
+   */
+  "no-with"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `{ foo: foo }` and similar object-literal shorthand
+   * candidates in favor of `{ foo }`. Autofixable.
+   *
+   * @reference https://eslint.org/docs/latest/rules/object-shorthand
+   */
+  "object-shorthand"?: TtscLintRuleSetting;
+
+  /**
+   * Prefer compound assignment (`x += y`) over the long form
+   * (`x = x + y`) where the two are equivalent.
+   *
+   * @reference https://eslint.org/docs/latest/rules/operator-assignment
+   */
+  "operator-assignment"?: TtscLintRuleSetting;
+
+  /**
+   * Reject `function() { ... }` expressions passed as callback arguments — prefer the arrow form.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-arrow-callback
+   */
+  "prefer-arrow-callback"?: TtscLintRuleSetting;
+
+  /**
+   * Require `const` for variables that are never reassigned after
+   * declaration. Autofixable for single-declaration `let`s.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-const
+   */
+  "prefer-const"?: TtscLintRuleSetting;
+
+  /**
+   * Reject single-property and single-index variable declarations
+   * (`const a = obj.a`, `const x = arr[0]`) that destructuring would
+   * replace verbatim.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-destructuring
+   */
+  "prefer-destructuring"?: TtscLintRuleSetting;
+
+  /**
+   * Prefer the `**` operator over `Math.pow(base, exp)`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-exponentiation-operator
+   */
+  "prefer-exponentiation-operator"?: TtscLintRuleSetting;
+
+  /**
+   * Prefer `for..of` over a traditional `for (let i = 0; i <
+   * arr.length; i++)` loop when the index is never used inside the
+   * body.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-for-of
+   */
+  "prefer-for-of"?: TtscLintRuleSetting;
+
+  /**
+   * Prefer `Object.hasOwn(obj, key)` over
+   * `Object.prototype.hasOwnProperty.call(obj, key)`. The new helper
+   * is shorter, less error-prone, and matches the form linters
+   * elsewhere recommend.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-object-has-own
+   */
+  "prefer-object-has-own"?: TtscLintRuleSetting;
+
+  /**
+   * Prefer object-spread `{ ...a, ...b }` over `Object.assign({}, a, b)`.
+   * Only fires when the first argument is an empty object literal —
+   * mutating `Object.assign(target, …)` calls are left alone because
+   * the spread form does not preserve their observable side effects.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-object-spread
+   */
+  "prefer-object-spread"?: TtscLintRuleSetting;
+
+  /**
+   * Reject regex literals with unnamed capturing groups `(...)` — prefer named groups `(?<name>...)`.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-named-capture-group
+   */
+  "prefer-named-capture-group"?: TtscLintRuleSetting;
+
+  /**
+   * Prefer ES2015+ numeric literal forms (`0b…`, `0o…`, `0x…`) over
+   * `parseInt(string, 2 | 8 | 16)`. The literal form is shorter, type-
+   * safe at lint time, and not subject to runtime radix mismatches.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-numeric-literals
+   */
+  "prefer-numeric-literals"?: TtscLintRuleSetting;
+
+  /**
+   * Reject reading from `arguments` in a non-arrow function body —
+   * prefer the ES2015 rest-parameter form `(...args)`, which declares
+   * the variadic contract on the signature and yields a real array.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-rest-params
+   */
+  "prefer-rest-params"?: TtscLintRuleSetting;
+
+  /**
+   * Prefer spread arguments `f(...args)` over `f.apply(null, args)`.
+   *
+   * Only flags `apply` calls whose `this` argument is provably the
+   * same receiver (or `null` / `undefined`); calls that genuinely
+   * rebind `this` are left alone.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-spread
+   */
+  "prefer-spread"?: TtscLintRuleSetting;
+
+  /**
+   * Prefer template literals over string concatenation when any
+   * operand is non-literal.
+   *
+   * @reference https://eslint.org/docs/latest/rules/prefer-template
+   */
+  "prefer-template"?: TtscLintRuleSetting;
+
+  /**
+   * Require an explicit radix argument for `parseInt(str, radix)`.
+   *
+   * Without it, `"0123"` parses as decimal or octal depending on the
+   * engine.
+   *
+   * @reference https://eslint.org/docs/latest/rules/radix
+   */
+  "radix"?: TtscLintRuleSetting;
+
+  /**
+   * Require generator functions to contain at least one `yield`. A
+   * `yield`-less generator is almost always a typo.
+   *
+   * @reference https://eslint.org/docs/latest/rules/require-yield
+   */
+  "require-yield"?: TtscLintRuleSetting;
+
+  /**
+   * Reject import specifiers within a single `import` declaration that aren't alphabetically sorted.
+   *
+   * @reference https://eslint.org/docs/latest/rules/sort-imports
+   */
+  "sort-imports"?: TtscLintRuleSetting;
+
+  /**
+   * Reject object-literal property keys that aren't alphabetically sorted.
+   *
+   * @reference https://eslint.org/docs/latest/rules/sort-keys
+   */
+  "sort-keys"?: TtscLintRuleSetting;
+
+  /**
+   * Require `Number.isNaN` / `isNaN` for `NaN` checks; restrict
+   * `typeof` comparisons to the documented strings.
+   *
+   * @reference https://eslint.org/docs/latest/rules/use-isnan
+   */
+  "use-isnan"?: TtscLintRuleSetting;
+
+  /**
+   * Restrict the right-hand operand of `typeof` to the documented
+   * strings (`"number"`, `"object"`, ...) so `typeof x === "undefiend"`
+   * typos are caught.
+   *
+   * @reference https://eslint.org/docs/latest/rules/valid-typeof
+   */
+  "valid-typeof"?: TtscLintRuleSetting;
+
+  /**
+   * Require `var` declarations to be hoisted to the top of their
+   * scope by hand, mirroring how the engine treats them.
+   *
+   * Has no effect when `no-var` forbids `var` altogether.
+   *
+   * @reference https://eslint.org/docs/latest/rules/vars-on-top
+   */
+  "vars-on-top"?: TtscLintRuleSetting;
+
+  /**
+   * Reject Yoda-style comparisons (`if (42 === x)`); use
+   * `if (x === 42)` so the variable comes first.
+   *
+   * @reference https://eslint.org/docs/latest/rules/yoda
+   */
+  "yoda"?: TtscLintRuleSetting;
+}