Additional cases that this rule should handle:

• class properties

  classF{prop:Fruit=1;}

  • There's also cases like this:

    interfaceF{prop:Fruit;}classFooimplementsF{prop=1;}

• object properties

  constx={prop:1}as{prop:Fruit))

• assertions in general?

  constx=1asFruit;consty=<Fruit>1;

• JSX attributes

  typeProps={prop:Fruit};declarefunctionComponent(props:Props):JSX.Element;(<Componentprop={1}/>);

• return statements

  functionx():Fruit{return1;}

• computed member expression properties

  declareconstfoo:{[kinFruit]:string};foo[0];foo?.[0];declareconstbar:{[Fruit.Apple]:string};bar[0];bar?.[0];

Edge cases to think about:

declarefunctionfn(arg:Fruit):void;fn(...[1]);constx=[1,Fruit.Apple,2]asconst;consty:readonlyFruit[]=x;interfaceFoo<TextendsFruit>{prop:T;}exportconstclazz:Foo<Fruit>=classWTF{staticprop=1;}

Yeah, there are alot of cases to handle here. Basically any identifier and literal has to be checked - including array literals and parameters to generic functions!

I don't have the time to work on this rule given other, more important features to work on. So I'm going to close this PR. If anybody else wants to pick it up, please do!

Note that the code will likely need to be refactored a good bit to support all the new cases.

I wonder@JoshuaKGoldberg - do you think this should be built directly into ourno-unsafe-* rules, rather than being their own rule.

The reason I originally split up the rules into a set was to isolate the logic for checking assignments in each case to reduce the overall maintenance complexity.
So those rules already contain much of the logic required by this rule in terms of getting contextual types and checking generics.

They don't currently do some of the checks I've listed (like checking when{prop: any} is assigned to{prop: string}), but at least there would be parity.

WDYT? Do we refactor to reuse logic or build into those rules?

Hmmmmm, my gut reaction is that I'd rather extract those things out into shared utilities. +1 to reusing the logic for sure. Enums really aren't the same use case asany safety. I also had to reimplement a bunch of them inTypeStat and that was a huge pain.