biome style/useNamingConvention: fix is not a fixpoint

Summary

- Name: useNamingConvention
- Fix: safe
- Default severity: info
- Available from version: 1.0.0
- Diagnostic category: lint/style/useNamingConvention


Description

 Enforce naming conventions for everything across a codebase.

 Enforcing [naming conventions](https://en.wikipedia.org/wiki/Naming_convention_(programming)) helps to keep the codebase consistent,
 and reduces overhead when thinking about the name [case] of a variable.

 The following section describes the default conventions enforced by the rule.
 You can also enforce custom conventions with the [rule options](#options).

Naming conventions

 All names can be prefixed and suffixed with underscores `_` and dollar signs `$`.
 Unused variables with a name prefixed with `_` are completely ignored.
 This avoids conflicts with the `noUnusedVariables` rule.

Variable and parameter names

 All variables and function parameters are in [`camelCase`] or [`PascalCase`].
 Catch parameters are in [`camelCase`].

 Additionally, global variables declared as `const` or `var` may be in [`CONSTANT_CASE`].
 Global variables are declared at module or script level.
 Variables declared in a TypeScript `namespace` are also considered global.

 ```js
 function f(param, _unusedParam) {
     let localValue = 0;
     try {
         /* ... */
     } catch (customError) {
         /* ... */
     }
 }

 export const A_CONSTANT = 5;

 let aVariable = 0;

 export namespace ns {
     export const ANOTHER_CONSTANT = "";
 }
 ```

 Examples of incorrect names:

 ```js,expect_diagnostic
 let a_value = 0;
 ```

 ```js,expect_diagnostic
 const fooYPosition = 0;
 ```

 ```js,expect_diagnostic
 function f(FIRST_PARAM) {}
 ```

Function names

 - A `function` name is in [`camelCase`] or [`PascalCase`].
 - A global `function` can also be in `UPPERCASE`.
   This allows supporting the frameworks that require some function to use valid [HTTP method names](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods).

 ```jsx
 function trimString(s) { /*...*/ }

 function Component() {
     return <div></div>;
 }

 export function GET() { /*...*/ }
 ```

TypeScript `enum` names

 A _TypeScript_ `enum` name is in [`PascalCase`].

 `enum` members are by default in [`PascalCase`].
 However, you can configure the [case] of `enum` members.
 See [options](#options) for more details.

 ```ts
 enum Status {
     Open,
     Close,
 }
 ```

Classes

 - A class name is in [`PascalCase`].

 - Static property and static getter names are in [`camelCase`] or [`CONSTANT_CASE`].

 - Class property and method names are in [`camelCase`].

 ```js
 class Person {
     static MAX_FRIEND_COUNT = 256;

     static get SPECIAL_PERSON_INSTANCE() { /*...*/ }

     initializedProperty = 0;

     specialMethod() {}
 }
 ```

TypeScript `type` aliases and `interface`

 - A `type` alias or an interface name are in [`PascalCase`].

 - Member names of a type are in [`camelCase`].

 - `readonly` property and getter names can also be in [`CONSTANT_CASE`].

 ```ts
 type Named = {
     readonly fullName: string;

     specialMethod(): void;
 };

 interface Named {
     readonly fullName: string;

     specialMethod(): void;
 }

 interface PersonConstructor {
     readonly MAX_FRIEND_COUNT: number;

     get SPECIAL_PERSON_INSTANCE(): Person;

     new(): Person;
 }
 ```

 Examples of an incorrect type alias:

 ```ts,expect_diagnostic
 type person = { fullName: string };
 ```

Literal object member names

 - Literal object members are in [`camelCase`].

 ```js
 const alice = {
     fullName: "Alice",
 }
 ```

 Example of an incorrect name:

 ```js,expect_diagnostic
 const alice = {
     full_name: "Alice",
 }
 ```

Import and export aliases and namespaces

 Import and export namespaces are in [`camelCase`] or [`PascalCase`].

 ```js
 import * as myLib from "my-lib";
 import * as Framework from "framework";

 export * as myLib from "my-lib";
 export * as Framework from "framework";
 ```

 `import` and `export` aliases are in [`camelCase`], [`PascalCase`], or [`CONSTANT_CASE`]:

 ```js
 import assert, {
     deepStrictEqual as deepEqual,
     AssertionError as AssertError
 } from "node:assert";
 ```

 Examples of an incorrect name:

 ```ts,expect_diagnostic
 import * as MY_LIB from "my-lib";
 ```

TypeScript type parameter names

 A _TypeScript_ type parameter name is in [`PascalCase`].

 ```ts
 function id<Val>(value: Val): Val { /* ... */}
 ```

TypeScript `namespace` names

 A _TypeScript_ `namespace` name is in [`camelCase`] or in [`PascalCase`].

 ```ts
 namespace mathExtra {
     /*...*/
 }

 namespace MathExtra {
     /*...*/
 }
 ```

Ignored declarations

 Note that some declarations are always ignored.
 You cannot apply a convention to them.
 This is the case for:

 - Member names that are not identifiers

   ```js
   class C {
     ["not an identifier"]() {}
   }
   ```

 - Named imports

  ```js
   import { an_IMPORT } from "mod"
   ```

 - Destructured object properties

   ```js
   const { destructed_PROP } = obj;
   ```

 - Class members marked with `override`:

   ```ts
   class C extends B {
     override overridden_METHOD() {}
   }
   ```

 - Declarations inside an external TypeScript module

   ```ts
   declare module "myExternalModule" {
     export interface my_INTERFACE {}
   }
   ```

 - Declarations inside a global declaration

   ```ts
   declare global {
     interface HTMLElement {}
   }
   ```

Options

 The rule provides several options that are detailed in the following subsections.

 ```json,options
 {
     "options": {
         "strictCase": false,
         "requireAscii": false,
         "conventions": [
             {
                 "selector": {
                     "kind": "classMember",
                     "modifiers": ["private"]
                 },
                 "match": "_(.+)",
                 "formats": ["camelCase"]
             }
         ]
     }
 }
 ```

strictCase

 When this option is set to `true`, it forbids consecutive uppercase characters in [`camelCase`] and [`PascalCase`].

 **Default:** `true`

 For instance, `HTTPServer` or `aHTTPServer` are not permitted for `strictCase: true`.
 These names should be renamed to `HttpServer` and `aHttpServer`:

 ```json,options
 {
     "options": {
         "strictCase": true
     }
 }
 ```

 ```js,expect_diagnostic,use_options
 class HTTPServer {
 }
 ```

 When `strictCase` is set to `false`, consecutive uppercase characters are allowed.
 For example, `HTTPServer` and `aHTTPServer` would be considered valid then:

 ```json,options
 {
     "options": {
         "strictCase": false
     }
 }
 ```

 ```js,use_options
 class HTTPServer {
 }
 ```

requireAscii

 When `true`, names must only consist of ASCII characters only,
 forbidding names like `café` or `안녕하세요` that include non-ASCII characters.

 When `requireAscii` is set to `false`, names may include non-ASCII characters.
 For example, `café` and `안녕하세요` would be considered valid then.

 **Default:** `true`

conventions

 The `conventions` option allows applying custom conventions.
 The option takes an array of conventions.
 Every convention is an object that includes an optional `selector` and one or more requirements (`match` and `formats`).

 For example, you can enforce the use of [`CONSTANT_CASE`] for global `const` declarations:

 ```json,options
 {
     "options": {
         "conventions": [
             {
                 "selector": {
                     "kind": "const",
                     "scope": "global"
                 },
                 "formats": ["CONSTANT_CASE"]
             }
         ]
     }
 }
 ```

 A selector describes which declarations the convention applies to.
 You can select a declaration based on several criteria:

 - `kind`: the kind of the declaration among:
   - `any` (default kind if the kind is unset)
   - `typeLike`: classes, enums, type aliases, and interfaces
   - `class`
   - `enum`
   - `enumMember`
   - `interface`
   - `typeAlias`
   - `function`: named function declarations and expressions
   - `namespaceLike`: TypeScript namespaces, import and export namespaces (`import * as namespace from`)
   - `namespace`: TypeScript namespaces
   - `importNamespace`
   - `exportNamespace`
   - `importAlias`: default imports and aliases of named imports
   - `exportAlias`: aliases of re-exported names
   - `variable`: const, let, using, and var declarations
     - `const`
     - `let`
     - `var`
     - `using`
   - `functionParameter`
   - `catchParameter`
   - `indexParameter`: parameters of index signatures
   - `typeParameter`: generic type parameter
   - `classMember`: class properties, parameter properties, methods, getters, and setters
     - `classProperty`: class properties, including parameter properties
     - `classMethod`
     - `classGetter`
     - `classSetter`
   - `objectLiteralMember`: literal object properties, methods, getters, and setters (you might want to duplicate the convention for `typeMember`)
     - `objectLiteralProperty`
     - `objectLiteralMethod`
     - `objectLiteralGetter`
     - `objectLiteralSetter`
   - `typeMember`: properties, methods, getters, and setters declared in type aliases and interfaces
     - `typeProperty`
     - `typeMethod`
     - `typeGetter`
     - `typeSetter`
 - `modifiers`: an array of modifiers among:
   - `abstract`: applies to class members and classes
   - `private`: applies to class members
   - `protected`: applies to class members
   - `readonly`: applies to class members and type members
   - `static`: applies to class members
 - `scope`: where the declaration appears. Allowed values:
   - `any`: anywhere (default value if the scope is unset)
   - `global`: the global scope (also includes the namespace scopes)

 For each declaration,
 the `conventions` array is traversed in-order until a selector selects the declaration.
 The requirements of the convention are so verified on the declaration.

 A convention must set at least one requirement among:

 - `match`: a regular expression that the name of the declaration must match.
 - `formats`: the string [case] that the name must follow.
   The supported cases are: [`PascalCase`], [`CONSTANT_CASE`], [`camelCase`], and [`snake_case`].

 If only `formats` is set, it's checked against the name of the declaration.
 In the following configuration, we require `static readonly` class properties to be in [`CONSTANT_CASE`].

 ```json,options
 {
     "options": {
         "conventions": [
             {
                 "selector": {
                     "kind": "classProperty",
                     "modifiers": ["static", "readonly"]
                 },
                 "formats": ["CONSTANT_CASE"]
             }
         ]
     }
 }
 ```

 The following code is then reported by the rule:

 ```ts,use_options,expect_diagnostic
 class C {
     static readonly prop = 0;
 }
 ```

 A convention can make another one useless.
 In the following configuration, the second convention is useless because the first one always applies to class members, including class properties.
 You should always place first more specific conventions.

 ```json,options
 {
     "options": {
         "conventions": [
             {
                 "selector": { "kind": "classMember" },
                 "formats": ["camelCase"]
             },
             {
                 "selector": { "kind": "classProperty" },
                 "formats": ["camelCase", "CONSTANT_CASE"]
             }
         ]
     }
 }
 ```

 If only `match` is set and the regular expression has no capturing groups,
 then `match` is checked against the name of the declaration directly.
 In the following configuration, all variable names must have a minimum of 3 characters and a maximum of 20 characters.

 ```json,options
 {
     "options": {
         "conventions": [
             {
                 "selector": { "kind": "variable" },
                 "match": ".{3,20}"
             }
         ]
     }
 }
 ```

 If both `match` and `formats` are set, then `formats` is checked against the first capture of the regular expression.
 Only the first capture is tested. Other captures are ignored.
 If nothing is captured, then `formats` is ignored.

 In the following example, we require that:

 - A private property starts with `_` and consists of at least two characters.
 - The captured name (the name without the leading `_`) is in [`camelCase`].

 ```json,options
 {
     "options": {
         "conventions": [
             {
                 "selector": { "kind": "classMember", "modifiers": ["private"] },
                 "match": "_(.+)",
                 "formats": ["camelCase"]
             }
         ]
     }
 }
 ```

 If `match` is set and `formats` is unset, then the part of the name captured by the regular expression is forwarded to the next conventions of the array that selects the declaration.
 The following configuration has exactly the same effect as the previous one.
 The first convention applies to any private class member name.
 It stipulates that the name must have a leading underscore.
 The regular expression captures the part of the name without the leading underscore.
 Because `formats` is not set, the capture is forwarded to the next convention that applies to a private class member name.
 In our case, the next convention applies.
 The capture is then checked against `formats`.

 ```jsonc,options
 {
     "options": {
         "conventions": [
             {
                 "selector": { "kind": "classMember", "modifiers": ["private"] },
                 "match": "_(.+)"
                 // We don't need to specify `formats` because the capture is forwarded to the next conventions.
             }, {
                 "selector": { "kind": "classMember", "modifiers": ["private"] },
                 "formats": ["camelCase"]
             }
         ]
     }
 }
 ```

 The forwarding has particularly useful to factorize some conventions.
 For example, the following configuration...

 ```jsonc,options
 {
     "options": {
         "conventions": [
             {
                 "selector": { "kind": "classMember", "modifiers": ["private"] },
                 "match": "_(.+)",
                 "formats": ["camelCase"]
             }, {
                 "selector": { "kind": "classMember" },
                 "formats": ["camelCase"]
             }
         ]
     }
 }
 ```

 can be factorized to...

 ```jsonc,options
 {
     "options": {
         "conventions": [
             {
                 "selector": { "kind": "classMember", "modifiers": ["private"] },
                 "match": "_(.+)"
             }, {
                 "selector": { "kind": "classMember" },
                 "formats": ["camelCase"]
             }
         ]
     }
 }
 ```

 If a declaration is not selected or if a capture is forwarded while there are no more conventions,
 then the declaration name is verified against the default conventions.
 Because the default conventions already ensure that class members are in ["camelCase"],
 the previous example can be simplified to:

 ```jsonc,options
 {
     "options": {
         "conventions": [
             {
                 "selector": { "kind": "classMember", "modifiers": ["private"] },
                 "match": "_(.+)"
                 // We don't need to specify `formats` because the capture is forwarded to the next conventions.
             }
             // default conventions
         ]
     }
 }
 ```

 If the capture is identical to the initial name (it is not a part of the initial name),
 then, leading and trailing underscore and dollar signs are trimmed before being checked against default conventions.
 In the previous example, the capture is a part of the name because `_` is not included in the capture, thus, no trimming is performed.

 You can reset all default conventions by adding a convention at the end of the array that accepts anything:

 ```jsonc,options
 {
     "options": {
         "conventions": [
             // your conventions
             // ...

             // Otherwise, accept anything
             {
                 "match": ".*"
             }
         ]
     }
 }
 ```

 Let's take a more complex example with the following conventions:

 1. A variable name is `i`, `j`, or follows the next selected convention (convention (2)).
 2. An identifier contains at least two characters and follow the next selected convention (the default convention).
 3. A `private` class member name starts with an underscore `_` and the name without the underscore follows the next selected convention (convention (4) for some of them, and the default convention for others).
 4. A `static readonly` class property name is in [`CONSTANT_CASE`].
 5. A global constant is in [`CONSTANT_CASE`] and can be enclosed by double underscores or to be named `_SPECIAL_`.
 6. An interface name starts with `I`, except for interfaces ending with `Error`, and is in [`PascalCase`].
 7. All other names follow the default conventions

 ```jsonc,options
 {
     "options": {
         "conventions": [
             {
                 "selector": {
                     "kind": "variable"
                 },
                 "match": "[ij]|(.*)"
             },
             {
                 "match": "(.{2,})"
             },
             {
                 "selector": {
                     "kind": "classMember",
                     "modifiers": ["private"]
                 },
                 "match": "_(.*)"
             }, {
                 "selector": {
                     "kind": "classProperty",
                     "modifiers": ["static", "readonly"]
                 },
                 "formats": ["CONSTANT_CASE"]
             }, {
                 "selector": {
                     "kind": "const",
                     "scope": "global"
                 },
                 "match": "__(.+)__|_SPECIAL_|(.+)",
                 "formats": ["CONSTANT_CASE"]
             }, {
                 "selector": {
                     "kind": "interface"
                 },
                 "match": "I(.*)|(.*?)Error",
                 "formats": ["PascalCase"]
             }
             // default conventions
         ]
     }
 }
 ```

 Hers some examples:

 - A private class property named `_` is reported by the rule because it contains a single character.
   According to the second convention, the name should contain at least two characters.
 - A variable `a_variable` is reported by the rule because it doesn't respect the default convention that forbid variable names in [`snake_case`].
   The variable name is first verified against the first convention.
   It is forwarded to the second convention, which is also respected, because it is neither `i` nor `j`.
   The name is captured and is forwarded to the next convention.
   In our case, the next convention is the default one.

Regular expression syntax

 The `match` option takes a regular expression that supports the following syntaxes:

 - Greedy quantifiers `*`, `?`, `+`, `{n}`, `{n,m}`, `{n,}`, `{m}`
 - Non-greedy quantifiers `*?`, `??`, `+?`, `{n}?`, `{n,m}?`, `{n,}?`, `{m}?`
 - Any character matcher `.`
 - Character classes `[a-z]`, `[xyz]`, `[^a-z]`
 - Alternations `|`
 - Capturing groups `()`
 - Non-capturing groups `(?:)`
 - Case-insensitive groups `(?i:)` and case-sensitive groups `(?-i:)`
 - A limited set of escaped characters including all special characters
   and regular string escape characters `\f`, `\n`, `\r`, `\t`, `\v`.
   Note that you can also escape special characters using character classes.
   For example, `\$` and `[$]` are two valid patterns that escape `$`.

 [case]: https://en.wikipedia.org/wiki/Naming_convention_(programming)#Examples_of_multiple-word_identifier_formats
 [`camelCase`]: https://en.wikipedia.org/wiki/Camel_case
 [`PascalCase`]: https://en.wikipedia.org/wiki/Camel_case
 [`CONSTANT_CASE`]: https://en.wikipedia.org/wiki/Snake_case
 [`snake_case`]: https://en.wikipedia.org/wiki/Snake_case