Replace find() with some() for existence checks and convert array to Set

[sonarqube-agent]

This PR was automatically created by the Remediation Agent's Scheduled backlog remediation feature.

Why these issues? The S7754 rule appears in 4 issues across distinct files, providing strong cohesion for a single PR focused on the mechanical .find() → .some() refactoring. The S7776 Set optimization was included from the same package to address a related array-based lookup pattern. All changes are low-risk, high-confidence improvements with clear functional and performance benefits.

This PR fixes 5 SonarQube code smells by replacing .find() with .some() in 4 files where the intent is to check for element existence rather than retrieve the element, and by converting BLOCKCHAIN_MODULES from an array to a Set for O(1) lookup performance. These changes improve code clarity, performance, and align with JavaScript best practices.

View Project in SonarCloud

---

Fixed Issues

typescript:S7776 - `BLOCKCHAIN_MODULES` should be a `Set`, and use `BLOCKCHAIN_MODULES.has()` to check existence or non-existence. • MINOR • View issue

Location: packages/analysis/src/jsts/rules/S7639/rule.ts:25

Why is this an issue?

Using Array#includes() for existence checks can lead to performance problems, especially with larger datasets.

What changed

Converts the BLOCKCHAIN_MODULES variable from an array literal to a Set by wrapping it with new Set(...). This addresses the code smell where BLOCKCHAIN_MODULES was declared as an array but used primarily for existence checking. Using a Set provides O(1) average time complexity for lookups instead of O(n) with Array#includes().

--- a/packages/analysis/src/jsts/rules/S7639/rule.ts
+++ b/packages/analysis/src/jsts/rules/S7639/rule.ts
@@ -25,1 +25,1 @@ import * as meta from './generated-meta.js';
-const BLOCKCHAIN_MODULES = ['ethers', 'viem/accounts', 'tronweb'];
+const BLOCKCHAIN_MODULES = new Set(['ethers', 'viem/accounts', 'tronweb']);

typescript:S7754 - Prefer `.some(…)` over `.find(…)`. • MINOR • View issue

Location: packages/analysis/src/jsts/rules/S131/rule.ts:52

Why is this an issue?

JavaScript’s Array.prototype.some() method is specifically designed to test whether at least one element in an array passes a provided test function. Using other array methods for this purpose creates several problems:

What changed

This hunk replaces the use of .find() (which returns the found element or undefined) with .some() (which returns a boolean) when checking whether any switch case has a null test (i.e., is a default clause). The original code used cases.find(c => c.test === null) and then checked if the result was falsy, but .some() is the semantically correct method for testing whether at least one element matches a condition. This change improves readability, performance (short-circuits on first match), and follows JavaScript best practices as recommended by the 'prefer-array-some' rule.

--- a/packages/analysis/src/jsts/rules/S131/rule.ts
+++ b/packages/analysis/src/jsts/rules/S131/rule.ts
@@ -52,2 +52,1 @@ const switchWithoutDefaultRule: Rule.RuleModule = {
-        const defaultClause = cases.find(c => c.test === null);
-        if (!defaultClause) {
+        if (!cases.some(c => c.test === null)) {

typescript:S7754 - Prefer `.some(…)` over `.find(…)`. • MINOR • View issue

Location: packages/analysis/src/jsts/rules/S4323/rule.ts:51

Why is this an issue?

JavaScript’s Array.prototype.some() method is specifically designed to test whether at least one element in an array passes a provided test function. Using other array methods for this purpose creates several problems:

What changed

This hunk replaces .find( with .some( on the ancestors array. The static analysis rule flags the use of .find() when the intent is to check whether any element in an array matches a condition, because .some() is semantically clearer and more efficient for existence checks. By changing ancestors.find( to ancestors.some(, the code now uses the appropriate method for testing if at least one ancestor meets the condition, which improves readability, performance (short-circuits on first match), and follows JavaScript best practices.

--- a/packages/analysis/src/jsts/rules/S4323/rule.ts
+++ b/packages/analysis/src/jsts/rules/S4323/rule.ts
@@ -51,1 +51,1 @@ export const rule: Rule.RuleModule = {
-        const declaration = ancestors.find(
+        const declaration = ancestors.some(

typescript:S7754 - Prefer `.some(…)` over `.find(…)`. • MINOR • View issue

Location: packages/analysis/src/jsts/rules/S5736/rule.ts:67

Why is this an issue?

JavaScript’s Array.prototype.some() method is specifically designed to test whether at least one element in an array passes a provided test function. Using other array methods for this purpose creates several problems:

What changed

Replaces .find(…) with .some(…) for checking if any array element matches a condition. The static analysis rule flagged the use of .find() as a code smell because .some() is the semantically correct method for existence checking — it's more readable, more efficient (short-circuits on first match), and clearly communicates intent. The variable is also renamed from sensitiveValue to hasSensitiveValue to reflect that it now holds a boolean rather than the found element.

--- a/packages/analysis/src/jsts/rules/S5736/rule.ts
+++ b/packages/analysis/src/jsts/rules/S5736/rule.ts
@@ -67,1 +67,1 @@ function isSafePolicy(policy: estree.Property): boolean {
-  const sensitiveValue = values.find(
+  const hasSensitiveValue = values.some(

typescript:S7754 - Prefer `.some(…)` over `.find(…)`. • MINOR • View issue

Location: packages/analysis/src/jsts/rules/S6351/rule.ts:127

Why is this an issue?

JavaScript’s Array.prototype.some() method is specifically designed to test whether at least one element in an array passes a provided test function. Using other array methods for this purpose creates several problems:

What changed

This hunk replaces .find(r => r.node === value) followed by a truthiness check (if (regex)) with .some(r => r.node === value). The original code used .find() to check whether any element in the regexes array matched a condition, but .find() returns the matched element (or undefined), which is less semantically clear for an existence check. The .some() method is specifically designed for this purpose — it returns a boolean indicating whether at least one element passes the test, and it short-circuits on the first match. This directly addresses the code smell about preferring .some(…) over .find(…) for existence checks.

--- a/packages/analysis/src/jsts/rules/S6351/rule.ts
+++ b/packages/analysis/src/jsts/rules/S6351/rule.ts
@@ -127,2 +127,1 @@ function extractResetRegex(
-        const regex = regexes.find(r => r.node === value);
-        if (regex) {
+        if (regexes.some(r => r.node === value)) {

Have a suggestion or found an issue? Share your feedback here.

---

SonarQube Remediation Agent uses AI. Check for mistakes.

[datadog-sonarsource]

⚠️ Warnings

🚦 3 Pipeline jobs failed

Build | Build ESLint Plugin     

Build | Build SonarJS on Linux     

Build | JS/TS Ruling     

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 96f4411 | Docs | Give us feedback!}