-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Enchancement: [strict-boolean-expressions] Treat !!x
same as Boolean(x)
#9060
Comments
Weird, I searched by rule name and found nothing, sorry. Still, in #7444 the author's point isn't addressed and I'd like to second it. |
My question for you would be: The main reasons that I think this goes against the rule is because it's (a) an uncommon syntax in modern TS and (b) unclear and easy to miss as a choice of syntax - it's two characters (c) it's a loose coercion where you're not strictly and explicitly handling the falsey cases. But ultimately the rule is configurable. But if you want to ban nullable strings and allow exceptions then you're in a small minority of users that were not actively looking to support. Realistically you can and should use a disable comment. As I mentioned in the other issue - IMO we should really be banning |
I'm still getting a feel for the rule. I'm in a new job and there was neither linting, nor Typescript here before me. Previously I've used mostly the recommended config, and learned that some fairly useful and obvious things are missing from it, so this time I've explored every single rule in eslint, typescript-eslint and react plugins, enabling those that looked reasonable to me. I've hit this one in the first file conversion to Typescript I've made. In that case, I've opted into doing a Still, IMO, allowing I don't really care whether you remove Boolean bypass or allow |
Sorry - I should clarify. The syntax itself is reasonably common but when people opt-in to the SBE rule they explicitly want to NOT have weak coercion of values - thus it's rare that they use the rule and also want to allow the syntax.
There are multiple reasons that it works this way. The first (and main) reason is that the argument passed to OTOH The reason we haven't made a change to specifically allow the The difference is the verbosity of it. The former is very easy to misread as I could see the possibility of an option for it - but as per the above - I don't think it's broadly applicable enough for us to move and implement it in our project. |
I see. Well, thank you for the explanation, it's very nice of you to go into such detail :) I still think they should match regardless, but at least it doesn't look like a missed case anymore. Nothing more I can say, so, see you around :) |
Before You File a Bug Report Please Confirm You Have Done The Following...
Playground Link
https://typescript-eslint.io/play/#ts=5.4.3&fileType=.tsx&code=GYVwdgxgLglg9mABACwKYBt1wBQFsCeAbgIYBOAXIgM5SkxgDmiAPomCJgJSIDeAUIkQxgibAEIxBEqW49EAXz6KgA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6ZfKsugIwHs%2BSAIZN6AD2LQUySnyaoMkRNGh9okcGAC%2BILUA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false
Repro Code
ESLint Config
Additional Info
Not strictly a bug, but IMO this is a valid, less verbose way to explicitly convert things to boolean.
The text was updated successfully, but these errors were encountered: