`split` command option/config for custom subdirectories of schemas
edonv opened this issue · 3 comments
Is your feature request related to a problem? Please describe.
I'd love to be able to categorize external schema files by their associated endpoint/response's tag(s).
Describe the solution you'd like
If it was possible to configure some way of how to organize schema files, that'd be awesome.
Describe alternatives you've considered
Maybe it'd be a plugin instead? Not sure though...
Additional context
Almost all of the schemas I have in my project are tied to a specific endpoint/response, which each has a single tag. It'd be great if the schema files could be organized by the tag.
Hi @edonv, could you clarify what you mean by categorization/organization? Any examples?
To be more concrete, say I have a very large API project, and nearly all of my schemas are tied to a specific group of endpoints (which are grouped by a shared tag
). Because the components/schemas
folder gets to be so overgrown and flooded, it'd be great if the split files can be placed in subfolders inside of the components/schemas
, labeled by the shared tags.
So for example, if I have a bunch of endpoints that share the tag "Utility," and there a bunch of schemas that are used by those endpoints, all of those split schema files would be placed in a subfolder inside of components/schemas
called utility
or something. So for a schema called "NamedAPIResource," it'd be located at components/schemas/utility/NamedAPIResource.json
. Does that make sense? It's possible this is too specific a scenario to warrant an option on the split
command and would require a custom plugin, but I figured I'd ask. I'd imagine it's not uncommon to have a super bloated components/schemas
folder.
Thanks for an interesting suggestion and discussion! It's difficult to generalise that this would be useful in most or even many cases, so while I can see the attraction for this particular case, there's a risk that this makes OpenAPI descriptions less maintainable where schemas are used in multiple tags, for example. I'm closing this issue and recommending we don't implement.