New Rule: no-override-native-methods | no-assignment-native-props?

Rule details

Prevents overriding native props/methods

Related ECMAScript feature

No

What type of rule is this?

Warns about a potential problem

Example code

Number.isNaN = () => {}; // should be prohibited
Object.entries = () => {}; // should be prohibited
console.log = () => {}; // considered as good, it should be prohibited as well


Number.prototype.isNaN = () => {}; // Number prototype is read only, properties should not be added. (no-extend-native)

Why should this rule be in the core instead of a plugin?

Basically, we need to prevent overriding methods or properties of native classes, and I couldn’t find a solution that makes it possible. Such change might cause pages to work unexpectedly in browsers when there is a native class method get’s overridden and used by libraries that are not related to each other. ESLint can alert if that happens

Participation

• I am willing to submit a pull request to implement this rule.

Additional comments

Related discussion https://github.com/eslint/eslint/discussions/15110

[nzakas]

@seahindeniz we realize that our policy isn’t what everyone would like, but that’s why ESLint supports plugins. We never want to stand in the way of people having the rules that they want, but we just can’t keep adding new rules to the core forever. With about 300 rules already, it’s a maintenance nightmare.

For more information, please see the blog post where we announced this change: https://eslint.org/blog/2020/05/changes-to-rules-policies

In small projects or projects that don’t have CI flows for ESLint, overriding Number.isNaN can happen intentionally, or some other situations may occur.

It’s clear that you feel strongly about this, and that’s why we have custom rules. You are still free to create a rule that does this, and to use it and even publicize why it’s important to use. This is how ESLint was intended to work: you can configure and extend it to do exactly what you want.

[aladdin-add]

Per our rules policies, we can only accept new rules if they relate to new ECMAScript features that reached stage 4 in the preceding 12 months, so this proposal doesn’t qualify.

I’m in favor of a new option for no-extend-native.