Static declaration of response transformation while using the CLI plugin

[ssteuteville]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

My team absolutely loves using the CLI plugin for this module because it reduces so much boilerplate code! Thank you for the awesome feature.

The issue we're facing is that we use this interceptor:

export interface SuccessfulResponse<T> {
  result: T;
}

@Injectable()
export class ResponseTransformInterceptor<T> implements NestInterceptor<T, SuccessfulResponse<T>> {
  intercept(context: ExecutionContext, next: CallHandler): Observable<SuccessfulResponse<T>> {
    return next.handle().pipe(map((data) => ({ result: data })));
  }
}

The openapi spec however does not wrap the responses properly with { result: <response-type> }.

Describe the solution you'd like

I understand that response transformers are a runtime construct, and that there is likely not a good way to magically infer these types and then have the plugin generate the proper decorations. However, I wonder if there might be a way to statically define a wrapper type for the plugin or the swagger module itself to use.

For instance, maybe we can provide a file name that specifies a generic class that can be used to wrap all response types in the plugin's generated decorations.

   responseWrapper: "src/responseDecorator.ts"

responseDecorator.ts

export class SuccessResponse<ResponseType> {
   result: ResponseType;
}

or maybe another possibility would be using the DocumentBuilder or options sent to SwaggerModule.createDocument?

The seems like it would be a fairly common use case that would make the CLI Plugin much more viable.

Teachability, documentation, adoption, migration strategy

The documentation for the plugin options could be updated to include information about the responseWrapper field and there could be an example similar to the stuff in my problem statement and proposed solution.

What is the motivation / use case for changing the behavior?

I really love the plugin and really dislike boilerplate. Having this feature would mean that I can continue using the plugin without having to manually add @ApiResponse all over my code. This would boost my team's productivity while still giving us a way to effortlessly generate an open API spec for documentation and code generation purposes.

Without this, I will have to customize any code generation tools we use such that they are aware of the wrapped type and return data appropriately.

[ssteuteville]

If this seems technically possible, I might be able to take a stab at a PR! Just a lot to ramp up on so would like some input first.

[alanskovrlj]

What is the status of this request? I would like to implement this as I would also like this feature to be available.