Allow `@Is{Type}` with TypeScript's decorator, not just JSDoc

[DjakaTechnology]

trafficstars

Sorting

• I'm submitting a ...

  • [ ] bug report
  • [x] feature request
  • [ ] support request

• I confirm that I

  • [x] used the search to make sure that a similar issue hasn't already been submit

Expected Behavior

            intAnnotated:
                type: integer
                format: int32
            longAnnotated:
                type: integer
                format: int64
            doubleAnnotated:
                type: number
                format: double
            floatAnnotated:
                type: number
                format: float

  @IsInt()
  public intAnnotated: number;
  @IsLong()
  public longAnnotated: number;
  @IsDouble()
  public doubleAnnotated: number;
  @IsFloat()
  public floatAnnotated: number;

Current Behavior

@IsType annotation is not possible

Possible Solution

Add @IsType support outside of java doc

Context (Environment)

Version of the library: v3.11.2

• Confirm you were using yarn not npm: [x]

Detailed Description

Writing java docs is not typesafe and quite overkill if only used for defining int, long etc. By giving annotation option, we can write less code and reduce potential typo since it will be validated by typescript

Breaking change?

No

[WoH]

See JSDoc annotations, which can be used on interfaces as well.

[DjakaTechnology]

@WoH

See JSDoc annotations

That's exactly my proposal. Currently we only able to set int, float etc through JSDoc or comment. I would like to expand that to type safe annotation too.

Compared to strictly do this:

/**
* @isInt
*/
test: number 

We give option to write it like this:

@IsInt
test: number

The annotation is type safe to its impossible to write a typo.

[WoH]

I see. Personally prefer to keep the amount of different approaches between Classes, Interfaces and Aliases lower (which affects the amount of maintenance, so I'm biased), but if there's more demand for it, we should consider it.

[DjakaTechnology]

I see. Personally prefer to keep the amount of different approaches between Classes, Interfaces and Aliases lower (which affects the amount of maintenance, so I'm biased), but if there's more demand for it, we should consider it.

I see, that's a good point, I think this is{Type} decoration is not needed yet as we can use type aliases if we don't want jsdoc

But I think there's different case with the decorators that already exist in @tsoa/runtime. When I tried tsoa, I immidiately expect that I can use decorator that exist there in anywhere that support it (if it aligned with OpenAPI) so my first instinct was using it in my model class.

My project rely to vendor extension x-extension and example and when I knew we had decorator of @Extension and @Example I tried it and expecting it to work on my use case. When it doesn't, I tried to debug it and then clone this repo to see why it happen, I tought its a bug but turns out there's no implementation about it in the generator it self which leads me to open: https://github.com/lukeautry/tsoa/issues/1094 https://github.com/lukeautry/tsoa/issues/1085

So what do you think about expanding decorator that already in @tsoa/runtime into model class (as long as it aligned with OpenAPI)? I think it will be more consistent and there will be no hidden rules like some places support decorator and JSDoc, some other places only support jsdoc (currently class model only support @Deprecated decorator)