New Rule: prefer-exponentiation-operator

[RyanZim]

Please describe what the rule should do:

ES2016 adds an exponentiation operator **; this may be preferred over using Math.pow(). The rule should disallow the use of the Math.pow() function, in favor of using **.

What category of rule is this? (place an "X" next to just one item)

[ ] Enforces code style
[ ] Warns about a potential error
[x] Suggests an alternate way of doing something
[ ] Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

// Good
const a = 5 ** 7

// Bad
const a = Math.pow(5, 7)

Why should this rule be included in ESLint (instead of a plugin)?

This is a ES2016 feature, which can replace an older way of doing things. There should be a rule to force upgrading code; similar to how ESLint has no-var, prefer-spread, etc.

[ljharb]

Instead, this rule should probably be called prefer-exponentiation-operator? Then it could also apply to 2 * 2 * 2 :-p

[RyanZim]

@ljharb Good point, that would work too; though I don't know how common 2 * 2 * 2 is; IDK if it's worth building the logic for that.

[platinumazure]

This is currently doable using no-restricted-properties.

That said, I'm not opposed to a new rule for this case.

[ljharb]

It would be wonderful for the airbnb config to have a standalone rule rather than using no-restricted-properties.

[RyanZim]

I didn't think about no-restricted-properties; that is one solution, though it's easier to understand if there's a rule explicitly for it, and a dedicated rule could potentially support auto-fixing.

[mysticatea]

I'll champion this proposal. I like the rule name prefer-exponentiation-operator and it has autofix. That rule will encourage to learn the new syntax.

[sindresorhus]

If anyone needs this rule, it's available in eslint-plugin-unicorn.

[ljharb]

@sindresorhus it'd be great if you PR'd it and its tests into eslint core :-)

[izayl]

https://stackoverflow.com/questions/41679191/why-is-math-pow-sometimes-not-equal-to-in-javascript

According to this questions, use Math.pow() is safer than **.

[ljharb]

The comments suggests it’s just a bug in v8; not a reason to write code differently.

[mdjermanovic]

👍 It's accepted now

I don't know is it relevant for the decision to implement the rule, but it seems that the bug hasn't been fixed yet:

https://bugs.chromium.org/p/v8/issues/detail?id=5848

[kaicataldo]

@mdjermanovic I don't think we should let a single runtime's bug prevent us from adding this rule, but it could be nice to include a link to the bug in the rule's docs.

[mdjermanovic]

I'm working on this.

From the specification, it seems that the only difference is when both arguments evaluate to bigint, as ** doesn't crash in that situation (it would crash if only one is bigint), unlike Math.pow.

Re the autofix, I think it's an acceptable change in behavior 👍