Improve Generic Class + Namespace Intellisense

[LukeAbby]

🔍 Search Terms

generic class, namespace, intellisense, hover hint

✅ 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

The hoverhint on namespaces declaration merged with generic classes gets ugly. I would prefer if they were simpler. Here's an example:

Because namespaces cannot access the generics of the class I also think it's a bit misleading of a display and arguably a bug. If it is intentional I would love to know. However I opened this issue as a feature request partially because I would like it to change even if this behavior is intentional.

This same phenomenon does not happen with associated functions only with classes. Perhaps this is because namespaces can be automatically generated on functions:

function identity<T extends number>(t: T): T { return x }

identity.prop = 123;

Compiles to this .d.ts file:

declare function identity<T extends number>(t: T): T;
declare namespace identity {
    var prop: number;
}

However I cannot find a way to get a poor intellisense even when I manually add types, consts etc. so it appears to be a phenomenon exclusive to classes.

📃 Motivating Example

declare namespace ClassAndNamespace {
    type Example = 1 | 2 | 3;
    //   ^ Is currently: type ClassAndNamespace<T extends ClassAndNamespace.Example>.Example = 1 | 2 | 3
    //     want: `type ClassAndNamespace.Example = 1 | 2 | 3`

   const example: 123;
   //    ^ Is currently: `const ClassAndNamespace<T extends ClassAndNamespace.Example>.example: 123`
   //      want: `const ClassAndNamespace.example: 123`
}

declare class ClassAndNamespace<T extends ClassAndNamespace.Example> {}
//                                                          ^ Same display as in namespace.

ClassAndNamespace.example;
//                ^ Same display as in namespace.

declare class Subclass<T extends ClassAndNamespace.Example> extends ClassAndNamespace<T> {}
//                                                 ^ Same display as in namespace.

const instance = new Subclass();
//                   ^ Is currently: constructor Subclass<ClassAndNamespace<T extends ClassAndNamespace.Example>.Example>(): Subclass<ClassAndNamespace.Example>
//                     want: constructor Subclass<ClassAndNamespace.Example>(): Subclass<ClassAndNamespace.Example>

💻 Use Cases

When I have a complex class with a great number of associated methods and interfaces the most natural way of organizing seems to be namespaces for this project. It's a bit older and heavily uses globals but that won't be changing any time soon and so this is the most convenient way of being organized.

Unfortunately whenever classes are generic the hover hints become unwieldy and I'd prefer for them not to be.

[RyanCavanaugh]

I agree there's no need to print type parameters when qualifying the namespace of a type.

Showing the constraint as part of the signature in e.g. new Subclass() is intentional -- you (may) need that information to know how to correctly call the constructor.

[LukeAbby]

Perfectly happy with showing the constraint, if you mean constructor Subclass<ClassAndNamespace.Example>(): Subclass<ClassAndNamespace.Example> that is. It's noted as my preference because it matches what goes on in other classes.

If you mean that it should still be constructor Subclass<ClassAndNamespace<T extends ClassAndNamespace.Example>.Example>(): Subclass<ClassAndNamespace.Example> I would find it odd to still show <T extends ClassAndNamespace.Example>. This is because if the namespace is named differently it will display as constructor Subclass<SomeOtherNamespace.Example>(): Subclass<ClassAndNamespace.Example> rather than constructor Subclass<ClassAndNamespace<T extends SomeOtherNamespace.Example>.Example>(): Subclass<ClassAndNamespace.Example>

[RyanCavanaugh]

Right, when the name is part of a qualified thing like Foo.bar where bar can't see T, we don't need to show Foo<T>.bar