typedoc icon indicating copy to clipboard operation
typedoc copied to clipboard

fix: Resolve the name of parameters referring to default exports

Open tristanzander opened this issue 1 year ago • 3 comments

Hello! My team recently discovered some strange behavior with TypeDoc resolving the type name of a class as default instead of the name of the class. I discovered that this happens when the following constraints are met:

  1. A file that's not included in the documentation exports a default function/class.
  2. Another file exports that default export as a non-default member.
  3. A file that is included in documentation references that type in the parameter of a function, a property of a class, etc.

Note: This can only happen if the function/class is declared using export default class or export default function, since TypeScript will resolve the type back to any normal export class or export function with the correct name.

I noticed that TypeScript itself resolves the parameter's symbol type as the name default instead of the name of the type. I'm unsure if this is correct, so I applied conditional logic to help handle this particular case.

Here's a visual example from our generated docs: image ...where the correct type should be DataTable.

Please let me know if a better solution is more desirable 🙏

tristanzander avatar May 15 '24 18:05 tristanzander

@Gerrit0 I tried to find a way to resolve those symbols as their re-exported name but I couldn't find I decent solution that didn't break other tests. This seems to be the way that type checker wants to resolve those types. Do you have any ideas for how I would determine if a given type was re-exported to apply this logic?

tristanzander avatar May 16 '24 17:05 tristanzander

I am noticing that the declaration.type.id and type.id are different in this example. That might be a way to determine if the types are different, but I'm not sure how generics come into play here (that's where most of the other tests seemed to break on)

tristanzander avatar May 16 '24 17:05 tristanzander

I incorrectly assumed that making the change to derive the name in the type converter would just make that work - given that the type converter is getting the resolved type, I think it's reasonable to leave the behavior as is

Gerrit0 avatar May 16 '24 17:05 Gerrit0

@Gerrit0 Any chance I could get a re-review on this soon?

tristanzander avatar May 20 '24 13:05 tristanzander

I meant to merge it last weekend, unfortunately it fell off my list. I'll definitely get it in next weekend!

Gerrit0 avatar May 21 '24 00:05 Gerrit0

Thanks!

Gerrit0 avatar May 24 '24 14:05 Gerrit0