New rule: Optional properties lead to unsoundness

[danielnixon]

This is unsettling:

type Foo = { readonly foo: string };
type Bar = { readonly foo: string, readonly bar?: () => unknown };
// This won't compile
// const foo: Foo = { foo: "foo", bar: "bar" };
// But this will
const thing = { foo: "foo", bar: "bar" };
const foo: Foo = thing;
// Uh oh...
const bar: Bar = foo;
if (bar.bar !== undefined) {
    // Runtime explosion
    // [ERR]: Executed JavaScript Failed: 
    // [ERR]: bar.bar is not a function 
    bar.bar();
}

It’s hard to point at precisely which line is “wrong”.

We may want a new rule that forbids:

const foo: Foo = thing;

We can think of it as taking the tsc error reported by

const foo: Foo = { foo: "foo", bar: "bar" };

and expanding its scope beyond just object literals.

[danielnixon]

Or is

const bar: Bar = foo;

the thing we want to flag as an error?

If the destination type has an optional property and the source type has no such property (optional or otherwise), there is no way for us to know whether an incompatible property with the same name exists at runtime.

And, importantly, you can't just blame this on unsafe type assertions, or incorrect *.d.ts typings or any shenanigans like that. You can pull it off with otherwise nicely typed, functional TypeScript (strict mode enabled, no interfaces, no classes, everything readonly, everything const, no type assertions, no plain JS, etc).