Add option for no-unused-expressions
See original GitHub issueI’m using Chai’s expect syntax for testing, and I’m getting no-unused-expression
errors. I understand that this is because expressions like expect(...).to.be.undefined
look like property access, even though chai’s actually using the property’s getter to call a method behind the scenes that causes some side effects.
I did a bit of googling and at least a few other people have encountered this.
I’m not sure what the best solution is (I don’t know enough about parsing JS to say) but it seems like one possibility might be an option that would not flag property access chains that start with certain identifiers. So the user could specify "expect"
as the option’s value and then all these chai calls would be let through.
Issue Analytics
- State:
- Created 9 years ago
- Reactions:27
- Comments:24 (10 by maintainers)
Top Results From Across the Web
no-unused-expressions - ESLint - Pluggable JavaScript Linter
This rule aims to eliminate unused expressions which have no effect on the state of the program. This rule does not apply to...
Read more >Nice way to get rid of no-unused-expressions linter error with ...
I've made a small plugin called eslint-plugin-chai-friendly that overrides the default no-unused-expressions rule and makes it friendly towards chai. The ...
Read more >no-unused-expressions | typescript-eslint
This rule extends the base eslint/no-unused-expressions rule. It adds support for optional call expressions x?.() , and directive in module declarations.
Read more >Solved: Optional Chaining no-unused-expressions ESLint Error
Fix for "no-unused-expressions" ESLint error when using JavaScript optional chaining.
Read more >no-unused-expression - Rule
Disallows unused expression statements. Unused expressions are expression statements which are not assignments or function calls (and thus usually no-ops).
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
@nzakas with all respect, you said:
But actually, ESLint, as JSHint, does support “environment options” such as
jasmine
,mocha
, andqunit
, plusprotractor
,atomtest
, andembertest
on ESLint side… so I think that adding achai
environment option would not break existing ESLint library approach.I just wrote a related feature request to the JSHint project
As I described in that feature request, another non ‘library related’ approach could be to add a
expr: 'accessor'
sub-option to not raise the warning when we ends an expression with the access to anaccessor property
(cf ES5 Property Attributes) . I mentioned related use cases like forced singleton instantiation.This library agnostic option can be interesting but:
👍 for
dirty-chai