Package: conditions/convert-equal-to-strict-equal - Comparisons to null not safe to transform

[epreston]

Package: conditions/convert-equal-to-strict-equal Issue: Comparisons to null not safe to transform

Example:

if (test != null) {
  // do something
}

This is not safe to transform into strict compare with !== when null is the right hand side of the expression. Often, the "loose equality comparison that performs type coercion if necessary" is desired to catch both null and undefined.

Detailed reference on the issue: https://stackoverflow.com/a/15992131/900263

---

Update:

Version: Version: 29.3

Description: yoda expressions are reversed but continue to be evaluated in the original order. This causes rule exclusions to be bypassed.

[coderaiser]

Are you up for a PR?

[epreston]

Almost, 11 more hours of testing. So many new goodies.

[coderaiser]

Wait a minute, as I see this case already handled:

https://github.com/coderaiser/putout/blob/ac566372d30937a7dba1e9282dd013e4478034f8/packages/plugin-conditions/lib/convert-equal-to-strict-equal/index.js#L5-L13

And it has tests:

https://github.com/coderaiser/putout/blob/ac566372d30937a7dba1e9282dd013e4478034f8/packages/plugin-conditions/lib/convert-equal-to-strict-equal/index.spec.js#L20-L28

How did you trap on it?

[epreston]

I was getting conversions in 2 cases. The normal one and when the operands reversed.

• test != null
• null != test

Will update with test cases.

[epreston]

I may have started with null != test that got corrected to test != null but then the transform was applied.

I have this habit of doing that because assigning to null by mistake triggers instant error. It also ensures that I can not assign null to the variable by missing a character. It's a habit from another language at the cost of readability.

[coderaiser]

May the yoda rule of ESLint help you with this.

[epreston]

Confirmed, I had statements like null != test that got reversed then snuck through.

The updated issue description would be:

yoda expressions are reversed but continue to be evaluated in the original order. This causes rule exclusions to be bypassed.

[epreston]

Retesting for 29.4.0 update

[coderaiser]

Retesting for 29.4.0 update

What purpose of this retest? I don't think it will be fixed if you don't send PR.

[epreston]

Oh.. ok. This is just a quick note to say that I'm not leaving old issues open from previous versions.
I'll get to work on it.

[coderaiser]

Closed due to a long time of inactivity 🏝. Fee free to reopen when you have chance to work on this.