Fix the type parameter naming rule by safely casting TypeScript AST visitor nodes and checking mapped type keys in addition to regular type parameter declarations. This resolves the previous bridge compilation error and the missing issue for mapped type parameters while staying within the approved syntax-based algorithm.

Detect TypeScript type parameter declarations whose names do not match the configured naming convention.

Aligned the S119 report message with the approved RSPEC text by removing the extra trailing period, and updated the exact-message assertions accordingly.

…rc/jsts/rules/S119/rule.ts

Comment: **Bug: `String.prototype.match` is used instead of `RegExp.prototype.test`.** `name.match(format)` passes a string to `match()`, which internally calls `new RegExp(format)` — this is fine for correctness, but it silently carries a subtle footgun: if the user-supplied `format` string contains anchors (`^`, `$`) or the default `^[A-Z][a-zA-Z0-9]*$`, `match` returns the matched substring array, not a boolean, and truthiness works accidentally. More importantly, `match` without the `g` flag checks for a *partial* match — only a prefix/suffix anchor in the pattern makes it behave like a full-string check. This means a format like `^[A-Z]` (no `$` anchor) would incorrectly pass `ABcd_123` even if the intent is a full match.

The idiomatic, safe, and explicit approach is `new RegExp(format).test(name)`. This also avoids a subtle `lastIndex`-mutation bug if the user supplies a `/g` pattern.

Note: the default pattern `^[A-Z][a-zA-Z0-9]*$` does have both anchors, so existing tests pass — but a custom format without both anchors will silently do partial matching.

```suggestion
  if (!new RegExp(format).test(name)) {
```

- [ ] Mark as noise

…rc/jsts/rules/S119/rule.ts

Comment: **Bug: `TSMappedType.key` is visited even when the mapped-type key is *not* a type parameter declaration.** In TypeScript's AST, `TSMappedType.key` is an `Identifier` that is always the key variable being iterated — e.g. `{ [K in keyof T]: ... }` — so this is correct for the direct mapped-type case.

However, there is a deeper issue: the `TSTypeParameter` visitor already fires for the implicit type parameter created by a mapped type key binder in some parser versions. Depending on the `@typescript-eslint` parser version, the mapped-type key may *also* be surfaced as a `TSTypeParameter` node, causing the identifier to be checked **twice** — once by `TSTypeParameter` and once by `TSMappedType`. You can verify by adding a test with a compliant mapped-type key that contains an invalid inner type parameter name and checking the error count.

If double-reporting is occurring, the fix is to remove the `TSMappedType` visitor entirely (the `TSTypeParameter` visitor covers it), or guard it with a check that the parent of the `TSTypeParameter` is not a `TSMappedType`.

- [ ] Mark as noise

…rc/jsts/rules/S119/rule.ts

Comment: **Bug: invalid `format` strings will throw an uncaught `SyntaxError` at analysis time.** `new RegExp(format)` (implicit inside `String.prototype.match` today, explicit after the fix above) throws if `format` is not a valid regular expression. There is no validation or try/catch, so a user-supplied bad regex will crash the rule for every file analysed.

Add a guard when constructing the regex:

```ts
let regexp: RegExp;
try {
  regexp = new RegExp(format);
} catch {
  context.report({ messageId: 'invalidFormat', ... });
  return {};
}
```

Or, validate once in `create()` before returning the visitors and fall back to the default pattern with a warning.

- [ ] Mark as noise

…rc/jsts/rules/S119/unit.test.ts

Comment: **Missing test coverage: type-alias usage sites are in the valid list but are not defined there as type parameters.** The valid case at line 84–90 (`const value: Promise<result_data>`, `Map<key, value>`, etc.) tests *usages* of type arguments — these are `TSTypeReference` nodes, not `TSTypeParameter` declarations, so the rule never fires on them. Including them is fine for documentation purposes, but there is no test verifying that a bare `TSTypeParameter` with a compliant name inside a `type` alias is *valid*. Add an explicit valid case like:

```ts
type Alias<MyParam> = MyParam | null;
```

to cover the `type` alias declaration path in the `TSTypeParameter` visitor.

