-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
Help catch non declared query or path parameters #1000
Comments
@mikavilpas Can you share your OpenAPI spec? |
I can't share the full spec, but I created a reproduction setup here https://github.com/mikavilpas/hey-api-reproduction-1000 Let me know if this helps. |
@mikavilpas Oh so you're asking for strict types? That is, unless something is explicitly defined as a possible value by the spec, don't allow it to be passed? |
Yes, that's it! If there's any way to opt into this kind of behaviour, it would be perfect. I'm building a new openapi client for our company's internal api with my team, and it would be great to enforce strict adherence to the spec like this. |
I'd need to think about it, this would have to be done on the (fetch/axios) client level. If you can think of anything feel free to open a pull request! We'd need to modify the types to either be more strict or loose as they're now depending on some generic variable |
I have an idea. It seems like it might be enough to add a missing diff --git a/examples/openapi-ts-fetch/src/client/types.gen.ts b/examples/openapi-ts-fetch/src/client/types.gen.ts
index 9dbad3c8..3d90d297 100644
--- a/examples/openapi-ts-fetch/src/client/types.gen.ts
+++ b/examples/openapi-ts-fetch/src/client/types.gen.ts
@@ -118,6 +118,7 @@ export type UpdatePetResponse = Pet;
export type UpdatePetError = unknown;
export type FindPetsByStatusData = {
+ path?: undefined;
query?: {
/**
* Status values that need to be considered for filter hey-api.mov |
This would then shift the ownership over strictness to the generator instead of the client, correct? I could get behind that. My immediate reaction is we'd want a |
Yeah I think it would have to be done in each client with this solution 🤔 |
Oh wait, did I get it backwards? |
As long as the client understands |
Added this to the Parser release. Thanks for your patience! |
Description
Hi, and thanks for this wonderful project!
At work, my team ran into an issue where we were accidentally passing in path parameters instead of query parameters, causing a profile search api to return a much larger dataset than what we expected 🙂
The generated data type for this api does not declare
path
options in the openapi specification. It's defined as/v0/temporaryEmployment/search:
.It looks like the defaults come from
Is there a way to disallow specifying parameters that are not defined by the API specification?
The text was updated successfully, but these errors were encountered: