Define JavaScript/JSX coverage contract for unsafe_type_assertion

[CodeDeficient]

Finding

The AST migration (PR #24) removed the regex-based unsafe_type_assertion pattern and replaced it with a never-match sentinel (/(?!)/). The AST detection in findUnsafeAssertions() only runs for .ts and .tsx file extensions. Since the regex path is also skipped for .js and .jsx, those targets no longer produce unsafe_type_assertion findings.

However:

• AISlopDetector.targetExtensions includes .js and .jsx.
• Standard JavaScript does not support TypeScript as assertion syntax, so detecting as any in .js files via AST is not valid.
• The old regex path would have detected as any in .js files, which may have produced false positives in JavaScript codebases where as is a valid identifier.

Open Questions (Need Decision)

1. Is .js/.jsx support for unsafe_type_assertion intentional?

   • If yes: find equivalent detection (parser/compatibility layer) that handles whatever subset is valid.
   • If no: remove .js/.jsx from the supported scope for this pattern and document the boundary.

2. If JS/JSX support is removed, should it be removed for all AST-based patterns or only unsafe_type_assertion?

   • unsafe_double_type_assertion, unsafe_object_assertion, unsafe_array_assertion all share the same AST-gate and would have the same issue.

Evidence

• ai-slop-detector.ts:1031-1036 — regex path skips unsafe_type_assertion for all extensions.
• ai-slop-detector.ts:178 — findUnsafeAssertions accepts only .ts and .tsx script kinds.
• targetExtensions — includes .js, .jsx, .ts, .tsx.

Requirements (apply after decision)

If JS/JSX support is kept:

• .js and .jsx files must detect the same as any patterns as .ts/.tsx or produce equivalent behavior.
• No false positives for standard JavaScript as keyword usage.

If JS/JSX support is dropped:

• unsafe_type_assertion must be explicitly documented as TypeScript/TSX-only.
• Target extension documentation must reflect this boundary.
• The regex sentinel must remain a never-match (no change needed).

Constraints

• Do not reintroduce regex detection for unsafe_type_assertion without proving it does not create false positives.
• Do not change extension handling for patterns unrelated to assertion detection.
• Do not modify findUnsafeAssertions to accept JavaScript script kinds without verifying it handles the syntax differences correctly.

Validation

1. Reproduce behavior for .js and .jsx against the merged PR baseline.
2. Document the reproduction result in this issue.
3. Based on the decision:
   • Implement and test the chosen path.
   • Or document the decision and close without implementation.

[coderabbitai]

🔗 Related PRs

#9 - fix: resolve all false positives (issues #2, #6, #7, #8) [closed]
#23 - feat: detect unsafe TypeScript type assertions via AST (issue #22) [open]
#24 - feat: migrate unsafe_type_assertion from regex to AST detection [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!