Disable the unicorn/prefer-number-properties rule

[leroykorterink]

There is a proposal to disable the unicorn/prefer-number-properties rule.

unicorn/prefer-number-properties: introduces unnecessary verbosity
- @edgardz

[leroykorterink]

ECMAScript 2015 moved globals onto the Number constructor for consistency and to slightly improve them. This rule enforces their usage to limit the usage of globals:

• Number.parseInt() over parseInt() (fixable)
• Number.parseFloat() over parseFloat() (fixable)
• Number.isNaN() over isNaN() (they have slightly different behavior)
• Number.isFinite() over isFinite() (they have slightly different behavior)
• Number.NaN over NaN (fixable)
• Number.POSITIVE_INFINITY over Infinity (fixable)
• Number.NEGATIVE_INFINITY over -Infinity (fixable)

Please see the documentation of the rule.

[ThaNarie]

Why would we keep legacy (and likely at some point deprecated) methods, while we can also use the newer (better) versions?

If the only reason is to not have to type read Number., then although understandable, I don't find that enough :)

[edgardz]

const queryParam = '0'
const parsed = +queryParam

[ThaNarie]

I would highly discourage relying on implicit coercions, like +"string" or !!variable, that do not clearly state their intent, and could be considered typo's.

Coercion is one of the most confusing parts of JS (hence why we require === in conditions), so I wouldn't recommend using operators to convert between datatypes.

const queryParam = '0';
const parsed = Number(queryParam); // when happy with any type of number
const parsed = Number.parseInt(queryParam); // when only needing an integer

Maybe writing is a bit quicker, but reading/understanding is slower, and that happens much more often.

---

Does your example actually apply to this rule? This rule only requires Number.parseInt() over parseInt(), it doesn't directly disallow your coercion trick, does it?