Additional cases that this rule should handle:

• class properties

  class F {
    prop: Fruit = 1;
  }

  • There's also cases like this:

    interface F { prop: Fruit; }
    class Foo implements F {
      prop = 1;
    }

• object properties

  const x = { prop: 1 } as { prop: Fruit ))

• assertions in general?

  const x = 1 as Fruit;
  const y = <Fruit>1;

• JSX attributes

  type Props = { prop: Fruit };
  declare function Component(props: Props): JSX.Element;
  (<Component prop={1} />);

• return statements

  function x(): Fruit {
    return 1;
  }

• computed member expression properties

  declare const foo: { [k in Fruit]: string };
  foo[0];
  foo?.[0];
  
  declare const bar: { [Fruit.Apple]: string };
  bar[0];
  bar?.[0];

Edge cases to think about:

declare function fn(arg: Fruit): void;
fn(...[1]);

const x = [1, Fruit.Apple, 2] as const;
const y: readonly Fruit[] = x;

interface Foo<T extends Fruit> { prop: T; }
export const clazz: Foo<Fruit> = class WTF {
    static prop = 1;
}

Yeah, there are a lot 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 our no-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 as any safety. I also had to reimplement a bunch of them in TypeStat and that was a huge pain.