-
Notifications
You must be signed in to change notification settings - Fork 124
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
parameter.definition[x-alias] #67
Comments
I love the idea of breaking it out. |
Everything looks good. Thanks! |
As promised - https://github.com/osher/swagger-params-alias |
Very nice. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi.
The snippet bellow describes a fitting that allows using in parameters a custom attribute
x-alias
that helps support API changes concerning parameter names.The use cases which I get to met a lot, are described as:
And the question to you:
Now that we can officially support loading user fittings from
node_modules
, I may wrap it as a package such asopenapi-parameter-alias
with it's own tests and all, and let users cherry-pick it into their projects by adding this fitting one step beforeswagger_validation
Yes, we're ready, lets rock.
OR - alternatively -
No, its too early from your point of view to start diverging modularity, you'd rather it as a PR into bagpipes if at all. In this case, it may not even need to be a separate step. It's a light non-breaking useful feature and same work can be done in fittings/swagger_params_parser.js
around lines
31~41saving an extra loop iteration over
swagger.params` per served request.What are your thoughts about it?
P.S:
the snippet is expressed only as a thought, I did not ran it yet, but I hope the spirit is clear.
it's written in ES6, but it can very easily be put in ES5 if need be, (just replace
const
forvar
and handle the destruction and arrows the old way...The text was updated successfully, but these errors were encountered: