Tsgo considers wrong API usage as correct - difference in typechecking

[jansedlon]

Steps to reproduce

1. Clone repo https://github.com/jansedlon/tsgo-repro
2. Install dependencies
3. Open index.ts

Behavior with typescript@5.9

The constant posts has a type of

const posts: {
    id: string;
    createdAt: Date;
    updatedAt: Date;
}[]

And typescript reports error in attachments object because selecting database fields needs to be inside of columns object and orderBy in attachments like so

attachments: {
  columns: {
    id: true,
    // ...
  },
  orderBy(fields, { asc }) {
    return asc(fields.createdAt);
  }
}

Behavior with tsgo

Not only it doesn't report any error, it even considers wrong API usage as correct and infers types. This would result in runtime error.

The type of posts is inferred as

const posts: {
  attachments: {
    createdAt: Date;
    filename: string | null;
    id: string;
    location: string;
    postId: string | null;
    size: number | null;
    type: string;
    updatedAt: Date;
  }[];
  id: string;
}[]

Note

I have found out that the thing that breaks this is the orderBy function. If you comment that out, it will start reporting errors.

[RyanCavanaugh]

Copilot-reduced repro, verified:

type KnownKeysOnly<T, U> = {
    [K in keyof T]: K extends keyof U ? T[K] : never;
};

type Config = {
    child: { foo: unknown };
};

declare function test<T extends Config>(config: KnownKeysOnly<T, Config>): void;

test({
    child: {
        id: true,
        foo: 'x',
    }
});

[RyanCavanaugh]

Actually, this doesn't repro in 6.0 at latest...

[jansedlon]

Oh i'm so sorry, i'm on 5.9 actually

[RyanCavanaugh]

So was I 😅. Worth a bisect to see where this changed so that we can mention it in the 6.0 blog, investigating

[RyanCavanaugh]

Bisects to microsoft/TypeScript#62722

[RyanCavanaugh]

Well, that's not explicable. It seems intentional, though. @Andarist any thoughts?

[Andarist]

It seems to me the formulation of the given KnownKeysOnly is actually incorrect. It only tries only limit the top-level properties but the example call implicitly expects a property at a deeper level to be rejected. That really had to only work accidentally before my PR - given the inner object (a result of reverse mapped symbol inference) wasn't widened and thus it still was treated as a regular EPC target.

In other words, in the given simplified example, it's not really KnownKeysOnly that leads to an error. It's the reverse mapped type itself. The same error gets reported if we switch it to using Identity (TS 5.9 playground):

type Identity<T> = {
  [K in keyof T]: T[K];
};

type Config = {
  child: { foo: unknown };
};

declare function test<T extends Config>(config: Identity<T>): void;

test({
  child: {
    id: true, // errors... but why?
    foo: "x",
  },
});

[RyanCavanaugh]

Thanks!