fix: resolve 10 SonarQube issues in estimator.js

[sonarqube-agent]

Updated estimator.js to follow modern JavaScript best practices by replacing var declarations with const, using optional chaining, preferring globalThis over window, and replacing global functions with their Number and RegExp namespace equivalents. These changes improve code quality, readability, and maintainability while reducing potential scope-related bugs.

View Project in SonarCloud

---

Fixed Issues

javascript:S6582 - Prefer using an optional chain expression instead, as it's more concise and easier to read. • MAJOR • View issue

Location: sklearn/utils/_repr_html/estimator.js:44

Why is this an issue?

Optional chaining allows to safely access nested properties or methods of an object without having to check for the existence of each intermediate property manually. It provides a concise and safe way to access nested properties or methods without having to write complex and error-prone null/undefined checks.

What changed

Replaces the verbose logical AND check !parent || !parent.nextElementSibling with the optional chaining expression !parent?.nextElementSibling. This is more concise and easier to read, as the ?. operator safely handles the case where parent is null/undefined without needing a separate check.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -44,1 +44,1 @@ document.querySelectorAll('.copy-paste-icon').forEach(function(element) {
-    if (!parent || !parent.nextElementSibling) {
+    if (!parent?.nextElementSibling) {

javascript:S3504 - Unexpected var, use let or const instead. • CRITICAL • View issue

Location: sklearn/utils/_repr_html/estimator.js:64

Why is this an issue?

Variables declared with var are function-scoped, meaning they are accessible within the entire function in which they are defined. If a variable is declared using var outside of any function, it becomes a global variable and is accessible throughout the entire JavaScript program.

What changed

Replaces var declarations with const for both detailsElem and wasOpen variables. Using const provides proper block scoping and signals that these variables are not reassigned, following modern ES6+ best practices and eliminating the issues with function-scoped var declarations.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -64,2 +64,2 @@ function copyFeatureNamesToClipboard(element) {
-    var detailsElem = element.closest('.features').querySelector('details');
-    var wasOpen = detailsElem.open;
+    const detailsElem = element.closest('.features').querySelector('details');
+    const wasOpen = detailsElem.open;

javascript:S3504 - Unexpected var, use let or const instead. • CRITICAL • View issue

Location: sklearn/utils/_repr_html/estimator.js:65

Why is this an issue?

Variables declared with var are function-scoped, meaning they are accessible within the entire function in which they are defined. If a variable is declared using var outside of any function, it becomes a global variable and is accessible throughout the entire JavaScript program.

What changed

Replaces var declarations with const for both detailsElem and wasOpen variables. Using const provides proper block scoping and signals that these variables are not reassigned, following modern ES6+ best practices and eliminating the issues with function-scoped var declarations.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -64,2 +64,2 @@ function copyFeatureNamesToClipboard(element) {
-    var detailsElem = element.closest('.features').querySelector('details');
-    var wasOpen = detailsElem.open;
+    const detailsElem = element.closest('.features').querySelector('details');
+    const wasOpen = detailsElem.open;

javascript:S7764 - Prefer `globalThis` over `window`. • MINOR • View issue

Location: sklearn/utils/_repr_html/estimator.js:133

Why is this an issue?

globalThis is the standardized way to access the global object across all JavaScript environments. Before globalThis, developers had to use different global references depending on the environment:

What changed

Makes two changes: (1) Replaces window.getComputedStyle(...) with globalThis.getComputedStyle(...) to use the standardized global object accessor instead of the browser-specific window. (2) Rewrites color.match(/regex/) as /regex/.exec(color), using RegExp.exec() instead of String.match() for better performance when the regex doesn't use the global flag.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -133,2 +133,2 @@ function detectTheme(element) {
-    const color = window.getComputedStyle(element.parentNode, null).getPropertyValue('color');
-    const match = color.match(/^rgb\s*\(\s*(\d+)\s*,\s*(\d+)\s*,\s*(\d+)\s*\)\s*$/i);
+    const color = globalThis.getComputedStyle(element.parentNode, null).getPropertyValue('color');
+    const match = /^rgb\s*\(\s*(\d+)\s*,\s*(\d+)\s*,\s*(\d+)\s*\)\s*$/i.exec(color);

javascript:S7773 - Prefer `Number.parseFloat` over `parseFloat`. • MINOR • View issue

Location: sklearn/utils/_repr_html/estimator.js:137

Why is this an issue?

ECMAScript 2015 introduced static methods and properties on the Number constructor to replace several global functions and values. Using these Number equivalents provides several benefits:

What changed

Replaces three occurrences of the global parseFloat() function with Number.parseFloat(). This uses the modern ES2015+ Number namespace method instead of the global function, improving code organization, reducing global namespace pollution, and aligning with modern JavaScript standards.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -137,3 +137,3 @@ function detectTheme(element) {
-            parseFloat(match[1]),
-            parseFloat(match[2]),
-            parseFloat(match[3])
+            Number.parseFloat(match[1]),
+            Number.parseFloat(match[2]),
+            Number.parseFloat(match[3])

javascript:S7773 - Prefer `Number.parseFloat` over `parseFloat`. • MINOR • View issue

Location: sklearn/utils/_repr_html/estimator.js:138

Why is this an issue?

ECMAScript 2015 introduced static methods and properties on the Number constructor to replace several global functions and values. Using these Number equivalents provides several benefits:

What changed

Replaces three occurrences of the global parseFloat() function with Number.parseFloat(). This uses the modern ES2015+ Number namespace method instead of the global function, improving code organization, reducing global namespace pollution, and aligning with modern JavaScript standards.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -137,3 +137,3 @@ function detectTheme(element) {
-            parseFloat(match[1]),
-            parseFloat(match[2]),
-            parseFloat(match[3])
+            Number.parseFloat(match[1]),
+            Number.parseFloat(match[2]),
+            Number.parseFloat(match[3])

javascript:S7773 - Prefer `Number.parseFloat` over `parseFloat`. • MINOR • View issue

Location: sklearn/utils/_repr_html/estimator.js:139

Why is this an issue?

ECMAScript 2015 introduced static methods and properties on the Number constructor to replace several global functions and values. Using these Number equivalents provides several benefits:

What changed

Replaces three occurrences of the global parseFloat() function with Number.parseFloat(). This uses the modern ES2015+ Number namespace method instead of the global function, improving code organization, reducing global namespace pollution, and aligning with modern JavaScript standards.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -137,3 +137,3 @@ function detectTheme(element) {
-            parseFloat(match[1]),
-            parseFloat(match[2]),
-            parseFloat(match[3])
+            Number.parseFloat(match[1]),
+            Number.parseFloat(match[2]),
+            Number.parseFloat(match[3])

javascript:S6594 - Use the "RegExp.exec()" method instead. • MINOR • View issue

Location: sklearn/utils/_repr_html/estimator.js:134

Why is this an issue?

String.match() behaves the same way as RegExp.exec() when the regular expression does not include the global flag g. While they work the same, RegExp.exec() can be slightly faster than String.match(). Therefore, it should be preferred for better performance.

What changed

Makes two changes: (1) Replaces window.getComputedStyle(...) with globalThis.getComputedStyle(...) to use the standardized global object accessor instead of the browser-specific window. (2) Rewrites color.match(/regex/) as /regex/.exec(color), using RegExp.exec() instead of String.match() for better performance when the regex doesn't use the global flag.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -133,2 +133,2 @@ function detectTheme(element) {
-    const color = window.getComputedStyle(element.parentNode, null).getPropertyValue('color');
-    const match = color.match(/^rgb\s*\(\s*(\d+)\s*,\s*(\d+)\s*,\s*(\d+)\s*\)\s*$/i);
+    const color = globalThis.getComputedStyle(element.parentNode, null).getPropertyValue('color');
+    const match = /^rgb\s*\(\s*(\d+)\s*,\s*(\d+)\s*,\s*(\d+)\s*\)\s*$/i.exec(color);

javascript:S7764 - Prefer `globalThis` over `window`. • MINOR • View issue

Location: sklearn/utils/_repr_html/estimator.js:157

Why is this an issue?

globalThis is the standardized way to access the global object across all JavaScript environments. Before globalThis, developers had to use different global references depending on the environment:

What changed

Replaces window.matchMedia(...) with globalThis.matchMedia(...) to use the standardized ES2020 global object accessor. This makes the code more portable across JavaScript environments and follows the recommendation to prefer globalThis over environment-specific globals like window.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -157,1 +157,1 @@ function detectTheme(element) {
-    return window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
+    return globalThis.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';

javascript:S7764 - Prefer `globalThis` over `window`. • MINOR • View issue

Location: sklearn/utils/_repr_html/estimator.js:12

Why is this an issue?

globalThis is the standardized way to access the global object across all JavaScript environments. Before globalThis, developers had to use different global references depending on the environment:

What changed

Replaces window.getComputedStyle(element) with globalThis.getComputedStyle(element) at line 12, fixing the static analysis warning about preferring globalThis over window for accessing the global object. This makes the code more portable across JavaScript environments.

--- a/sklearn/utils/_repr_html/estimator.js
+++ b/sklearn/utils/_repr_html/estimator.js
@@ -12,1 +12,1 @@ function copyToClipboard(text, element) {
-    const computedStyle = window.getComputedStyle(element);
+    const computedStyle = globalThis.getComputedStyle(element);

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

---

SonarQube Remediation Agent uses AI. Check for mistakes.

[sonarqubecloud]

SonarQube reviewer guide

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud