eqeqeq rule allow-undefined

What rule do you want to change?

Require === and !== (eqeqeq) https://eslint.org/docs/rules/eqeqeq#allow-null

Does this change cause the rule to produce more or fewer warnings?

In ECMA262:

null value is primitive value that represents the intentional absence of any object value.

undefined value is primitive value used when a variable has not been assigned a value.

In TypeScript team coding guidelines:

Use undefined. Do not use null.

https://github.com/microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined

So i think comparing with the undefined literal should also can be allowed.

How will the change be implemented? (New option, new default behavior, etc.)? Please support allow-undefined.

Please provide some example code that this change will affect:

foo == null
foo == undefined

What does the rule currently do for this code?

foo == null // correct
foo == undefined // incorrect

What will the rule do after it’s changed?

foo == null // correct
foo == undefined // correct

Are you willing to submit a pull request to implement this change?

It’s my pleasure

[kaicataldo]

I don’t think this change should be made in core for a few reasons:

1. Since this is purely stylistic, it falls under our new policy.

2. If you’re never using null, why not just use a === undefined everywhere? It would be safer and more explicit. The way I read this guideline is that you should never use null to represent a null value for APIs you control. That doesn’t mean you wouldn’t have to use a === null in your code, since there’s a good chance you’ll be interacting with someone else’s code (even if it’s just the Node builtin or DOM APIs) that may return null.

[SyMind]

Also note that the undefined literal can be redefined, everywhere but the global scope. == null is the only safe usage of ==.

In the ECMA262 specification, [[Writable]] of undefined is false. So i don’t think is problem to use undefined in 2020.

The value of undefined is undefined (see 6.1.1). This property has the attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }.

And most people use feature like ES Module and Class, they are always in strict mode. In strict mode will throw TypeError when undefined = anything.

I don’t agree - null isn’t buggy.

In the following url, Brendan Eich say in 2011/01/14 20:18:

https://web.archive.org/web/20160331031419/http://wiki.ecmascript.org:80/doku.php?id=harmony:typeof_null

I would very much prefer to fix typeof. We talked about this before, and decided that there is code out there that depends on typeof ‘s bad behavior. Are we now saying that the migration tax is acceptable?

Obviously, this is a bug that the author agreed.