jlalmes / trpc-openapi

OpenAPI support for tRPC 🧩
https://www.npmjs.com/package/trpc-openapi
MIT License
2.17k stars 146 forks source link

zod array objects break this #391

Open davidawad opened 1 year ago

davidawad commented 1 year ago

heres' an example:

image

if I have this code defining a schema and try to make TRPC calls (on ANY API, not just this one), I'll get this error:

error - TRPCError: [query.question.read] - Input parser key: "labels" must be ZodString, ZodNumber, ZodBoolean, ZodBigInt or ZodDate
    at /Users/david/Projects/WORK/DFDF/DDQ360/node_modules/trpc-openapi/dist/generator/schema.js:72:27
    at Array.map (<anonymous>)
    at getParameterObjects (/Users/david/Projects/WORK/DFDF/DDQ360/node_modules/trpc-openapi/dist/generator/schema.js:65:10)
    at /Users/david/Projects/WORK/DFDF/DDQ360/node_modules/trpc-openapi/dist/generator/paths.js:61:66
    at forEachOpenApiProcedure (/Users/david/Projects/WORK/DFDF/DDQ360/node_modules/trpc-openapi/dist/utils/procedure.js:34:13)
    at getOpenApiPathsObject (/Users/david/Projects/WORK/DFDF/DDQ360/node_modules/trpc-openapi/dist/generator/paths.js:13:45)
    at generateOpenApiDocument (/Users/david/Projects/WORK/DFDF/DDQ360/node_modules/trpc-openapi/dist/generator/index.js:27:50)
    at eval (webpack-internal:///(api)/./src/server/api/root.ts:51:98)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'INTERNAL_SERVER_ERROR',
  [cause]: undefined
}
Pridestalkerr commented 1 year ago

I believe this happens because there is no "default" way to pass an array of values as a query parameter. It might work for tRPC, but there's no easy widely adopted method of passing arrays as a query parameter and most implementations are framework specific. Which one of the following endpoints should even be generated?

?cars[]=Saab&cars[]=Audi
?cars=Saab&cars=Audi
?cars=Saab,Audi

I suggest using a POST request instead and passing everything in the body. Alternatively, you can make "labels" into a string, and parse it manually (using the format you chose) inside the procedure. But that's a bit weird IMO.

ntindle commented 1 year ago

I've also been unable to use arrays in inputs for PUT. See #255

popuguytheparrot commented 11 months ago

+1

tdanh2k commented 6 months ago

image

image I'm building a pagination router with the above schema but also facing the same ordeal. Hope this get fixed soon :(

tdanh2k commented 6 months ago

image

image I'm building a pagination router with the above schema but also facing the same ordeal. Hope this get fixed soon :(

image

Or maybe just comment the .meta() method and move on.

renke0 commented 3 weeks ago

@Pridestalkerr

I suggest using a POST request instead and passing everything in the body. Alternatively, you can make "labels" into a string, and parse it manually (using the format you chose) inside the procedure. But that's a bit weird IMO.

It kind of defeats the purpose of generating the openapi spec, doesn't it? If the document generated is not representing what is expected by the implementing code, what is it good for then?

Pridestalkerr commented 3 weeks ago

@Pridestalkerr

I suggest using a POST request instead and passing everything in the body. Alternatively, you can make "labels" into a string, and parse it manually (using the format you chose) inside the procedure. But that's a bit weird IMO.

It kind of defeats the purpose of generating the openapi spec, doesn't it? If the document generated is not representing what is expected by the implementing code, what is it good for then?

@renke0 some clarifications. Most REST specs do not support arrays in query parameters. How would you even represent it? /your/get/endpoint?array=["v1", "v2"] What if the array contains objects? Do you stringify them? At that point you probably just stringify the entire array. But then the query value of array will be string. I'm sure there's frameworks that can do this on the fly and convert any query values from json strings to objects, but not tRPC. Hence my suggestion to pass it in the body instead. GET requests can have a body, but AFAIK the REST spec says thats a bad idea and the request should be a POST instead (not my opinion). This library generates a REST spec, and thus assumes that GET requests only receive query parameters, no body.

Please, do take this with a grain of salt. It's just what i learned back when I encountered this issue myself. Best of luck!