Nullable types

[alekbarszczewski]

First of all I am not sure which swagger version docs this library is generating. However in the latest swagger version there is a nullable keyword (https://swagger.io/docs/specification/data-models/data-types/). What I am thinking is that it would be possible to parse types like this:

interface Test {
  a: string | null;
  b?: number | null;
  c: null | SomeOtherType;
  d: boolean;
}

If type is a UnionTypeNode AND it consists of exactly two types AND one of them is NullKeyword then we could either:

• set nullable: true modifier on swagger type
• or remove field name from required list of object type

Former option is compatible with newest swagger spec, while latter is compatible with any swagger spec.

// example result in case of first option
{
  type: 'object',
  required: ['a', 'c', 'd'],
  a: { type: 'string', nullable: true },
  b: { type: 'number', format: 'double', nullable: true },
  c: { type: { $ref: '...' }, nullable: true },
  d: { type: 'boolean' }, 
}

// example result in case of second option
{
  type: 'object',
  required: ['d'],
  a: { type: 'string' },
  b: { type: 'number', format: 'double' },
  c: { type: { $ref: '...' } },
  d: { type: 'boolean' }, 
}

What do you think about this @thiagobustamante ? I could work on PR only not sure if we have to stick to any specific swagger specification version?

Applies to #33 .

[thiagobustamante]

Hi, @alekbarszczewski ,

I think we should keep updating the library to support the latest version. Would be great to receive a PR to add this support.

[dgreene1]

@alekb you can use the tsoa library instead which has support for unions. We don't yet support a union of T | null but since we just merged union support, I think it would be much easier to add T | null support to tsoa than it would be to add it to this library.

@thiagobustamante I mentioned it over in #84 but would you be interested in deprecating this library so we can continue to work on this over in the tsoa library?

We can continue this over in #84 but at the moment, tsoa has more features, more test coverage, more usage in npm trends, and has more maintainers. I think that if we were to combine our energy to focus on promoting the same library then we would be able to foster an even stronger community of TypeScript users who like Swagger/OpenAPI.

[alekbarszczewski]

@dgreene1 Hmm, right now we heavily depend on typescript-rest-swagger, already on prod. Are there any major differences between typescript-rest-swagger and tsoa? One difference that I see is that typescript-rest (not typescript-rest-swagger) generates endpoints during runtime and does not require extra step to "generate endpoints" - is that right?

[dgreene1]

@alekbarszczewski tsoa also generates the endpoints by creating a routes.ts file. The readme is really good at explaining all of the capabilities: https://github.com/lukeautry/tsoa

I don’t believe you would experience significant differences if you were to migrate. You would get many additional advantages, which are detailed here: https://github.com/thiagobustamante/typescript-rest-swagger/issues/84