-
Notifications
You must be signed in to change notification settings - Fork 126
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
Support internalFlagProperty as a list for remove-x-internal decorator #1525
Comments
Thanks @samanthawritescode ! I think this aligns pretty closely with existing issue #970, where you could at least add the decorator multiple times for the API description that wants two sets of filtering applied. I think your current options are either the filter-out decorator as you already mentioned, to use a custom plugin that does something similar and accepts multiple things-to-remove, or to prepare the the documentation version of the OpenAPI file by applying filtering to the result of preparing the GitHub version (hopefully that makes sense). |
Thanks @lornajane for the response! I agree that existing issue is related. I didn't even think to try something like that. Preparing the documentation version of the spec by applying filtering to the result of the GitHub version is interesting, I'll consider it. Clever idea. |
Is your feature request related to a problem? Please describe.
I have an API that I bundle for 2 different usages:
We have 2 use cases that involve hiding functionality:
The relevant part of our
redocly.yaml
configuration:Right now, if we want to accomplish the second use case, we have to include BOTH
x-remove-from-readme
andx-remove-from-github
on the relevant node. I introduced this behavior yesterday and I already ran into an issue where we forgot to add one of them 😅Describe the solution you'd like
I'd like to be able to do something like:
So that I can accomplish use case 1 by using
x-remove-from-github
and use case 2 by only usingx-internal
. In this case, I would expect nodes withx-internal
to be removed from both bundled versions of the spec.Describe alternatives you've considered
Mostly just the current behavior I'm using described above. I've also considered using filter-out to handle use case 1 and filter out specific APIs based on tag or something, but I don't like it. I'd like for it to be obvious which endpoints are filtered out within the definition for those specific endpoints. Also I have some endpoints that use the same tag but only some of them need to be hidden from the GitHub bundled version. I could use
summary
or something, but what if it gets changed?The text was updated successfully, but these errors were encountered: