Comments (6)
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. Boolean()
is in the proposed fixes list, and !!
is equivalent. Either remove Boolean()
as a solution, or allow !!
?
from typescript-eslint.
from typescript-eslint.
My question for you would be:
If you want to allow weak, unstrict boolean expressions then why aren't you using the rule with allowNullableString
et al?
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 Boolean()
behind an option. The reason we didn't originally is because it is a very loud and explicit way of opting out if the rule (as in "this expression right here is being coerced") that is nicer than a disable comment.
from typescript-eslint.
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 !== null
check instead of !!
. I'm not sure I won't disable this rule, or relax it as much as possible in the future.
Still, IMO, allowing Boolean()
as a bypass, and forbidding !!
is just weird. Now, I don't know if what you're saying about it being uncommon syntax is true, but it was widely used by my previous team, there's 119 hits in the JS codebase of my current one, and 56 on a naive search of this repo right here (vs just 19 hits on Boolean(
). It very clearly tells me this is an explicit coercion.
I don't really care whether you remove Boolean bypass or allow !!
though, I do strongly believe they should be treated the same.
from typescript-eslint.
Sorry - I should clarify.
"In codebases that use strict-boolean-expressions
usage of !!
to loosely coerce a value to a boolean is uncommon"
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.
Still, IMO, allowing Boolean() as a bypass, and forbidding !! is just weird.
There are multiple reasons that it works this way.
The first (and main) reason is that the argument passed to Boolean()
is not a boolean context - it's a function that accepts any
and returns a boolean. So it's not explicitly handled by any of the rule's logic by default as the rule was designed to inspect boolean contexts aka logical expressions.
OTOH !value
is a logical expression that the rule checks intentional and by design. So following from that !!value
is also checked by design as !!value
is no different to !value
from the rule's perspective.
The reason we haven't made a change to specifically allow the !!
case is as mentioned - it's very uncommon people actually want to allow it when using the rule - as evidenced by the fact that we've only had a few requests over the years.
The difference is the verbosity of it.
!!value
vs
Boolean(value)
The former is very easy to misread as !value
and miss the fact that it's in-fact doing a weak coercion.
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.
from typescript-eslint.
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 :)
from typescript-eslint.
Related Issues (20)
- Rule proposal: functions should not be `async` unless they `await` HOT 15
- Enhancement: Add v8 projectService name to withoutProjectParserOptions HOT 1
- Enhancement: Remove getTokenAtPosition from type-utils
- Rule proposal: check that function is not returning promise and non-promise HOT 4
- Docs: Add generated documentation on packages exports to the site HOT 3
- Bug: TypeOrValueSpecifier should allow intersection types (no-floating-promises allowForKnownSafePromises)
- Bug: [prefer-optional-chain] conflict with [strict-boolean-expressions] HOT 3
- Document rationale for allowNumber: false in restrict-template-expressions HOT 3
- Bug: Vue + TypeScript project slowdown with v8 alpha HOT 9
- projectService / EXPERIMENTAL_useProjectService gives TS error if not boolean on v8 alpha / v7 HOT 1
- Docs: add an FAQ section about eslint TIMING/`--stats` and type-aware rules being misleading HOT 1
- Bug: `disabled-type-checked` config does not disable project service
- Enhancement: `no-misused-promises` should not flag functions whose contents are wrapped in `try`/`catch` HOT 2
- Base rule extension: nonblock-statement-body-position HOT 1
- Enhancement(typescript-estree): expose ProjectService logs through plugin HOT 1
- Website: Playground is currently broken HOT 2
- Docs: Release note of v7.12.0 contains critical misleading typo HOT 2
- Bug: `[email protected]` has TS error HOT 1
- Bug(website): React key error on internal pages of website
- Rule proposal: disallow comparing non-numeric values with >, < operators HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typescript-eslint.