Schema not generated for "base" type declaration with a generic parameter

[pushred]

Example types:

export type BaseExample<T> = {
  results: T;
};

export type BaseExampleWithDefault<T = Record<string, unknown>[]> = {
  results: T;
};

export type BaseExampleWithConstraint<T extends Record<string, unknown>[]> = {
  results: T;
};

None of these result in a schema with these config options (or without):

• expose = all
• skipTypeCheck = true
• type = *

Running 2.4.0-next.7

Full reproduction

---

This seems like an intentional omission; if so consider this a feature request. But it seemed like it should work looking at the generic-default valid data case. What's the difference between Generic there and MyObject if the latter does nothing but alias it?

#346 also seems to demonstrate the same issue but the test case for the fix in #347 omits the type arguments.

Also when I do add an implementation the type is given a quite verbose name that varies depending on what the implementation specifies for the argument, e.g.:

• Example<Record<string, unknown>[]>
  • Example<def-alias-t_lib_lib.es5.d.ts-73393-73519-t_lib_lib.es5.d.ts-0-217694<string,unknown>[]>
• Example<object[]>
  • Example<object-131809358-260-266-131809358-260-268-131809358-238-269-131809358-195-270-131809358-0-271[]>

This is maybe related to #2009

If the name itself is unique at least within the given file I would expect the definition to be named the same as the type, without any reference to it's arguments.

[pushred]

Followup re: the naming issue, I did see that this improves somewhat when following the pattern of simply aliasing a type that defines a default argument value. Doing this I see a definitions key with just the type name as I wanted.

However this presents a different issue in that the base type has a circular ref while another orphaned definition for the default value is created. That issue is resolved if I don't use expose: 'all' and curiously I see only the base type and don't see the "implementation" alias at all. Probably warrants filing a separate issue with repro but this does seem like a successful workaround for the original issue.

[arthurfiorette]

Hey @pushred, thanks for the detailed explanation! I agree that this seems to be a bug and should be fixed. Would you like to open up a PR addressing it? I'd love to help you by reviewing it!

[pushred]

@arthurfiorette Sorry missed your reply. Sure I can try to fix this however will be away on a trip later this week and will have to figure out where I can slot the time in.. will try to come back to this next week though.