\n\n### Desired behavior\n\nA performance score of 90 or above\n\n### Reproduction\n\nhttps://vitepress-openapi.vercel.app/example/operations/getAllArtists.html\n\n### Steps to reproduce\n\n- Open any page generated by this plugin\n- Open Lighthouse\n- Look at the performance score\n",[2867,2870],{"name":2868,"color":2869},"enhancement","a2eeef",{"name":2871,"color":2872},"help wanted","008672",171,"enzonotario","vitepress-openapi","open","Performance issues","2025-02-08T02:57:38Z","https://github.com/enzonotario/vitepress-openapi/issues/171",0.8330958,{"description":2882,"labels":2883,"number":2887,"owner":2874,"repository":2875,"state":2888,"title":2889,"updated_at":2890,"url":2891,"score":2892},"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.",[2884],{"name":2885,"color":2886},"bug","d73a4a",57,"closed","[BUG] Generator crashes if openapi-spec contains a circular reference","2024-09-28T15:43:59Z","https://github.com/enzonotario/vitepress-openapi/issues/57",0.7785061,{"description":2894,"labels":2895,"number":2896,"owner":2874,"repository":2897,"state":2888,"title":2898,"updated_at":2899,"url":2900,"score":2901},"_Originally posted by @danielGithinji in https://github.com/moby/buildkit/pull/5291_",[],40,"esjs-dolar-api","H","2025-03-02T11:54:17Z","https://github.com/enzonotario/esjs-dolar-api/issues/40",0.8012288,{"description":2903,"labels":2904,"number":1499,"owner":2874,"repository":2875,"state":2888,"title":2906,"updated_at":2907,"url":2908,"score":2909},"### What would you like?\r\n\r\nCurrently, each endpoint can only use 1 securityScheme despite OAS 3 being able to specify multiple securityScheme must be used together \r\nhttps://swagger.io/docs/specification/v3_0/authentication/#using-multiple-authentication-types\r\n\r\nDefining security schemes:\r\n```json\r\n\"securitySchemes\": {\r\n \"ApiKeyAuth\": {\r\n \"type\": \"http\",\r\n \"scheme\": \"bearer\",\r\n \"description\": \"API Key\"\r\n },\r\n \"Signature\": {\r\n \"name\": \"x-signature\",\r\n \"type\": \"apiKey\",\r\n \"in\": \"header\",\r\n \"description\": \"Request signature\"\r\n }\r\n },\r\n```\r\n\r\nIn endpoint:\r\n```json\r\n\"security\": [{ \"Signature\": [] }, { \"ApiKeyAuth\": [] }],\r\n```\r\n\r\n### Why is this needed?\r\n\r\nWhen allowing user to test the endpoints, if the API requires 2+ security schemes to be used together, the try it would not able to show 2 security fields\r\n\r\n\r\n\r\n### How could it be implemented?\r\n\r\nUpdating OASecurity and OATryWithVariables\r\n\r\n### Other information\r\n\r\nExample implementation from [Scalar](https://github.com/scalar/scalar):\r\n\r\n",[2905],{"name":2868,"color":2869},"Support multiple security together when specified","2024-12-21T01:50:26Z","https://github.com/enzonotario/vitepress-openapi/issues/129",0.8022436,{"description":2911,"labels":2912,"number":2914,"owner":2874,"repository":2875,"state":2888,"title":2915,"updated_at":2916,"url":2917,"score":2918},"### 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.",[2913],{"name":2868,"color":2869},92,"Modify Sample Code Based on Variables","2024-11-15T02:40:07Z","https://github.com/enzonotario/vitepress-openapi/issues/92",0.81181705,{"description":2920,"labels":2921,"number":2925,"owner":2874,"repository":2897,"state":2888,"title":2926,"updated_at":2927,"url":2928,"score":2929},"Hola buenos dias estimados queria consultarles el horario de actualizacion que tienen para el Dolar Bolsa para no realizar requests de más. Desde ya muchas gracias",[2922],{"name":2923,"color":2924},"question","d876e3",42,"Consulta horarios de actualizacion","2025-03-20T18:46:11Z","https://github.com/enzonotario/esjs-dolar-api/issues/42",0.81210345,{"description":2931,"labels":2932,"number":2936,"owner":2874,"repository":2875,"state":2888,"title":2937,"updated_at":2938,"url":2939,"score":2940},"### 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_",[2933],{"name":2934,"color":2935},"documentation","0075ca",107,"useTheme have no effect","2024-11-02T22:51:19Z","https://github.com/enzonotario/vitepress-openapi/issues/107",0.8178524,{"description":2942,"labels":2943,"number":2945,"owner":2874,"repository":2875,"state":2888,"title":2946,"updated_at":2947,"url":2948,"score":2949},"### What would you like?\n\nVitepress-openapi is beautiful. I have a doc site already, and I would like to add the vitepress-openapi docs as a menu item on my top navigation menu. \r\n\r\n\r\n\n\n### Why is this needed?\n\nThere is often a lot of material besides the openapi specification that one needs for documentation. I'd like to be able to include the openapi site within another site to keep everything together.\n\n### How could it be implemented?\n\nI'm not knowledgeable enough to know. Right now I am embedding `openapi-explorer` in a simple `layout: page` page associated with the menu item:\r\n\r\n```vue\r\n---\r\nlayout: page\r\nsidebar: false\r\n---\r\n\u003Cscript setup>\r\n import 'openapi-explorer/dist/es/openapi-explorer.js';\r\n import { useData } from 'vitepress'\r\n const { isDark, theme, page, frontmatter } = useData()\r\n\u003C/script>\r\n\r\n\u003CClientonly>\r\n \u003Copenapi-explorer\r\n v-if = isDark\r\n spec-url = \"/adm-spec.yaml\"\r\n hide-console = true\r\n hide-authentication = true\r\n hide-server-selection = true\r\n hide-components = false\r\n nav-bg-color = #1b1b1f\r\n secondary-color = #F8F8F5\r\n nav-hover-text-color = #85bd4f\r\n bg-color = #1b1b1f\r\n text-color = \"#F8F8F5\"\r\n >\r\n \u003C/openapi-explorer>\r\n\r\n\r\n \u003Copenapi-explorer\r\n v-else\r\n spec-url = \"/adm-spec.yaml\"\r\n hide-console = true\r\n hide-authentication = true\r\n hide-server-selection = true\r\n hide-components = false\r\n nav-bg-color = #ffffff\r\n secondary-color = #000000\r\n nav-hover-text-color = #F8F8F5\r\n >\r\n \u003C/openapi-explorer>\r\n\r\n\u003C/ClientOnly>\r\n```\r\n\r\nThis seems very awkward, and it's difficult to get the styles to match Vitepress's theme. Might there be a way to extend the default theme with a layout called `openapi` and somehow link my spec file in the front matter?\n\n### Other information\n\nI appreciate this work very much. Thanks for considering the suggestion.",[2944],{"name":2923,"color":2924},71,"Is it possible to add vitepress-openapi to an existing Vitepress site as a menu item","2024-10-19T02:30:08Z","https://github.com/enzonotario/vitepress-openapi/issues/71",0.81843936,{"description":2951,"labels":2952,"number":2954,"owner":2874,"repository":2875,"state":2888,"title":2955,"updated_at":2956,"url":2957,"score":2958},"### What would you like?\n\nI'd like to be able to render the openapi specification with a signle column layout. It would be nice if it is configurable in the parameters of the components like OASpec or globally in the theme config. In addition to that, it would also be nice if the different child components could be enabled/disabled (i.e. turn off samples). \n\n### Why is this needed?\n\nI want this because the standard theme does not have a lot of content width, Having a two column layout looks crowded and sometimes the content is wrapped. Having all the child components below each other with a single column layout would bring more clarity to the rendered documentation.\n\n### How could it be implemented?\n\n_No response_\n\n### Other information\n\n_No response_",[2953],{"name":2868,"color":2869},91,"Single column layout","2024-10-27T14:41:53Z","https://github.com/enzonotario/vitepress-openapi/issues/91",0.8190593,{"description":2960,"labels":2961,"number":285,"owner":2874,"repository":2897,"state":2888,"title":2965,"updated_at":2966,"url":2967,"score":2968},"La api esta fallando con el valor del dolar blue",[2962],{"name":2963,"color":2964},"duplicate","cfd3d7","Error en la cotización del blue","2024-02-09T14:55:00Z","https://github.com/enzonotario/esjs-dolar-api/issues/15",0.8214991,["Reactive",2970],{},["Set"],["ShallowReactive",2973],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fhmmTg8BNdj6lZBpUlNtjoHBznpDPywL4WolZJqXcpxA":-1},"/enzonotario/esjs-dolar-api/41"]