Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
Description
Before You File a Documentation Request Please Confirm You Have Done The Following...
- I have looked for existingopen or closed documentation requests that match my proposal.
- I haveread the FAQ and my problem is not listed.
Suggested Changes
I'd like to add a section thatbriefly alerts users to the nuances around primitives being assignable to object types, causing sort-of-false-positives with no-unnecessary-condition's truthiness checks.
I'd like to mention:
"object types" are just "things with properties",not objects (a superset ofno-empty-object-type shenanigans)
functionfoo(x:{toString:Function}){if(x){// reported by no-unnecessary-condition as always-truthy}}foo(false);foo(true);foo({});
object
can easily contain primitives at runtime, without typical obviously unsafe TS patterns.functionfoo(o:object){if(o){// reported by no-unnecessary-condition as always-truthy}}foo(false);// TS error.constlol:{}=false;foo(lol);// but this is allowed by TS.
As said, I think this should bebrief, just to alert users to possibly-faulty common assumptions about the type system, and then punt deeper dive tomicrosoft/TypeScript#60582 (comment) or any other good references. The main goal is really to conveythink closely about your application before "fixing" a truthiness report, since the condition may actually be necessary, despite what the types appear to be indicate.
Affected URL(s)
https://main--typescript-eslint.netlify.app/rules/no-unnecessary-condition#limitations
Additional Info
Relates to#10378, which may eventually change some of this behavior. But regardless of rule behavior change on our side, it's valuable for users to know that primitives may be lurking places they didn't expect.