Add support for `typeof` keyword in type parameters

[pclements12]

All Submissions:

• [x] Have you followed the guidelines in our Contributing document?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [x] Have you written unit tests?
• [x] Have you written unit tests that cover the negative cases (i.e.: if bad data is submitted, does the library respond properly)?
• [x] This PR is associated with an existing issue? #1256

References Issue

This attempts to fix at least one of the sub issues related to the ability to use Zod's z.infer that was identified in #1256 https://github.com/lukeautry/tsoa/issues/1256#issuecomment-2649340573

1. Typeof Name Calculation Issue Error message: No matching model found for referenced type value.

@Route("/test")
export class TSOATestController extends Controller {
  @Get("/")
  async test(): Promise<ValueType> {
    return null as unknown as ValueType;
  }
}

const value = null;

type Infer<T> = T;

type ValueType = Infer<typeof value>;

The issue is that when calcTypeName runs for a typeof operator type (a TypeQueryNode), it calls calcRefTypeName on the operand. The doc comment and code for calcRefTypeName indicate it only accepts a reference to a type. The obvious problem here is that the operand of typeof is never going to reference a type. The typescript typeof operator only accepts references to javascript variables, functions, etc. – i.e., non-types.

Thus, the call to this.calcRefTypeName(arg.exprName) is simply wrong, and is an outright bug that needs to be fixed.

Test plan

Adds a test case to the metadata / parameter resolver for typeof types as a parameter or return type

Adds an (expensive) unit test for TypeResolver to explicitly enumerate all of the type combinations that the resolver supports in a clean room environment. Open to suggestions on making this more efficient by combining into a single virtual source file, but the context of type right next to test is very valuable imo.

I've also included some types in this test that still fail (currently skipped) and are related to the other issues identified in #1256

[pclements12]

@WoH can you take a look at this when you get a chance?

[WoH]

I'll get to it over the weekend!

It looks good from slimming the code, but I'll try to play around with it a bit

[idan2468]

Hey, what is the status with this PR? @WoH @pclements12 My team is also waiting for this PR, and it seems that quite a lot of people are also waiting for it. Can we do something to speed up the process?

[WoH]

Hey, what is the status with this PR? @WoH @pclements12 My team is also waiting for this PR, and it seems that quite a lot of people are also waiting for it. Can we do something to speed up the process?

Please fork this branch and consolidate the property handling, everything else is perfectly fine imo.

[lobabob]

Is this PR still necessary? It looks like this PR and https://github.com/lukeautry/tsoa/pull/1782 that was just merged in address the same issue (https://github.com/lukeautry/tsoa/issues/1256).

[pclements12]

Is this PR still necessary? It looks like this PR and #1782 that was just merged in address the same issue (#1256).

I think the PR can be closed based on that other one that was merged.