Discrepancy when typeToString when enclosingDeclaration is undefined vs defined.

[stacey-gammon]

Bug Report

I'm using typeToString functionality from the typescript compiler (via ts-morph) to build auto-generated API documentation. I've run into an issue with certain types that use default generic types. My goals:

• I don't want the default parameters to show up
• I want the module/sourcefile import included

If I pass enclosingDeclaration, the default parameters don't show up, but the import is gone. If I don't pass enclosingDeclaration the opposite happens - import is there, but the default parameters show up.

🔎 Search Terms

Typescript typeToString generic optional default parameter ignore enclosingDeclaration

🕗 Version & Regression Information

I'm not sure this is bug but there is nothing I could find about it anywhere else.

⏯ Playground Link

link

Code sandbox which shows the issue.

💻 Code

Types:

export interface WithDefaultGenerics<A = string, B = number> {
  irrelevant: string;
}

export type Test = () => WithDefaultGenerics;

    const text = compiler.typeToString(
      compilerType, // This is the type of `Test`
      undefined,
      TypeFormatFlags.UseFullyQualifiedType | TypeFormatFlags.InTypeAlias
    );
    console.log('text is ', text);

    const text2 = compiler.typeToString(
      compilerType, // This is the type of `Test`
      node.compilerNode, // This is the node container of `Test`
      TypeFormatFlags.UseFullyQualifiedType | TypeFormatFlags.InTypeAlias
    );
    console.log('text2 is ', text2);

🙁 Actual behavior

text is  () => import("/Users/path/to/file").WithDefaultGenerics<string, number>

text2 is  () => WithDefaultGenerics

🙂 Expected behavior

I'm trying to get () => import("/Users/path/to/file").WithDefaultGenerics

The reason this is important to me is because in conjunction with, I suspect, this issue, getting a type for (props: AllCasesProps) => ReactElement<AllCasesProps> ends up looking like this:

[RyanCavanaugh]

• I don't want the default parameters to show up
• I want the module/sourcefile import included

I'm not sure this is going to be possible. The type printer has two main cases:

• The originating declaration is printable "as-is", i.e. we can reuse all its nodes because its names are in scope. This is what you hit in type 2 because the parent node is the same source file.
• The originating declaration is not printable "as-is", and we need to do a semantic printback that works off the types themselves rather than the nodes of the declaration

In the latter case, the distinction between T and T<default1, default2> has been lost; these type expressions have the same semantic representation. I don't know if the type printer has any configuration to skip same-as-default type arguments.

@weswigham anything to add?

[weswigham]

Yeah, I also don't think that we attempt to see if the type parameters match the defaults at any point if we synthesize a node.