[no-constant-condition] all literal should be treated like boolean literal
See original GitHub issueWhat rule do you want to change? no-constant-condition
Does this change cause the rule to produce more or fewer warnings? More warnings
How will the change be implemented? (New option, new default behavior, etc.)? New option
Please provide some example code that this change will affect:
// Unexpected constant condition. eslintno-constant-condition
if (true || this.loginpage) {
console.log('1');
}
// no error reported
if (1 || this.loginpage) {
console.log('1');
}
What does the rule currently do for this code?
Only the first if
statement is reported
What will the rule do after it’s changed?
The second if
statement will be reported too.
Are you willing to submit a pull request to implement this change? Yes
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (8 by maintainers)
Top Results From Across the Web
Should we extend no-constant-condition to catch comparisons ...
A UnaryExpression with a ! operator will always result in a boolean. It can never be null, so the whole expression could be...
Read more >ESLint v7.12.0 released - ESLint - Pluggable JavaScript Linter
A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.
Read more >ExpressibleByBooleanLiteral | Apple Developer Documentation
A type that can be initialized with the Boolean literals and . ... Bool , DarwinBoolean , ObjCBool , and WindowsBool are treated...
Read more >Integration with ESLint JavaScript Linter - Codacy | Blog
A popular linter for the JavaScript community, ESL Lint is now supported by Codacy static analysis tool making it very easy to write...
Read more >Python Literal - Character, String and Boolean - Tools QA
We have already discussed the characters in the tutorial. What if you want to know the ASCII value of a character? What will...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Online Demo
Hi, @Zzzen. 😃. It seems a bug to me. I think the truthy literal on the left side of
||
should be reported.so, maybe, it should be fixed rather than adding new options? Let’s hear from others.
I believe the only reason to not report
1 || foo
as a constant condition inif (1 || foo);
would be to avoid overlapping with another rule (or an option in this rule) that would report1
in1 || foo
.In that case,
true || foo
inif (true || foo);
shouldn’t be reported as well.foo || 1
is different because it can be a valid code, depending on the context.Even if we add such a rule or option at some point, I don’t think that the mentioned overlapping would be a big problem, so I’d vote to accept this issue as a bug and fix it in a semver-minor release.
In addition to
||
, the actual behavior with&&
also seems to be inconsistent: