Skip to content
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

Allow multiple schemas with same name #2826

Open
1 task done
bc-m opened this issue Feb 7, 2024 · 2 comments
Open
1 task done

Allow multiple schemas with same name #2826

bc-m opened this issue Feb 7, 2024 · 2 comments
Labels

Comments

@bc-m
Copy link

bc-m commented Feb 7, 2024

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

In our project we reuse name patterns like "FindOneDto" or "FindAllDto". We now have the problem that the Swagger docs reuse one of the DTOs (perhaps the first one calculated) and display the same DTO as schema in all places where a different DTO with the same name should be displayed.

Describe the solution you'd like

Maybe a solution like in NestJS v8 is possible, where the class reference is used as key instead the name.

Or the build process should throw a warning/error if unique schema names are still required. Now the build will continue with an incorrect result.

Teachability, documentation, adoption, migration strategy

Mention as new feature (or bugfix?) in changelog.

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

Avoidance of a pitfall for nestjs-swagger users.

@Seung-o
Copy link

Seung-o commented Feb 20, 2024

I have also encountered the same issue. I believe it's necessary to explicitly specify the type of the class being used or even intentionally break the build when there are multiple classes with the same naming convention. This is important because it's difficult for developers to be aware of the implications when such issues arise.

@Stono
Copy link

Stono commented Apr 17, 2024

Ahh this is exactly the issue i'm having (associated issue: hey-api/openapi-ts#42).

You can see here using the metadata generation we have two controllers that both implement their own ListDeviceResponse:

Screenshot 2024-04-17 at 08 22 50

This subsequently means the swagger actually only ends up with a single definition, which as @bc-m pointed out looks to be the first one.

Screenshot 2024-04-17 at 08 23 43

Which then obviously leads to downstream issues when clients are generated from the swagger etc, they're returning the wrong types.

This is a frustrating gotcha/limitation that will totally catch people off guard, as it doesn't result in any sort of compilation error or warning. For now i'm going to try and write some sort of linting to enforce dto names are unique across a project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants