Does lint/style/useNumberNamespace provide any benefit?

[lgarron]

Every time I see lint/style/useNumberNamespace error on parseInt(…) while adding/upgrading Biome for a codebase, I wonder if it has any benefit:

• It will generally only have a net negative benefit to code size (either source or compiled).
  • Note that a human coder can almost always conclude that removing the Number. namespace is safe for code size optimization, but it is not safe for a bundler to assume this and a bundler must preserve it.
• As far as I can tell, the global versions of these functions are not "deprecated" and are supported in all runtimes so they are perfectly safe to use indefinitely.
• The global and namespaced versions covered by this lint do exactly the same thing.
• I can't think of situations where Number.parseInt provides maintainability or safety over parseInt.
  • For example, I don't think searching parseInt for a codebase would generally return a lot of false positives. To the contrary, if someone assumes it's sufficient to search for Number.parseInt instead then they are more likely to get false negatives (i.e. failing to find any un-namespaced calls).

The rule's explanation states:

ES2015 moved some globals into the Number properties for consistency.

I'm unfortunately unable to to find the proposal that led to this, so I can't quite fact-check this. In any case, I don't know about you, but I have yet to encounter any use case in a real-world codebase where this consistency would have resulted in a concrete benefit. 🤔

By contrast:

• https://biomejs.dev/linter/rules/use-numeric-literals/#_top could prevent bugs.
• lint/suspicious/noGlobalIsFinite and lint/suspicious/noGlobalIsNan could reasonably prevent subtle bugs, but for this reason they are explicitly excluded from lint/style/useNumberNamespace.

Is there a reason I'm not missing why there would be a benefit? Would it be reasonable perhaps to turn this lint off by default?

I'm finding that it creates a lot of "noise" in repos that are otherwise trivial to convert. I know I could turn off this rule in every repo, but I've found myself considering doing this so often that I thought I'd post here to see if perhaps I could make that unnecessary.

[dyc3]

This rule comes from eslint-plugin-unicorn. I found the original issue on that repo for adding the rule: sindresorhus/eslint-plugin-unicorn#594 and it doesn't really provide much insight. This is the kind of rule you would enable if you want to ban globals as much as possible. We exclude the functions that have slightly different behavior so that we can provide a safe fix for this rule.

We've already removed the rule from the recommended set on the next branch, so that will be in the next release.

[lgarron]

We've already removed the rule from the recommended set on the next branch, so that will be in the next release.

Ooh, I'm really glad to hear that! 🤩