You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using nested mapped types with generics (don't know what's exactly at fault here), will produce a different swagger.json file based on the order of method declarations. To be more precise, if the method without generics is used first the type is inferred correctly, however if the generic type variant is used first it won't infer the type correctly. Both interfaces map to the same type, which means tsoa will produce a single type (even though one is based on a nested generic and the other isn't)
Sorting
I'm submitting a ...
bug report
feature request
support request
I confirm that I
used the search to make sure that a similar issue hasn't already been submit
Expected Behavior
I expect the different usages of the generic type to produce the same interface independant on the order of usage of the generics. The problem here is I think that with nested generics the type can't be determined. If the type without nested generic is used first it will correctly generate the type, while if the methods are switched the type won't be valid.
If the declaration of the withoutGeneric and withGeneric methods are switched this will not add typing for the PayloadMap_PayloadTypes_ type. While how it is written now will generate the correct typing.
import{Body,Controller,Post,Route}from"tsoa";interfacePayload{key: string;payload: unknown;}exportinterfaceThePayloadextendsPayload{key: "theKey";payload: {thePayload: string;};}typePayloadMap<PayloadsextendsPayload[]>={[PayloadinPayloads[number]asPayload["key"]]?: Payload["payload"];};typePayloadTypes=[ThePayload];// Use generic, pass payloads using payload arrayexportinterfaceTheRequestBodyWithGeneric<PayloadsextendsPayload[]>{payloadData: PayloadMap<Payloads>;}// Do not use generic, pass PayloadTypes directlyexportinterfaceTheRequestBodyWithoutGeneric{payloadData: PayloadMap<PayloadTypes>;}
@Route("example")exportclassExampleControllerextendsController{
@Post("without-generic")publicasyncwithoutGeneric(
@Body()requestBody: TheRequestBodyWithoutGeneric){console.log(requestBody);}
@Post("with-generic")publicasyncwithGeneric(
@Body()requestBody: TheRequestBodyWithGeneric<PayloadTypes>){console.log(requestBody);}}
Possible Solution
Not sure. Either types should not map to the same name if not 100% equal (the type should be equal here, but there are issues with the generics). However, the real issue here is that nested genreic/mapped types (not sure what the root cause is) are not always correctly generated to types. Semantically the two methods have the same interface, but one method has an extra layer of generics that doesn't play well with tsoa. I've opened a separate issue for this here: #1268
Using nested mapped types with generics (don't know what's exactly at fault here), will produce a different swagger.json file based on the order of method declarations. To be more precise, if the method without generics is used first the type is inferred correctly, however if the generic type variant is used first it won't infer the type correctly. Both interfaces map to the same type, which means tsoa will produce a single type (even though one is based on a nested generic and the other isn't)
Sorting
I'm submitting a ...
I confirm that I
Expected Behavior
I expect the different usages of the generic type to produce the same interface independant on the order of usage of the generics. The problem here is I think that with nested generics the type can't be determined. If the type without nested generic is used first it will correctly generate the type, while if the methods are switched the type won't be valid.
Current Behavior
The
PayloadMap_PayloadTypes_
properties
are emtpy.If the declaration of the
withoutGeneric
andwithGeneric
methods are switched this will not add typing for thePayloadMap_PayloadTypes_
type. While how it is written now will generate the correct typing.Possible Solution
Not sure. Either types should not map to the same name if not 100% equal (the type should be equal here, but there are issues with the generics). However, the real issue here is that nested genreic/mapped types (not sure what the root cause is) are not always correctly generated to types. Semantically the two methods have the same interface, but one method has an extra layer of generics that doesn't play well with tsoa. I've opened a separate issue for this here: #1268
Steps to Reproduce
https://github.com/TimoGlastra/tsoa-error/tree/repro-nested-generics-no-generic (note it's not main branch)
PayloadMap_PayloadTypes_
.)PayloadMap_PayloadTypes_
.)Context (Environment)
Version of the library: 4.1.0
Version of NodeJS: 16.13.0
Detailed Description
Breaking change?
Not sure, don't know enough about the library to say.
The text was updated successfully, but these errors were encountered: