[next] Major release notes & plans

The @nestjs/swagger is one of the most widely used @nestjs packages under the @nestjs organization. So far it works pretty great - we have a declarative way to easily generate OpenAPI specification using decorators placed near to our DTOs/routes, we cover 3/4 potential use-cases providing a quite simple API to interact with.

However, the current model of this library doesn’t fit the requirements which we should set ourselves in order to ensure that we provide the best quality for developers. Let me list a number of them.

• massive redundancy (lots of decorators that shouldn’t be required)
• lack of consistency (if we want to change our property to an optional one, we very likely have to add @IsOptional() - for the validation purposes, change the decorator to @ApiModelPropertyOptional() and add a question ? mark by the end of the property name)
• no generics support
• no interfaces support
• no auto-response schemas generation
• lack of flexibility (hard to add custom rules/decorators/interpreters)
• no circular-dependencies support

The main reason for all of these outlined issues is weak TypeScript reflection capability. Hence, the library itself will be very likely rewritten and will use TypeScript AST to support all these amazing features out-of-the-box.

I have created this issue in order to share plans with you as well as encourage you to share your personal experiences with this library - if there is something else that was very troublesome/unsupported so far, please, let me know here - we can work on the design specification together.

[MumblesNZ]

+1 for the support for OpenAPI 3.0, great work on nestjs in general BTW =).

[nartc]

Is OpenAPI 3.0 taken into consideration? And also, an abstraction for controllers coverage/approach with Swagger enabled would be awesome. Right now, @Apixxx decorators make it quite hard to implement a BaseController (for lack of better name). ApiUseTags and then the responses types (as you stated, no generics support)