Using `satisfies` on a self-referencing object causes `any` - TS 4.9.2-RC

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

Version 4.9.2-rc

💻 Code

interface Items {
  id: 'a' | 'b';
  condition: () => boolean;
}

// 'items' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.ts (7022)
const items = {
  foo: {
    id: 'a',
    condition: () => true
  },
  bar: {
    id: 'b',
    condition: () => items.foo.id === 'a'
  },
} satisfies Record<string, Items>;

🙁 Actual behavior

items implicitly has type any.

🙂 Expected behavior

items should be checked with the Items interface and still have typesafe keys.

[fatcerberus]

I feel like TS needs better error messages.

The error text…

because it does not have a type annotation and is referenced directly or indirectly in its own initializer

…implies that simply referencing yourself is sufficient cause for error, but in reality sometimes it’s allowed (intentionally, even). I’m starting to see why people complain so much about TS being inconsistent—context matters, but the error messages tend to speak in absolutes, making any difference in error-producing behavior look like a bug…

I guess if I had to put my finger on it, it’s the difference between “you’re not allowed to do this” vs. “I can’t resolve this and here’s the complication I ran into while trying”, and it’s easy to read some errors as implying the former when it’s really the latter.

[DanielRosenwasser]

I’m not sure if there’s a way for us to avoid pulling on the type of types here before it’s been initialized, but since you can observe the same thing with a “fake” version of satisfies in older versions of TypeScript, I might be tempted to say that this is an expected design limitation.

interface Items {
  id: 'a' | 'b';
  condition: () => boolean;
}

declare function satisfies<U, T extends U = U>(val: T): T

// 'items' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.ts (7022)
const items = satisfies<Record<string, Items>>({
  foo: {
    id: 'a',
    condition: () => true
  },
  bar: {
    id: 'b',
    condition: () => items.foo.id === 'a'
  },
});

That said, maybe we could do something a little different here. We could possibly defer all comparisons for satisifes until after all deferred function bodies have been checked as well. So basically satisfies does nothing except for provide a contextual type at first, and then is checked after everything else.