How to deal with unused-expressions
See original GitHub issueNode.js is full of unused expressions.
For example, If I call setHeader
on a ClientRequest
I have a non-useful return.
There are things like Eff
or Io
to model side-effects; Is the best approach to disable eslint checking for unused expressions inside these monads?
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (2 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.
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 >no-unused-expressions | typescript-eslint
Disallow unused expressions. ... This rule extends the base eslint/no-unused-expressions rule. It adds support for optional call expressions x?
Read more >Failed to compile Expected assignment function call instead ...
... Error Failed to compile Expected an assignment or function call and instead saw an expression no- unused -expressio...
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
Yup, that was it; thanks 😃
Hi @jgrund!
You are right that Node.js has plenty of APIs that “kind of” makes use of unused expressions, and that’s because Node, or JavaScript for that matter, was not made to be a full-fledged FP language / ecosystem.
You can’t for instance use FP techniques with tools like
express
out of the box, but you’re right that you can remove the side-effects by using Monads. I haven’t used them as much as I would have liked to (and never usedIo
orEff
), so take the rest of my comment with a grain of salt.I think the approach you described is a very good one, if I understood you correctly: Create a new Monad type that wraps your HTTP requests tool and make its API stateless just like you’d expect from other monads.
In its implementation, you can then disable the ESLint rules that create errors. As long as you avoid things that would make your API not stateless and side-effectful, you are good to go. You are simply relocating your side-effectful code to a part where it is controlled and outside of your pure logic, and that’s 👍.
Let me know if my answer was not clear, or if I misunderstood you 😃