- [ ] Mark as noise

S119 only checked TSTypeParameter nodes, but mapped type parameter names are exposed by the parser as TSMappedType.key. This skipped names like property_name in mapped types and caused the unit test to report one fewer issue than expected.

Add a TSMappedType visitor that reuses the existing type parameter naming check for mapped type keys.

…rc/jsts/rules/S119/rule.ts

Comment: **Bug: invalid `format` strings are silently swallowed.** When the user-supplied `format` is not a valid regex, `buildRegExp` catches the `SyntaxError` and falls back to `DEFAULT_FORMAT` without any diagnostic. The rule then silently enforces the default pattern instead of the one the user configured — a confusing, invisible failure.

Either report a configuration error (preferred) or at minimum log a warning. If a report is preferred, the guard belongs in `create()` so it fires once per file, not once per identifier:

```ts
create(context) {
  const rawFormat = (context.options as FromSchema<typeof meta.schema>)[0]?.format ?? DEFAULT_FORMAT;
  let regexp: RegExp;
  try {
    regexp = new RegExp(rawFormat);
  } catch {
    // Invalid regex — fall back silently or report once and return no visitors
    return {};
  }
  const format = rawFormat;
  // ... return visitors
}
```

Dropping `buildRegExp` entirely and inlining the try/catch in `create()` avoids the silent fallback.

- [ ] Mark as noise

S119 only validated TSTypeParameter nodes, so mapped type keys such as
[property_name in keyof Source] were skipped even though the unit test
expects them to follow the configured type parameter naming format.

Validate TSMappedType key identifiers with the existing naming check.

…rc/jsts/rules/S119/rule.ts

Comment: **Logic duplication:** `DEFAULT_FORMAT` is defined here as `'^[A-Z][a-zA-Z0-9]*$'` and also independently defined with the same string literal in `unit.test.ts` (line 22) and matches the `default` value in `config.ts` (line 26). If the default pattern ever changes, all three places need updating in sync.

The canonical value belongs in `config.ts` (which already holds it as the `default` field). `rule.ts` should import and reference it from there, and `unit.test.ts` should import it from `config.ts` rather than re-declaring it.

- [ ] Mark as noise

…rc/jsts/rules/S119/rule.ts

Comment: **Bug: `TSMappedType` visitor is almost certainly redundant and risks double-reporting.**

The standalone invalid test added at line 155 of `unit.test.ts`:
```ts
{ code: `type PickValues<Source> = { [property_name in keyof Source]: Source[property_name] };`, errors: [error()] }
```
expects exactly **1** error. If `@typescript-eslint` surfaces the mapped-type key binder as a `TSTypeParameter` node (which it does in all modern versions), both the `TSTypeParameter` visitor and the `TSMappedType` visitor will fire on the same `property_name` identifier — producing 2 errors, not 1.

The fact that the test passes with 1 error means one of:
1. The `TSTypeParameter` visitor covers it and `TSMappedType` is never reached (making `TSMappedType` dead code), OR
2. The `TSTypeParameter` visitor is NOT covering it and `TSMappedType` is the sole handler — but then the compound test at line 127 (`class EventBus<event_1, handlerType> {} type PickValues<Source> = { [property_name in keyof Source]: ... } ...`) listing 7 errors may be under-counting.

Verify by temporarily removing `TSMappedType` and running the tests. If they pass, the visitor is redundant — delete it.

```suggestion
      TSTypeParameter: (node: unknown) => {
        // Safe: ESLint invokes this visitor only for TSTypeParameter nodes.
        const typeParameter = node as TSESTree.TSTypeParameter;
        checkIdentifier(typeParameter.name, format, regexp, context);
      },
```

- [ ] Mark as noise

S119 only visited TSTypeParameter nodes, so mapped type keys like
[property_name in keyof Source] were not validated against the configured
type parameter naming format. Add TSMappedType key validation through the
existing identifier check.

S119 only checked TSTypeParameter visitor nodes, so parser constructs that
store type parameter names on TSInferType and TSMappedType were missed. Add
explicit checks for inferred and mapped type parameter identifiers.