Inline IIFE return type when assigned to a variable of the same name.

[DanKaplanSES]

🔍 Search Terms

IIFE, Quick Info, Type Display, Type Inference

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When an IIFE's return type shares the same name as the variable it's assigned to, the type information of the variable appears self-referential (const Foo: typeof Foo); I'd like to recommend inlining the variable's type to be equivalent to the IIFE's return type.

📃 Motivating Example

This may be a "garbage-in, garbage-out" situation, but I'm working with legacy JS code that frequently uses this pattern:

As code:

export const Foo = (() => {
  //         ^?
  //          Wouldn't `class Foo` be just as accurate yet more informative?
  class Foo {
    //  ^?
  }

  return Foo;
  //     ^?
})();

// compare to Bar, it has a type of `class Bar`
export class Bar {
  //         ^?
}

const x = Foo;
//    ^?

Expected

const Foo's type would be class Foo

Actual

const Foo's type is typeof Foo

💻 Use Cases

1. What do you want to use this for? This feature would reduce cognitive load in certain legacy code bases, reducing the effort in porting JS to TS. I'm expecting my use case to be too niche to be considered, but I think inlining the return type of IIFEs could make the tooltip more helpful in other (/most?) scenarios.
2. What shortcomings exist with current approaches? They appear uninformative at first glance.
3. What workarounds are you using in the meantime? I tinkered around with the code enough to understand what the typeof Foo really refers to. Alternatively, you can rename the variable or the IIFE's return type. But in a legacy code base, that could introduce risk.

[MartinJohns]

But class Foo doesn't exist at that scope.

[DanKaplanSES]

But class Foo doesn't exist at that scope.

True. I don't have a lot of language design experience; does that introduce significant problems and/or challenges? I'm not tied to the solution in my "Expected" section if there's a better one. Personally, if it inlined the "shape" of the class, I'd like that better, but I saw other issues requesting that quick infos go in the opposite direction, so I didn't propose that above.

[fatcerberus]

if it inlined the "shape" of the class, I'd like that better

That’s not currently feasible; see #41581 and #41587

[RyanCavanaugh]

This would arguably be more confusing - there isn't a class Foo in scope here; you can't use it as a type.