eqeqeq Rule Change Proposal: Allow only == undefined

What rule do you want to change?

eqeqeq

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

Both fewer and more. See example below.

How will the change be implemented? (New option, new default behavior, etc.)?

It will be a new option. Currently we can do:

["error", "always", {"null": "ignore"}]

The new option would allow to set the rule this way:

["error", "always", {"undefined": "ignore"}]

Thus, that would allow the use of == and != only in the case one compares to undefined.

Please provide some example code that this change will affect:

It will be beneficial to people who want to use undefined exclusively, instead of null, but keep the possibility to check both null and undefined.

Although people might forbid null in their code, it still has to be checked in case it is returned in some third party library call, or JSON deserialized objects.

const foo = someThirdPartyFunction()
const bar = JSON.parse(json)

if (foo == undefined && bar != undefined) {
  // ...
}

if (foo == null && bar != null) {
  // ...
}

What does the rule currently do for this code?

Currently the following code is invalid :

// ["error", "always", {"null": "ignore"}]

const foo = someThirdPartyFunction()
const bar = JSON.parse(json)

if (foo == undefined && bar != undefined) {
  // ...
}

Currently the following code is valid :

// ["error", "always", {"null": "ignore"}]

const foo = someThirdPartyFunction()
const bar = JSON.parse(json)

if (foo == null && bar != null) {
  // ...
}

What will the rule do after it’s changed? The following code would be valid :

// ["error", "always", {"undefined": "ignore"}]

const foo = someThirdPartyFunction()
const bar = JSON.parse(json)

if (foo == undefined && bar != undefined) {
  // ...
}

The following code would be invalid :

// ["error", "always", {"undefined": "ignore"}]

const foo = someThirdPartyFunction()
const bar = JSON.parse(json)

if (foo == null && bar != null) {
  // ...
}

[kirly-af]

Hi @vitorbal, @platinumazure

Sorry I’ve been quite busy recently. I’ve updated the proposal, hopefully now there’s enough information.

EDIT: and btw, I’ll be happy to make a PR for it if the change is acceptable.

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get enough support from the team and so I’m closing it. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach consensus after a long time tend to never do it, and as such, we close those issues. This doesn’t mean the idea isn’t interesting, just that it’s not something the team can commit to.