Typescript: Tooltips / IntelliSense: Don't resolve type aliases (aka "semantic sugar") set explicitly

[Sgt-Nukem]

We have defined a bunch of "semantic sugar" type aliases like:

Status quo (bad): VS Code is resolving these along the alias chain in tooltips and IntelliSense suggestions (which kinda makes non-sense of the type alias in the first place)
(c.f. hovered tooltip over this.url at bottom)

Better: Let VS Code show UrlString as type here instead of string to aid developers with semantic sugar as of what type of string to expect.

Alternative: Show both, i.e. BufferingWebSocket.url: UrlString (= string).

[MartinJohns]

From the documentation: https://www.typescriptlang.org/docs/handbook/advanced-types.html#type-aliases

Aliasing doesn’t actually create a new type - it creates a new name to refer to that type.
Type aliases don’t create a new name — for instance, error messages won’t use the alias name.

So it seems to be intentional, tho I personally would hope for a change regarding this as well.

[Sgt-Nukem]

It is NOT a new type of course, it's just an alias - I mean: That's the whole point of an alias.

Nonetheless nothing contradicts showing the alias in tooltips (or both - c.f. Alternative in my OP) IMHO.

Aliasing doesn’t actually create a new type - it creates a new name to refer to that type.
Type aliases don’t create a new name — for instance, error messages won’t use the alias name.

These two sentences are contradicting another, aren't they?
--> it doesn't CREATE TYPE - it CREATES NAME
--> it doesn't CREATE NAME ???

[OliverJAsh]

Given:

// ./provider.ts
export type DOMFile = File;

// ./consumer.ts
import { DOMFile } from './provider';

type File = {
  id: string;
  file: DOMFile;
};

Hover over File and you'll see:

type File = {
  id: string;
  file: File;
};

The type inspection shows file: File when I expect it to show file: DOMFile. This makes it look like a recursive type, but actually _this_ File type is a different type entirely. This creates a very confusing user experience.

This issue does not apply if we use interfaces:

// ./provider.ts
export interface DOMFile extends File {}

Is there a reason for type aliases to have different behaviour to interfaces in this context?

[martaver]

I have also found, repeatedly, that it would be far more useful to simply show the developer the name of the type being referenced in intellisense, rather than trying to resolve the type definition.

Actually, it would be useful. Fullstop. Since descriptions in intellisense like this, really aren't:
´´´
(method) Observable<{ [P in keyof SourceMap]: SourceMap[P] extends SourceInput ? U : never; }>.subscribe(next?: (value: { [P in keyof SourceMap]: SourceMap[P] extends SourceInput ? U : never; }) => void, error?: (error: any) => void, complete?: () => void): Subscription (+4 overloads)
´´´

If it kept the type name, I could actually go to the type, read its documentation etc. and better understand the intent.

Understand that type aliases are 'just aliases'... but this is really just about creating a better developer experience.

Personally, I never really understood why there needed to be separate 'type' and 'interface' entities.

[Sgt-Nukem]

Actually, it would be useful. Fullstop. Since descriptions in intellisense like this, really aren't:
´´´
(method) Observable<{ [P in keyof SourceMap]: SourceMap[P] extends SourceInput ? U : never; }>.subscribe(next?: (value: { [P in keyof SourceMap]: SourceMap[P] extends SourceInput ? U : never; }) => void, error?: (error: any) => void, complete?: () => void): Subscription (+4 overloads)
´´´

OMG!! I've never seen the correlation to my feature request until now!!

Yes, I fully second this. Error messages would be far more readable if Shape stayed Shape and wouldn't be blown up to 'Square' | 'Rectangle' | 'Circle' | 'Ellipse' | 'Triangle' or something...

[Polatrite]

+1 for this.

In our project, I wanted to declare some semantic types representing numbers, to remove some of the ambiguity of "what does this random float value actually mean?", so I added these type alias declarations:

type percentage = number
type timeInSeconds = number
type timeInMilliseconds = number
type radians = number
type degrees = number
type gameUnits = number

I was quite disappointed to see that the assorted tooltips/intellisense did not keep the alias in tact, and just resolved down to a number.

[PunkIslamist]

I just stumbled across this behavior as well and would like to see the recommended change. Having type aliases can make code clearer and easier to read. But when this information gets erased in the tooltip, it looses its purpose.

[svdHero]

+1

It gets even worse with generic functions. For rich type modelling, type hints like this:

(methode) toResult<Readonly<{
    searchIndexId: string;
    searchResult: Readonly<{
        pageInfo: Readonly<{
            pageIndex: number;
            totalNumPages: number;
            numItemsOnThisPage: number;
            numItemsPerPage: number;
            totalNumItems: number;
        }>;
        pageData: readonly Readonly<...>[];
    }>;
}>>(response: ServerResponse<...>): Result<...>

are almost useless. I can't even see the function parameter's full type, because all the space is used up for the generic type description.
What the above should have said, is:

(methode) toResult<SearchForProjects>(response: ServerResponse<SearchForProjects>): Result<string, SearchForProjects>

honoring my type aliases.

[carljohnesan]

Faced same issue when wanted to short Record<string, unknown> to Dict via type Dict = Record<string, unknown>, as there was alot of them, and saw this alias nowhere! For example following function signature:

function foo<
  T1 extends Dict,
  T2 extends Dict,
  T3 extends Dict,
  T4 extends Dict
>(
  param1: T1,
  param2: T2,
  param3: T3
): T4

Showed in tooltip as:

function foo<T1 extends Record<string, unknown>, T2 extends Record<string, unknown>, T3 extends Record<string, unknown>, T4 extends Record<string, unknown>>(param1: T1, param2: T2, param3: T3):  T4

I was very frustrated when faced this problem! Please fix this or at least add setting to change this behavior! Definitions are just unreadable!