This rule raises an issue when global functions like parseInt(), parseFloat(), isNaN(), isFinite() or global values like NaN, Infinity are used instead of their Number constructor equivalents.

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:

Consistency and Organization: All number-related utilities are grouped under the Number namespace, making the code more organized and easier to understand.

Reduced Global Namespace Pollution: By using Number methods instead of globals, you help keep the global namespace cleaner and reduce the risk of naming conflicts.

Improved Behavior: Some Number methods have better behavior than their global counterparts:

Modern JavaScript Standards: Using Number methods aligns with modern JavaScript practices and demonstrates familiarity with ES2015+ features.

The global functions still exist for backward compatibility, but the Number equivalents are the recommended approach in modern JavaScript development.

What is the potential impact?

Using global functions instead of Number methods can lead to:

How to fix?

Replace global parsing functions with their Number equivalents. The behavior is identical, but the Number methods are more explicit and organized.

Non-compliant code example

const num1 = parseInt('42', 10); // Noncompliant
const num2 = parseFloat('3.14'); // Noncompliant

Compliant code example

const num1 = Number.parseInt('42', 10);
const num2 = Number.parseFloat('3.14');

Documentation