Rule proposal: Prefer `Number` methods

Fail

parseInt(…);
parseFloat(…);
isNaN(…);
isFinite(…);

Pass

Number.parseInt(…);
Number.parseFloat(…);
Number.isNaN(…);
Number.isFinite(…);

This rule cannot be auto-fixable as the globals methods have slightly different behavior. However, it should use the ESLint suggestions API.

Should we also enforce Number.NaN over NaN? They equivalent. I’m leaning towards “yes”, for consistency, and also less use of floating globals.

[jimmywarting]

I would like to see a reasoning for why number properties are better, (and not just because of global-phobia) If you can’t argument for a good reason, then don’t break something that isn’t broken.

I came here for the Number.NaN reason… never seen anyone write that …or using Number Number.NEGATIVE_INFINITY That’s just too long and unpleasant to write Some functions are the same, parseInt === Number.parseInt, Number.parseFloat === parseFloat, So why should you use Number[xxx]?

isNaN i can understand it’s not the same as Number.isNaN and dose things differently

The global isNaN() function converts the tested value to a Number, then tests it.

There may just be usecases where you would prefer to use one over the other, just because of it’s differences

[fisker]

I think

- if (isNaN(numberOrIdk)) {
+ if (Number.isNaN(Number(numberOrIdk))) {

is more correct.