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 Proposal Please Confirm You Have Done The Following...
- I havesearched for related issues and found none that match my proposal.
- I have searched thecurrent rule list and found no rules that match my proposal.
- I haveread the FAQ and my problem is not listed.
My proposal is suitable for this project
- My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
- My proposal is not a "formatting rule"; meaning it does not just enforce how code is formatted (whitespace, brace placement, etc).
- I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).
Background
In languages likepython use thein
operator to check for key existence in sets and maps. Polyglot engineers may make the mistake to usein
in JS.
Withthis change to TS to be released in 4.9, thein
operator will now refine any object type by intersecting it withRecord<key, unknown>
. This means you could get some funky behaviour that previously was not allowed.
For example:
declareconstmap:Map<string,unknown>;declarefunctionacceptsAnything(arg:unknown):void;if('woopsie'inmap){acceptsAnything(map['woopsie']);}
Currently in TS 4.8 this errors withElement implicitly has an 'any' type because type 'Map<string, unknown>' has no index signature. Did you mean to call 'map.get'? (7052)
After the above PR, this no longer errors at all because the type ofmap
is refined toMap<string, unknown> & Record<'woopsie', unknown>
, sotypeof map['woopsie'] === unknown
.
Rule Description
In the vast, vast majority of cases you wouldn't want to allowin
to be used. I can think of the following cases that youwould want to allowin
:
{}
object
- A type with an index signature (i.e.
Record<K, V>
)
I think behind a (default false) flag we could also allowin
to be used against types if and only if the type (or one of the types if it is a union) has that property.
Fail Cases
declareconstset:Set<string>;if('woopsie'inset){}declareconstmap:Map<string,unknown>;if('woopsie'inmap){}classFoo{}if('woopsie'in(newFoo()){}declareconstarray:string[];if('woopsie'inarray){}if(1inarray){}'a'in['a'];// some languages like python allow `in` to be used like `.includes`
With the "allow known keys in objects" flag turned OFF:
declareconstobj:{a:string};if('a'inobj){}if('b'inobj){}declareconstunion:{a:string}|{b:string};if('a'inunion){}
Pass Cases
for(constvalinarr){}// ForInStatement should be ignored by this rule as it has different meaningdeclareconstobjectType:object;if('key'inobjectType){}declareconstemptyObjectType:{};if('key'inemptyObjectType){}declareconstrecord1:{a:string,[k:string]:unknown};if('key'inrecord1){}if('a'inrecord1){}declareconstrecord2:Record<string,number>;if('key'inrecord2){}
With the "allow known keys in objects" flag turned ON:
declareconstobj:{a:string};if('a'inobj){}// allowed --- should probably be flagged by no-unnecessary-condition?declareconstunion:{a:string}|{b:string};if('a'inunion){}