tsserver hangs indefinitely when inferring return type of class method that passes this to a function with deeply nested conditional return type

[kkirby]

🔎 Search Terms

hang circular

🕗 Version & Regression Information

This behavior is present in TypeScript 5 and TypeScript 6 beta.

⏯ Playground Link

N/A — requires the remeda package (npm i remeda). Reproduction is a self-contained file below.

💻 Code

import { pick } from "remeda";

export class MyClass {
  constructor(public readonly field: number) {}

  // [bad] tsserver hangs indefinitely: no explicit return type
  getIdentity() {
    return pick(this, ["field"]);
  }

  // [good] works fine: explicit return type breaks the cycle
  getIdentityFixed(): Pick<MyClass, "field"> {
    return pick(this, ["field"]);
  }
}

🙁 Actual behavior

tsserver becomes completely unresponsive. The editor (VS Code) loses all language service features (hover types, completions, diagnostics) until tsserver is manually restarted. No error is emitted; tsserver simply loops forever.

The cause is an undetected circular type inference chain. To infer the return type of getIdentity(), TypeScript must evaluate PickFromArray<MyClass, ["field"]> (remeda's pick return type). That involves IsBoundedRecord<MyClass> → IsBounded<KeysOfUnion<MyClass>>. KeysOfUnion uses UnionToIntersection, which places MyClass in a contravariant function parameter position — forcing eager, non-deferred evaluation of the full structural type of MyClass. The full type of MyClass includes getIdentity: () => <inferred>, whose inferred return type is what we started trying to compute. Because the cycle passes through ~5 distinct type alias instantiations, TypeScript's cycle-detection heuristics never fire, and the checker loops indefinitely instead of emitting a "circularly references itself" error.

🙂 Expected behavior

TypeScript should detect the circular inference and either:

• Emit a "Return type annotation circularly references itself" error (as it does for simpler cycles), or
• Fall back to any with a warning.

Either outcome is acceptable. The checker should never hang.

Additional information about the issue

Workaround: add an explicit return type annotation to the method. This gives TypeScript the type of MyClass.getIdentity() upfront, preventing the cycle from forming.

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Possible Relevant FAQs

TS7022 Circularity Errors May Occur In The Presence of Circularities

The hang is triggered by an undetected type-checking cycle. While the compiler normally spots most cycles and reports something like

TS7022: 'getIdentity' implicitly has type 'any' because it is referenced directly or indirectly in its own initializer

there are still patterns where the cycle slips past the heuristic and the checker keeps recursing. The path you described—getIdentity → pick → IsBoundedRecord → IsBounded → KeysOfUnion → UnionToIntersection → back to getIdentity—is one of those edge cases.

Two practical ways to unblock work until the underlying cycle detection is improved:

1. Annotate the method explicitly, as you already did:

getIdentity(): Pick<MyClass, 'field'> {
  return pick(this, ['field']);
}

2. Break the chain by asserting the return type at the call-site of pick, e.g.

return pick(this, ['field']) as Pick<MyClass, 'field'>;

The team does investigate hangs like this, but in general the bar for adding new cycle diagnostics is high, because tightening the heuristics can surface spurious errors in existing code. If someone can devise a safe fix that eliminates the infinite recursion without introducing new false-positive TS7022 reports, it will be reviewed.

Until then, using an explicit return type (or a type assertion) avoids the problematic inference path and keeps tsserver responsive.

Possibly Working as Intended

It looks like this behavior might be intentional. Here's what a computer had to say about it.

The compiler is not expected to loop forever. A method without an explicit return type may trigger heavy inference, but the checker is supposed to either finish the computation or reject it with a circular-reference error. The fact that the type graph here sends the checker into an infinite expansion (making the server unresponsive) is a defect in the cycle-detection logic, not correct behavior. Adding a return-type annotation is only a workaround.