typeAlias = type, however, definition to convert types resolution into a hierarchy(Tree) for enhanced display, granularity control

[wesleyolis]

The ability to allow type resolution of typescript for design time behaviour to not always resolve down to its base primitives, would help in communicate which type names should be used at the different layers of code composition. It would be nicer to see a modules type or an alternative internal named type instead of a primitive type. Currently this can be achieved by using interface names, however, I do feel it can be clumb some and potentially with structural typing not always a good thing.

It would be great to just define alias type using 'typeAlias', instead other more detail methods previously mention and similar to other languages, which is used to control the granularity.

When a type is resolved I would imagine that it would be presented in graphical tree eventually,
were the first typeAlias or interface token/node encountered would be the top level entry. Their after any typeAlias definitions on the path to resolving a type to its primitive are added as child elements.
This would allow the operator to decide the level of detail nessary to resolve his typing issues and peel back as many type layers as required, by expanding the child items.

[] Square brackets communicate this is a resolved type and their are potentially many types between this and the primitive.

It may still be useful to show all type redefinition for debugging purposes, in which case a different tree child symbol could be used, which is clickable on to communicate this. !->

Examples:

Case 1

Code

type A = boolean
type B = A
type C = B
interface/class D implemented/extends C {}
typeAlias E = D
type F = E
type G = F
typeAlias H = G
type I = H

Tree:

! H = G [boolean] // In Square brackets the most base type
 -> E  = D  [C] // Here present in square brackets, last successive child item type, probably too verbose
     !-> D = C
            |-> A = boolean

Case 2

Code

type A = string
type B = A
typeAlias C = B

Tree:

! C = [string] //square brackets communicate this is resolved type.

Case 3

Code

interface/class D implements/extends C
type A = string
type B = A
typeAlias C = B

Tree:

D = C [string]
   |->C = [string]

My suggestion meets these guidelines:

• 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. new expression-level syntax)

[mhegazy]

Type aliases are just that, aliases. the compiler aggressively inline their values when using them. that is why for instance a type alias can not reference itself. This is a design choice that we have made a while back, this allows the compiler to save memory storing an additional object of every type alias, but more importantly save time, since comparing two type does not have to delve through their alias chain.

[mhegazy]

you might find #15807 interesting for your use case.

[wesleyolis]

@mhegazy Thanx I will take a look into that, unique structural wrappers, identifier and a random symbols for safety.

When you say design limitation, would be not be able to write additional integration tools, to inspect AST for VSCode? I am were the limitation would be determine at which layer and stage the AST be being consumed/interrogated by VSCode?

A littler bit off topic here:
Out of interest I have pulled and start poking around in typescript repository.. Is their a drop in manual for getting on up to speed with normiculture and conventions of normiculture used to describe certain patterns of characters for tokenisation as well project architecture layout..
I have my own interest in getting into it as I have some other features of interest and language enhancements for literal type validation and potentially a new GUI Event based programming language to deal with complicated issues that arise, which needs both language and framework support.

Is the a drop in manual for getting upto speed with the internals of the typescript repository?

[mhegazy]

to inspect AST for VSCode?

this is not the AST. this is the type that the compiler inferred.

. Is their a drop in manual for getting on up to speed with normiculture and conventions of normiculture used to describe certain patterns of characters for tokenisation as well project architecture layout..

take a look at https://github.com/Microsoft/TypeScript/wiki/Architectural-Overview and https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.