JS-1997 Fix S1848 RegExp validation FP

[francois-mora-sonarsource]

Part of JS-1997

Summary

• Suppress S1848 for discarded built-in RegExp constructors used as a validation step before returning parsed regex data.
• Keep reporting arbitrary discarded RegExp constructors, unrelated returns, and locally shadowed RegExp/globalThis constructors.
• Add JS/TS-focused unit coverage for the Jira reproducer and guardrails.

Validation

• npm run generate-meta
• npx tsx --test packages/analysis/src/jsts/rules/S1848/**/*.test.ts
• npm run eslint-plugin:check
• npx prettier --check packages/analysis/src/jsts/rules/S1848/rule.ts packages/analysis/src/jsts/rules/S1848/unit.test.ts

[hashicorp-vault-sonar-prod]

JS-1997

[github-actions]

Ruling Report

✅ No changes to ruling expected issues in this PR

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
86.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[erwan-leforestier-sonarsource]

I would challenge the need for verifying that the next statement is a "return statement". Most likely a new RegExp(...) statement is always about validating a string, regardless of what follows this line. Wdyt ?

[francois-mora-sonarsource]

I kept the return check intentionally to make the exception prove a very specific intent: the discarded new RegExp(...) is used to validate a value that is immediately returned.

A later use of the same identifier is weaker evidence. For example, this should still be reported:

new RegExp(pattern); // forgot: this.regexp = new RegExp(pattern);
this.pattern = pattern;

Here pattern is reused afterwards, but that does not show the constructor was only for validation. It is also compatible with a real S1848 bug where the regexp result was meant to be stored and got discarded by mistake.

So the current heuristic is deliberately narrow:

• built-in RegExp
• immediate following return
• returned value directly contains one of the validated identifier arguments

That felt like the safest boundary for JS-1997. If we want to broaden it later, I think we would need more concrete cases than just identifier being used afterwards.

[erwan-leforestier-sonarsource]

Thanks for the explanation, i'm ok with that

[gitar-bot]

Code Review ✅ Approved

Refines RegExp constructor validation logic to suppress false positives in S1848 while maintaining strict checks for discarded instances. Comprehensive unit coverage confirms the fix for the specified JS-1997 use case.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}