New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement: [strict-boolean-expressions] Check truthiness assertion functions #9009
Comments
EDIT - I crossed wires with something else when writing that. Reading more closely, I'm fully +1 on this. An assertion function argument is a boolean context, complete with narrowing. We'll see what others think! |
I'd never really thought about it like this. It may be a bit weird for people to think of assertions like this but I think there's value in it. Though note that we would only check |
Question - do we think that we should check this context analogously in function assert(x: unknown): asserts x {
// eslint-disable-next-line @typescript-eslint/strict-boolean-expressions
if (!x) {
throw new Error('assertion');
}
}
const truthyString = 'string';
if (truthyString) { }
~~~~~~~~~~~~
const alsoTruthyString = 'string';
assert(alsoTruthyString) I'm of the opinion that we should, though it's less easy of a call to make than for the |
Sounds like a valuable thing yeah. |
Yep, that's exactly my reservation as well, having used assertions myself to defend against regressions due to types at runtime not matching their declared types. Will file dedicated issue for that. Do you think there ought to be an option for this rule as well? |
nah this rule is straight-forward. It's not going to ban an assertion - just ensure you're using it strictly. |
Before You File a Proposal Please Confirm You Have Done The Following...
My proposal is suitable for this project
Link to the rule's documentation
https://typescript-eslint.io/rules/strict-boolean-expressions/
Description
For example,
ok
fromnode:assert
has the following shape:It appears that currently the rule just looks at
value
, seesunknown
, and moves on. So it's possible to write this:Instead, it would be nice if it also looked at the return type and took
asserts value
into account, treating it asif (!value) throw
. There's more toasserts
than just checking truthiness, but handling the simplest case (nois
) would already go a long way, as that covers allok
-like assertion functions out there.Fail
Pass
Additional Info
No response
The text was updated successfully, but these errors were encountered: