-
Notifications
You must be signed in to change notification settings - Fork 477
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] - Property/Field Overwriting Doesn't Manifest In Swagger When Extending A Class #1321
Comments
Please provide a minimum reproduction repository. |
Here's the minimun reproduction repository: https://github.com/koxanybak/nestjs.swagger.issues.1321 |
Any updates on this or planned fixes for future versions? Or wasn't the minimun reproduction repository not clear enough? If that's the case, tell me and I'll make it better. |
Would you like to create a PR for this issue? |
I found a workaround/solution for the issue. The key is to not overwrite any fields. I solved this by creating an abstract base entity DTO with all the fields that will be not overwritten. Then all the other DTOs inherit that base entity. This way no fields are overwritten, thus avoiding the bug. The bug is still there but with this workaround you can avoid it. export class InfoPostDTO {
@ApiProperty()
name: string;
}
export class InfoPutDTO extends InfoPostDTO {
@ApiProperty()
id: number;
}
abstract class BaseEntityDTO {
@ApiProperty()
id: number;
}
export class EntityPostDTO extends BaseEntityDTO {
@ApiProperty()
info: InfoPostDTO;
}
export class EntityPutDTO extends BaseEntityDTO {
@ApiProperty()
info: InfoPutDTO;
} |
I'm submitting a...
Current behavior
When I extend a class and try overwrite an inherited property/field. The result of the overwriting doesn't manifest in the Swagger documentation. See code below how to reproduce.
Expected behavior
The desired behaviour would be how the overwriting manifests in the TypeScript code: The property info of EntityPutDTO should be of type InfoPutDTO, not InfoPostDTO. (See code below)
Minimal reproduction of the problem with instructions
What is the motivation / use case for changing the behavior?
The motivation is that the classes manifest themselves the same way into the documentation that they do in the TypeScript code.
Environment
The text was updated successfully, but these errors were encountered: