Generic with intersection: `Could not match intersection against any of the possible combinations: [[]]`

[CodeSmith32]

TSOA resolves the following type for Body correctly:

interface Foo {
  x: number;
  y: number;
}

@Route("/v1/foo")
class Foo extends Controller {
  @Post("/")
  async route(@Body() data: Partial<Foo> & Required<Pick<Foo, "x">>) {
    // ...
  }
}

But as soon as I try to make this type generic, TSOA breaks down:

interface Foo {
  x: number;
  y: number;
}

type OnlyRequire<T, U extends keyof T> = Partial<T> & Required<Pick<T, U>>;

type FooDto = OnlyRequire<Foo, "x">;

@Route("/v1/foo")
class Foo extends Controller {
  @Post("/")
  async route(@Body() data: FooDto) {
    // ...
  }
}

At this point, when the routes are generated, the validation model data appears something like follows, where the resulting type is a union of two objects with no properties in nestedProperties:

const models: TsoaRoute.Models = {
    "Partial_Foo_": {
        "dataType": "refAlias",
        "type": {"dataType":"nestedObjectLiteral","nestedProperties":{},"validators":{}}, // <----- No properties
    },
    // WARNING: This file was auto-generated with tsoa. Please do not modify it. Re-run tsoa to re-generate this file: https://github.com/lukeautry/tsoa
    "Required_Pick_Foo.x__": {
        "dataType": "refAlias",
        "type": {"dataType":"nestedObjectLiteral","nestedProperties":{},"validators":{}}, // <----- No properties
    },
    // WARNING: This file was auto-generated with tsoa. Please do not modify it. Re-run tsoa to re-generate this file: https://github.com/lukeautry/tsoa
    "OnlyRequire_Foo.x_": {
        "dataType": "refAlias",
        "type": {"dataType":"intersection","subSchemas":[{"ref":"Partial_Foo_"},{"ref":"Required_Pick_Foo.x__"}],"validators":{}},
    },
}

Thus, it doesn't crash when it runs, but any requests to this endpoint fail with a validation error:

Could not match intersection against any of the possible combinations: [[]]

[CodeSmith32]

Ok, I was not able to reproduce this issue on StackBlitz because, sometimes the TypeResolver gets used, and sometimes the type is directly resolved via the TypeScript lib. I have no idea when one happens over the other, making it extremely hard to trip the mechanism to break. TypeScript's built-in resolver pretty much always works. But TSOA's resolver has serious issues.. this is just another one.

With that said, if anyone knows some trick to trip up TSOA to use its custom resolver over the TypeScript resolver, I will try to exploit it and update the StackBlitz to reproduce the issue.

---

In any case, the issue is that TSOA's resolver doesn't handle mapped types properly. In this case, it fails to process TypeScript's lib definition of the Partial utility. The declaration is as such:

type Partial<T> = {
    [P in keyof T]?: T[P];
};

The AST for this appears as such:

TypeAliasDeclaration {
  name: Identifier {
    escapedText: "Partial"
  }
  typeParameters: [
    TypeParameter {
      name: Identifier {
        escapedText: "T"
      }
    }
  ]
  type: MappedType {
    typeParameter: TypeParameter {
      name: Identifier {
        escapedText: "P"
      }
      constraint: TypeOperator {
        operator: keyof
        type: TypeReference {
          typeName: Identifier {
            escapedText: "T"
          }
        }
      }
    }
    questionToken: QuestionToken { }
    type: IndexedAccessType {
      objectType: TypeReference {
        typeName: Identifier {
          escapedText: "T"
        }
      }
      indexType: TypeReference {
        typeName: Identifier {
          escapedText: "P"
        }
      }
    }
    members: [ ] // <----
  }
}

From what I debugged, since the members array is empty, the call to getProperties() under the mapped type handler returns an empty array:

// .....
        } else if (this.hasFlag(type, ts.TypeFlags.Object)) {
          const typeProperties: ts.Symbol[] = type.getProperties(); // <-----
          const properties: Tsoa.Property[] = typeProperties
// .....

It does look like it tries to get the non-named 'index' signatures after this too, but it's definitely returning an empty array (maybe a TypeScript bug?):

Let me know if more info could be helpful.