Pros/Cons of this libary vs tsoa

[dgreene1]

Hello. I noticed that this library has a very large overlap in goals with tsoa. I'm curious if: (a) someone can describe some of the offerings that this library has over tsoa and (b) if the maintainers of this library would be interested in combining (or something like that) so that we could have more strength in our union.

Full transparency:

I recently volunteered to be a maintainer of tsoa. To be clear on a few points: (a) I'm not the maintainer of tsoa. I'm just a guy who liked using it a lot and wanted to support it (b) This is really just a conversation. I'd like to see TypeScript become one of the more popular server-side languages, and I think having a really strong unified approach to developing services would help that goal. That being said, I obviously think that providing users with options is also good too. Which, in summary, is why I'm looking to understand the comparative offers to understand why someone would choose this library over tsoa.

Comparisons so far:

feature	tsoa has it	typescript-rest-swagger has it
excess property checking	:heavy_check_mark:	:x:
union types	:heavy_check_mark:	:x:
aggregate types	:heavy_check_mark:	:x:
can do validation and swagger generation	:heavy_check_mark:	:heavy_check_mark:
configurable collectionFormat	:x:	:heavy_check_mark:
securityDefinitions	:heavy_check_mark:	:heavy_check_mark:
overridable swagger output	:heavy_check_mark:	*only some supported
isString with custom error message	:heavy_check_mark:	:x:
isBoolean with custom error message	:heavy_check_mark:	:x:
type parameter tags can be JSDoc	:heavy_check_mark:	:heavy_check_mark:
type parameter tags can be a ES6+ decorator	:x:	:heavy_check_mark:
minItems	:heavy_check_mark:	:x:
maxItems	:heavy_check_mark:	:x:
uniqueItems	:heavy_check_mark:	:x:
minLength	:heavy_check_mark:	:x:
maxLength	:heavy_check_mark:	:x:
pattern	:heavy_check_mark:	:x:
minimum	:heavy_check_mark:	:x:
maximum	:heavy_check_mark:	:x:
minDate	:heavy_check_mark:	:x:
maxDate	:heavy_check_mark:	:x:
isInt	:heavy_check_mark:	:heavy_check_mark:
isLong	:heavy_check_mark:	:heavy_check_mark:
isFloat	:heavy_check_mark:	:heavy_check_mark:
isDouble	:heavy_check_mark:	:heavy_check_mark:
isDateTime	:heavy_check_mark:	:x:
isDateTime with custom error message	:heavy_check_mark:	:x:
isDate (i.e. like a birth day, not the instant of woke up today)	:heavy_check_mark:	:x:
supports express	:heavy_check_mark:	:heavy_check_mark:
supports koa	:heavy_check_mark:	:x:
supports hapi	:heavy_check_mark:	:x:
supports custom server frameworks	:heavy_check_mark:	:x:

[dgreene1]

Update: I've done a little more research into the two libraries and I will do my best to update this document. If I've left anything out on either side, please comment below.

[YousefED]

Thanks! Useful. I also noticed there's some overlap between tsoa / trs in terms of JSON schema generation from Typescript with existing libraries. I've done some early work on this @ https://github.com/yousefed/typescript-json-schema (now mostly superseded by https://github.com/vega/ts-json-schema-generator), figured it might be useful to re-use

[ArminEberle]

Thanks also from my side. We recently found tsoa and are now migrating to it. A really decent thing that matters to us is actually something that comes as a hidden benefit when using tsoa is the fact that at runtime, we don't need the decorator metadata anymore: We're packaging our server code with esbuild so when can easily ship the code into a docker-image. With ts-rest, we have to compile the code first with typescript tsc and build from the generated .js sources, as esbuild (and webpack as well) cannot handle decorator code emit when compiling from .ts . With tsoa, I hope that we can run esbuild directly on the .ts files and and run typescript tsc only for typechecking, in parallel to esbuild. This will save us a minute or so on every build, which does not really matter on the build server, but locally during development, this will save the developer something in the range of 5-10 minutes per day.