#43707 drops correct errors for @types/mongoose

[sandersn]

type Disarray<Type> = Type extends ReadonlyArray<infer Element> ? Element : Type;
interface L {
    facilities: string[];
    coords: number[];
}
declare var d: {
        // broken
        $pull?: { a?: 1 } & { [key in keyof L]?: { eq?: "unassignable" } } // used to have Disarray<TSchema[key]>, to get the correct error
        // OK
        $push?: { [key in keyof L]?: Disarray<L[key]>;}
    } & {
        b?: 2
    };

d = { $pull: { coords: "should be type error" } }
d = { $pull: { facilities: -1 } }
d = { $push: { coords: "should be type error" } }
d = { $push: { facilities: -1 } }

Expected: Errors on all
Actual: Only errors on the $push assignments.

Broken by #43707

The break should apply to all users of mongodb, mongoose just has the most tests.

[sandersn]

By the way, @amcasey suggested that I learn how to generate and read traces by using mongoose/mongodb. The types are painfully slow.

[sandersn]

Well, I figured out how the original fix was wrong. Passing through the intersection state correctly turns off excess property checking for the title source property to the Route target object:

export interface ChildrenFn {
    (): Route[];
}

interface Route {
    path?: string;
    children?: Route[] | ChildrenFn;
}

type RouteWithTitle = Route & { title?: string; children?: RouteWithTitle[] };

const mainView: RouteWithTitle = { // 
    path: "",
    children: [
        {
            path: "",
            title: "Empty",
        }
    ],
};

But it incorrectly turns off common property checking, allowing "hi" to be assigned to RouteWithTitle. I'm not yet sure why the post-intersection whole-object check doesn't catch this, so the fix might be there. Or it might not be easily fixed at all.

const mainView: RouteWithTitle = {
    path: "",
    children: [ "hi" ]
}

[sandersn]

The whole-object check only applies when the target is an intersection, but when IntersectionState.Target is not set. That's exactly what #43884 sets -- good in that case, since it turns off an excess property error, but bad in this case, since it removes a correct common property error.

I think the right thing to do is revert #43707 and re-open #42715 with a note that (1) a complex tweak to excess property checking is probably needed but (2) it's not worth it.