\n\nthe postman request:\n\u003Cimg width=\"1356\" height=\"550\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/d8f101f6-ff4f-4106-bd8f-016970e70c1e\" />\n\n\u003Cimg width=\"1091\" height=\"691\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/92855ba7-fb6c-4526-8db2-5698519cd093\" />\n\n\n\n2、When I call the download file interface, the \"download files\" button is not responding。\n\n\u003Cimg width=\"392\" height=\"274\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/05b06400-49b1-4885-a710-27fc7be3c34e\" />",[],279,"enzonotario","vitepress-openapi","open","upload and download issues","2025-07-24T13:26:47Z","https://github.com/enzonotario/vitepress-openapi/issues/279",0.854147,{"description":3028,"labels":3029,"number":3033,"owner":3020,"repository":3021,"state":3034,"title":3035,"updated_at":3036,"url":3037,"score":3038},"### What would you like?\n\nsupport openapi yml file\n\n### Why is this needed?\n\n_No response_\n\n### How could it be implemented?\n\n_No response_\n\n### Other information\n\n_No response_",[3030],{"name":3031,"color":3032},"enhancement","a2eeef",204,"closed","support openapi yml file","2025-04-19T22:22:53Z","https://github.com/enzonotario/vitepress-openapi/issues/204",0.6683102,{"description":3040,"labels":3041,"number":3043,"owner":3020,"repository":3021,"state":3034,"title":3044,"updated_at":3045,"url":3046,"score":3047},"### What would you like?\n\nThe current version generates \"static\" code for each language, based only on the url and method. Unfortunately, the url is simply: `const url = props.baseUrl + props.path`. This has the issue that any path parameters are left as-is in the code.\r\n\r\nIt would be great if the sample code could be updated to include the variables in the \"try it\" box. This way the code sample would be \"complete\". I _think_ this would be done in much the same was as the `OACodeBlock` currently computes the URL for curl\n\n### Why is this needed?\n\nIf you copy-and-paste the code sample as-is, you will end up with an invalid URL if there are path parameters.\r\n\r\nAlso, it would be nice to mix-and-match such that you can _remove_ the try it portion of the playground, but keep the sample code. This way people can \"build\" a request in their language of choice based on the variables form.\n\n### How could it be implemented?\n\nI _think_ you would need to extract (or just duplicate?) the code used to compute the curl information:\r\n\r\n```\r\nconst curl = computed(() => {\r\n const headers = request.value.headers\r\n if (!headers?.['Content-Type']) {\r\n headers['Content-Type'] = 'application/json'\r\n }\r\n\r\n return fetchToCurl({\r\n method: props.method.toUpperCase(),\r\n url: request.value.url,\r\n headers,\r\n body: request.value.body ? formatJson(request.value.body) : null,\r\n })\r\n})\r\n```\r\n\r\nThen pass this as a parameter to `generateCodeSamples` so that it can generate each code sample appropriately.\n\n### Other information\n\nIt would also be _awesome_ to select _which_ languages you want to support, and possibly even some way to provide the template for each language. I realize this is above-and-beyond, but something to think about if you're changing this.",[3042],{"name":3031,"color":3032},92,"Modify Sample Code Based on Variables","2024-11-15T02:40:07Z","https://github.com/enzonotario/vitepress-openapi/issues/92",0.8182019,{"description":3049,"labels":3050,"number":3051,"owner":3020,"repository":3021,"state":3034,"title":3052,"updated_at":3053,"url":3054,"score":3055},"### What would you like?\n\nVitepress has the ability to define [custom components](https://vitepress.dev/guide/extending-default-theme#registering-global-components) which can later on be used across the documentation.\r\n\r\nIt would be nice if we could use such custom components in the generated api operations.\r\n\n\n### Why is this needed?\n\n_No response_\n\n### How could it be implemented?\n\n_No response_\n\n### Other information\n\n_No response_",[],89,"(Custom Slots usage) Allow using custom components in operations","2024-10-16T22:01:29Z","https://github.com/enzonotario/vitepress-openapi/issues/89",0.8197655,{"description":3057,"labels":3058,"number":3060,"owner":3020,"repository":3021,"state":3034,"title":3061,"updated_at":3062,"url":3063,"score":3064},"### What would you like?\n\nThere is another package that allows for adding icons to code groups. This is commonly found on other VitePress sites when displaying commands or programming languages. It appears that the code group relies on there being a data-title attribute for it to display icons.\n\nThe code group icon package is called: vitepress-plugin-group-icons\nhttps://github.com/yuyinws/vitepress-plugin-group-icons\n\nYou can see it in use here on the main VitePress site: https://vitepress.dev/guide/getting-started in the installation section.\n\nI should note that the package seems to look for file extensions when displaying language icons but I used custom icons in my implementation so that it could work with the vitepress-openapi implementation.\n\n\n\n### Why is this needed?\n\nIt may be common for people to utilize code group icons elsewhere in their documentation and it would be helpful for the openapi generated pages to be able to display icons in those code groups as well.\n\n### How could it be implemented?\n\nI believe this could be achieved by changing the OACodeSamples component and adding sample.lang in a data-title attribute added to the label. I don't believe this would impact functionality for people not using code group icons but would allow those that are, compatibility when combining it with custom icons.\n\n*I should note that there appears to be some oddities that deal with the capitalization, or lack thereof for the value in the data-title attribute, but I plan to bring that up to the code group icon package maintainer when I can narrow down the issue.\n\n\n\n### Other information\n\n_No response_",[3059],{"name":3031,"color":3032},198,"Request to add data-title attribute to code block group labels","2025-04-13T18:53:02Z","https://github.com/enzonotario/vitepress-openapi/issues/198",0.8210353,{"description":3066,"labels":3067,"number":3071,"owner":3020,"repository":3021,"state":3034,"title":3072,"updated_at":3073,"url":3074,"score":3075},"### Current behavior\n\nI am using\r\n\r\n```\r\nuseTheme({\r\n\trequest: {\r\n\t\t// Set the default schema view.\r\n\t\tdefaultView: 'schema', // schema or contentType\r\n\t},\r\n});\r\n```\r\n\r\nto set the default view to schema but this does not work\n\n### Desired behavior\n\n_No response_\n\n### Reproduction\n\n_No response_\n\n### Steps to reproduce\n\n```\r\ngit clone https://github.com/wighawag/fuzd.git\r\ncd fuzd\r\ngit checkout feat/vitepress-openapi\r\npnpm i\r\npnpm docs:dev\r\n# navigate to http://localhost:5173/api-all-in-one/\r\n# it still use JSON as default view\r\n```\n\n### Logs and Error Messages\n\n_No response_\n\n### Other Information\n\n_No response_",[3068],{"name":3069,"color":3070},"documentation","0075ca",107,"useTheme have no effect","2024-11-02T22:51:19Z","https://github.com/enzonotario/vitepress-openapi/issues/107",0.8214734,{"description":3077,"labels":3078,"number":3080,"owner":3020,"repository":3021,"state":3034,"title":3081,"updated_at":3082,"url":3083,"score":3084},"### What would you like?\n\nThe ability to change the default url/port for the \"Try It Out\" button. \n\n### Why is this needed?\n\nThe API I'm building has different ports for different things. In my specific case, the current behavior does not invoke my api. \n\n### How could it be implemented?\n\nCould we possibly have an additional env variable that overwrites the default behavior?\n\n### Other information\n\n_No response_",[3079],{"name":3031,"color":3032},127,"Overwrite \"Try It Out\" url","2024-12-21T01:51:19Z","https://github.com/enzonotario/vitepress-openapi/issues/127",0.8234709,{"description":3086,"labels":3087,"number":3091,"owner":3020,"repository":3021,"state":3034,"title":3092,"updated_at":3093,"url":3094,"score":3095},"### Current behavior\n\nI noticed that in the latest version, after executing onSubmit in OAPlayground.vue, the Content-Type header in the POST request observed in the browser console is incorrectly parsed as: `application/json, application/json`\n\nThis issue causes all POST endpoints to fail.\n\n### Desired behavior\n\nManually correcting the Content-Type header to a valid format resolves the issue:\n\n```\ncurl 'https://stoplight.io/mocks/enzonotario/argentine-rock/122547792/api/v1/artists/1/albums' \\\n -H 'accept: */*' \\\n -H 'accept-language: zh-TW,zh;q=0.9,en-US;q=0.8,en;q=0.7' \\\n -H 'authorization: Bearer Token' \\\n -H 'content-type: application/json' \\\n -H 'origin: https://vitepress-openapi.vercel.app' \\\n -H 'priority: u=1, i' \\\n -H 'referer: https://vitepress-openapi.vercel.app/' \\\n -H 'sec-ch-ua: \"Chromium\";v=\"134\", \"Not:A-Brand\";v=\"24\", \"Microsoft Edge\";v=\"134\"' \\\n -H 'sec-ch-ua-mobile: ?0' \\\n -H 'sec-ch-ua-platform: \"macOS\"' \\\n -H 'sec-fetch-dest: empty' \\\n -H 'sec-fetch-mode: cors' \\\n -H 'sec-fetch-site: cross-site' \\\n -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0' \\\n --data-raw '{\"id\":1,\"name\":\"La Máquina de Hacer Pájaros\",\"year\":1976,\"image\":\"https://cdn.rock-legends.com/photos/la-maquina.jpg\"}'\n```\n\nReturns the expected response:\n```\n{\n \"id\": 1,\n \"name\": \"La Máquina de Hacer Pájaros\",\n \"year\": 1976,\n \"image\": \"https://cdn.rock-legends.com/photos/la-maquina.jpg\"\n}\n```\n\n### Reproduction\n\n_No response_\n\n### Steps to reproduce\n\nReproduction Steps\n\nThis can be verified by copying the generated cURL request. For example, sending a request via the sandbox at:\nhttps://vitepress-openapi.vercel.app/sandbox/#createArtist\n\nThe generated request:\n```\ncurl 'https://stoplight.io/mocks/enzonotario/argentine-rock/122547792/api/v1/artists/1/albums' \\\n -H 'accept: */*' \\\n -H 'accept-language: zh-TW,zh;q=0.9,en-US;q=0.8,en;q=0.7' \\\n -H 'authorization: Bearer Token' \\\n -H 'content-type: application/json, application/json' \\\n -H 'origin: https://vitepress-openapi.vercel.app' \\\n -H 'priority: u=1, i' \\\n -H 'referer: https://vitepress-openapi.vercel.app/' \\\n -H 'sec-ch-ua: \"Chromium\";v=\"134\", \"Not:A-Brand\";v=\"24\", \"Microsoft Edge\";v=\"134\"' \\\n -H 'sec-ch-ua-mobile: ?0' \\\n -H 'sec-ch-ua-platform: \"macOS\"' \\\n -H 'sec-fetch-dest: empty' \\\n -H 'sec-fetch-mode: cors' \\\n -H 'sec-fetch-site: cross-site' \\\n -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0' \\\n --data-raw '{\"id\":1,\"name\":\"La Máquina de Hacer Pájaros\",\"year\":1976,\"image\":\"https://cdn.rock-legends.com/photos/la-maquina.jpg\"}'\n```\nResults in a 500 Internal Server Error.\n\n### Logs and Error Messages\n\n_No response_\n\n### Other Information\n\nEnsure that the Content-Type header is set correctly in POST requests to avoid duplicate values.",[3088],{"name":3089,"color":3090},"bug","d73a4a",192,"Incorrect Content-Type Parsing in POST Requests Causes Guaranteed Failure","2025-04-04T22:07:17Z","https://github.com/enzonotario/vitepress-openapi/issues/192",0.8353777,{"description":3097,"labels":3098,"number":3100,"owner":3020,"repository":3021,"state":3034,"title":3101,"updated_at":3102,"url":3103,"score":3104},"Take the following minimal crashable example:\r\n\r\n```json\r\n{\r\n \"openapi\": \"3.0.0\",\r\n \"info\": {\r\n \"title\": \"Minimal API with Circular Reference\",\r\n \"version\": \"1.0.0\"\r\n },\r\n \"paths\": {\r\n \"/parent\": {\r\n \"get\": {\r\n \"summary\": \"Get a parent\",\r\n \"operationId\": \"getParent\",\r\n \"responses\": {\r\n \"200\": {\r\n \"description\": \"A parent with a child\",\r\n \"content\": {\r\n \"application/json\": {\r\n \"schema\": {\r\n \"$ref\": \"#/components/schemas/Parent\"\r\n }\r\n }\r\n }\r\n }\r\n }\r\n }\r\n }\r\n },\r\n \"components\": {\r\n \"schemas\": {\r\n \"Parent\": {\r\n \"type\": \"object\",\r\n \"properties\": {\r\n \"id\": {\r\n \"type\": \"string\"\r\n },\r\n \"child\": {\r\n \"$ref\": \"#/components/schemas/Child\"\r\n }\r\n }\r\n },\r\n \"Child\": {\r\n \"type\": \"object\",\r\n \"properties\": {\r\n \"id\": {\r\n \"type\": \"string\"\r\n },\r\n \"parent\": {\r\n \"$ref\": \"#/components/schemas/Parent\"\r\n }\r\n }\r\n }\r\n }\r\n }\r\n}\r\n```\r\n\r\nThis is valid openapi spec as can be seen checked using a [validator](https://apitools.dev/swagger-parser/online/). Of course, dealing with a circular swagger requires a form of normalization. \r\n\r\nI am currently using the standard swagger UI, which does nicely deal with circular references. However, as I have moved all my documentation over to vitepress, I would also prefer to maybe include some swagger here and there as it could help make explanations a bit clearer.",[3099],{"name":3089,"color":3090},57,"[BUG] Generator crashes if openapi-spec contains a circular reference","2024-09-28T15:43:59Z","https://github.com/enzonotario/vitepress-openapi/issues/57",0.8373185,{"description":3106,"labels":3107,"number":3108,"owner":3020,"repository":3021,"state":3034,"title":3109,"updated_at":3110,"url":3111,"score":3112},"Hi! I was working on my current project, where I have a schema that produces this UI:\n\nhttps://github.com/user-attachments/assets/21f90ff1-fb58-4aff-86e5-249e453c829f\n\nThis little screencast aims to show that it's a bit non-obvious - especially for people who are just starting to explore the site with the spec and don't know how the UI works - that object properties are there. Long description with some markdown/emojis makes it seem like the description is all that exists under this property.\n\nIn contrast, when there's no description, it's pretty obvious that the properties are expandable:\n\n\u003Cimg width=\"390\" height=\"113\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/5b945a5a-e471-44b3-8f18-0e0219c8caa0\" />\n\nBut in the case of a rich description - which is visible by default and draws attention away from the relatively small \"expand\" button icon on the top - a user who reads the description might reasonably assume that it's the only content. They may not think, \"Hmm, I read the description, but there must be properties - let me look for some element that will let me show them!\"\n\n## Suggestions:\n\n### Option 1:\n\nHide descriptions for objects when in Collapsed state, show only when Expanded:\n\nhttps://github.com/user-attachments/assets/40ead49f-6023-4cbb-9a7b-8e5a5c96b952\n\n### Option 2:\n\nShow a small hint after the description, like a verbose \"Expand\" text button or a similar UI element (only shown when it's an array/object and has a description):\n\nhttps://github.com/user-attachments/assets/c8a31a05-6b54-400d-84a9-b126b9762b1e\n\n---\n\nLet me know what you think, @enzonotario! Do you like any of the proposed options, or do you have some other idea of how to address this?",[],271,"[Discussion] When an object has a description, it's not obvious that its properties are expandable","2025-07-21T01:18:22Z","https://github.com/enzonotario/vitepress-openapi/issues/271",0.8383569,["Reactive",3114],{},["Set"],["ShallowReactive",3117],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$f4gCqvR6qnLzYjQ0uh5k1dssoWicsXShNIJv5lE1McfM":-1},"/enzonotario/vitepress-openapi/115"]