From ec55d4c4f5ee4fb37b520376de11d9b42dc06151 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Sun, 8 Dec 2024 12:50:07 +0000 Subject: [PATCH] Updates --- 404.html | 4 ++-- _next/static/chunks/nextra-data-en-US.json | 2 +- .../_buildManifest.js | 0 .../_ssgManifest.js | 0 getting-started/quick-start.html | 4 ++-- getting-started/tips-for-writing-specifications.html | 4 ++-- guides/client-templates/typescript-angular.html | 4 ++-- guides/client-templates/typescript-axios.html | 4 ++-- guides/client-templates/typescript-fetch.html | 4 ++-- guides/concepts/authenticated-input-specifications.html | 4 ++-- guides/concepts/extract-inline-schemas.html | 4 ++-- guides/concepts/servers-object-handling.html | 4 ++-- guides/server-templates/typescript-koa.html | 4 ++-- guides/use-with-react-query.html | 4 ++-- index.html | 2 +- overview/about.html | 4 ++-- overview/compatibility.html | 4 ++-- overview/roadmap.html | 4 ++-- overview/schema-first-design.html | 4 ++-- reference/cli-options.html | 4 ++-- reference/release-notes.html | 4 ++-- 21 files changed, 36 insertions(+), 36 deletions(-) rename _next/static/{IAjNhorSMAQYQlItTXsBX => kXi3c5JOdEE0KV7td5iHq}/_buildManifest.js (100%) rename _next/static/{IAjNhorSMAQYQlItTXsBX => kXi3c5JOdEE0KV7td5iHq}/_ssgManifest.js (100%) diff --git a/404.html b/404.html index 2b936623..b4f8d668 100644 --- a/404.html +++ b/404.html @@ -1,3 +1,3 @@ -Page not found – OpenAPI Code Generator
404

Page not found

+Page not found – OpenAPI Code Generator
404

Page not found

Sorry this page doesn’t exist 😞

-

Please use the navigation on your left, or the search box at the top to get back on track.

Schema-first design
\ No newline at end of file +

Please use the navigation on your left, or the search box at the top to get back on track.

Schema-first design
\ No newline at end of file diff --git a/_next/static/chunks/nextra-data-en-US.json b/_next/static/chunks/nextra-data-en-US.json index 773535db..a29567e3 100644 --- a/_next/static/chunks/nextra-data-en-US.json +++ b/_next/static/chunks/nextra-data-en-US.json @@ -1 +1 @@ -{"/guides/concepts/authenticated-input-specifications":{"title":"Authenticated input specifications","data":{"":"Sometimes you want to generate using a URL as the input, but the URL requires some kind of authentication\nheader to be passed.A good example is Google cloud platforms IAP proxy,\nwhich was the original motivation for supporting this, where we must pass a Proxy-Authorization header.\nOr from private github repositories,\nwhere a Authorization header should be supplied.This can be achieved using the environment variable (preferred)) OPENAPI_REMOTE_SPEC_REQUEST_HEADERS,\nalso available as the --remote-spec-request-headers cli flag.","format#Format":"The format of the value is a JSON object keyed by URI, with values being either an object,\nor array of {name, value} pairs.For example:\n{\n \"https://example.com\": [\n {\"name\": \"X-Client-Id\", \"value\": \"my-client-id\"},\n {\"name\": \"X-Client-Secret\", \"value\": \"some-secret-value\"}\n ],\n \"https://example.org/some/path\": {\"name\": \"Proxy-Authorization\", \"value\": \"some token\"}\n}\nAs a typescript type:\ntype OPENAPI_REMOTE_SPEC_REQUEST_HEADERS = {\n [uri: string]: { name: string, value: string }[] | { name: string, value: string }\n}","hostname-matching#Hostname matching":"You should set the uris to the least specific uris you're happy for the header to be sent to -\na full match on the provided uri is required for the headers to be sent.Eg: given a uri of https://exmaple.com:8080/openapi.yaml the headers would not\nbe sent for requests to other ports, resource paths, or protocols, but a less specific\nuri like https://example.com will send headers on any (https) request to that domain,\nsuch as https://exmaple.com/some/path/openapi.yaml","tips-for-generating-the-json#Tips for generating the JSON":"Unfortunately it is a little annoying to formulate in shell scripts, so here's some examples to get you started.Typically, in any real use cases the secret values would be coming from other shell variables, eg: storing a\nshort-lived access token, etc.","use-jq#Use jq":"Using jq:\nOPENAPI_REMOTE_SPEC_REQUEST_HEADERS=$(jq --null-input --compact-output \\\n --arg domain \"https://example.com\" \\\n --arg name \"proxy-authorization\" \\\n --arg value \"some secret value\" '{$domain: {$name, $value}}')\necho $OPENAPI_REMOTE_SPEC_REQUEST_HEADERS\nOutputs:\n{\"https://example.com\":{\"name\":\"proxy-authorization\",\"value\":\"some secret value\"}}","use-node#Use node":"Using nodejs:\nOPENAPI_REMOTE_SPEC_REQUEST_HEADERS=$(node -p 'JSON.stringify({[process.argv[1]]: {name: process.argv[2], value: process.argv[3]}})' \\\n https://example.com \\\n proxy-authorization \\\n 'some secret value')\necho $OPENAPI_REMOTE_SPEC_REQUEST_HEADERS\nOutputs:\n{\"https://example.com\":{\"name\":\"proxy-authorization\",\"value\":\"some secret value\"}}","why-json#Why JSON":"Why JSON you ask? Simply put it has very well-defined semantics, and is easy to parse without\nfear of jumbling the pieces together.I started by trying to come up with a more ergonomic format, and then felt like I was re-inventing JSON\nwhen it came to dealing with all the edge cases correctly."}},"/guides/concepts/servers-object-handling":{"title":"Guide to servers object handling","data":{"":"OpenAPI 3 has a servers property that can be used to define the base url for the whole document, or\nspecific operations. This guide aims to explain how this is processed.You can find the specifications definition of the servers object hereThis is fully supported, including placeholder/variable substitution, and overriding.\nThe servers object is only used for client SDK templates.It doesn't really make sense in the context of a server template, and so is ignored.","overview#Overview":"Consider an example servers block:\nservers:\n - url: '{protocol}://{host}:{port}'\n variables:\n host:\n default: localhost\n protocol:\n enum: [http, https]\n default: http\n port:\n default: '8080'\nIt defines a single server, with three variables.This will generate a ApiClientServers object that you can use to create a basePath like so:\nconst client = new ApiClient({\n// basePath will be https://localhost:80\nbasePath: ApiClientServers\n .server(\"{protocol}://{host}:{port}\") // the url template determines the build function\n .build(\n \"https\", // string literal union to form the enum\n undefined, // pass undefined to take the default\n \"80\", // override defaults\n )\n})\nIf you pass no args to build, the defaults from the specification are used:\nconst client = new ApiClient({\n// basePath will be http://localhost:8080\nbasePath: ApiClientServers\n .server(\"{protocol}://{host}:{port}\")\n .build()\n})\nYou can also take the default (first) server like so:\nconst client = new ApiClient({\n// basePath will be http://localhost:8080\nbasePath: ApiClientServers\n .server()\n .build()\n})","operation-specific-overrides#Operation specific overrides":"You can specify servers overrides at the path, or individual operation level. The most specific servers block\nwill be used for a given operation.For example, override the url for all operations under the /attachments route:\npaths:\n /attachments:\n servers:\n - url: 'https://attachments.example.com'\nWhen overrides are specified, an additional basePath positional argument will be added to the operation, defaulting\nto the first overridden server with default placeholder values.\nexport class ApiClient {\n async uploadAttachment(\n p: { ... },\n // Overridden server param\n basePath:\n | Server<\"uploadAttachment_ApiClient\">\n | string = ApiClientServers.operations\n .uploadAttachment()\n .build(),\n timeout?: number,\n opts: RequestInit = {},\n ): Promise>> {\n ...\n }\n}\nAs you can see the overrides for each operation are exposed as ApiClientServers.operations.() following\nthe same pattern as the root servers.","configuration#Configuration":"This behavior is optional, and be turned off by passing:\n--enable-typed-base-paths=false\nWhen disabled basePath: string parameters will still be added to operations that have a servers override, but\nno code based on the url or variables will be generated.See also CLI reference"}},"/overview/schema-first-design":{"title":"Why schema first","data":{"":"Broadly speaking there are two approaches people take to maintaining API specifications:\nSchema first, where you write the schema by hand\nCode first, where you generate the schema from your code\nThis project being a code generator from API specification files is on the schema first side of the debate, but why?Ultimately this is fairly subjective, but there are four primary motivators that lead us to believe schema first\nis the better approach.This is also recommended by the OpenAPI initiative (OAI) itself, where they refer to this as \"Design-first\" with similar arguments","longevity#Longevity":"APIs are forever,\nchanging them in backwards incompatible ways is hard/expensive, or sometimes not possible.With that in mind, we believe it's important to be thoughtful about your API design, and\nthat writing an explicit specification/contract is a great forcing function to accomplish this.Additionally, programming languages / frameworks come and go - they are an implementation detail,\nand subject to change as business requirements evolve.\nOpenAPI (originally Swagger) has been around for over a decade now, and we're confident it'll be around for a long time.","common-language#Common Language":"Many large projects / systems will involve multiple programming languages. For example, you might have a Java backend,\nKotlin Android app, Swift iOS app, and Typescript web frontend.For writing your API contracts using OpenAPI up front, you create a common ground for developers of all languages to discuss\nand hash out the details.","constraints#Constraints":"General purpose programming languages are very flexible. If you try hard enough, you can probably implement it.\nSpecifications like OpenAPI on the other hand are more rigid and constraining.We believe it's better to lean into this and design your system such that it can be represented fully by a\nspecification, rather than attempt to generate a specification from the implementation and lose\ninformation/nuance in the process.","separation#Separation":"A good specification not only defines the API contract, but also includes a lot of supplementary information such as examples,\nand documentation.Generating a good specification from your code, therefore requires including all this extra metadata in the code, which\ncan make the code more difficult to work with.We prefer to separate these concerns out into the specification, and keep the implementation code leaner and simpler."}},"/getting-started/tips-for-writing-specifications":{"title":"Tips for writing a good specification","data":{"":"Garbage in, garbage out applies especially to code generation tools. In short the more detailed, and accurate the\nspecification, the better the code and documentation you'll get from it.This page outlines some tips to enhance the quality of the generated code, and make your specification easier to maintain.","declare-operationids#Declare operationIds":"The operationId is used to generate method and type names. If you don't specify one,\nthen one will be generated from the HTTP method and route.Eg:\nWithout an operation id, you'll get generated method names, that might look like:\nclient.getV2ListListIdItems(...)\nclient.postV2ListListIdItems(...)\nInstead of more readable ones like:\nclient.getTodoListItems(...)\nclient.createTodoListItem(...)","make-liberal-use-of-ref#Make liberal use of $ref":"Using $ref can reduce the repetition in your specification, making it far more readable\nand maintainable.It also has the advantage of giving a name to things, that can be used in the generated code,\nand avoid generating duplicate code.If you can't use $ref easily, there is also the option to extract-inline-schemas\nwhich will generate names to avoid inline types, but it won't save you from duplicate code.Example:\npaths:\n /list:\n get:\n operationId: getTodoLists\n responses:\n 200:\n description: 'success'\n content:\n application/json:\n schema:\n type: array\n items:\n $ref: '#/components/schemas/TodoList'\ncomponents:\n schemas:\n TodoList:\n properties:\n ...","compose-refs-using-allof--anyof#Compose $refs using allOf / anyOf":"You can create union and intersection types using allOf and anyOfUnion Types\nUsing anyOf we can combine types / schemas into unions.\ncomponents:\n schemas:\n Apple:\n type: object\n Pear:\n type: object\n Fruit:\n anyOf:\n - $ref: \"#/components/schemas/Apple\"\n - $ref: \"#/components/schemas/Pear\"\nProduces something like:\nexport type Apple = {}\nexport type Pear = {}\nexport type Fruit = Apple | Pear\nIntersection Types\nUsing allOf of we can combine types / schemas into intersection types. This is often\nhandy for \"extending\" a type with additional properties\ncomponents:\n schemas:\n Profile:\n type: object\n properties:\n ...\n FullProfile:\n type: object\n allOf:\n - $ref: \"#/components/schemas/Profile\"\n - type: object\n properties:\n ...\nProduces something like:\nexport type Profile = {}\nexport type FullProfile = Profile & {}","use-validation-constraints-where-sensible#Use validation constraints where sensible":"A fairly rich set of validations can be specified in the specification. Make use of these in order\nfor robust runtime validation.Example:\ncomponents:\n schemas:\n MyRequestBody:\n type: object\n properties:\n name:\n type: string\n minLength: 1\n tags:\n type: array\n minItems: 1\n maxItems: 100\n items:\n type: string\nSee compatibility table for an idea of what's possible.","use-a-clear-infotitle#Use a clear info.title":"The root info.title property is used to name the generated client. Using a name like:\ninfo:\n title: Awesome Service\nWill output a class AwesomeServiceClientIf you can't modify the title, you can use --override-specification-title \"Some Other Title\"\nto workaround."}},"/getting-started/quick-start":{"title":"Quick Start","data":{"":"Install the latest NodeJS LTS release, though any recent version of NodeJS will likely work.You'll also need either an OpenAPI v3 / v3.1, or TypeSpec API specification to generate from. You can\nprovide OpenAPI specifications as YAML or JSON, local files or remote urls - we'll load them all! 🚀Cross-file references are also supported, so don't worry about pre-processing the input.You can check the version we develop and test against here.\nFirst install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator\nnpm i @nahkies/typescript-fetch-runtime\npnpm add --dev @nahkies/openapi-code-generator\npnpm add @nahkies/typescript-fetch-runtime\nyarn add --dev @nahkies/openapi-code-generator\nyarn add @nahkies/typescript-fetch-runtime\nbun add --dev @nahkies/openapi-code-generator\nbun add @nahkies/typescript-fetch-runtime\nYou could also install the CLI globally if you prefer, but it's best to version it per project.This will generate the client to ./src/generated/clients/some-serviceYou can provide either a local file path or url for the input file.\nnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-fetch\npnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-fetch\nyarn openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-fetch\nbun run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-fetch\nUse your new type-safe client, and never worry about making a typo in a url or parameter name again.\nLet the typescript compiler take care of checking that for you.See Guide to typescript-fetch client template for more details.\nFirst install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator\nnpm i axios @nahkies/typescript-axios-runtime\npnpm add --dev @nahkies/openapi-code-generator\npnpm add axios @nahkies/typescript-axios-runtime\nyarn add --dev @nahkies/openapi-code-generator\nyarn add axios @nahkies/typescript-axios-runtime\nbun add --dev @nahkies/openapi-code-generator\nbun add axios @nahkies/typescript-axios-runtime\nYou could also install the CLI globally if you prefer, but it's best to version it per project.This will generate the client to ./src/generated/clients/some-serviceYou can provide either a local file path or url for the input file.\nnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-axios\npnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-axios\nyarn openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-axios\nbun run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-axios\nUse your new type-safe client, and never worry about making a typo in a url or parameter name again.\nLet the typescript compiler take care of checking that for you.See Guide to typescript-axios client template for more details.\nFirst install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nnpm i @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\npnpm add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\npnpm add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nyarn add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nyarn add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nbun add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nbun add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nYou could also install the CLI globally if you prefer, but it's best to version it per project.You can provide either a local file path or url for the input file.This will generate the server router and validation logic to ./src/generated\nnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated \\\n--template typescript-koa\npnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated \\\n--template typescript-koa\nyarn openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated \\\n--template typescript-koa\nbun run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated \\\n--template typescript-koa\nImplement handlers for your server, and be confident that they match what the client expects. Everything\nwill be strongly typed, so typos are surfaced at development time, not runtime.By default the runtime validation is using zod.See Guide to typescript-koa client template for more details.","cli-options#CLI options":"See the cli reference for the full range of supported options, or try\nnpm run openapi-code-generator --help\npnpm run openapi-code-generator --help\nyarn openapi-code-generator --help\nbun run openapi-code-generator --help","typespec-specifications#Typespec specifications":"If you want to use typespec instead of openapi3\nas your input specifications, additionally install the typespec compiler and supporting packages.\nnpm i --dev @typespec/compiler @typespec/http @typespec/openapi @typespec/openapi3 @typespec/versioning\npnpm add --dev @typespec/compiler @typespec/http @typespec/openapi @typespec/openapi3 @typespec/versioning\nyarn add --dev @typespec/compiler @typespec/http @typespec/openapi @typespec/openapi3 @typespec/versioning\nbun add --dev @typespec/compiler @typespec/http @typespec/openapi @typespec/openapi3 @typespec/versioning\nDepending on how your typespec specification is written, you may need to install additional packages such\nas @typespec/rest.You can then generate like so:\nnpm run openapi-code-generator \\\n --input ./some-service.tsp \\ # or https://example.com/some-service.tsp\n --input-type=typespec \\\n --output ./src/generated/clients/some-service \\\n --template typescript-fetch\npnpm run openapi-code-generator \\\n --input ./some-service.tsp \\ # or https://example.com/some-service.tsp\n --input-type=typespec \\\n --output ./src/generated/clients/some-service \\\n --template typescript-fetch\nyarn openapi-code-generator \\\n --input ./some-service.tsp \\ # or https://example.com/some-service.tsp\n --input-type=typespec \\\n --output ./src/generated/clients/some-service \\\n --template typescript-fetch\nbun run openapi-code-generator \\\n --input ./some-service.tsp \\ # or https://example.com/some-service.tsp\n --input-type=typespec \\\n --output ./src/generated/clients/some-service \\\n --template typescript-fetch\nYou can see examples of code generated from typespec specifications here"}},"/guides/client-templates/typescript-angular":{"title":"Using the typescript-angular template","data":{"":"this is the least battle tested of the templates and most likely to have critical bugs\nThe typescript-angular template outputs a client SDK based on the Angular HttpClient that gives the following:\nTyped methods to call each endpoint returning an RxJS Observable\nIt does not yet support runtime validation/parsing - compile time type safety only at this stage.See integration-tests/typescript-angular for more samples.","install-dependencies#Install dependencies":"First install the CLI to your project:\nnpm i --dev @nahkies/openapi-code-generator\npnpm add --dev @nahkies/openapi-code-generator\nyarn add --dev @nahkies/openapi-code-generator\nbun add --dev @nahkies/openapi-code-generator\nSee also quick start guide","run-generation#Run generation":"npm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod","using-the-generated-code#Using the generated code":"Running the above will output these files into ./src/app/clients/some-service:\n./api.module.ts: exports a class ApiModule as an NgModule\n./client.service.ts: exports a class ApiClient as injectable Angular service\n./models.ts: exports typescript types\n./schemas.ts: exports runtime parsers using the chosen schema-builder (default zod)\nOnce generated usage should look something like this:\n// Root Angular module\n@NgModule({\n declarations: [AppComponent],\n imports: [BrowserModule, AppRoutingModule, ApiModule],\n providers: [],\n bootstrap: [AppComponent],\n})\nexport class AppModule {}\n@Component({\n selector: \"app-root\",\n templateUrl: \"./app.component.html\",\n styleUrls: [\"./app.component.css\"],\n})\nexport class AppComponent {\n // inject into your component\n constructor(client: ApiClient) {\n client.updateTodoListById({listId: \"1\", requestBody: {name: \"Foo\"}}).subscribe((next) => {\n if (next.status === 200) {\n // TODO: body is currently incorrectly `unknown` here\n console.log(next.body.id)\n }\n })\n }\n}"}},"/guides/client-templates/typescript-axios":{"title":"Using the typescript-axios template","data":{"":"The typescript-axios template outputs a client SDK based on the axios that gives the following:\nTyped methods to call each endpoint\nOptionally, runtime response validation\nIt follows the standard axios pattern of rejecting any response that isn't 2xx and thus can't provide typed\nerror responses. If you'd like to have strong typing over your error responses consider using the typescript-fetch template.Runtime request parameter validation is not currently supported.See integration-tests/typescript-axios for more samples.","install-dependencies#Install dependencies":"First install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator\nnpm i axios @nahkies/typescript-axios-runtime\npnpm add --dev @nahkies/openapi-code-generator\npnpm add axios @nahkies/typescript-axios-runtime\nyarn add --dev @nahkies/openapi-code-generator\nyarn add axios @nahkies/typescript-axios-runtime\nbun add --dev @nahkies/openapi-code-generator\nbun add axios @nahkies/typescript-axios-runtime\nSee also quick start guide","run-generation#Run generation":"Experimental support for runtime response validation is available behind the --enable-runtime-response-validation\nflag.\nnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod","using-the-generated-code#Using the generated code":"Running the above will output these files into ./src/clients/some-service:\n./client.ts: exports a class ApiClient that implements methods for calling each endpoint\n./models.ts: exports typescript types\n./schemas.ts: exports runtime parsers using the chosen schema-builder (default zod)\nOnce generated usage should look something like this:\nconst client = new ApiClient({\n // Pass a axios instance if you wish to use interceptors for auth, logging, etc\n // axios: axios.create({...}),\n basePath: `http://localhost:${address.port}`,\n defaultHeaders: {\n \"Content-Type\": \"application/json\",\n Authorisation: \"Bearer: \", // can pass auth headers here\n },\n})\n// rejects if status code isn't 2xx, following typical axios behavior\nconst res = await client.createTodoListItem({\n listId: list.id,\n requestBody: {content: \"test item\"},\n // optionally pass a timeout (ms), or any arbitrary axios options\n // timeout?: number,\n // opts?: AxiosRequestConfig\n})\n// data will be typed correctly\nconsole.log(`id is: ${res.data.id}`)"}},"/guides/client-templates/typescript-fetch":{"title":"Using the typescript-fetch template","data":{"":"The typescript-fetch template outputs a client SDK based on the fetch api that gives the following:\nTyped methods to call each endpoint\nSupport for passing a timeout, abort signals are still respected\nOptionally, runtime response validation\nRuntime request parameter validation is not currently supported.See integration-tests/typescript-fetch for more samples.Dependencies:","install-dependencies#Install dependencies":"First install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator\nnpm i @nahkies/typescript-fetch-runtime\npnpm add --dev @nahkies/openapi-code-generator\npnpm add @nahkies/typescript-fetch-runtime\nyarn add --dev @nahkies/openapi-code-generator\nyarn add @nahkies/typescript-fetch-runtime\nbun add --dev @nahkies/openapi-code-generator\nbun add @nahkies/typescript-fetch-runtime\nSee also quick start guide\nIf you're using an older version of NodeJS, or targeting very old web browsers,\nyou may need a polyfill like node-fetch-native","run-generation#Run generation":"Experimental support for runtime response validation is available behind the --enable-runtime-response-validation\nflag.\nnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod","using-the-generated-code#Using the generated code":"Running the above will output these files into ./src/clients/some-service:\n./client.ts: exports a class ApiClient that implements methods for calling each endpoint\n./models.ts: exports typescript types\n./schemas.ts: exports runtime parsers using the chosen schema-builder (default zod)\nOnce generated usage should look something like this:\nconst client = new ApiClient({\n basePath: `http://localhost:${address.port}`,\n defaultHeaders: {\n \"Content-Type\": \"application/json\",\n Authorisation: \"Bearer: \", // can pass auth headers here\n },\n})\nconst res = await client.createTodoListItem({\n listId: list.id,\n requestBody: {content: \"test item\"},\n // optionally pass a timeout (ms), or any arbitrary fetch options (eg: an abort signal)\n // timeout?: number,\n // opts?: RequestInit\n})\n// checking the status code narrows the response body types (ie: remove error types from the type union)\nif (res.status !== 200) {\n throw new Error(\"failed to create item\")\n}\n// body will be typed correctly\nconst body = await res.json()\nconsole.log(`id is: ${body.id}`)"}},"/guides/concepts/extract-inline-schemas":{"title":"Extract inline schemas","data":{"":"We have experimental support for \"extracting inline schemas\" behind the\n--extract-inline-schemas / OPENAPI_EXTRACT_INLINE_SCHEMAS=true configuration flag.","what-does-this-mean#What does this mean?":"There are basically two ways you can define schemas in your openapi specifications:\nNamed schemas\nInline schemas\nThese are handled differently by code generation. Enabling --extract-inline-schemas aims to\nmake inline schemas emit similar code to named schemas.","named-schema-example#Named schema example":"Normally when writing openapi specifications it is desirable to make use of $ref and define your schemas as named\ncomponents.\npaths:\n /list/{listId}:\n parameters:\n - $ref: '#/components/parameters/listId'\n get:\n operationId: getTodoListById\n responses:\n 200:\n description: 'success'\n content:\n application/json:\n schema:\n $ref: '#/components/schemas/TodoList'\ncomponents:\n schemas:\n TodoList:\n type: object\n required:\n - id\n - name\n - totalItemCount\n - incompleteItemCount\n - created\n properties:\n id:\n type: string\n format: uuid\n name:\n type: string\n totalItemCount:\n type: number\n incompleteItemCount:\n type: number\n created:\n type: string\n format: date-time\nWhen we run code generation for this, we expect a type and a schema for the TodoList to be generated, something like:\nimport {z} from 'zod'\nexport type t_TodoList = {\n id: string\n name: string\n totalItemCount: number\n incompleteItemCount: number\n created: string\n}\nexport const s_TodoList = z.object({\n id: z.string(),\n name: z.string(),\n totalItemCount: z.coerce.number(),\n incompleteItemCount: z.coerce.number(),\n created: z.string().datetime({ offset: true }),\n})\nThis is useful, as it means that we can easily reference the type, or use the schema as we require.","inline-schema-example#Inline Schema Example":"However, not everyone will write their specifications using named $refs, and instead inline schemas may be used.\nThis is especially prolific when generating the specification from implementation code in our experience.Consider the same example as above, but with the schema inlined:\npaths:\n /list/{listId}:\n parameters:\n - $ref: '#/components/parameters/listId'\n get:\n operationId: getTodoListById\n responses:\n 200:\n description: 'success'\n content:\n application/json:\n schema:\n type: object\n required:\n - id\n - name\n - totalItemCount\n - incompleteItemCount\n - created\n properties:\n id:\n type: string\n format: uuid\n name:\n type: string\n totalItemCount:\n type: number\n incompleteItemCount:\n type: number\n created:\n type: string\n format: date-time\ncomponents:\n schemas: {}\nBy default, this will be emitted as in-line types / schemas\nexport type GetTodoListById = (\n params: Params,\n respond: GetTodoListByIdResponder,\n ctx: RouterContext,\n) => Promise<\n | KoaRuntimeResponse\n | Response<\n 200,\n {\n id: string\n name: string\n totalItemCount: number\n incompleteItemCount: number\n created: string\n }\n >\n | Response\n | Response\n>\nconst getTodoListByIdResponseValidator = responseValidationFactory(\n [\n [\n \"200\",\n z.object({\n id: z.string(),\n name: z.string(),\n totalItemCount: z.coerce.number(),\n incompleteItemCount: z.coerce.number(),\n created: z.string().datetime({ offset: true }),\n }),\n ],\n [\"4XX\", s_Error],\n ],\n z.undefined(),\n)\nrouter.get(\"getTodoListById\", \"/list/:listId\", async (ctx, next) => {\n // ...\n const responder = {\n with200() {\n return new KoaRuntimeResponse<{\n id: string\n name: string\n totalItemCount: number\n incompleteItemCount: number\n created: string\n }>(200)\n }\n }\n // ...\n})","with---extract-inline-schemas-enabled#With --extract-inline-schemas enabled":"Notice how this:\nCreates a lot of duplication, we have to repeat the definition anytime it is used\nMakes it inconvenient, or impossible to reference the type/schema in our implementation code\nWith --extract-inline-schemas enabled, the code generator will synthesis a name for each inline schema based on\nits usage, and emit exported types/schemas, eg:\nexport type t_getTodoListByIdJson200Response = {\n id: string\n name: string\n totalItemCount: number\n incompleteItemCount: number\n created: string\n}\nexport const s_getTodoListByIdJson200Response = z.object({\n id: z.string(),\n name: z.string(),\n totalItemCount: z.coerce.number(),\n incompleteItemCount: z.coerce.number(),\n created: z.string().datetime({ offset: true }),\n})\nThis can be a handy trick to make the code generated from schemas you don't own/control easier to work with. In general\nyou should prefer to improve the specifications to be more suitable for code generation, which generally also improves\nthe result of documentation tools like Redoc"}},"/guides/server-templates/typescript-koa":{"title":"Using the typescript-koa template","data":{"":"The typescript-koa template outputs scaffolding code that handles the following:\nBuilding a @koa/router instance with all routes in the openapi specification\nGenerating types and runtime schema parsers for all request parameters/bodies and response bodies\nGenerating types for route implementations that receive validated inputs, and have return types that are additionally\nvalidated at runtime prior to sending the response\n(Optionally) Actually starting the server and binding to a port\nSee integration-tests/typescript-koa for more samples.","install-dependencies#Install dependencies":"First install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nnpm i @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\npnpm add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\npnpm add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nyarn add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nyarn add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nbun add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nbun add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nSee also quick start guide","run-generation#Run generation":"npm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod","using-the-generated-code#Using the generated code":"Running the above will output three files into ./src:\ngenerated.ts - exports a createRouter and bootstrap function, along with associated types used to create your server\nmodels.ts - exports typescript types for schemas\nschemas.ts - exports runtime schema validators\nOnce generated usage should look something like this:\nimport {bootstrap, createRouter, CreateTodoList, GetTodoLists} from \"../generated\"\n// Define your route implementations as async functions implementing the types\n// exported from generated.ts\nconst createTodoList: CreateTodoList = async ({body}, respond) => {\n const list = await prisma.todoList.create({\n data: {\n // body is strongly typed and parsed at runtime\n name: body.name,\n },\n })\n // (recommended) the respond parameter is a strongly typed helper that\n // provides a better editor experience.\n // the response body is additionally validated against the response schema/status code at runtime\n return respond.with200().body(dbListToApiList(list))\n // (deprecated) alternatively, you can return a {status, body} object which is also strongly typed\n // pattern matching the status code against the response schema:\n // return {\n // status: 200 as const,\n // body: dbListToApiList(list)\n // }\n}\nconst getTodoLists: GetTodoLists = async ({query}) => {\n // omitted for brevity\n}\n// Starts a server listening on `port`\nbootstrap({\n router: createRouter({getTodoLists, createTodoList}),\n port: 8080,\n})","custom-koa-appconfig#Custom Koa app/config":"The provided bootstrap function has a limited range of options. For more advanced use-cases,\nsuch as https you will need to construct your own Koa app, and mount the router returned by createRouter.The only real requirement is that you provide a body parsing middleware before the router that places\na parsed request body on the ctx.body property.Eg:\nimport {createRouter} from \"../generated\"\nimport KoaBody from \"koa-body\"\nimport https from \"https\"\n// ...implement routes here\nconst app = new Koa()\n// it doesn't have to be koa-body, but it does need to put the parsed body on `ctx.body`\napp.use(KoaBody())\n// mount the generated router\nconst router = createRouter({getTodoLists, createTodoList})\napp.use(router.allowedMethods())\napp.use(router.routes())\nhttps\n .createServer(\n {\n key: \"...\",\n cert: \"...\",\n },\n app.callback(),\n )\n .listen(433)","error-handling#Error Handling":"Any errors thrown during the request processing will be wrapped in KoaRuntimeError objects,\nand tagged with the phase the error was thrown.\ninterface KoaRuntimeError extends Error {\n cause: unknown // the originally thrown exception\n phase: \"request_validation\" | \"request_handler\" | \"response_validation\"\n}\nThis allows for implementing catch-all error middleware for common concerns like failed request validation,\nor internal server errors.Eg:\nexport async function genericErrorMiddleware(ctx: Context, next: Next) {\n try {\n await next()\n } catch (err) {\n // if the request validation failed, return a 400 and include helpful\n // information about the problem\n if (KoaRuntimeError.isKoaError(err) && err.phase === \"request_validation\") {\n ctx.status = 400\n ctx.body = {\n message: \"request validation failed\",\n meta: err.cause instanceof ZodError ? {issues: err.cause.issues} : {},\n } satisfies t_Error\n return\n }\n // return a 500 and omit information from the response otherwise\n logger.error(\"internal server error\", err)\n ctx.status = 500\n ctx.body = {\n message: \"internal server error\",\n } satisfies t_Error\n }\n}"}},"/guides/use-with-react-query":{"title":"Using with tanstack react-query","data":{"":"Tanstack Query is a popular data fetching library for react applications. We\ndon't offer any out the box integration with it (yet), but it does integrate easily with our generated client SDKs.Here's a basic example implementation. It's not perfect, but it should give you a good starting point.","define-the-queries-and-mutations#Define the queries and mutations":"First we setup a context and define the queries / mutations we'll be making\nimport {ApiClient} from \"@/generated/clients/client\"\nimport {t_ScanRepositoriesBodySchema} from \"@/generated/models\"\nimport {\n QueryClient,\n UseMutationOptions,\n queryOptions,\n} from \"@tanstack/react-query\"\nimport {createContext, useContext} from \"react\"\nexport const QueryOptionsContext = createContext<\n ReturnType | null\n>(null)\nexport const useQueryOptions = () => {\n const v = useContext(QueryOptionsContext)\n if (!v) throw new Error(\"useQueryOptions must be used within provider\")\n return v\n}\nexport const createQueryOptions = (\n fetchClient: ApiClient,\n queryClient: QueryClient,\n) => {\n const result = {\n getSomeResource: (\n id: string,\n ) => {\n return queryOptions({\n queryKey: [\n \"getSomeResource\",\n id\n ],\n queryFn: async () => {\n const res = await fetchClient.getSomeResource({\n id,\n })\n if (res.status !== 200) {\n throw new Error(\"request failed\", {\n cause: new Error(await res.text()),\n })\n }\n return await res.json()\n },\n })\n },\n updateSomeResource: (): UseMutationOptions<\n void,\n Error,\n t_ScanRepositoriesBodySchema\n > => {\n return {\n mutationKey: [\"updateSomeResource\"],\n mutationFn: async (id: string, body: t_SomeBodyType) => {\n const res = await fetchClient.updateSomeResource({id, requestBody: body})\n if (res.status !== 204) {\n throw new Error(\"request failed\", {\n cause: new Error(await res.text()),\n })\n }\n },\n onSuccess: () => {\n void queryClient.invalidateQueries({queryKey: [\"updateSomeResource\"]})\n },\n }\n },\n }\n return result\n}","initialize-the-clients#Initialize the clients":"At the root of our application provide the context\nimport {\n QueryOptionsContext,\n createQueryOptions,\n} from \"@/app/providers/query-options\"\nimport {ApiClient} from \"@/generated/clients/client\"\nimport {QueryClient, QueryClientProvider} from \"@tanstack/react-query\"\nimport {ReactQueryDevtools} from \"@tanstack/react-query-devtools\"\nimport {ReactQueryStreamedHydration} from \"@tanstack/react-query-next-experimental\"\nimport * as React from \"react\"\nimport {useState} from \"react\"\nexport function ClientProviders(props: {children: React.ReactNode}) {\n const [queryClient] = useState(\n () =>\n new QueryClient({\n defaultOptions: {\n queries: {\n staleTime: 5_000,\n },\n },\n }),\n )\n const [fetchClient] = useState(\n new ApiClient({\n basePath: \"http://localhost:3000\",\n }),\n )\n return (\n \n \n \n {props.children}\n \n \n \n \n )\n}\nexport default function RootLayout({\n children,\n}: Readonly<{\n children: React.ReactNode\n}>) {\n return (\n \n \n \n \n \n \n {children}\n \n \n \n )\n}","use-the-queries#Use the queries":"Finally use the useQueryOptions hook in conjunction with the normal useQuery / useMutation hooks\nto make your requests\nimport {useQueryOptions} from \"@/app/providers/query-options\"\nimport {useMutation, useQuery} from \"@tanstack/react-query\"\nexport const SomeComponent = () => {\n const queryOptions = useQueryOptions()\n const someResource = useQuery(\n queryOptions.getSomeResource(\"123\"),\n )\n const doUpdate = useMutation(queryOptions.updateSomeResource())\n return
\n

{someResource.title}

\n
\n}"}},"/":{"title":"Index","data":{}},"/overview/about":{"title":"Welcome","data":{"":"@nahkies/openapi-code-generator is a CLI tool that aims to generate high quality typescript client SDK's,\nand API server scaffolding (routing, validation, serialization) from OpenAPI 3 specifications.Currently, OpenAPI 3.0, OpenAPI 3.1, and TypeSpec are supported an input specifications.This gives you amazing auto-complete, and compile-time safety. Typescript's expressive type system is used to\nmake the generated clients feel idiomatic, and as close to handwritten as possible.\nAlready know that code generation will save you time? Jump straight in with the quick start guide","server-scaffolding-templates#Server Scaffolding Templates":"Server templates handle the routing setup, request and response validation/serialization so that you\ncan focus on the business logic.\ntypescript-koa","client-sdk-templates#Client SDK Templates":"Client templates give you a strongly typed interface to your remote server calls, ensuring that you\nnever misspell a field name or route again.\ntypescript-fetch\ntypescript-axios\ntypescript-angular","project-goal--principals#Project Goal / Principals":"To make it fun, easy and productive to generate both client and server \"glue\"\ncode from openapi 3 definitions. This is code that is tedious and error-prone to maintain by hand,\nby automating it we can reduce toil and frustration.The generated code output should be \"stable\" in the sense that it will not\narbitrarily change between generation without need (for a given version). For\nexample outputting entities in alphabetic order where possible.It should also be generated in a way that human would reasonably write it,\nthe intent is that the generated code can and should be committed to the consuming project\nrepositories, allowing it to be reviewed, and audited overtime.This is particularly useful in the case of mistakes in the generation or schemas, and also\nserves to reduce risk of adoption. There should be no lock-in - if you wish to stop using the\ncode generation, you can simply start maintaining the previously generated code by hand.The initial focus on typescript, with an intention to later support other languages. kotlin\nis the most likely candidate for a second language.","compatibility--completeness#Compatibility / Completeness":"This project should be considered beta quality, though it's getting close to a v1 release.It does not yet handle all aspects of the OpenAPI / JSON schema specification, but most common\nfeatures are implemented. In particular at the moment only JSON content types are supported properly.You can get a sense of what works by looking at the compatibility tables, or the roadmap.\nHowever often the best way is to just try it out with your API specification and see what happens!The integration tests also act as a good showcase of the sort of output you can expect.","compared-to-other-projects#Compared to other projects":"There are many similar projects out there, so why should you use this one?\nStrong emphasis on \"human like\" code output\nTackles the program space from both ends - client and server, for a single source of truth\nComprehensive runtime parsing/validation in addition to static compile time safety\nSo if you want a low risk, write-once, get strong build & runtime guarantees experience then we're worth giving a try."}},"/overview/compatibility":{"title":"Compatibility Tables","data":{"":"This page aims to document which parts of the openapi 3.1.0 specification is supported.\nIt may not be totally complete / accurate, but it should be broadly correct and give you\nan understanding of what does / doesn't work.\nIf something you need isn't supported yet, please raise a Github\nissue\ndetailing your use-case, and we can work together to get support added / extended.We will also accept pull requests where implemented functionality follows the OpenAPI\nspecification,\nand the output code is of a high quality in terms of developer experience and robustness. See\nCONTRIBUTING.md\nto get started","tldr#tldr;":"Most common functionality used by JSON based APIs should work.\nGreat support for paths using application/json request / response bodies\nComprehensive support for most schema properties, including json validation stuff like minLength,\nbut only for json content types. Notable exceptions:\nreadonly is currently implemented incorrectly\ndiscriminator is ignored, but union / intersection types will be generated based on anyOf / allOf so\nthis isn't often an issue in practice\nNo support for security schemes, you'll need to fudge these as header parameters, or implement out-of-band\nfor the specification for now.\nNo support for webhooks / callbacks yet","legend#Legend":"Symbol\tMeaning\t✅/🚧\tSupported in some way. May be incomplete\t🚫\tNot supported, likely to be supported eventually\tN/A\tIgnored, unlikely to be used for anything","root-openapi-object#Root OpenAPI Object":"Root object of openapi documents. A ✅ means at least some support for this field - click through to the table\nfor each attribute for further details.\nAttribute\tSupported\tNotes\topenapi\t✅\tEither 3.1.x or 3.0.x is supported\tinfo\tN/A\tIgnored\tjsonSchemaDialect\t🚫\tNot yet supported\tservers\t✅\tUsed by client SDK templates\tpaths\t✅\t\twebhooks\t🚫\tNot yet supported. Emulate by defining as normal paths.\tcomponents\t✅\t\tsecurity\t🚫\tNot yet supported. Implement out of band or using header parameters.\ttags\t✅\tOptionally used to split output into multiple files\texternalDocs\tN/A\tIgnored","sub-objects#Sub-objects":"","reference-object#Reference Object":"Reference objects are supported to be used in place of the actual object definition anywhere in the documents.\nThey can also cross files (and maybe urls - needs testing).\nIt's recommended to use $ref objects as much as possible. It both promotes re-use, and also allows control\nover the naming of the type / schema in the generated code.\nExample:\n requestBody:\n required: true\n content:\n application/json:\n schema:\n $ref: \"#/components/schemas/ExampleSchema\"\nAttribute\tSupported\tNotes\t$ref\t✅\t$ref support is robust, and works correctly across multiple input files.\tsummary\tN/A\tIgnored\tdescription\tN/A\tIgnored","server-object#Server Object":"Used by the client SDKs to generate builders for basePath's and override parameters.See servers object guide for detailed explanation\nof how this is handled.\nAttribute\tSupported\tNotes\turl\t✅\tOptionally used to type client SDK basePath configuration\tdescription\tN/A\tIgnored\tvariables\t✅","components-object#Components Object":"Technically you can define any \"components\" you like, and $refs to them will work, regardless\nof if they appear in the official specification.The table indicates what will actually typically be used for anything right now.\nAttribute\tSupported\tNotes\tschemas\t✅\t\tresponses\t✅\t\tparameters\t✅\t\texamples\tN/A\t\trequestBodies\t✅\t\theaders\t✅\t\tsecuritySchemes\t🚫\tNot yet supported\tlinks\t🚫\tNot yet supported\tcallbacks\t🚫\tNot yet supported\tpathItems\t✅","paths-object#Paths Object":"Paths are well supported.\nAttribute\tSupported\tNotes\t{path}\t✅","path-item-object#Path Item Object":"All common http methods are supported.\nAttribute\tSupported\tNotes\tsummary\tN/A\tIgnored\tdescription\tN/A\tIgnored\tget\t✅\t\tput\t✅\t\tpost\t✅\t\tdelete\t✅\t\thead\t✅\t\tpatch\t✅\t\ttrace\t🚫\tNot yet supported\tservers\t✅\tUsed by client SDK templates\tparameters\t✅","operation-object#Operation Object":"Most things are supported. It's recommended you supply an operationId as otherwise\none will be generated from the path / http method, which is often overly verbose.\nAttribute\tSupported\tNotes\ttags\t✅\tOptionally used to split output into multiple files\tsummary\tN/A\tIgnored\tdescription\tN/A\tIgnored\texternalDocs\tN/A\tIgnored\toperationId\t✅\tUsed to generate names on types / methods / interfaces\tparameters\t✅\t\trequestBody\t✅\t\tresponses\t✅\t\tcallbacks\t🚫\tNot yet supported\tdeprecated\t🚫\tNot yet supported\tsecurity\t🚫\tNot yet supported\tservers\t✅\tUsed by client SDK templates","parameter-object#Parameter Object":"Whilst attributes like style and explode are not yet supported, for most common parameter use-cases\neverything should just work as you'd guess/expect.\nAttribute\tSupported\tNotes\tname\t✅\t\tin\t✅/🚧\tEverything supported apart from \"cookie\".\tdescription\tN/A\tIgnored\trequired\t✅\t\tdeprecated\tN/A\tIgnored\tallowEmptyValue\t🚫\tUse schema minLength: 1 to prevent empty string values in query parameters\tstyle\t🚫\tNot yet supported\texplode\t🚫\tNot yet supported\tallowReserved\t🚫\tUse schema pattern to emulate\tschema\t✅\t\texample\tN/A\tIgnored\texamples\tN/A\tIgnored\tcontent\t🚫\tNot yet supported","request-body-object#Request Body Object":"Well-supported for application/json content types. Support for form data, and file uploads, etc\nplanned to come soon.\nAttribute\tSupported\tNotes\tdescription\tN/A\tIgnored\tcontent\t✅/🚧\tOnly media types of application/json work properly.\trequired\t✅","media-type-object#Media Type Object":"Attribute\tSupported\tNotes\tschema\t✅\t\texample\tN/A\tIgnored\texamples\tN/A\tIgnored\tencoding\t🚫\tNot yet supported","responses-object#Responses Object":"Well supported.\nAttribute\tSupported\tNotes\tdefault\t✅\t\t{http-status-code}\t✅","response-object#Response Object":"Generally well-supported for application/json content types.\nAttribute\tSupported\tNotes\tdescription\tN/A\tIgnored\theaders\t🚫\tNot yet supported\tcontent\t✅/🚧\tOnly media types of application/json work properly.\tlinks\t🚫\tNot yet supported","header-object#Header Object":"Attribute\tSupported\tNotes\tdescription\tN/A\tIgnored\tschema\t✅\tComplex schemas for headers may not work. Stick to string / number if possible.","tag-object#Tag Object":"Tags are only used for code organization purposes, when passing the --grouping-strategy first-tag\nCLI option.\nAttribute\tSupported\tNotes\tname\t✅\tOptionally used to split output into multiple files\tdescription\tN/A\tIgnored\texternalDocs\tN/A\tIgnored","schema-object#Schema Object":"The majority of attributes that can be specified by schema objects are supported, and accurately match the underlying\nopenapi specification / json schema validation specifications.Most notable exception is readOnly / writeOnly which are currently implemented incorrectly, planned to be addressed\nas a breaking change prior to v1.\nAttribute\tSupported\tNotes\ttitle\tN/A\t\tmultipleOf\t✅\tApplies to type: number\tmaximum\t✅\tApplies to type: number\texclusiveMaximum\t✅\tApplies to type: number\tminimum\t✅\tApplies to type: number\texclusiveMinimum\t✅\tApplies to type: number\tmaxLength\t✅\tApplies to type: string\tminLength\t✅\tApplies to type: string\tpattern\t✅\tSupport for type: string\tmaxItems\t✅\tApplies to type: array\tminItems\t✅\tApplies to type: array\tuniqueItems\t✅\tApplies to type: array\tmaxProperties\t🚫\tNot yet supported\tminProperties\t🚫\tNot yet supported\trequired\t✅\tControls whether undefined is allowed for each value in properties\tenum\t✅\tApplies to type: number and type: string\ttype\t✅\t\tnot\t🚫\tNot yet supported\tallOf\t✅\tProduces a intersection type like A & B\toneOf\t✅\tProduces a union type like A | B\tanyOf\t✅\tProduces a union type like A | B\titems\t✅\tApplies to type: array\tproperties\t✅\tApplies to type: object\tadditionalProperties\t✅/🚧\tFairly comprehensive support, produces Record or unknown/any (dependent on --ts-allow-any)\tformat\t✅/🚧\tLimited support for format email and date-time\tdefault\t✅\t\tnullable\t✅\tAlso supports type: null as an alternative\tdiscriminator\t🚫\tIgnored. Union / Intersection types are usd based on anyOf / allOf / oneOf.\treadOnly\t🚫\tProduces readonly modifiers, but this behavior is incorrect\twriteOnly\t🚫\tNot yet supported\texample\tN/A\tIgnored\texternalDocs\tN/A\tIgnored\tdeprecated\t🚫\tNot yet supported\txml\t🚫\tNot yet supported","completely-unsupported-things#Completely unsupported things":"The following objects are completely unsupported at this stage.","encoding-object#Encoding Object":"Attribute\tSupported\tNotes\tcontentType\t🚫\tNot yet supported\theaders\t🚫\tNot yet supported\tstyle\t🚫\tNot yet supported\texplode\t🚫\tNot yet supported\tallowReserved\t🚫\tNot yet supported","callback-object#Callback Object":"The callback object is completely unsupported.\nAttribute\tSupported\tNotes\t\\{expression\\}\t🚫","link-object#Link Object":"The link object is completely unsupported.\nAttribute\tSupported\tNotes\toperationRef\t🚫\t\toperationId\t🚫\t\tparameters\t🚫\t\trequestBody\t🚫\t\tdescription\tN/A\t\tserver\t🚫","discriminator-object#Discriminator Object":"The discriminator object is completely unsupported.\nAttribute\tSupported\tNotes\tpropertyName\t🚫\t\tmapping\t🚫","xml-object#XML Object":"The XML object is completely unsupported.\nAttribute\tSupported\tNotes\tname\t🚫\t\tnamespace\t🚫\t\tprefix\t🚫\t\tattribute\t🚫\t\twrapped\t🚫","security-scheme-object#Security Scheme Object":"The security scheme object is completely unsupported.\nAttribute\tSupported\tNotes\ttype\t🚫\t\tdescription\t🚫\t\tname\t🚫\t\tin\t🚫\t\tscheme\t🚫\t\tbearerFormat\t🚫\t\tflows\t🚫\t\topenIdConnectUrl\t🚫","oauth-flows-object#OAuth Flows Object":"The oauth flows object is completely unsupported.\nAttribute\tSupported\tNotes\timplicit\t🚫\t\tpassword\t🚫\t\tclientCredentials\t🚫\t\tauthorizationCode\t🚫","oauth-flow-object#OAuth Flow Object":"The oauth flow object is completely unsupported.\nAttribute\tSupported\tNotes\tauthorizationUrl\t🚫\t\ttokenUrl\t🚫\t\trefreshUrl\t🚫\t\tscopes\t🚫","security-requirement-object---patterned-fields#Security Requirement Object - Patterned Fields":"The security requirement object is completely unsupported.\nAttribute\tSupported\tNotes\t\\{name\\}\t🚫"}},"/overview/roadmap":{"title":"Roadmap","data":{"":"This is a very loosely ordered view of known things that are planned in the roadmap. It's probably not exhaustive.","near-term---sometime-in-the-next-6-months#Near-term - \"Sometime in the next 6 months\"":"These are broadly speaking the known blockers to doing the first v1 release.\nThe project was started approximately July\n2020, over 4\nyears ago.It'd be really nice to get to a v1 / stable release before it turns 5 years old 😅, so we'll aim for this to happen\napproximately Q1/Q2 of 2025.","support-multipartform-data-file-uploads#Support multipart/form-data (file uploads)":"Currently only application/json request bodies are supported properly.This is particularly problematic when wanting to upload files, such as images\nor videos.Adding multipart/form-data support will aim to solve this.ref: https://spec.openapis.org/oas/v3.1.1.html#considerations-for-file-uploads","support-response-headers#Support response headers":"It's common for important metadata, such as rate limit information to be\ncommunicated using response headers.At the moment this information is lost during code generation, adding support\nwill mean that it is typed and validated at runtime.ref: https://spec.openapis.org/oas/v3.1.1.html#response-object","support-cookie-parameters#Support cookie parameters":"Cookies are often used to store small pieces of information to be sent on every\nrequest. These are currently ignored, but should be supported.","review-handling-of-parameter-style#Review handling of parameter style":"Review and improve the way that parameter style is interpreted.ref: https://spec.openapis.org/oas/v3.1.1.html#style-values","fix-interpretation-of-readonly--writeonly#Fix interpretation of readOnly / writeOnly":"The meaning of these attributes was incorrectly interpreted and implemented. Changing this will\nbe a breaking change, so this should be revisited prior to v1.","clean-up--rethink-cli-options#Clean up / rethink CLI options":"As the number of CLI options has grown, it's been a bit confusing around when options are/aren't\nused, and it's not super clear how languages other than typescript might be introduced.We should have a rethink of this, and probably separate client sdk vs server stubs in the option\nstructure to make it clear when args are applicable.It may be difficult to maintain backwards compatibility, but if possible then we should.","mid-term---hopefully-in-the-next-year#Mid-term - \"Hopefully in the next year\"":"These are items that are nice to have, but generally not breaking and therefore not blocking for a v1\nrelease. There's a decent chance that many of these will beat a v1 release still.","implement-a-typescript-express-template#Implement a typescript-express template":"express is probably still the most popular\nweb framework for nodejs, with approximately 10x more weekly downloads than koaIt's also pretty similar in design to koa, and so it should low-effort to add a\ntemplate for it.This would be beneficial in terms of making the project useful to a wider userbase,\nbut also be a forcing function to tidy up the koa template code, and abstract it in\na similar way to the client templates are.","complete-an-interactive-playground#Complete an interactive playground":"Many tools of this genre offer an interactive playground on their documentation sites,\nto better communicate the tools purpose and features.An interactive playground PR has been up for a while, https://github.com/mnahkies/openapi-code-generator/pull/216\nbut it turns out these are hard to build, and it needs some more effort to get over the line.","support-custom-serializationdeserialization#Support custom serialization/deserialization":"Sometimes you want to serialize or deserialize objects in a custom way. Good examples\nmight be parsing date-time strings as a moment / Instant instead of the native Date,\nor parsing a uuid string to a first class Uuid type.https://github.com/mnahkies/openapi-code-generator/pull/220 starts to explore this idea,\nand how we could potentially make use of a custom extension to facilitate this use-case.","implement-a-typescript-next-template#Implement a typescript-next template":"next.js is a popular framework for building site using react.\nAn experimental template has been up here https://github.com/mnahkies/openapi-code-generator/pull/152\nfor months, but it needs some effort to really nail the user experience.This is coming after an typescript-express template, as producing the former will\nnecessitate several important refactorings that will make this easier to achieve.","explore-test-framework-integrations#Explore test framework integrations":"nock is a popular library for mocking http requests\nin test suites. What would an integration with nock look like? Or maybe mock service worker?Could we leverage examples to create fixture factories?","support-security-schemas#Support Security Schemas":"At the moment we ignore security schemas, and expect the user to handle this themselves\nout of band of the code generation.For example by mounting a custom authentication middleware for Koa servers, or passing\nan Authorization header for client SDKs.It would be good to investigate how to improve things using declared security schemes.ref: https://spec.openapis.org/oas/v3.1.1.html#security-scheme-object-0","long-term---one-day#Long-term - \"One Day\"":"This is a set of possible future enhancements, generally covering more niche/uncommon parts\nof the OpenAPI standard, that we might implement one day.Whilst these are lower down the list due to being uncommon (often appearing 0 times in the range of\nintegration tests we currently run), there's also an argument to be made that unless tooling steps up\nto support these features, then adoption will remain low, and so support should be added regardless.","support-xml#Support XML":"Whilst JSON has broadly gained popularity over XML as a markup for HTTP requests,\nXML isn't dead. It would be good to support it, especially for client SDK's where\na server might not support JSON.ref: https://spec.openapis.org/oas/v3.1.1.html#xml-object","support-webhooks#Support webhooks":"The webhooks object is a new way to declare webhooks in 3.1. We should investigate\nsupporting it.ref: https://learn.openapis.org/examples/v3.1/webhook-example.html","support-links#Support links":"The links object on responses is an interesting mechanism to declare relationships\nbetween operations, and how to traverse these, using a static declaration.It essentially allows you to specify a mapping of properties from one request, to be\nparameters for another request. Eg: $request.path.idWhilst interesting, it's also uncommon - currently there isn't a single usage of this\nfeature in the specifications we use for our integration tests.ref: https://spec.openapis.org/oas/v3.1.1.html#link-object","support-callbacks#Support callbacks":"The callbacks field of an operation is similar to the links response object, in that\nit provides a way to specify callbacks related to an operation.Much like links, it's uncommon to see this used in practice, without a single callbacks\nobject defined in any specifications we see.ref: https://spec.openapis.org/oas/v3.1.1.html#callback-object"}},"/reference/cli-options":{"title":"CLI Options","data":{"cli-configuration-reference#CLI Configuration Reference":"All CLI options can be provided as command-line parameters, or environment variables as you prefer.","generate#Generate":"The default action is to run code generation.","required-parameters#Required Parameters":"","-i---input-value#-i --input ":"As environment variable OPENAPI_INPUTPath to the input specification to generate from. Either a local path, or a url may be provided, though not all\nspecifications will build correctly from a url.By default, this must be a OpenAPI 3.0 or OpenAPI 3.1\nspecification, in either YAML or JSON format.When used in conjunction with --input-type typespec then a TypeSpec specification can be\nsupplied instead.","-o---output-value#-o --output ":"As environment variable OPENAPI_OUTPUTdirectory to output generated code (env: )","-t---template-value#-t --template ":"As environment variable OPENAPI_TEMPLATEWhich template you wish to generate, one of:\ntypescript-koa\ntypescript-fetch\ntypescript-axios\ntypescript-angular","optional-parameters#Optional Parameters":"","--input-type-value#--input-type ":"As environment variable OPENAPI_INPUT_TYPEWhat type of input file is being provided, one of:\nopenapi3 (default)\ntypespec","--override-specification-title-value#--override-specification-title ":"As environment variable OPENAPI_OVERRIDE_SPECIFICATION_TITLEAllows overriding the info.title field of the input OpenAPI document. This field is used to generate\nsome symbol names, and so this is useful when you don't directly control the source specification, and\nwish to customize the output symbol names.","-s---schema-builder-value#-s --schema-builder ":"As environment variable OPENAPI_SCHEMA_BUILDERWhich runtime schema parsing library to use, one of:\nzod (default)\njoi","--grouping-strategy-value-experimental#--grouping-strategy (experimental)":"As environment variable OPENAPI_GROUPING_STRATEGYStrategy to use for splitting output into separate files. Set to none for a single generated.ts file, one of:\nnone don't split output, yield single generated.ts (default)\nfirst-tag group operations based on their first tag\nfirst-slug group operations based on their first route slug/segment","--enable-runtime-response-validation-experimental#--enable-runtime-response-validation (experimental)":"As environment variable whether to validate response bodies using the chosen runtime schema library.Default false\nNote: this is currently always true for server templates, and only applies to the client library templates.","--enable-typed-base-paths-client-sdks-only#--enable-typed-base-paths (client sdks only)":"As environment variable OPENAPI_ENABLE_TYPED_BASE_PATHSControls whether to generate a URL builder from the openapi specifications\narray of server urls and placeholder variables.When disabled a plain string type is used for these parameters.See servers object guide for detailed explanation\nof how this is handled.Default: true","--extract-inline-schemas-experimental#--extract-inline-schemas (experimental)":"As environment variable OPENAPI_EXTRACT_INLINE_SCHEMASGenerate names based on usage, and extract in-line schemas to be standalone types / schemas in the\ngenerated code. This is especially useful when dealing with input schemas that don't make good use\nof named $ref's.See extract-inline-schemas guide for details of how this works.Default false","--allow-unused-imports#--allow-unused-imports":"As environment variable OPENAPI_ALLOW_UNUSED_IMPORTSAllow unused imports to be emitted in generated code. Offered as an escape hatch if any bugs\nin the unused-import elimination occur.Default false","--ts-allow-any#--ts-allow-any":"As environment variable OPENAPI_TS_ALLOW_ANYDetermines whether to use any or unknown when generating types for schemas that don't have\nconcrete definitions. Eg: additionalProperties: true or {} schemas.Using unknown will push you towards using type guards / making runtime checks before interacting\nwith the model and should generally result in more robust code, whilst any may be more convenient\nduring rapid prototyping.Default: false (use unknown rather than any)\nInput schema\t--ts-allow-any\t(default)\t{}\tany\tunknown\t{additionalProperties: true}\tany\tunknown\t{additionalProperties: false}\t{ [key: string]: never }\t{ [key: string]: never }\t{type: \"object\", additionalProperties: true}\t{[key: string]: any}\t{[key: string]: unknown}\t{type: \"array\", items: {}}\tany[]\tunknown[]","--ts-server-implementation-method-experimental-server-sdks-only#--ts-server-implementation-method (experimental) (server sdks only)":"As environment variable OPENAPI_TS_SERVER_IMPLEMENTATION_METHODDetermines whether to represent server stubs / interfaces as type, interface, or abstract class entities.This is mostly a case of personal preference, but can be important for better integration with dependency injection\nframeworks, such as diod which rely on abstract class objects to define\ninterfaces for injection.\nOption\tExample Output\tinterface\texport interface Implementation { ... } `\ttype\texport type Implementation = { ... }\tabstract-class\texport abstract class Implementation { ... }\t\nDefault: type","--filename-convention-value#--filename-convention ":"As environment variable OPENAPI_FILENAME_CONVENTIONDetermines which naming convention to use for dynamically generated filenames\n(eg: those generated from tags or route prefixes).\nValue\tExample Filename\tkebab-case\tmy-file.ts\tcamel-case\tmyFile.ts\ttitle-case\tMyFile.ts\tsnake-case\tmy_file.ts\t\nDefault: kebab-case","misc#Misc":"","--remote-spec-request-headers-authenticated-remote-specifications#--remote-spec-request-headers (authenticated remote specifications)":"As environment variable OPENAPI_REMOTE_SPEC_REQUEST_HEADERSAllows providing request headers to use when fetching remote specifications. This allows for running\ngeneration against remote sources that require authentication.See authenticated-input-specifications guide for\ndetails of how to use.","-h---help#-h, --help":"Displays help text for command"}},"/reference/release-notes":{"title":"Release notes","data":{"":"This page is statically generated from the Github releases,\nand may sometimes be slightly out of date.","2-nov-2024-v0160#2 Nov 2024 (v0.16.0)":"Client class exports will now be given unique names generated from the input specifications info.title field. This can additionally be overridden through a new cli arg --override-specification-title.The previous generic exports are kept for backwards compatibility.POTENTIALLY BREAKING: Filenames generated from tags or route prefixes will now follow kebab-case naming convention by default. This can be customized to other conventions like camel-case, etc using --filename-conventionFeatures\nfeat: unique client export names by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/263\nfeat!: dynamic filename conventions / no spaces in filenames by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/259\nfeat: safer identifier transformation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/260\nMisc\nfix: format/emit in parallel by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/265\nchore: upgrade to next@15 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/261\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/262\nchore: refresh data + regenerate by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/264\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.15.0...v0.16.0","27-oct-2024-v0150#27 Oct 2024 (v0.15.0)":"It's now possible to change the construct used for the \"implementation\" symbol between being a type, interface or abstract class using the new option --ts-server-implementation-method. This is particularly useful if using a dependency injection library that requires abstract class as part of its wiring approach.Additionally, when splitting the generated files by first-tag / first-slug (using --grouping-strategy), the tag/slug will now be added to the exported symbol names, eg: createRouter -> createMyTagRouter and Implementation -> MyTagImplementation. This can reduce the need to alias imports manually.The generic Implementation / createRouter exports have be retained to keep this backwards compatible.Features\nfeat: support emitting abstract classes for implementation types by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/256\nfeat: emit unique symbol names for Implementation / createRouter functions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/258\nMisc\nfix(docs): improve meta tags by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/255\nchore: dependencies / refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/257\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.14.0...v0.15.0","12-oct-2024-v0140#12 Oct 2024 (v0.14.0)":"Fixes a few small bugs, and adds support for relative $refs when using a URI as the input.Features\nfeat: support loading relative remote uris by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/254\nBug fixes\nfix: allow $ref to be used as a schema property by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/250\nfix: handle type: \"null\" in anyOf / oneOf / allOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/252\nMisc\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/251\nfix(docs): use absolute url for og:image by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/253\nchore(docs): switch to self-hosted plausible ce by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/249\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.13.0...v0.14.0","20-sept-2024-v0130#20 Sept 2024 (v0.13.0)":"This release adds support for schemas specifying default values, and begins validating / parsing incoming request headers. Note: this may be a breaking change if your server currently accepts requests with invalid request headers.Features\nfeat: support default values by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/241\nfeat!: parse/validate request headers by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/247\nfeat: include urls from servers array in basePath type by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/246\nDocs\ndocs: add compatibility tables by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/248\nMisc\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/239\nchore(deps): Bump micromatch from 4.0.7 to 4.0.8 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/240\nchore: update dependencies and refresh data files by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/244\nchore: upgrade typescript by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/245\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.12.1...v0.13.0","17-aug-2024-v0121#17 Aug 2024 (v0.12.1)":"This release fixes a small typing mistake preventing queries parameters of type number[] from building properly, and fixes bugs in the handling of header parameters / defaults and the \"escape hatch\" parameters allowing arbitrary fetch / axios request options to be passed.It's also the first release with automated end-to-end tests in place, though the coverage is still low - this will be improved during the course of development going forward.Bug fixes\nfix: allow number array query param by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/236\nfix(fetch/axios): correctly merge headers from opts by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/231\nTesting\nfeat: add e2e test suite by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/235\nMisc\nchore(deps): update dependency axios to v1.7.4 [security] by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/232\nchore: dependencies / refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/233\nchore: tweak npm metadata by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/234\nchore: use node 22 by default by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/237\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.12.0...v0.12.1","5-aug-2024-v0120#5 Aug 2024 (v0.12.0)":"Another small release, adding a new CLI parameter OPENAPI_REMOTE_SPEC_REQUEST_HEADERS / --remote-spec-request-headers that allows request headers to be sent when fetching specifications from remote URI's.This makes it possible to generate from a remote URI that is behind some form of header based authentication, eg: Authorization: Bearer (which includes cookie based authentication since cookies are just a Cookie header, and basic auth as this is just Authorization: Basic ).The headers are scoped to specific domains/urls such that you can mix and match sources without leaking tokens to the wrong servers.Features\nfeat: support remote specs with authentication by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/230\nMisc\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/228\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.11.2...v0.12.0","29-jul-2024-v0112#29 Jul 2024 (v0.11.2)":"This is a bug fix release, solving an issue with the order schemas were output when generating from specifications that are split over multiple files, causing variable used before declaration issues.Bug fixes\nfix: include schemas from all documents in dependency graph by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/227\nDocumentation\nfix: improve seo, use plausible by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/226\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.11.1...v0.11.2","27-jul-2024-v0111#27 Jul 2024 (v0.11.1)":"This is a bug fix release, containing a solution for https://github.com/mnahkies/openapi-code-generator/issues/217.Previously query parameters of an array type did not work when a single element was provided, now this will be parsed and handed to the route handler as an array of one element.Bug fixes\nfix: support array of 1 for query parameter arrays (round 2) by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/225\nMisc\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/210\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/221\nchore: refresh data / use new okta specs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/222\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/223\nfix: peer dependency by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/224\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.11.0...v0.11.1","8-jun-2024-v0110#8 Jun 2024 (v0.11.0)":"This release contains 1 bug fix for default header handling in typescript-axios and several internal refactoring changes required to facilitate the work-in-progress documentation playgroundAlso dropped eslint for biome because I can't be bothered figuring out the eslint@^9 upgrade / configuration migration.Bug fixes\nfix(axios): always apply default headers by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/218\nInternal refactoring\nfix: make logger compatible with web by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/211\nfix: decouple validator from readline by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/212\nfeat: add a prettier based formatter by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/213\nfix: move tsconfig loading by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/214\nfix: decouple typespec loader from readline by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/215\nMisc\nchore: ditch eslint by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/219\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.10.0...v0.11.0","25-may-2024-v0100#25 May 2024 (v0.10.0)":"This release is primarily bug fixes, and internal refactoring to facilitate improvements to documentation. Most effort has gone into the new documentation site live at https://openapi-code-generator.nahkies.co.nz/It also splits the cli from the library entrypoint such that you can now import {generate} from '@nahkies/openapi-code-generator' for programmatic usage if you wish, and improves handling of boolean cli flags.BREAKING CHANGES\nThere are several potentially breaking changes here:\nDropped the \"safe edit region\" functionality, I doubt anyone was using this and it wasn't particularly robust\nImproved handling of additionalProperties / {} schemas to better align with the specification\nJoi validation became stricter for strings with format email / date-time\nThis may make some schemas / types change type to unknown, and start serializing/deserializing values that were previously stripped (see #200). If you want more permissive types (any) in these situations rather than unknown you can use the --ts-allow-any cli flag.Bug fixes\nfix!: an schema should be an unknown/any type by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/204\nfix!: drop safe edit regions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/198\nfix!: joi supports email / date-time string formats by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/206\nfix: improve handling of cli boolean params by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/205\nfix: only allow publish of releases from latest main by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/161\nInternal refactoring\nrefactor: create TypescriptFormatter class by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/199\nrefactor: isolate filesystem interaction by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/201\nrefactor: split cli to allow programmatic use by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/202\nDocs\nfeat: new documentation website by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/162\nfeat: publish docs from ci, add ga to docs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/163\nfix: provide a user by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/164\nfix: try git config by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/165\nfix: set url by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/166\nfix: move script to _app by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/167\nfix: replace default nextra meta descriptions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/168\ndocs: show typespec shell snippets, mention runtime response validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/169\ndocs: move architecture into nextra site by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/186\ndocs: update readme by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/187\nfix(docs): correct header level by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/209\nMisc\nchore: upgrade dependencies / angular v18 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/207\nchore: refresh data and regenerate by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/208\nchore: bump lerna by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/203\nfix: make renovate less noisy by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/197\nchore: Configure Renovate by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/170\nchore(deps): update dependency @azure-tools/typespec-client-generator-core to v0.41.8 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/171\nchore(deps): update dependency @types/node to v20.12.8 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/172\nfix(deps): update angular monorepo by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/175\nchore(deps): update dependency typescript to ~5.4.0 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/180\nchore(deps): update dependency node to v20.12.2 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/179\nchore(deps): update yarn to v4.2.1 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/182\nchore(deps): update dependency zod to v3.23.6 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/174\nchore(deps): update typescript-eslint monorepo to v7.8.0 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/181\nfix(deps): update dependency ajv to v8.13.0 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/183\nchore(deps): update dependency eslint-plugin-jest to v28.5.0 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/178\nfix(deps): update dependency @biomejs/biome to v1.7.2 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/176\n@renovate made their first contribution in https://github.com/mnahkies/openapi-code-generator/pull/170\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.9.0...v0.10.0","27-apr-2024-v090#27 Apr 2024 (v0.9.0)":"There are two new features in this release:\nTypespec can now be used as an input file by passing --input-type=typespec as an additional arg\nYou can now use a url for your input file (openapi specs only, typespec must be local files)\nFeatures\nfeat: support typespec as an input format by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/158\nfeat: support loading input from uri by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/150\nBug fixes\nfix: allow options by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/151\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.8.0...v0.9.0","7-apr-2024-v080#7 Apr 2024 (v0.8.0)":"There are three main features in this release:\nImprove json schema validation support for string, number, array (min / max / etc)\nMake boolean schema validation stricter\nStart using a pre-compiled ajv validator for better performance\nBREAKING CHANGES\nPreviously any truthy value would be accepted for a boolean, eg: any-string would parse to true. Now its parsed like:\ntrue | \"true\" | 1 -> true\nfalse | \"false\" | 0 -> false\nanything else -> error\nFeatures\nfeat: support minimum / maximum for numbers by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/140\nfeat: use pre-compiled ajv validators at runtime by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/141\nfeat: joi number min/max validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/143\nfeat: support exclusive min/max and multipleOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/144\nfeat: support string validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/145\nfix!: stricter booleans by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/146\nfeat: support basic array validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/147\nMisc\nchore(deps): Bump follow-redirects from 1.15.5 to 1.15.6 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/136\nchore(deps): Bump webpack-dev-middleware from 5.3.3 to 5.3.4 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/137\nchore(deps): Bump express from 4.18.3 to 4.19.2 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/138\nchore: deps by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/139\nchore: refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/142\nchore: bump deps by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/149\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.7.0...v0.8.0","3-mar-2024-v070#3 Mar 2024 (v0.7.0)":"Features\nfeat: experimental support for splitting code by tags / route segments by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/134\nfeat: eliminate unused imports by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/132\nfeat: use strict typescript settings by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/131\nfeat: adopt biome for code formatting by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/129\nMisc\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/133\nchore(deps): Bump ip from 2.0.0 to 2.0.1 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/130\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.6.0...v0.7.0","19-feb-2024-v060#19 Feb 2024 (v0.6.0)":"Features\nfeat: improve additional properties support by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/126\nfeat: support response validation for joi by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/127\nMisc\nchore: adopt prettier everywhere by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/128\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.5.0...v0.6.0","10-feb-2024-v050#10 Feb 2024 (v0.5.0)":"Features\nfeat: experimental support for extracting inline schemas by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/123\nfeat: client generators support experimental runtime response validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/112\nMisc\ndocs: tiny improvement by @asfaltboy in https://github.com/mnahkies/openapi-code-generator/pull/122\nchore: update deps / use RouterContext by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/124\nUpgrading notes\nYou may need to replace the Context type from koa with RouterContext from @koa/router in some cases due to changes in the upstream type definitions.\n@asfaltboy made their first contribution in https://github.com/mnahkies/openapi-code-generator/pull/122\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.4.0...v0.5.0","5-jan-2024-v040#5 Jan 2024 (v0.4.0)":"feat(typescript-koa): introduce optional \"respond\" pattern by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/96\nBugs\nfix: incorrect .d.ts path for zod by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/119\nfix(koa): don't camel-case route placeholders by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/120\nMisc\nchore(deps-dev): Bump @koa/cors from 4.0.0 to 5.0.0 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/116\nchore: bump deps by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/121\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.3.0...v0.4.0","2-dec-2023-v030#2 Dec 2023 (v0.3.0)":"feat: add typescript-axios template by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/83\nfeat!: throw discriminable errors indicating point of failure by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/95\nBreaking Changes\nErrors thrown during request handling in typescript-koa will now be wrapped in KoaRuntimeError objects with the original exception included as the cause, in order to provide additional context about where the error was thrown.Misc\nfix: decouple schema builders from typescript-koa by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/113\nfeat: include schema builder in client generators by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/114\nchore: upgrade angular / dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/115\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.2.0...v0.3.0","12-nov-2023-v020#12 Nov 2023 (v0.2.0)":"Features\nfeat: basic support for openapi 3.1 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/109\nBug Fixes\nfix: skip broken openapi 3.1 validation for now by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/104\nfix: allow numeric header values by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/105\nfix: handle null in enums by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/106\nfix: handle \" in string enum values by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/107\nfix: use numerical enums when creating zod schema by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/108\nfix: optional oneOf / allOf / anyOf / $ref's by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/110\nMisc\nchore: refresh lockfile by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/100\nchore: use branch as preid / dist-tag on alpha versions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/101\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.1.1...v0.2.0","11-nov-2023-v011#11 Nov 2023 (v0.1.1)":"Breaking changes\nfeat!: more flexible koa server creation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/88\nFixes\nfix: don't coerce strings by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/87\nMisc\nchore(deps): bump @babel/traverse from 7.22.19 to 7.23.2 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/85\nchore(deps): Bump zod from 3.22.2 to 3.22.3 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/86\nchore: yarn 4, @swc/jest by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/89\nstyle: comma-dangle always-multiline by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/91\nchore: move generated files into a generated sub-directory by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/92\nfix: delete files missed in #92 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/93\nfix: unused imports by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/97\nfix: avoid warning for non-nullable paths by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/90\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.1.0...v0.1.1","1-oct-2023-v010#1 Oct 2023 (v0.1.0)":"Initial Release.\nchore: refresh dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/1\nfix(typescript-fetch): omit optional query params by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/2\nchore: switch source of GitHub defs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/3\nfeat: add script consuming github fetch client by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/4\nfeat: support zod for parsing inputs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/7\nchore(deps): bump ua-parser-js from 0.7.32 to 0.7.33 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/5\nchore(deps): bump http-cache-semantics from 4.1.0 to 4.1.1 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/6\nfeat: support string enums in zod parsing by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/8\nfeat: new approach to server stubs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/9\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/10\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/15\nchore: upgrade to yarn berry by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/16\nchore: add lint-staged / husky, improve lint cmd by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/17\ndocs: add table of contents / format by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/18\nchore: switch from mocha/chai to jest by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/19\nfeat: move static code to normal files by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/20\nfeat: move more static code into koa runtime by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/21\nfix: respect optional $ref properties by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/22\nfeat: initial support for oneOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/23\nfix: request bodies can be optional by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/24\nfeat: rework input schema parsing by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/25\nrefactor: several tidy ups by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/26\nfeat: zod schema builder supports allOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/27\nfix: use merge instead of intersection by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/28\nfeat: response body validation and types by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/29\nfix: eslint disable in generated files by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/30\nfix: use request body by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/32\nfix: improve support for nullable types by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/33\nfix: improve validation to switch between 3.1.0 / 3.0.0 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/34\nfeat: improve client generation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/35\nfeat: clients default params to when none are required by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/36\nfeat: order schemas correctly by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/37\nchore: update github definition by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/31\nrefactor: move schema builders to common, rename model builder by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/38\nfeat: config flag to switch schema parser by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/39\nfix: improve null support by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/40\nrefactor: simplify by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/41\nrefactor: consistently use yaml instead of yml by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/47\nchore: refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/48\nfix: replace . in identifiers by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/50\nchore: review todos and create tickets for most by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/54\nfeat: initial support for anyOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/55\nfix: switch to qs and add tests for query string by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/56\nfeat: better support for additional properties by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/57\nfeat: support circular references by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/58\ntests: add stripe api definitions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/49\nchore(deps): bump engine.io from 6.4.1 to 6.4.2 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/61\nchore: upgrade to angular v16 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/62\nfix: surface status code -> body relationship in angular template by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/63\nchore: update data and regenerate by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/64\nfeat: fetch client supports abort signals by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/65\nchore(deps): bump socket.io-parser from 4.2.2 to 4.2.3 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/66\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/69\nchore: upgrade prettier by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/70\nchore: refresh yarn lock by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/71\nfix: dependency graph handles oneOf allOf nesting by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/73\nchore: refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/72\nchore: add okta api specs as tests by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/74\nfix: master -> main by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/77\nfeat: use commander for cli args for better ux by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/76\nchore: refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/79\nfix: plumb through middleware by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/80\nfeat: overhaul docs / publish to npm by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/75\nfix: remove broken functionality by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/78\nfix: try using wildcard version to work around lerna publish bug by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/84\n@mnahkies made their first contribution in https://github.com/mnahkies/openapi-code-generator/pull/1\n@dependabot made their first contribution in https://github.com/mnahkies/openapi-code-generator/pull/5\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/commits/v0.1.0"}}} \ No newline at end of file +{"/guides/concepts/authenticated-input-specifications":{"title":"Authenticated input specifications","data":{"":"Sometimes you want to generate using a URL as the input, but the URL requires some kind of authentication\nheader to be passed.A good example is Google cloud platforms IAP proxy,\nwhich was the original motivation for supporting this, where we must pass a Proxy-Authorization header.\nOr from private github repositories,\nwhere a Authorization header should be supplied.This can be achieved using the environment variable (preferred)) OPENAPI_REMOTE_SPEC_REQUEST_HEADERS,\nalso available as the --remote-spec-request-headers cli flag.","format#Format":"The format of the value is a JSON object keyed by URI, with values being either an object,\nor array of {name, value} pairs.For example:\n{\n \"https://example.com\": [\n {\"name\": \"X-Client-Id\", \"value\": \"my-client-id\"},\n {\"name\": \"X-Client-Secret\", \"value\": \"some-secret-value\"}\n ],\n \"https://example.org/some/path\": {\"name\": \"Proxy-Authorization\", \"value\": \"some token\"}\n}\nAs a typescript type:\ntype OPENAPI_REMOTE_SPEC_REQUEST_HEADERS = {\n [uri: string]: { name: string, value: string }[] | { name: string, value: string }\n}","hostname-matching#Hostname matching":"You should set the uris to the least specific uris you're happy for the header to be sent to -\na full match on the provided uri is required for the headers to be sent.Eg: given a uri of https://exmaple.com:8080/openapi.yaml the headers would not\nbe sent for requests to other ports, resource paths, or protocols, but a less specific\nuri like https://example.com will send headers on any (https) request to that domain,\nsuch as https://exmaple.com/some/path/openapi.yaml","tips-for-generating-the-json#Tips for generating the JSON":"Unfortunately it is a little annoying to formulate in shell scripts, so here's some examples to get you started.Typically, in any real use cases the secret values would be coming from other shell variables, eg: storing a\nshort-lived access token, etc.","use-jq#Use jq":"Using jq:\nOPENAPI_REMOTE_SPEC_REQUEST_HEADERS=$(jq --null-input --compact-output \\\n --arg domain \"https://example.com\" \\\n --arg name \"proxy-authorization\" \\\n --arg value \"some secret value\" '{$domain: {$name, $value}}')\necho $OPENAPI_REMOTE_SPEC_REQUEST_HEADERS\nOutputs:\n{\"https://example.com\":{\"name\":\"proxy-authorization\",\"value\":\"some secret value\"}}","use-node#Use node":"Using nodejs:\nOPENAPI_REMOTE_SPEC_REQUEST_HEADERS=$(node -p 'JSON.stringify({[process.argv[1]]: {name: process.argv[2], value: process.argv[3]}})' \\\n https://example.com \\\n proxy-authorization \\\n 'some secret value')\necho $OPENAPI_REMOTE_SPEC_REQUEST_HEADERS\nOutputs:\n{\"https://example.com\":{\"name\":\"proxy-authorization\",\"value\":\"some secret value\"}}","why-json#Why JSON":"Why JSON you ask? Simply put it has very well-defined semantics, and is easy to parse without\nfear of jumbling the pieces together.I started by trying to come up with a more ergonomic format, and then felt like I was re-inventing JSON\nwhen it came to dealing with all the edge cases correctly."}},"/guides/concepts/servers-object-handling":{"title":"Guide to servers object handling","data":{"":"OpenAPI 3 has a servers property that can be used to define the base url for the whole document, or\nspecific operations. This guide aims to explain how this is processed.You can find the specifications definition of the servers object hereThis is fully supported, including placeholder/variable substitution, and overriding.\nThe servers object is only used for client SDK templates.It doesn't really make sense in the context of a server template, and so is ignored.","overview#Overview":"Consider an example servers block:\nservers:\n - url: '{protocol}://{host}:{port}'\n variables:\n host:\n default: localhost\n protocol:\n enum: [http, https]\n default: http\n port:\n default: '8080'\nIt defines a single server, with three variables.This will generate a ApiClientServers object that you can use to create a basePath like so:\nconst client = new ApiClient({\n// basePath will be https://localhost:80\nbasePath: ApiClientServers\n .server(\"{protocol}://{host}:{port}\") // the url template determines the build function\n .build(\n \"https\", // string literal union to form the enum\n undefined, // pass undefined to take the default\n \"80\", // override defaults\n )\n})\nIf you pass no args to build, the defaults from the specification are used:\nconst client = new ApiClient({\n// basePath will be http://localhost:8080\nbasePath: ApiClientServers\n .server(\"{protocol}://{host}:{port}\")\n .build()\n})\nYou can also take the default (first) server like so:\nconst client = new ApiClient({\n// basePath will be http://localhost:8080\nbasePath: ApiClientServers\n .server()\n .build()\n})","operation-specific-overrides#Operation specific overrides":"You can specify servers overrides at the path, or individual operation level. The most specific servers block\nwill be used for a given operation.For example, override the url for all operations under the /attachments route:\npaths:\n /attachments:\n servers:\n - url: 'https://attachments.example.com'\nWhen overrides are specified, an additional basePath positional argument will be added to the operation, defaulting\nto the first overridden server with default placeholder values.\nexport class ApiClient {\n async uploadAttachment(\n p: { ... },\n // Overridden server param\n basePath:\n | Server<\"uploadAttachment_ApiClient\">\n | string = ApiClientServers.operations\n .uploadAttachment()\n .build(),\n timeout?: number,\n opts: RequestInit = {},\n ): Promise>> {\n ...\n }\n}\nAs you can see the overrides for each operation are exposed as ApiClientServers.operations.() following\nthe same pattern as the root servers.","configuration#Configuration":"This behavior is optional, and be turned off by passing:\n--enable-typed-base-paths=false\nWhen disabled basePath: string parameters will still be added to operations that have a servers override, but\nno code based on the url or variables will be generated.See also CLI reference"}},"/overview/compatibility":{"title":"Compatibility Tables","data":{"":"This page aims to document which parts of the openapi 3.1.0 specification is supported.\nIt may not be totally complete / accurate, but it should be broadly correct and give you\nan understanding of what does / doesn't work.\nIf something you need isn't supported yet, please raise a Github\nissue\ndetailing your use-case, and we can work together to get support added / extended.We will also accept pull requests where implemented functionality follows the OpenAPI\nspecification,\nand the output code is of a high quality in terms of developer experience and robustness. See\nCONTRIBUTING.md\nto get started","tldr#tldr;":"Most common functionality used by JSON based APIs should work.\nGreat support for paths using application/json request / response bodies\nComprehensive support for most schema properties, including json validation stuff like minLength,\nbut only for json content types. Notable exceptions:\nreadonly is currently implemented incorrectly\ndiscriminator is ignored, but union / intersection types will be generated based on anyOf / allOf so\nthis isn't often an issue in practice\nNo support for security schemes, you'll need to fudge these as header parameters, or implement out-of-band\nfor the specification for now.\nNo support for webhooks / callbacks yet","legend#Legend":"Symbol\tMeaning\t✅/🚧\tSupported in some way. May be incomplete\t🚫\tNot supported, likely to be supported eventually\tN/A\tIgnored, unlikely to be used for anything","root-openapi-object#Root OpenAPI Object":"Root object of openapi documents. A ✅ means at least some support for this field - click through to the table\nfor each attribute for further details.\nAttribute\tSupported\tNotes\topenapi\t✅\tEither 3.1.x or 3.0.x is supported\tinfo\tN/A\tIgnored\tjsonSchemaDialect\t🚫\tNot yet supported\tservers\t✅\tUsed by client SDK templates\tpaths\t✅\t\twebhooks\t🚫\tNot yet supported. Emulate by defining as normal paths.\tcomponents\t✅\t\tsecurity\t🚫\tNot yet supported. Implement out of band or using header parameters.\ttags\t✅\tOptionally used to split output into multiple files\texternalDocs\tN/A\tIgnored","sub-objects#Sub-objects":"","reference-object#Reference Object":"Reference objects are supported to be used in place of the actual object definition anywhere in the documents.\nThey can also cross files (and maybe urls - needs testing).\nIt's recommended to use $ref objects as much as possible. It both promotes re-use, and also allows control\nover the naming of the type / schema in the generated code.\nExample:\n requestBody:\n required: true\n content:\n application/json:\n schema:\n $ref: \"#/components/schemas/ExampleSchema\"\nAttribute\tSupported\tNotes\t$ref\t✅\t$ref support is robust, and works correctly across multiple input files.\tsummary\tN/A\tIgnored\tdescription\tN/A\tIgnored","server-object#Server Object":"Used by the client SDKs to generate builders for basePath's and override parameters.See servers object guide for detailed explanation\nof how this is handled.\nAttribute\tSupported\tNotes\turl\t✅\tOptionally used to type client SDK basePath configuration\tdescription\tN/A\tIgnored\tvariables\t✅","components-object#Components Object":"Technically you can define any \"components\" you like, and $refs to them will work, regardless\nof if they appear in the official specification.The table indicates what will actually typically be used for anything right now.\nAttribute\tSupported\tNotes\tschemas\t✅\t\tresponses\t✅\t\tparameters\t✅\t\texamples\tN/A\t\trequestBodies\t✅\t\theaders\t✅\t\tsecuritySchemes\t🚫\tNot yet supported\tlinks\t🚫\tNot yet supported\tcallbacks\t🚫\tNot yet supported\tpathItems\t✅","paths-object#Paths Object":"Paths are well supported.\nAttribute\tSupported\tNotes\t{path}\t✅","path-item-object#Path Item Object":"All common http methods are supported.\nAttribute\tSupported\tNotes\tsummary\tN/A\tIgnored\tdescription\tN/A\tIgnored\tget\t✅\t\tput\t✅\t\tpost\t✅\t\tdelete\t✅\t\thead\t✅\t\tpatch\t✅\t\ttrace\t🚫\tNot yet supported\tservers\t✅\tUsed by client SDK templates\tparameters\t✅","operation-object#Operation Object":"Most things are supported. It's recommended you supply an operationId as otherwise\none will be generated from the path / http method, which is often overly verbose.\nAttribute\tSupported\tNotes\ttags\t✅\tOptionally used to split output into multiple files\tsummary\tN/A\tIgnored\tdescription\tN/A\tIgnored\texternalDocs\tN/A\tIgnored\toperationId\t✅\tUsed to generate names on types / methods / interfaces\tparameters\t✅\t\trequestBody\t✅\t\tresponses\t✅\t\tcallbacks\t🚫\tNot yet supported\tdeprecated\t🚫\tNot yet supported\tsecurity\t🚫\tNot yet supported\tservers\t✅\tUsed by client SDK templates","parameter-object#Parameter Object":"Whilst attributes like style and explode are not yet supported, for most common parameter use-cases\neverything should just work as you'd guess/expect.\nAttribute\tSupported\tNotes\tname\t✅\t\tin\t✅/🚧\tEverything supported apart from \"cookie\".\tdescription\tN/A\tIgnored\trequired\t✅\t\tdeprecated\tN/A\tIgnored\tallowEmptyValue\t🚫\tUse schema minLength: 1 to prevent empty string values in query parameters\tstyle\t🚫\tNot yet supported\texplode\t🚫\tNot yet supported\tallowReserved\t🚫\tUse schema pattern to emulate\tschema\t✅\t\texample\tN/A\tIgnored\texamples\tN/A\tIgnored\tcontent\t🚫\tNot yet supported","request-body-object#Request Body Object":"Well-supported for application/json content types. Support for form data, and file uploads, etc\nplanned to come soon.\nAttribute\tSupported\tNotes\tdescription\tN/A\tIgnored\tcontent\t✅/🚧\tOnly media types of application/json work properly.\trequired\t✅","media-type-object#Media Type Object":"Attribute\tSupported\tNotes\tschema\t✅\t\texample\tN/A\tIgnored\texamples\tN/A\tIgnored\tencoding\t🚫\tNot yet supported","responses-object#Responses Object":"Well supported.\nAttribute\tSupported\tNotes\tdefault\t✅\t\t{http-status-code}\t✅","response-object#Response Object":"Generally well-supported for application/json content types.\nAttribute\tSupported\tNotes\tdescription\tN/A\tIgnored\theaders\t🚫\tNot yet supported\tcontent\t✅/🚧\tOnly media types of application/json work properly.\tlinks\t🚫\tNot yet supported","header-object#Header Object":"Attribute\tSupported\tNotes\tdescription\tN/A\tIgnored\tschema\t✅\tComplex schemas for headers may not work. Stick to string / number if possible.","tag-object#Tag Object":"Tags are only used for code organization purposes, when passing the --grouping-strategy first-tag\nCLI option.\nAttribute\tSupported\tNotes\tname\t✅\tOptionally used to split output into multiple files\tdescription\tN/A\tIgnored\texternalDocs\tN/A\tIgnored","schema-object#Schema Object":"The majority of attributes that can be specified by schema objects are supported, and accurately match the underlying\nopenapi specification / json schema validation specifications.Most notable exception is readOnly / writeOnly which are currently implemented incorrectly, planned to be addressed\nas a breaking change prior to v1.\nAttribute\tSupported\tNotes\ttitle\tN/A\t\tmultipleOf\t✅\tApplies to type: number\tmaximum\t✅\tApplies to type: number\texclusiveMaximum\t✅\tApplies to type: number\tminimum\t✅\tApplies to type: number\texclusiveMinimum\t✅\tApplies to type: number\tmaxLength\t✅\tApplies to type: string\tminLength\t✅\tApplies to type: string\tpattern\t✅\tSupport for type: string\tmaxItems\t✅\tApplies to type: array\tminItems\t✅\tApplies to type: array\tuniqueItems\t✅\tApplies to type: array\tmaxProperties\t🚫\tNot yet supported\tminProperties\t🚫\tNot yet supported\trequired\t✅\tControls whether undefined is allowed for each value in properties\tenum\t✅\tApplies to type: number and type: string\ttype\t✅\t\tnot\t🚫\tNot yet supported\tallOf\t✅\tProduces a intersection type like A & B\toneOf\t✅\tProduces a union type like A | B\tanyOf\t✅\tProduces a union type like A | B\titems\t✅\tApplies to type: array\tproperties\t✅\tApplies to type: object\tadditionalProperties\t✅/🚧\tFairly comprehensive support, produces Record or unknown/any (dependent on --ts-allow-any)\tformat\t✅/🚧\tLimited support for format email and date-time\tdefault\t✅\t\tnullable\t✅\tAlso supports type: null as an alternative\tdiscriminator\t🚫\tIgnored. Union / Intersection types are usd based on anyOf / allOf / oneOf.\treadOnly\t🚫\tProduces readonly modifiers, but this behavior is incorrect\twriteOnly\t🚫\tNot yet supported\texample\tN/A\tIgnored\texternalDocs\tN/A\tIgnored\tdeprecated\t🚫\tNot yet supported\txml\t🚫\tNot yet supported","completely-unsupported-things#Completely unsupported things":"The following objects are completely unsupported at this stage.","encoding-object#Encoding Object":"Attribute\tSupported\tNotes\tcontentType\t🚫\tNot yet supported\theaders\t🚫\tNot yet supported\tstyle\t🚫\tNot yet supported\texplode\t🚫\tNot yet supported\tallowReserved\t🚫\tNot yet supported","callback-object#Callback Object":"The callback object is completely unsupported.\nAttribute\tSupported\tNotes\t\\{expression\\}\t🚫","link-object#Link Object":"The link object is completely unsupported.\nAttribute\tSupported\tNotes\toperationRef\t🚫\t\toperationId\t🚫\t\tparameters\t🚫\t\trequestBody\t🚫\t\tdescription\tN/A\t\tserver\t🚫","discriminator-object#Discriminator Object":"The discriminator object is completely unsupported.\nAttribute\tSupported\tNotes\tpropertyName\t🚫\t\tmapping\t🚫","xml-object#XML Object":"The XML object is completely unsupported.\nAttribute\tSupported\tNotes\tname\t🚫\t\tnamespace\t🚫\t\tprefix\t🚫\t\tattribute\t🚫\t\twrapped\t🚫","security-scheme-object#Security Scheme Object":"The security scheme object is completely unsupported.\nAttribute\tSupported\tNotes\ttype\t🚫\t\tdescription\t🚫\t\tname\t🚫\t\tin\t🚫\t\tscheme\t🚫\t\tbearerFormat\t🚫\t\tflows\t🚫\t\topenIdConnectUrl\t🚫","oauth-flows-object#OAuth Flows Object":"The oauth flows object is completely unsupported.\nAttribute\tSupported\tNotes\timplicit\t🚫\t\tpassword\t🚫\t\tclientCredentials\t🚫\t\tauthorizationCode\t🚫","oauth-flow-object#OAuth Flow Object":"The oauth flow object is completely unsupported.\nAttribute\tSupported\tNotes\tauthorizationUrl\t🚫\t\ttokenUrl\t🚫\t\trefreshUrl\t🚫\t\tscopes\t🚫","security-requirement-object---patterned-fields#Security Requirement Object - Patterned Fields":"The security requirement object is completely unsupported.\nAttribute\tSupported\tNotes\t\\{name\\}\t🚫"}},"/overview/schema-first-design":{"title":"Why schema first","data":{"":"Broadly speaking there are two approaches people take to maintaining API specifications:\nSchema first, where you write the schema by hand\nCode first, where you generate the schema from your code\nThis project being a code generator from API specification files is on the schema first side of the debate, but why?Ultimately this is fairly subjective, but there are four primary motivators that lead us to believe schema first\nis the better approach.This is also recommended by the OpenAPI initiative (OAI) itself, where they refer to this as \"Design-first\" with similar arguments","longevity#Longevity":"APIs are forever,\nchanging them in backwards incompatible ways is hard/expensive, or sometimes not possible.With that in mind, we believe it's important to be thoughtful about your API design, and\nthat writing an explicit specification/contract is a great forcing function to accomplish this.Additionally, programming languages / frameworks come and go - they are an implementation detail,\nand subject to change as business requirements evolve.\nOpenAPI (originally Swagger) has been around for over a decade now, and we're confident it'll be around for a long time.","common-language#Common Language":"Many large projects / systems will involve multiple programming languages. For example, you might have a Java backend,\nKotlin Android app, Swift iOS app, and Typescript web frontend.For writing your API contracts using OpenAPI up front, you create a common ground for developers of all languages to discuss\nand hash out the details.","constraints#Constraints":"General purpose programming languages are very flexible. If you try hard enough, you can probably implement it.\nSpecifications like OpenAPI on the other hand are more rigid and constraining.We believe it's better to lean into this and design your system such that it can be represented fully by a\nspecification, rather than attempt to generate a specification from the implementation and lose\ninformation/nuance in the process.","separation#Separation":"A good specification not only defines the API contract, but also includes a lot of supplementary information such as examples,\nand documentation.Generating a good specification from your code, therefore requires including all this extra metadata in the code, which\ncan make the code more difficult to work with.We prefer to separate these concerns out into the specification, and keep the implementation code leaner and simpler."}},"/getting-started/tips-for-writing-specifications":{"title":"Tips for writing a good specification","data":{"":"Garbage in, garbage out applies especially to code generation tools. In short the more detailed, and accurate the\nspecification, the better the code and documentation you'll get from it.This page outlines some tips to enhance the quality of the generated code, and make your specification easier to maintain.","declare-operationids#Declare operationIds":"The operationId is used to generate method and type names. If you don't specify one,\nthen one will be generated from the HTTP method and route.Eg:\nWithout an operation id, you'll get generated method names, that might look like:\nclient.getV2ListListIdItems(...)\nclient.postV2ListListIdItems(...)\nInstead of more readable ones like:\nclient.getTodoListItems(...)\nclient.createTodoListItem(...)","make-liberal-use-of-ref#Make liberal use of $ref":"Using $ref can reduce the repetition in your specification, making it far more readable\nand maintainable.It also has the advantage of giving a name to things, that can be used in the generated code,\nand avoid generating duplicate code.If you can't use $ref easily, there is also the option to extract-inline-schemas\nwhich will generate names to avoid inline types, but it won't save you from duplicate code.Example:\npaths:\n /list:\n get:\n operationId: getTodoLists\n responses:\n 200:\n description: 'success'\n content:\n application/json:\n schema:\n type: array\n items:\n $ref: '#/components/schemas/TodoList'\ncomponents:\n schemas:\n TodoList:\n properties:\n ...","compose-refs-using-allof--anyof#Compose $refs using allOf / anyOf":"You can create union and intersection types using allOf and anyOfUnion Types\nUsing anyOf we can combine types / schemas into unions.\ncomponents:\n schemas:\n Apple:\n type: object\n Pear:\n type: object\n Fruit:\n anyOf:\n - $ref: \"#/components/schemas/Apple\"\n - $ref: \"#/components/schemas/Pear\"\nProduces something like:\nexport type Apple = {}\nexport type Pear = {}\nexport type Fruit = Apple | Pear\nIntersection Types\nUsing allOf of we can combine types / schemas into intersection types. This is often\nhandy for \"extending\" a type with additional properties\ncomponents:\n schemas:\n Profile:\n type: object\n properties:\n ...\n FullProfile:\n type: object\n allOf:\n - $ref: \"#/components/schemas/Profile\"\n - type: object\n properties:\n ...\nProduces something like:\nexport type Profile = {}\nexport type FullProfile = Profile & {}","use-validation-constraints-where-sensible#Use validation constraints where sensible":"A fairly rich set of validations can be specified in the specification. Make use of these in order\nfor robust runtime validation.Example:\ncomponents:\n schemas:\n MyRequestBody:\n type: object\n properties:\n name:\n type: string\n minLength: 1\n tags:\n type: array\n minItems: 1\n maxItems: 100\n items:\n type: string\nSee compatibility table for an idea of what's possible.","use-a-clear-infotitle#Use a clear info.title":"The root info.title property is used to name the generated client. Using a name like:\ninfo:\n title: Awesome Service\nWill output a class AwesomeServiceClientIf you can't modify the title, you can use --override-specification-title \"Some Other Title\"\nto workaround."}},"/getting-started/quick-start":{"title":"Quick Start","data":{"":"Install the latest NodeJS LTS release, though any recent version of NodeJS will likely work.You'll also need either an OpenAPI v3 / v3.1, or TypeSpec API specification to generate from. You can\nprovide OpenAPI specifications as YAML or JSON, local files or remote urls - we'll load them all! 🚀Cross-file references are also supported, so don't worry about pre-processing the input.You can check the version we develop and test against here.\nFirst install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator\nnpm i @nahkies/typescript-fetch-runtime\npnpm add --dev @nahkies/openapi-code-generator\npnpm add @nahkies/typescript-fetch-runtime\nyarn add --dev @nahkies/openapi-code-generator\nyarn add @nahkies/typescript-fetch-runtime\nbun add --dev @nahkies/openapi-code-generator\nbun add @nahkies/typescript-fetch-runtime\nYou could also install the CLI globally if you prefer, but it's best to version it per project.This will generate the client to ./src/generated/clients/some-serviceYou can provide either a local file path or url for the input file.\nnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-fetch\npnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-fetch\nyarn openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-fetch\nbun run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-fetch\nUse your new type-safe client, and never worry about making a typo in a url or parameter name again.\nLet the typescript compiler take care of checking that for you.See Guide to typescript-fetch client template for more details.\nFirst install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator\nnpm i axios @nahkies/typescript-axios-runtime\npnpm add --dev @nahkies/openapi-code-generator\npnpm add axios @nahkies/typescript-axios-runtime\nyarn add --dev @nahkies/openapi-code-generator\nyarn add axios @nahkies/typescript-axios-runtime\nbun add --dev @nahkies/openapi-code-generator\nbun add axios @nahkies/typescript-axios-runtime\nYou could also install the CLI globally if you prefer, but it's best to version it per project.This will generate the client to ./src/generated/clients/some-serviceYou can provide either a local file path or url for the input file.\nnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-axios\npnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-axios\nyarn openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-axios\nbun run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated/clients/some-service \\\n--template typescript-axios\nUse your new type-safe client, and never worry about making a typo in a url or parameter name again.\nLet the typescript compiler take care of checking that for you.See Guide to typescript-axios client template for more details.\nFirst install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nnpm i @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\npnpm add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\npnpm add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nyarn add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nyarn add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nbun add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nbun add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nYou could also install the CLI globally if you prefer, but it's best to version it per project.You can provide either a local file path or url for the input file.This will generate the server router and validation logic to ./src/generated\nnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated \\\n--template typescript-koa\npnpm run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated \\\n--template typescript-koa\nyarn openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated \\\n--template typescript-koa\nbun run openapi-code-generator \\\n--input ./openapi.yaml \\ # or https://example.com/openapi.{json,yaml}\n--output ./src/generated \\\n--template typescript-koa\nImplement handlers for your server, and be confident that they match what the client expects. Everything\nwill be strongly typed, so typos are surfaced at development time, not runtime.By default the runtime validation is using zod.See Guide to typescript-koa client template for more details.","cli-options#CLI options":"See the cli reference for the full range of supported options, or try\nnpm run openapi-code-generator --help\npnpm run openapi-code-generator --help\nyarn openapi-code-generator --help\nbun run openapi-code-generator --help","typespec-specifications#Typespec specifications":"If you want to use typespec instead of openapi3\nas your input specifications, additionally install the typespec compiler and supporting packages.\nnpm i --dev @typespec/compiler @typespec/http @typespec/openapi @typespec/openapi3 @typespec/versioning\npnpm add --dev @typespec/compiler @typespec/http @typespec/openapi @typespec/openapi3 @typespec/versioning\nyarn add --dev @typespec/compiler @typespec/http @typespec/openapi @typespec/openapi3 @typespec/versioning\nbun add --dev @typespec/compiler @typespec/http @typespec/openapi @typespec/openapi3 @typespec/versioning\nDepending on how your typespec specification is written, you may need to install additional packages such\nas @typespec/rest.You can then generate like so:\nnpm run openapi-code-generator \\\n --input ./some-service.tsp \\ # or https://example.com/some-service.tsp\n --input-type=typespec \\\n --output ./src/generated/clients/some-service \\\n --template typescript-fetch\npnpm run openapi-code-generator \\\n --input ./some-service.tsp \\ # or https://example.com/some-service.tsp\n --input-type=typespec \\\n --output ./src/generated/clients/some-service \\\n --template typescript-fetch\nyarn openapi-code-generator \\\n --input ./some-service.tsp \\ # or https://example.com/some-service.tsp\n --input-type=typespec \\\n --output ./src/generated/clients/some-service \\\n --template typescript-fetch\nbun run openapi-code-generator \\\n --input ./some-service.tsp \\ # or https://example.com/some-service.tsp\n --input-type=typespec \\\n --output ./src/generated/clients/some-service \\\n --template typescript-fetch\nYou can see examples of code generated from typespec specifications here"}},"/guides/client-templates/typescript-angular":{"title":"Using the typescript-angular template","data":{"":"this is the least battle tested of the templates and most likely to have critical bugs\nThe typescript-angular template outputs a client SDK based on the Angular HttpClient that gives the following:\nTyped methods to call each endpoint returning an RxJS Observable\nIt does not yet support runtime validation/parsing - compile time type safety only at this stage.See integration-tests/typescript-angular for more samples.","install-dependencies#Install dependencies":"First install the CLI to your project:\nnpm i --dev @nahkies/openapi-code-generator\npnpm add --dev @nahkies/openapi-code-generator\nyarn add --dev @nahkies/openapi-code-generator\nbun add --dev @nahkies/openapi-code-generator\nSee also quick start guide","run-generation#Run generation":"npm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/app/clients/some-service \\\n --template typescript-angular \\\n --schema-builder zod","using-the-generated-code#Using the generated code":"Running the above will output these files into ./src/app/clients/some-service:\n./api.module.ts: exports a class ApiModule as an NgModule\n./client.service.ts: exports a class ApiClient as injectable Angular service\n./models.ts: exports typescript types\n./schemas.ts: exports runtime parsers using the chosen schema-builder (default zod)\nOnce generated usage should look something like this:\n// Root Angular module\n@NgModule({\n declarations: [AppComponent],\n imports: [BrowserModule, AppRoutingModule, ApiModule],\n providers: [],\n bootstrap: [AppComponent],\n})\nexport class AppModule {}\n@Component({\n selector: \"app-root\",\n templateUrl: \"./app.component.html\",\n styleUrls: [\"./app.component.css\"],\n})\nexport class AppComponent {\n // inject into your component\n constructor(client: ApiClient) {\n client.updateTodoListById({listId: \"1\", requestBody: {name: \"Foo\"}}).subscribe((next) => {\n if (next.status === 200) {\n // TODO: body is currently incorrectly `unknown` here\n console.log(next.body.id)\n }\n })\n }\n}"}},"/guides/client-templates/typescript-fetch":{"title":"Using the typescript-fetch template","data":{"":"The typescript-fetch template outputs a client SDK based on the fetch api that gives the following:\nTyped methods to call each endpoint\nSupport for passing a timeout, abort signals are still respected\nOptionally, runtime response validation\nRuntime request parameter validation is not currently supported.See integration-tests/typescript-fetch for more samples.Dependencies:","install-dependencies#Install dependencies":"First install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator\nnpm i @nahkies/typescript-fetch-runtime\npnpm add --dev @nahkies/openapi-code-generator\npnpm add @nahkies/typescript-fetch-runtime\nyarn add --dev @nahkies/openapi-code-generator\nyarn add @nahkies/typescript-fetch-runtime\nbun add --dev @nahkies/openapi-code-generator\nbun add @nahkies/typescript-fetch-runtime\nSee also quick start guide\nIf you're using an older version of NodeJS, or targeting very old web browsers,\nyou may need a polyfill like node-fetch-native","run-generation#Run generation":"Experimental support for runtime response validation is available behind the --enable-runtime-response-validation\nflag.\nnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-fetch \\\n --schema-builder zod","using-the-generated-code#Using the generated code":"Running the above will output these files into ./src/clients/some-service:\n./client.ts: exports a class ApiClient that implements methods for calling each endpoint\n./models.ts: exports typescript types\n./schemas.ts: exports runtime parsers using the chosen schema-builder (default zod)\nOnce generated usage should look something like this:\nconst client = new ApiClient({\n basePath: `http://localhost:${address.port}`,\n defaultHeaders: {\n \"Content-Type\": \"application/json\",\n Authorisation: \"Bearer: \", // can pass auth headers here\n },\n})\nconst res = await client.createTodoListItem({\n listId: list.id,\n requestBody: {content: \"test item\"},\n // optionally pass a timeout (ms), or any arbitrary fetch options (eg: an abort signal)\n // timeout?: number,\n // opts?: RequestInit\n})\n// checking the status code narrows the response body types (ie: remove error types from the type union)\nif (res.status !== 200) {\n throw new Error(\"failed to create item\")\n}\n// body will be typed correctly\nconst body = await res.json()\nconsole.log(`id is: ${body.id}`)"}},"/guides/client-templates/typescript-axios":{"title":"Using the typescript-axios template","data":{"":"The typescript-axios template outputs a client SDK based on the axios that gives the following:\nTyped methods to call each endpoint\nOptionally, runtime response validation\nIt follows the standard axios pattern of rejecting any response that isn't 2xx and thus can't provide typed\nerror responses. If you'd like to have strong typing over your error responses consider using the typescript-fetch template.Runtime request parameter validation is not currently supported.See integration-tests/typescript-axios for more samples.","install-dependencies#Install dependencies":"First install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator\nnpm i axios @nahkies/typescript-axios-runtime\npnpm add --dev @nahkies/openapi-code-generator\npnpm add axios @nahkies/typescript-axios-runtime\nyarn add --dev @nahkies/openapi-code-generator\nyarn add axios @nahkies/typescript-axios-runtime\nbun add --dev @nahkies/openapi-code-generator\nbun add axios @nahkies/typescript-axios-runtime\nSee also quick start guide","run-generation#Run generation":"Experimental support for runtime response validation is available behind the --enable-runtime-response-validation\nflag.\nnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src/clients/some-service \\\n --template typescript-axios \\\n --schema-builder zod","using-the-generated-code#Using the generated code":"Running the above will output these files into ./src/clients/some-service:\n./client.ts: exports a class ApiClient that implements methods for calling each endpoint\n./models.ts: exports typescript types\n./schemas.ts: exports runtime parsers using the chosen schema-builder (default zod)\nOnce generated usage should look something like this:\nconst client = new ApiClient({\n // Pass a axios instance if you wish to use interceptors for auth, logging, etc\n // axios: axios.create({...}),\n basePath: `http://localhost:${address.port}`,\n defaultHeaders: {\n \"Content-Type\": \"application/json\",\n Authorisation: \"Bearer: \", // can pass auth headers here\n },\n})\n// rejects if status code isn't 2xx, following typical axios behavior\nconst res = await client.createTodoListItem({\n listId: list.id,\n requestBody: {content: \"test item\"},\n // optionally pass a timeout (ms), or any arbitrary axios options\n // timeout?: number,\n // opts?: AxiosRequestConfig\n})\n// data will be typed correctly\nconsole.log(`id is: ${res.data.id}`)"}},"/guides/concepts/extract-inline-schemas":{"title":"Extract inline schemas","data":{"":"We have experimental support for \"extracting inline schemas\" behind the\n--extract-inline-schemas / OPENAPI_EXTRACT_INLINE_SCHEMAS=true configuration flag.","what-does-this-mean#What does this mean?":"There are basically two ways you can define schemas in your openapi specifications:\nNamed schemas\nInline schemas\nThese are handled differently by code generation. Enabling --extract-inline-schemas aims to\nmake inline schemas emit similar code to named schemas.","named-schema-example#Named schema example":"Normally when writing openapi specifications it is desirable to make use of $ref and define your schemas as named\ncomponents.\npaths:\n /list/{listId}:\n parameters:\n - $ref: '#/components/parameters/listId'\n get:\n operationId: getTodoListById\n responses:\n 200:\n description: 'success'\n content:\n application/json:\n schema:\n $ref: '#/components/schemas/TodoList'\ncomponents:\n schemas:\n TodoList:\n type: object\n required:\n - id\n - name\n - totalItemCount\n - incompleteItemCount\n - created\n properties:\n id:\n type: string\n format: uuid\n name:\n type: string\n totalItemCount:\n type: number\n incompleteItemCount:\n type: number\n created:\n type: string\n format: date-time\nWhen we run code generation for this, we expect a type and a schema for the TodoList to be generated, something like:\nimport {z} from 'zod'\nexport type t_TodoList = {\n id: string\n name: string\n totalItemCount: number\n incompleteItemCount: number\n created: string\n}\nexport const s_TodoList = z.object({\n id: z.string(),\n name: z.string(),\n totalItemCount: z.coerce.number(),\n incompleteItemCount: z.coerce.number(),\n created: z.string().datetime({ offset: true }),\n})\nThis is useful, as it means that we can easily reference the type, or use the schema as we require.","inline-schema-example#Inline Schema Example":"However, not everyone will write their specifications using named $refs, and instead inline schemas may be used.\nThis is especially prolific when generating the specification from implementation code in our experience.Consider the same example as above, but with the schema inlined:\npaths:\n /list/{listId}:\n parameters:\n - $ref: '#/components/parameters/listId'\n get:\n operationId: getTodoListById\n responses:\n 200:\n description: 'success'\n content:\n application/json:\n schema:\n type: object\n required:\n - id\n - name\n - totalItemCount\n - incompleteItemCount\n - created\n properties:\n id:\n type: string\n format: uuid\n name:\n type: string\n totalItemCount:\n type: number\n incompleteItemCount:\n type: number\n created:\n type: string\n format: date-time\ncomponents:\n schemas: {}\nBy default, this will be emitted as in-line types / schemas\nexport type GetTodoListById = (\n params: Params,\n respond: GetTodoListByIdResponder,\n ctx: RouterContext,\n) => Promise<\n | KoaRuntimeResponse\n | Response<\n 200,\n {\n id: string\n name: string\n totalItemCount: number\n incompleteItemCount: number\n created: string\n }\n >\n | Response\n | Response\n>\nconst getTodoListByIdResponseValidator = responseValidationFactory(\n [\n [\n \"200\",\n z.object({\n id: z.string(),\n name: z.string(),\n totalItemCount: z.coerce.number(),\n incompleteItemCount: z.coerce.number(),\n created: z.string().datetime({ offset: true }),\n }),\n ],\n [\"4XX\", s_Error],\n ],\n z.undefined(),\n)\nrouter.get(\"getTodoListById\", \"/list/:listId\", async (ctx, next) => {\n // ...\n const responder = {\n with200() {\n return new KoaRuntimeResponse<{\n id: string\n name: string\n totalItemCount: number\n incompleteItemCount: number\n created: string\n }>(200)\n }\n }\n // ...\n})","with---extract-inline-schemas-enabled#With --extract-inline-schemas enabled":"Notice how this:\nCreates a lot of duplication, we have to repeat the definition anytime it is used\nMakes it inconvenient, or impossible to reference the type/schema in our implementation code\nWith --extract-inline-schemas enabled, the code generator will synthesis a name for each inline schema based on\nits usage, and emit exported types/schemas, eg:\nexport type t_getTodoListByIdJson200Response = {\n id: string\n name: string\n totalItemCount: number\n incompleteItemCount: number\n created: string\n}\nexport const s_getTodoListByIdJson200Response = z.object({\n id: z.string(),\n name: z.string(),\n totalItemCount: z.coerce.number(),\n incompleteItemCount: z.coerce.number(),\n created: z.string().datetime({ offset: true }),\n})\nThis can be a handy trick to make the code generated from schemas you don't own/control easier to work with. In general\nyou should prefer to improve the specifications to be more suitable for code generation, which generally also improves\nthe result of documentation tools like Redoc"}},"/guides/server-templates/typescript-koa":{"title":"Using the typescript-koa template","data":{"":"The typescript-koa template outputs scaffolding code that handles the following:\nBuilding a @koa/router instance with all routes in the openapi specification\nGenerating types and runtime schema parsers for all request parameters/bodies and response bodies\nGenerating types for route implementations that receive validated inputs, and have return types that are additionally\nvalidated at runtime prior to sending the response\n(Optionally) Actually starting the server and binding to a port\nSee integration-tests/typescript-koa for more samples.","install-dependencies#Install dependencies":"First install the CLI and the required runtime packages to your project:\nnpm i --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nnpm i @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\npnpm add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\npnpm add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nyarn add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nyarn add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nbun add --dev @nahkies/openapi-code-generator @types/koa @types/koa__router\nbun add @nahkies/typescript-koa-runtime @koa/cors @koa/router koa koa-body zod\nSee also quick start guide","run-generation#Run generation":"npm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./openapi.yaml \\\n --input-type openapi3 \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\npnpm run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nyarn openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod\nbun run openapi-code-generator \\\n --input ./typespec.tsp \\\n --input-type typespec \\\n --output ./src \\\n --template typescript-koa \\\n --schema-builder zod","using-the-generated-code#Using the generated code":"Running the above will output three files into ./src:\ngenerated.ts - exports a createRouter and bootstrap function, along with associated types used to create your server\nmodels.ts - exports typescript types for schemas\nschemas.ts - exports runtime schema validators\nOnce generated usage should look something like this:\nimport {bootstrap, createRouter, CreateTodoList, GetTodoLists} from \"../generated\"\n// Define your route implementations as async functions implementing the types\n// exported from generated.ts\nconst createTodoList: CreateTodoList = async ({body}, respond) => {\n const list = await prisma.todoList.create({\n data: {\n // body is strongly typed and parsed at runtime\n name: body.name,\n },\n })\n // (recommended) the respond parameter is a strongly typed helper that\n // provides a better editor experience.\n // the response body is additionally validated against the response schema/status code at runtime\n return respond.with200().body(dbListToApiList(list))\n // (deprecated) alternatively, you can return a {status, body} object which is also strongly typed\n // pattern matching the status code against the response schema:\n // return {\n // status: 200 as const,\n // body: dbListToApiList(list)\n // }\n}\nconst getTodoLists: GetTodoLists = async ({query}) => {\n // omitted for brevity\n}\n// Starts a server listening on `port`\nbootstrap({\n router: createRouter({getTodoLists, createTodoList}),\n port: 8080,\n})","custom-koa-appconfig#Custom Koa app/config":"The provided bootstrap function has a limited range of options. For more advanced use-cases,\nsuch as https you will need to construct your own Koa app, and mount the router returned by createRouter.The only real requirement is that you provide a body parsing middleware before the router that places\na parsed request body on the ctx.body property.Eg:\nimport {createRouter} from \"../generated\"\nimport KoaBody from \"koa-body\"\nimport https from \"https\"\n// ...implement routes here\nconst app = new Koa()\n// it doesn't have to be koa-body, but it does need to put the parsed body on `ctx.body`\napp.use(KoaBody())\n// mount the generated router\nconst router = createRouter({getTodoLists, createTodoList})\napp.use(router.allowedMethods())\napp.use(router.routes())\nhttps\n .createServer(\n {\n key: \"...\",\n cert: \"...\",\n },\n app.callback(),\n )\n .listen(433)","error-handling#Error Handling":"Any errors thrown during the request processing will be wrapped in KoaRuntimeError objects,\nand tagged with the phase the error was thrown.\ninterface KoaRuntimeError extends Error {\n cause: unknown // the originally thrown exception\n phase: \"request_validation\" | \"request_handler\" | \"response_validation\"\n}\nThis allows for implementing catch-all error middleware for common concerns like failed request validation,\nor internal server errors.Eg:\nexport async function genericErrorMiddleware(ctx: Context, next: Next) {\n try {\n await next()\n } catch (err) {\n // if the request validation failed, return a 400 and include helpful\n // information about the problem\n if (KoaRuntimeError.isKoaError(err) && err.phase === \"request_validation\") {\n ctx.status = 400\n ctx.body = {\n message: \"request validation failed\",\n meta: err.cause instanceof ZodError ? {issues: err.cause.issues} : {},\n } satisfies t_Error\n return\n }\n // return a 500 and omit information from the response otherwise\n logger.error(\"internal server error\", err)\n ctx.status = 500\n ctx.body = {\n message: \"internal server error\",\n } satisfies t_Error\n }\n}"}},"/guides/use-with-react-query":{"title":"Using with tanstack react-query","data":{"":"Tanstack Query is a popular data fetching library for react applications. We\ndon't offer any out the box integration with it (yet), but it does integrate easily with our generated client SDKs.Here's a basic example implementation. It's not perfect, but it should give you a good starting point.","define-the-queries-and-mutations#Define the queries and mutations":"First we setup a context and define the queries / mutations we'll be making\nimport {ApiClient} from \"@/generated/clients/client\"\nimport {t_ScanRepositoriesBodySchema} from \"@/generated/models\"\nimport {\n QueryClient,\n UseMutationOptions,\n queryOptions,\n} from \"@tanstack/react-query\"\nimport {createContext, useContext} from \"react\"\nexport const QueryOptionsContext = createContext<\n ReturnType | null\n>(null)\nexport const useQueryOptions = () => {\n const v = useContext(QueryOptionsContext)\n if (!v) throw new Error(\"useQueryOptions must be used within provider\")\n return v\n}\nexport const createQueryOptions = (\n fetchClient: ApiClient,\n queryClient: QueryClient,\n) => {\n const result = {\n getSomeResource: (\n id: string,\n ) => {\n return queryOptions({\n queryKey: [\n \"getSomeResource\",\n id\n ],\n queryFn: async () => {\n const res = await fetchClient.getSomeResource({\n id,\n })\n if (res.status !== 200) {\n throw new Error(\"request failed\", {\n cause: new Error(await res.text()),\n })\n }\n return await res.json()\n },\n })\n },\n updateSomeResource: (): UseMutationOptions<\n void,\n Error,\n t_ScanRepositoriesBodySchema\n > => {\n return {\n mutationKey: [\"updateSomeResource\"],\n mutationFn: async (id: string, body: t_SomeBodyType) => {\n const res = await fetchClient.updateSomeResource({id, requestBody: body})\n if (res.status !== 204) {\n throw new Error(\"request failed\", {\n cause: new Error(await res.text()),\n })\n }\n },\n onSuccess: () => {\n void queryClient.invalidateQueries({queryKey: [\"updateSomeResource\"]})\n },\n }\n },\n }\n return result\n}","initialize-the-clients#Initialize the clients":"At the root of our application provide the context\nimport {\n QueryOptionsContext,\n createQueryOptions,\n} from \"@/app/providers/query-options\"\nimport {ApiClient} from \"@/generated/clients/client\"\nimport {QueryClient, QueryClientProvider} from \"@tanstack/react-query\"\nimport {ReactQueryDevtools} from \"@tanstack/react-query-devtools\"\nimport {ReactQueryStreamedHydration} from \"@tanstack/react-query-next-experimental\"\nimport * as React from \"react\"\nimport {useState} from \"react\"\nexport function ClientProviders(props: {children: React.ReactNode}) {\n const [queryClient] = useState(\n () =>\n new QueryClient({\n defaultOptions: {\n queries: {\n staleTime: 5_000,\n },\n },\n }),\n )\n const [fetchClient] = useState(\n new ApiClient({\n basePath: \"http://localhost:3000\",\n }),\n )\n return (\n \n \n \n {props.children}\n \n \n \n \n )\n}\nexport default function RootLayout({\n children,\n}: Readonly<{\n children: React.ReactNode\n}>) {\n return (\n \n \n \n \n \n \n {children}\n \n \n \n )\n}","use-the-queries#Use the queries":"Finally use the useQueryOptions hook in conjunction with the normal useQuery / useMutation hooks\nto make your requests\nimport {useQueryOptions} from \"@/app/providers/query-options\"\nimport {useMutation, useQuery} from \"@tanstack/react-query\"\nexport const SomeComponent = () => {\n const queryOptions = useQueryOptions()\n const someResource = useQuery(\n queryOptions.getSomeResource(\"123\"),\n )\n const doUpdate = useMutation(queryOptions.updateSomeResource())\n return
\n

{someResource.title}

\n
\n}"}},"/":{"title":"Index","data":{}},"/overview/about":{"title":"Welcome","data":{"":"@nahkies/openapi-code-generator is a CLI tool that aims to generate high quality typescript client SDK's,\nand API server scaffolding (routing, validation, serialization) from OpenAPI 3 specifications.Currently, OpenAPI 3.0, OpenAPI 3.1, and TypeSpec are supported an input specifications.This gives you amazing auto-complete, and compile-time safety. Typescript's expressive type system is used to\nmake the generated clients feel idiomatic, and as close to handwritten as possible.\nAlready know that code generation will save you time? Jump straight in with the quick start guide","server-scaffolding-templates#Server Scaffolding Templates":"Server templates handle the routing setup, request and response validation/serialization so that you\ncan focus on the business logic.\ntypescript-koa","client-sdk-templates#Client SDK Templates":"Client templates give you a strongly typed interface to your remote server calls, ensuring that you\nnever misspell a field name or route again.\ntypescript-fetch\ntypescript-axios\ntypescript-angular","project-goal--principals#Project Goal / Principals":"To make it fun, easy and productive to generate both client and server \"glue\"\ncode from openapi 3 definitions. This is code that is tedious and error-prone to maintain by hand,\nby automating it we can reduce toil and frustration.The generated code output should be \"stable\" in the sense that it will not\narbitrarily change between generation without need (for a given version). For\nexample outputting entities in alphabetic order where possible.It should also be generated in a way that human would reasonably write it,\nthe intent is that the generated code can and should be committed to the consuming project\nrepositories, allowing it to be reviewed, and audited overtime.This is particularly useful in the case of mistakes in the generation or schemas, and also\nserves to reduce risk of adoption. There should be no lock-in - if you wish to stop using the\ncode generation, you can simply start maintaining the previously generated code by hand.The initial focus on typescript, with an intention to later support other languages. kotlin\nis the most likely candidate for a second language.","compatibility--completeness#Compatibility / Completeness":"This project should be considered beta quality, though it's getting close to a v1 release.It does not yet handle all aspects of the OpenAPI / JSON schema specification, but most common\nfeatures are implemented. In particular at the moment only JSON content types are supported properly.You can get a sense of what works by looking at the compatibility tables, or the roadmap.\nHowever often the best way is to just try it out with your API specification and see what happens!The integration tests also act as a good showcase of the sort of output you can expect.","compared-to-other-projects#Compared to other projects":"There are many similar projects out there, so why should you use this one?\nStrong emphasis on \"human like\" code output\nTackles the program space from both ends - client and server, for a single source of truth\nComprehensive runtime parsing/validation in addition to static compile time safety\nSo if you want a low risk, write-once, get strong build & runtime guarantees experience then we're worth giving a try."}},"/overview/roadmap":{"title":"Roadmap","data":{"":"This is a very loosely ordered view of known things that are planned in the roadmap. It's probably not exhaustive.","near-term---sometime-in-the-next-6-months#Near-term - \"Sometime in the next 6 months\"":"These are broadly speaking the known blockers to doing the first v1 release.\nThe project was started approximately July\n2020, over 4\nyears ago.It'd be really nice to get to a v1 / stable release before it turns 5 years old 😅, so we'll aim for this to happen\napproximately Q1/Q2 of 2025.","support-multipartform-data-file-uploads#Support multipart/form-data (file uploads)":"Currently only application/json request bodies are supported properly.This is particularly problematic when wanting to upload files, such as images\nor videos.Adding multipart/form-data support will aim to solve this.ref: https://spec.openapis.org/oas/v3.1.1.html#considerations-for-file-uploads","support-response-headers#Support response headers":"It's common for important metadata, such as rate limit information to be\ncommunicated using response headers.At the moment this information is lost during code generation, adding support\nwill mean that it is typed and validated at runtime.ref: https://spec.openapis.org/oas/v3.1.1.html#response-object","support-cookie-parameters#Support cookie parameters":"Cookies are often used to store small pieces of information to be sent on every\nrequest. These are currently ignored, but should be supported.","review-handling-of-parameter-style#Review handling of parameter style":"Review and improve the way that parameter style is interpreted.ref: https://spec.openapis.org/oas/v3.1.1.html#style-values","fix-interpretation-of-readonly--writeonly#Fix interpretation of readOnly / writeOnly":"The meaning of these attributes was incorrectly interpreted and implemented. Changing this will\nbe a breaking change, so this should be revisited prior to v1.","clean-up--rethink-cli-options#Clean up / rethink CLI options":"As the number of CLI options has grown, it's been a bit confusing around when options are/aren't\nused, and it's not super clear how languages other than typescript might be introduced.We should have a rethink of this, and probably separate client sdk vs server stubs in the option\nstructure to make it clear when args are applicable.It may be difficult to maintain backwards compatibility, but if possible then we should.","mid-term---hopefully-in-the-next-year#Mid-term - \"Hopefully in the next year\"":"These are items that are nice to have, but generally not breaking and therefore not blocking for a v1\nrelease. There's a decent chance that many of these will beat a v1 release still.","implement-a-typescript-express-template#Implement a typescript-express template":"express is probably still the most popular\nweb framework for nodejs, with approximately 10x more weekly downloads than koaIt's also pretty similar in design to koa, and so it should low-effort to add a\ntemplate for it.This would be beneficial in terms of making the project useful to a wider userbase,\nbut also be a forcing function to tidy up the koa template code, and abstract it in\na similar way to the client templates are.","complete-an-interactive-playground#Complete an interactive playground":"Many tools of this genre offer an interactive playground on their documentation sites,\nto better communicate the tools purpose and features.An interactive playground PR has been up for a while, https://github.com/mnahkies/openapi-code-generator/pull/216\nbut it turns out these are hard to build, and it needs some more effort to get over the line.","support-custom-serializationdeserialization#Support custom serialization/deserialization":"Sometimes you want to serialize or deserialize objects in a custom way. Good examples\nmight be parsing date-time strings as a moment / Instant instead of the native Date,\nor parsing a uuid string to a first class Uuid type.https://github.com/mnahkies/openapi-code-generator/pull/220 starts to explore this idea,\nand how we could potentially make use of a custom extension to facilitate this use-case.","implement-a-typescript-next-template#Implement a typescript-next template":"next.js is a popular framework for building site using react.\nAn experimental template has been up here https://github.com/mnahkies/openapi-code-generator/pull/152\nfor months, but it needs some effort to really nail the user experience.This is coming after an typescript-express template, as producing the former will\nnecessitate several important refactorings that will make this easier to achieve.","explore-test-framework-integrations#Explore test framework integrations":"nock is a popular library for mocking http requests\nin test suites. What would an integration with nock look like? Or maybe mock service worker?Could we leverage examples to create fixture factories?","support-security-schemas#Support Security Schemas":"At the moment we ignore security schemas, and expect the user to handle this themselves\nout of band of the code generation.For example by mounting a custom authentication middleware for Koa servers, or passing\nan Authorization header for client SDKs.It would be good to investigate how to improve things using declared security schemes.ref: https://spec.openapis.org/oas/v3.1.1.html#security-scheme-object-0","long-term---one-day#Long-term - \"One Day\"":"This is a set of possible future enhancements, generally covering more niche/uncommon parts\nof the OpenAPI standard, that we might implement one day.Whilst these are lower down the list due to being uncommon (often appearing 0 times in the range of\nintegration tests we currently run), there's also an argument to be made that unless tooling steps up\nto support these features, then adoption will remain low, and so support should be added regardless.","support-xml#Support XML":"Whilst JSON has broadly gained popularity over XML as a markup for HTTP requests,\nXML isn't dead. It would be good to support it, especially for client SDK's where\na server might not support JSON.ref: https://spec.openapis.org/oas/v3.1.1.html#xml-object","support-webhooks#Support webhooks":"The webhooks object is a new way to declare webhooks in 3.1. We should investigate\nsupporting it.ref: https://learn.openapis.org/examples/v3.1/webhook-example.html","support-links#Support links":"The links object on responses is an interesting mechanism to declare relationships\nbetween operations, and how to traverse these, using a static declaration.It essentially allows you to specify a mapping of properties from one request, to be\nparameters for another request. Eg: $request.path.idWhilst interesting, it's also uncommon - currently there isn't a single usage of this\nfeature in the specifications we use for our integration tests.ref: https://spec.openapis.org/oas/v3.1.1.html#link-object","support-callbacks#Support callbacks":"The callbacks field of an operation is similar to the links response object, in that\nit provides a way to specify callbacks related to an operation.Much like links, it's uncommon to see this used in practice, without a single callbacks\nobject defined in any specifications we see.ref: https://spec.openapis.org/oas/v3.1.1.html#callback-object"}},"/reference/cli-options":{"title":"CLI Options","data":{"cli-configuration-reference#CLI Configuration Reference":"All CLI options can be provided as command-line parameters, or environment variables as you prefer.","generate#Generate":"The default action is to run code generation.","required-parameters#Required Parameters":"","-i---input-value#-i --input ":"As environment variable OPENAPI_INPUTPath to the input specification to generate from. Either a local path, or a url may be provided, though not all\nspecifications will build correctly from a url.By default, this must be a OpenAPI 3.0 or OpenAPI 3.1\nspecification, in either YAML or JSON format.When used in conjunction with --input-type typespec then a TypeSpec specification can be\nsupplied instead.","-o---output-value#-o --output ":"As environment variable OPENAPI_OUTPUTdirectory to output generated code (env: )","-t---template-value#-t --template ":"As environment variable OPENAPI_TEMPLATEWhich template you wish to generate, one of:\ntypescript-koa\ntypescript-fetch\ntypescript-axios\ntypescript-angular","optional-parameters#Optional Parameters":"","--input-type-value#--input-type ":"As environment variable OPENAPI_INPUT_TYPEWhat type of input file is being provided, one of:\nopenapi3 (default)\ntypespec","--override-specification-title-value#--override-specification-title ":"As environment variable OPENAPI_OVERRIDE_SPECIFICATION_TITLEAllows overriding the info.title field of the input OpenAPI document. This field is used to generate\nsome symbol names, and so this is useful when you don't directly control the source specification, and\nwish to customize the output symbol names.","-s---schema-builder-value#-s --schema-builder ":"As environment variable OPENAPI_SCHEMA_BUILDERWhich runtime schema parsing library to use, one of:\nzod (default)\njoi","--grouping-strategy-value-experimental#--grouping-strategy (experimental)":"As environment variable OPENAPI_GROUPING_STRATEGYStrategy to use for splitting output into separate files. Set to none for a single generated.ts file, one of:\nnone don't split output, yield single generated.ts (default)\nfirst-tag group operations based on their first tag\nfirst-slug group operations based on their first route slug/segment","--enable-runtime-response-validation-experimental#--enable-runtime-response-validation (experimental)":"As environment variable whether to validate response bodies using the chosen runtime schema library.Default false\nNote: this is currently always true for server templates, and only applies to the client library templates.","--enable-typed-base-paths-client-sdks-only#--enable-typed-base-paths (client sdks only)":"As environment variable OPENAPI_ENABLE_TYPED_BASE_PATHSControls whether to generate a URL builder from the openapi specifications\narray of server urls and placeholder variables.When disabled a plain string type is used for these parameters.See servers object guide for detailed explanation\nof how this is handled.Default: true","--extract-inline-schemas-experimental#--extract-inline-schemas (experimental)":"As environment variable OPENAPI_EXTRACT_INLINE_SCHEMASGenerate names based on usage, and extract in-line schemas to be standalone types / schemas in the\ngenerated code. This is especially useful when dealing with input schemas that don't make good use\nof named $ref's.See extract-inline-schemas guide for details of how this works.Default false","--allow-unused-imports#--allow-unused-imports":"As environment variable OPENAPI_ALLOW_UNUSED_IMPORTSAllow unused imports to be emitted in generated code. Offered as an escape hatch if any bugs\nin the unused-import elimination occur.Default false","--ts-allow-any#--ts-allow-any":"As environment variable OPENAPI_TS_ALLOW_ANYDetermines whether to use any or unknown when generating types for schemas that don't have\nconcrete definitions. Eg: additionalProperties: true or {} schemas.Using unknown will push you towards using type guards / making runtime checks before interacting\nwith the model and should generally result in more robust code, whilst any may be more convenient\nduring rapid prototyping.Default: false (use unknown rather than any)\nInput schema\t--ts-allow-any\t(default)\t{}\tany\tunknown\t{additionalProperties: true}\tany\tunknown\t{additionalProperties: false}\t{ [key: string]: never }\t{ [key: string]: never }\t{type: \"object\", additionalProperties: true}\t{[key: string]: any}\t{[key: string]: unknown}\t{type: \"array\", items: {}}\tany[]\tunknown[]","--ts-server-implementation-method-experimental-server-sdks-only#--ts-server-implementation-method (experimental) (server sdks only)":"As environment variable OPENAPI_TS_SERVER_IMPLEMENTATION_METHODDetermines whether to represent server stubs / interfaces as type, interface, or abstract class entities.This is mostly a case of personal preference, but can be important for better integration with dependency injection\nframeworks, such as diod which rely on abstract class objects to define\ninterfaces for injection.\nOption\tExample Output\tinterface\texport interface Implementation { ... } `\ttype\texport type Implementation = { ... }\tabstract-class\texport abstract class Implementation { ... }\t\nDefault: type","--filename-convention-value#--filename-convention ":"As environment variable OPENAPI_FILENAME_CONVENTIONDetermines which naming convention to use for dynamically generated filenames\n(eg: those generated from tags or route prefixes).\nValue\tExample Filename\tkebab-case\tmy-file.ts\tcamel-case\tmyFile.ts\ttitle-case\tMyFile.ts\tsnake-case\tmy_file.ts\t\nDefault: kebab-case","misc#Misc":"","--remote-spec-request-headers-authenticated-remote-specifications#--remote-spec-request-headers (authenticated remote specifications)":"As environment variable OPENAPI_REMOTE_SPEC_REQUEST_HEADERSAllows providing request headers to use when fetching remote specifications. This allows for running\ngeneration against remote sources that require authentication.See authenticated-input-specifications guide for\ndetails of how to use.","-h---help#-h, --help":"Displays help text for command"}},"/reference/release-notes":{"title":"Release notes","data":{"":"This page is statically generated from the Github releases,\nand may sometimes be slightly out of date.","2-nov-2024-v0160#2 Nov 2024 (v0.16.0)":"Client class exports will now be given unique names generated from the input specifications info.title field. This can additionally be overridden through a new cli arg --override-specification-title.The previous generic exports are kept for backwards compatibility.POTENTIALLY BREAKING: Filenames generated from tags or route prefixes will now follow kebab-case naming convention by default. This can be customized to other conventions like camel-case, etc using --filename-conventionFeatures\nfeat: unique client export names by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/263\nfeat!: dynamic filename conventions / no spaces in filenames by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/259\nfeat: safer identifier transformation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/260\nMisc\nfix: format/emit in parallel by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/265\nchore: upgrade to next@15 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/261\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/262\nchore: refresh data + regenerate by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/264\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.15.0...v0.16.0","27-oct-2024-v0150#27 Oct 2024 (v0.15.0)":"It's now possible to change the construct used for the \"implementation\" symbol between being a type, interface or abstract class using the new option --ts-server-implementation-method. This is particularly useful if using a dependency injection library that requires abstract class as part of its wiring approach.Additionally, when splitting the generated files by first-tag / first-slug (using --grouping-strategy), the tag/slug will now be added to the exported symbol names, eg: createRouter -> createMyTagRouter and Implementation -> MyTagImplementation. This can reduce the need to alias imports manually.The generic Implementation / createRouter exports have be retained to keep this backwards compatible.Features\nfeat: support emitting abstract classes for implementation types by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/256\nfeat: emit unique symbol names for Implementation / createRouter functions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/258\nMisc\nfix(docs): improve meta tags by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/255\nchore: dependencies / refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/257\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.14.0...v0.15.0","12-oct-2024-v0140#12 Oct 2024 (v0.14.0)":"Fixes a few small bugs, and adds support for relative $refs when using a URI as the input.Features\nfeat: support loading relative remote uris by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/254\nBug fixes\nfix: allow $ref to be used as a schema property by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/250\nfix: handle type: \"null\" in anyOf / oneOf / allOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/252\nMisc\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/251\nfix(docs): use absolute url for og:image by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/253\nchore(docs): switch to self-hosted plausible ce by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/249\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.13.0...v0.14.0","20-sept-2024-v0130#20 Sept 2024 (v0.13.0)":"This release adds support for schemas specifying default values, and begins validating / parsing incoming request headers. Note: this may be a breaking change if your server currently accepts requests with invalid request headers.Features\nfeat: support default values by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/241\nfeat!: parse/validate request headers by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/247\nfeat: include urls from servers array in basePath type by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/246\nDocs\ndocs: add compatibility tables by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/248\nMisc\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/239\nchore(deps): Bump micromatch from 4.0.7 to 4.0.8 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/240\nchore: update dependencies and refresh data files by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/244\nchore: upgrade typescript by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/245\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.12.1...v0.13.0","17-aug-2024-v0121#17 Aug 2024 (v0.12.1)":"This release fixes a small typing mistake preventing queries parameters of type number[] from building properly, and fixes bugs in the handling of header parameters / defaults and the \"escape hatch\" parameters allowing arbitrary fetch / axios request options to be passed.It's also the first release with automated end-to-end tests in place, though the coverage is still low - this will be improved during the course of development going forward.Bug fixes\nfix: allow number array query param by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/236\nfix(fetch/axios): correctly merge headers from opts by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/231\nTesting\nfeat: add e2e test suite by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/235\nMisc\nchore(deps): update dependency axios to v1.7.4 [security] by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/232\nchore: dependencies / refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/233\nchore: tweak npm metadata by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/234\nchore: use node 22 by default by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/237\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.12.0...v0.12.1","5-aug-2024-v0120#5 Aug 2024 (v0.12.0)":"Another small release, adding a new CLI parameter OPENAPI_REMOTE_SPEC_REQUEST_HEADERS / --remote-spec-request-headers that allows request headers to be sent when fetching specifications from remote URI's.This makes it possible to generate from a remote URI that is behind some form of header based authentication, eg: Authorization: Bearer (which includes cookie based authentication since cookies are just a Cookie header, and basic auth as this is just Authorization: Basic ).The headers are scoped to specific domains/urls such that you can mix and match sources without leaking tokens to the wrong servers.Features\nfeat: support remote specs with authentication by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/230\nMisc\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/228\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.11.2...v0.12.0","29-jul-2024-v0112#29 Jul 2024 (v0.11.2)":"This is a bug fix release, solving an issue with the order schemas were output when generating from specifications that are split over multiple files, causing variable used before declaration issues.Bug fixes\nfix: include schemas from all documents in dependency graph by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/227\nDocumentation\nfix: improve seo, use plausible by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/226\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.11.1...v0.11.2","27-jul-2024-v0111#27 Jul 2024 (v0.11.1)":"This is a bug fix release, containing a solution for https://github.com/mnahkies/openapi-code-generator/issues/217.Previously query parameters of an array type did not work when a single element was provided, now this will be parsed and handed to the route handler as an array of one element.Bug fixes\nfix: support array of 1 for query parameter arrays (round 2) by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/225\nMisc\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/210\nchore(deps): update all dependencies by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/221\nchore: refresh data / use new okta specs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/222\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/223\nfix: peer dependency by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/224\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.11.0...v0.11.1","8-jun-2024-v0110#8 Jun 2024 (v0.11.0)":"This release contains 1 bug fix for default header handling in typescript-axios and several internal refactoring changes required to facilitate the work-in-progress documentation playgroundAlso dropped eslint for biome because I can't be bothered figuring out the eslint@^9 upgrade / configuration migration.Bug fixes\nfix(axios): always apply default headers by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/218\nInternal refactoring\nfix: make logger compatible with web by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/211\nfix: decouple validator from readline by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/212\nfeat: add a prettier based formatter by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/213\nfix: move tsconfig loading by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/214\nfix: decouple typespec loader from readline by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/215\nMisc\nchore: ditch eslint by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/219\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.10.0...v0.11.0","25-may-2024-v0100#25 May 2024 (v0.10.0)":"This release is primarily bug fixes, and internal refactoring to facilitate improvements to documentation. Most effort has gone into the new documentation site live at https://openapi-code-generator.nahkies.co.nz/It also splits the cli from the library entrypoint such that you can now import {generate} from '@nahkies/openapi-code-generator' for programmatic usage if you wish, and improves handling of boolean cli flags.BREAKING CHANGES\nThere are several potentially breaking changes here:\nDropped the \"safe edit region\" functionality, I doubt anyone was using this and it wasn't particularly robust\nImproved handling of additionalProperties / {} schemas to better align with the specification\nJoi validation became stricter for strings with format email / date-time\nThis may make some schemas / types change type to unknown, and start serializing/deserializing values that were previously stripped (see #200). If you want more permissive types (any) in these situations rather than unknown you can use the --ts-allow-any cli flag.Bug fixes\nfix!: an schema should be an unknown/any type by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/204\nfix!: drop safe edit regions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/198\nfix!: joi supports email / date-time string formats by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/206\nfix: improve handling of cli boolean params by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/205\nfix: only allow publish of releases from latest main by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/161\nInternal refactoring\nrefactor: create TypescriptFormatter class by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/199\nrefactor: isolate filesystem interaction by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/201\nrefactor: split cli to allow programmatic use by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/202\nDocs\nfeat: new documentation website by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/162\nfeat: publish docs from ci, add ga to docs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/163\nfix: provide a user by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/164\nfix: try git config by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/165\nfix: set url by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/166\nfix: move script to _app by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/167\nfix: replace default nextra meta descriptions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/168\ndocs: show typespec shell snippets, mention runtime response validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/169\ndocs: move architecture into nextra site by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/186\ndocs: update readme by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/187\nfix(docs): correct header level by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/209\nMisc\nchore: upgrade dependencies / angular v18 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/207\nchore: refresh data and regenerate by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/208\nchore: bump lerna by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/203\nfix: make renovate less noisy by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/197\nchore: Configure Renovate by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/170\nchore(deps): update dependency @azure-tools/typespec-client-generator-core to v0.41.8 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/171\nchore(deps): update dependency @types/node to v20.12.8 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/172\nfix(deps): update angular monorepo by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/175\nchore(deps): update dependency typescript to ~5.4.0 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/180\nchore(deps): update dependency node to v20.12.2 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/179\nchore(deps): update yarn to v4.2.1 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/182\nchore(deps): update dependency zod to v3.23.6 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/174\nchore(deps): update typescript-eslint monorepo to v7.8.0 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/181\nfix(deps): update dependency ajv to v8.13.0 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/183\nchore(deps): update dependency eslint-plugin-jest to v28.5.0 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/178\nfix(deps): update dependency @biomejs/biome to v1.7.2 by @renovate in https://github.com/mnahkies/openapi-code-generator/pull/176\n@renovate made their first contribution in https://github.com/mnahkies/openapi-code-generator/pull/170\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.9.0...v0.10.0","27-apr-2024-v090#27 Apr 2024 (v0.9.0)":"There are two new features in this release:\nTypespec can now be used as an input file by passing --input-type=typespec as an additional arg\nYou can now use a url for your input file (openapi specs only, typespec must be local files)\nFeatures\nfeat: support typespec as an input format by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/158\nfeat: support loading input from uri by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/150\nBug fixes\nfix: allow options by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/151\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.8.0...v0.9.0","7-apr-2024-v080#7 Apr 2024 (v0.8.0)":"There are three main features in this release:\nImprove json schema validation support for string, number, array (min / max / etc)\nMake boolean schema validation stricter\nStart using a pre-compiled ajv validator for better performance\nBREAKING CHANGES\nPreviously any truthy value would be accepted for a boolean, eg: any-string would parse to true. Now its parsed like:\ntrue | \"true\" | 1 -> true\nfalse | \"false\" | 0 -> false\nanything else -> error\nFeatures\nfeat: support minimum / maximum for numbers by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/140\nfeat: use pre-compiled ajv validators at runtime by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/141\nfeat: joi number min/max validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/143\nfeat: support exclusive min/max and multipleOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/144\nfeat: support string validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/145\nfix!: stricter booleans by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/146\nfeat: support basic array validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/147\nMisc\nchore(deps): Bump follow-redirects from 1.15.5 to 1.15.6 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/136\nchore(deps): Bump webpack-dev-middleware from 5.3.3 to 5.3.4 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/137\nchore(deps): Bump express from 4.18.3 to 4.19.2 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/138\nchore: deps by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/139\nchore: refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/142\nchore: bump deps by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/149\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.7.0...v0.8.0","3-mar-2024-v070#3 Mar 2024 (v0.7.0)":"Features\nfeat: experimental support for splitting code by tags / route segments by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/134\nfeat: eliminate unused imports by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/132\nfeat: use strict typescript settings by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/131\nfeat: adopt biome for code formatting by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/129\nMisc\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/133\nchore(deps): Bump ip from 2.0.0 to 2.0.1 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/130\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.6.0...v0.7.0","19-feb-2024-v060#19 Feb 2024 (v0.6.0)":"Features\nfeat: improve additional properties support by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/126\nfeat: support response validation for joi by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/127\nMisc\nchore: adopt prettier everywhere by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/128\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.5.0...v0.6.0","10-feb-2024-v050#10 Feb 2024 (v0.5.0)":"Features\nfeat: experimental support for extracting inline schemas by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/123\nfeat: client generators support experimental runtime response validation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/112\nMisc\ndocs: tiny improvement by @asfaltboy in https://github.com/mnahkies/openapi-code-generator/pull/122\nchore: update deps / use RouterContext by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/124\nUpgrading notes\nYou may need to replace the Context type from koa with RouterContext from @koa/router in some cases due to changes in the upstream type definitions.\n@asfaltboy made their first contribution in https://github.com/mnahkies/openapi-code-generator/pull/122\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.4.0...v0.5.0","5-jan-2024-v040#5 Jan 2024 (v0.4.0)":"feat(typescript-koa): introduce optional \"respond\" pattern by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/96\nBugs\nfix: incorrect .d.ts path for zod by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/119\nfix(koa): don't camel-case route placeholders by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/120\nMisc\nchore(deps-dev): Bump @koa/cors from 4.0.0 to 5.0.0 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/116\nchore: bump deps by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/121\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.3.0...v0.4.0","2-dec-2023-v030#2 Dec 2023 (v0.3.0)":"feat: add typescript-axios template by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/83\nfeat!: throw discriminable errors indicating point of failure by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/95\nBreaking Changes\nErrors thrown during request handling in typescript-koa will now be wrapped in KoaRuntimeError objects with the original exception included as the cause, in order to provide additional context about where the error was thrown.Misc\nfix: decouple schema builders from typescript-koa by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/113\nfeat: include schema builder in client generators by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/114\nchore: upgrade angular / dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/115\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.2.0...v0.3.0","12-nov-2023-v020#12 Nov 2023 (v0.2.0)":"Features\nfeat: basic support for openapi 3.1 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/109\nBug Fixes\nfix: skip broken openapi 3.1 validation for now by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/104\nfix: allow numeric header values by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/105\nfix: handle null in enums by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/106\nfix: handle \" in string enum values by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/107\nfix: use numerical enums when creating zod schema by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/108\nfix: optional oneOf / allOf / anyOf / $ref's by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/110\nMisc\nchore: refresh lockfile by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/100\nchore: use branch as preid / dist-tag on alpha versions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/101\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.1.1...v0.2.0","11-nov-2023-v011#11 Nov 2023 (v0.1.1)":"Breaking changes\nfeat!: more flexible koa server creation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/88\nFixes\nfix: don't coerce strings by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/87\nMisc\nchore(deps): bump @babel/traverse from 7.22.19 to 7.23.2 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/85\nchore(deps): Bump zod from 3.22.2 to 3.22.3 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/86\nchore: yarn 4, @swc/jest by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/89\nstyle: comma-dangle always-multiline by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/91\nchore: move generated files into a generated sub-directory by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/92\nfix: delete files missed in #92 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/93\nfix: unused imports by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/97\nfix: avoid warning for non-nullable paths by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/90\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/compare/v0.1.0...v0.1.1","1-oct-2023-v010#1 Oct 2023 (v0.1.0)":"Initial Release.\nchore: refresh dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/1\nfix(typescript-fetch): omit optional query params by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/2\nchore: switch source of GitHub defs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/3\nfeat: add script consuming github fetch client by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/4\nfeat: support zod for parsing inputs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/7\nchore(deps): bump ua-parser-js from 0.7.32 to 0.7.33 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/5\nchore(deps): bump http-cache-semantics from 4.1.0 to 4.1.1 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/6\nfeat: support string enums in zod parsing by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/8\nfeat: new approach to server stubs by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/9\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/10\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/15\nchore: upgrade to yarn berry by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/16\nchore: add lint-staged / husky, improve lint cmd by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/17\ndocs: add table of contents / format by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/18\nchore: switch from mocha/chai to jest by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/19\nfeat: move static code to normal files by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/20\nfeat: move more static code into koa runtime by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/21\nfix: respect optional $ref properties by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/22\nfeat: initial support for oneOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/23\nfix: request bodies can be optional by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/24\nfeat: rework input schema parsing by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/25\nrefactor: several tidy ups by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/26\nfeat: zod schema builder supports allOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/27\nfix: use merge instead of intersection by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/28\nfeat: response body validation and types by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/29\nfix: eslint disable in generated files by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/30\nfix: use request body by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/32\nfix: improve support for nullable types by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/33\nfix: improve validation to switch between 3.1.0 / 3.0.0 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/34\nfeat: improve client generation by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/35\nfeat: clients default params to when none are required by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/36\nfeat: order schemas correctly by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/37\nchore: update github definition by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/31\nrefactor: move schema builders to common, rename model builder by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/38\nfeat: config flag to switch schema parser by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/39\nfix: improve null support by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/40\nrefactor: simplify by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/41\nrefactor: consistently use yaml instead of yml by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/47\nchore: refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/48\nfix: replace . in identifiers by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/50\nchore: review todos and create tickets for most by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/54\nfeat: initial support for anyOf by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/55\nfix: switch to qs and add tests for query string by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/56\nfeat: better support for additional properties by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/57\nfeat: support circular references by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/58\ntests: add stripe api definitions by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/49\nchore(deps): bump engine.io from 6.4.1 to 6.4.2 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/61\nchore: upgrade to angular v16 by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/62\nfix: surface status code -> body relationship in angular template by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/63\nchore: update data and regenerate by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/64\nfeat: fetch client supports abort signals by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/65\nchore(deps): bump socket.io-parser from 4.2.2 to 4.2.3 by @dependabot in https://github.com/mnahkies/openapi-code-generator/pull/66\nchore: update dependencies by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/69\nchore: upgrade prettier by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/70\nchore: refresh yarn lock by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/71\nfix: dependency graph handles oneOf allOf nesting by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/73\nchore: refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/72\nchore: add okta api specs as tests by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/74\nfix: master -> main by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/77\nfeat: use commander for cli args for better ux by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/76\nchore: refresh data by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/79\nfix: plumb through middleware by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/80\nfeat: overhaul docs / publish to npm by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/75\nfix: remove broken functionality by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/78\nfix: try using wildcard version to work around lerna publish bug by @mnahkies in https://github.com/mnahkies/openapi-code-generator/pull/84\n@mnahkies made their first contribution in https://github.com/mnahkies/openapi-code-generator/pull/1\n@dependabot made their first contribution in https://github.com/mnahkies/openapi-code-generator/pull/5\nFull Changelog: https://github.com/mnahkies/openapi-code-generator/commits/v0.1.0"}}} \ No newline at end of file diff --git a/_next/static/IAjNhorSMAQYQlItTXsBX/_buildManifest.js b/_next/static/kXi3c5JOdEE0KV7td5iHq/_buildManifest.js similarity index 100% rename from _next/static/IAjNhorSMAQYQlItTXsBX/_buildManifest.js rename to _next/static/kXi3c5JOdEE0KV7td5iHq/_buildManifest.js diff --git a/_next/static/IAjNhorSMAQYQlItTXsBX/_ssgManifest.js b/_next/static/kXi3c5JOdEE0KV7td5iHq/_ssgManifest.js similarity index 100% rename from _next/static/IAjNhorSMAQYQlItTXsBX/_ssgManifest.js rename to _next/static/kXi3c5JOdEE0KV7td5iHq/_ssgManifest.js diff --git a/getting-started/quick-start.html b/getting-started/quick-start.html index cfe34a48..82ff1cd5 100644 --- a/getting-started/quick-start.html +++ b/getting-started/quick-start.html @@ -1,4 +1,4 @@ -Quick Start – OpenAPI Code Generator
Getting StartedQuick Start

Quick Start

+Quick Start – OpenAPI Code Generator
Getting StartedQuick Start

Quick Start

Install the latest NodeJS LTS release, though any recent version of NodeJS will likely work.

You’ll also need either an OpenAPI v3 / v3.1, or TypeSpec API specification to generate from. You can provide OpenAPI specifications as YAML or JSON, local files or remote urls - we’ll load them all! 🚀

@@ -83,4 +83,4 @@

--input-type=typespec \ --output ./src/generated/clients/some-service \ --template typescript-fetch

-

You can see examples of code generated from typespec specifications here

RoadmapTips for Writing Specifications
\ No newline at end of file +

You can see examples of code generated from typespec specifications here

RoadmapTips for Writing Specifications
\ No newline at end of file diff --git a/getting-started/tips-for-writing-specifications.html b/getting-started/tips-for-writing-specifications.html index 43899a83..0ec417ad 100644 --- a/getting-started/tips-for-writing-specifications.html +++ b/getting-started/tips-for-writing-specifications.html @@ -1,4 +1,4 @@ -Tips for writing a good specification – OpenAPI Code Generator
Getting StartedTips for Writing Specifications

Tips for writing a good specification

+Tips for writing a good specification – OpenAPI Code Generator
Getting StartedTips for Writing Specifications

Tips for writing a good specification

Garbage in, garbage out applies especially to code generation tools. In short the more detailed, and accurate the specification, the better the code and documentation you’ll get from it.

This page outlines some tips to enhance the quality of the generated code, and make your specification easier to maintain.

@@ -101,4 +101,4 @@

title: Awesome Service

Will output a class AwesomeServiceClient

If you can’t modify the title, you can use --override-specification-title "Some Other Title" -to workaround.

Quick StartAuthenticated Input Specifications
\ No newline at end of file +to workaround.

Quick StartAuthenticated Input Specifications
\ No newline at end of file diff --git a/guides/client-templates/typescript-angular.html b/guides/client-templates/typescript-angular.html index 96c56bcc..4ed5068f 100644 --- a/guides/client-templates/typescript-angular.html +++ b/guides/client-templates/typescript-angular.html @@ -1,4 +1,4 @@ -Using the typescript-angular template – OpenAPI Code Generator
GuidesClient TemplatesTypeScript Angular

Using the typescript-angular template

+Using the typescript-angular template – OpenAPI Code Generator
GuidesClient TemplatesTypeScript Angular

Using the typescript-angular template

⚠️

this is the least battle tested of the templates and most likely to have critical bugs

The typescript-angular template outputs a client SDK based on the Angular HttpClient that gives the following:

    @@ -85,4 +85,4 @@

    } }) } -}

Servers Object HandlingTypeScript Axios
\ No newline at end of file +}
Servers Object HandlingTypeScript Axios
\ No newline at end of file diff --git a/guides/client-templates/typescript-axios.html b/guides/client-templates/typescript-axios.html index 4586d676..b90d0541 100644 --- a/guides/client-templates/typescript-axios.html +++ b/guides/client-templates/typescript-axios.html @@ -1,4 +1,4 @@ -Using the typescript-axios template – OpenAPI Code Generator
GuidesClient TemplatesTypeScript Axios

Using the typescript-axios template

+Using the typescript-axios template – OpenAPI Code Generator
GuidesClient TemplatesTypeScript Axios

Using the typescript-axios template

The typescript-axios template outputs a client SDK based on the axios that gives the following:

  • Typed methods to call each endpoint
    • @@ -87,4 +87,4 @@

    }) // data will be typed correctly -console.log(`id is: ${res.data.id}`)

TypeScript AngularTypeScript Fetch
\ No newline at end of file +console.log(`id is: ${res.data.id}`)
TypeScript AngularTypeScript Fetch
\ No newline at end of file diff --git a/guides/client-templates/typescript-fetch.html b/guides/client-templates/typescript-fetch.html index 586ee204..ba2f875f 100644 --- a/guides/client-templates/typescript-fetch.html +++ b/guides/client-templates/typescript-fetch.html @@ -1,4 +1,4 @@ -Using the typescript-fetch template – OpenAPI Code Generator
GuidesClient TemplatesTypeScript Fetch

Using the typescript-fetch template

+Using the typescript-fetch template – OpenAPI Code Generator
GuidesClient TemplatesTypeScript Fetch

Using the typescript-fetch template

The typescript-fetch template outputs a client SDK based on the fetch api that gives the following:

  • Typed methods to call each endpoint
    • @@ -92,4 +92,4 @@

    // body will be typed correctly const body = await res.json() -console.log(`id is: ${body.id}`)

TypeScript AxiosTypeScript Koa
\ No newline at end of file +console.log(`id is: ${body.id}`)
TypeScript AxiosTypeScript Koa
\ No newline at end of file diff --git a/guides/concepts/authenticated-input-specifications.html b/guides/concepts/authenticated-input-specifications.html index c936d153..8bd6d618 100644 --- a/guides/concepts/authenticated-input-specifications.html +++ b/guides/concepts/authenticated-input-specifications.html @@ -1,4 +1,4 @@ -Authenticated input specifications – OpenAPI Code Generator
GuidesConceptsAuthenticated Input Specifications

Authenticated input specifications

+Authenticated input specifications – OpenAPI Code Generator
GuidesConceptsAuthenticated Input Specifications

Authenticated input specifications

Sometimes you want to generate using a URL as the input, but the URL requires some kind of authentication header to be passed.

A good example is Google cloud platforms IAP proxy, @@ -55,4 +55,4 @@

Why JSON you ask? Simply put it has very well-defined semantics, and is easy to parse without fear of jumbling the pieces together.

I started by trying to come up with a more ergonomic format, and then felt like I was re-inventing JSON -when it came to dealing with all the edge cases correctly.

Tips for Writing SpecificationsExtract Inline Schemas

\ No newline at end of file +when it came to dealing with all the edge cases correctly.

Tips for Writing SpecificationsExtract Inline Schemas
\ No newline at end of file diff --git a/guides/concepts/extract-inline-schemas.html b/guides/concepts/extract-inline-schemas.html index 10361d7d..ebc81f5f 100644 --- a/guides/concepts/extract-inline-schemas.html +++ b/guides/concepts/extract-inline-schemas.html @@ -1,4 +1,4 @@ -Extract inline schemas – OpenAPI Code Generator
GuidesConceptsExtract Inline Schemas

Extract inline schemas

+Extract inline schemas – OpenAPI Code Generator
GuidesConceptsExtract Inline Schemas

Extract inline schemas

We have experimental support for “extracting inline schemas” behind the --extract-inline-schemas / OPENAPI_EXTRACT_INLINE_SCHEMAS=true configuration flag.

What does this mean?

@@ -184,4 +184,4 @@

})

This can be a handy trick to make the code generated from schemas you don’t own/control easier to work with. In general you should prefer to improve the specifications to be more suitable for code generation, which generally also improves -the result of documentation tools like Redoc

Authenticated Input SpecificationsServers Object Handling
\ No newline at end of file +the result of documentation tools like Redoc

Authenticated Input SpecificationsServers Object Handling
\ No newline at end of file diff --git a/guides/concepts/servers-object-handling.html b/guides/concepts/servers-object-handling.html index a8ef7079..5d70df6e 100644 --- a/guides/concepts/servers-object-handling.html +++ b/guides/concepts/servers-object-handling.html @@ -1,4 +1,4 @@ -Guide to servers object handling – OpenAPI Code Generator
GuidesConceptsServers Object Handling

Guide to servers object handling

+Guide to servers object handling – OpenAPI Code Generator
GuidesConceptsServers Object Handling

Guide to servers object handling

OpenAPI 3 has a servers property that can be used to define the base url for the whole document, or specific operations. This guide aims to explain how this is processed.

You can find the specifications definition of the servers object here

@@ -74,4 +74,4 @@ 

--enable-typed-base-paths=false

When disabled basePath: string parameters will still be added to operations that have a servers override, but no code based on the url or variables will be generated.

-

See also CLI reference

Extract Inline SchemasTypeScript Angular
\ No newline at end of file +

See also CLI reference

Extract Inline SchemasTypeScript Angular
\ No newline at end of file diff --git a/guides/server-templates/typescript-koa.html b/guides/server-templates/typescript-koa.html index eba5d479..d15fc365 100644 --- a/guides/server-templates/typescript-koa.html +++ b/guides/server-templates/typescript-koa.html @@ -1,4 +1,4 @@ -Using the typescript-koa template – OpenAPI Code Generator
GuidesServer TemplatesTypeScript Koa

Using the typescript-koa template

+Using the typescript-koa template – OpenAPI Code Generator
GuidesServer TemplatesTypeScript Koa

Using the typescript-koa template

The typescript-koa template outputs scaffolding code that handles the following:

  • Building a @koa/router instance with all routes in the openapi specification
    • @@ -162,4 +162,4 @@

    message: "internal server error", } satisfies t_Error } -}

TypeScript FetchUse with React Query
\ No newline at end of file +}
TypeScript FetchUse with React Query
\ No newline at end of file diff --git a/guides/use-with-react-query.html b/guides/use-with-react-query.html index 785872b9..111a1cda 100644 --- a/guides/use-with-react-query.html +++ b/guides/use-with-react-query.html @@ -1,4 +1,4 @@ -Using with tanstack react-query – OpenAPI Code Generator
GuidesUse with React Query

Using with tanstack react-query

+Using with tanstack react-query – OpenAPI Code Generator
GuidesUse with React Query

Using with tanstack react-query

Tanstack Query is a popular data fetching library for react applications. We don’t offer any out the box integration with it (yet), but it does integrate easily with our generated client SDKs.

Here’s a basic example implementation. It’s not perfect, but it should give you a good starting point.

@@ -163,4 +163,4 @@

<button onClick={() => doUpdate.mutate("123", {title: "new title"})}/> </div> } -

TypeScript KoaCLI Options
\ No newline at end of file +
TypeScript KoaCLI Options
\ No newline at end of file diff --git a/index.html b/index.html index d363f7bc..0742a12e 100644 --- a/index.html +++ b/index.html @@ -1 +1 @@ -OpenAPI Code Generator
\ No newline at end of file +OpenAPI Code Generator
\ No newline at end of file diff --git a/overview/about.html b/overview/about.html index 346183f0..ae4028d3 100644 --- a/overview/about.html +++ b/overview/about.html @@ -1,4 +1,4 @@ -Welcome – OpenAPI Code Generator
OverviewAbout

Welcome

+Welcome – OpenAPI Code Generator
OverviewAbout

Welcome

@nahkies/openapi-code-generator is a CLI tool that aims to generate high quality typescript client SDK’s, and API server scaffolding (routing, validation, serialization) from OpenAPI 3 specifications.

Currently, OpenAPI 3.0, OpenAPI 3.1, and TypeSpec are supported an input specifications.

@@ -49,4 +49,4 @@

Tackles the program space from both ends - client and server, for a single source of truth
  • Comprehensive runtime parsing/validation in addition to static compile time safety
    • -

    So if you want a low risk, write-once, get strong build & runtime guarantees experience then we’re worth giving a try.

    Schema-first design

    \ No newline at end of file +

    So if you want a low risk, write-once, get strong build & runtime guarantees experience then we’re worth giving a try.

    Schema-first design
    \ No newline at end of file diff --git a/overview/compatibility.html b/overview/compatibility.html index 8eb9f03b..ffd85811 100644 --- a/overview/compatibility.html +++ b/overview/compatibility.html @@ -1,4 +1,4 @@ -Compatibility Tables – OpenAPI Code Generator
    OverviewCompatibility

    Compatibility Tables

    +Compatibility Tables – OpenAPI Code Generator
    OverviewCompatibility

    Compatibility Tables

    This page aims to document which parts of the openapi 3.1.0 specification is supported. It may not be totally complete / accurate, but it should be broadly correct and give you an understanding of what does / doesn’t work.

    @@ -117,4 +117,4 @@

    AttributeSupportedNotesauthorizationUrl🚫tokenUrl🚫refreshUrl🚫scopes🚫

    Security Requirement Object - Patterned Fields

    The security requirement object is completely unsupported.

    -
    AttributeSupportedNotes
    \{name\}🚫
    Schema-first designRoadmap
    \ No newline at end of file +
    AttributeSupportedNotes
    \{name\}🚫
    Schema-first designRoadmap
    \ No newline at end of file diff --git a/overview/roadmap.html b/overview/roadmap.html index 4b0770e6..79f84064 100644 --- a/overview/roadmap.html +++ b/overview/roadmap.html @@ -1,4 +1,4 @@ -Roadmap – OpenAPI Code Generator
    OverviewRoadmap

    Roadmap

    +Roadmap – OpenAPI Code Generator
    OverviewRoadmap

    Roadmap

    This is a very loosely ordered view of known things that are planned in the roadmap. It’s probably not exhaustive.

    Near-term - “Sometime in the next 6 months”

    These are broadly speaking the known blockers to doing the first v1 release.

    @@ -47,4 +47,4 @@

    $request.path.id

    Whilst interesting, it’s also uncommon - currently there isn’t a single usage of this feature in the specifications we use for our integration tests.

    ref: https://spec.openapis.org/oas/v3.1.1.html#link-object

    Support callbacks

    The callbacks field of an operation is similar to the links response object, in that it provides a way to specify callbacks related to an operation.

    Much like links, it’s uncommon to see this used in practice, without a single callbacks -object defined in any specifications we see.

    ref: https://spec.openapis.org/oas/v3.1.1.html#callback-object

    CompatibilityQuick Start
    \ No newline at end of file +object defined in any specifications we see.

    ref: https://spec.openapis.org/oas/v3.1.1.html#callback-object

    CompatibilityQuick Start
    \ No newline at end of file diff --git a/overview/schema-first-design.html b/overview/schema-first-design.html index 990b1ac2..cd9ffaf8 100644 --- a/overview/schema-first-design.html +++ b/overview/schema-first-design.html @@ -1,4 +1,4 @@ -Why schema first – OpenAPI Code Generator
    OverviewSchema-first design

    Why schema first

    +Why schema first – OpenAPI Code Generator
    OverviewSchema-first design

    Why schema first

    Broadly speaking there are two approaches people take to maintaining API specifications:

    • Schema first, where you write the schema by hand
      • @@ -32,4 +32,4 @@

      Generating a good specification from your code, therefore requires including all this extra metadata in the code, which can make the code more difficult to work with.

      -

      We prefer to separate these concerns out into the specification, and keep the implementation code leaner and simpler.

      AboutCompatibility

    \ No newline at end of file +

    We prefer to separate these concerns out into the specification, and keep the implementation code leaner and simpler.

    AboutCompatibility
    \ No newline at end of file diff --git a/reference/cli-options.html b/reference/cli-options.html index d8b2ea66..49d9421f 100644 --- a/reference/cli-options.html +++ b/reference/cli-options.html @@ -1,4 +1,4 @@ -CLI Options – OpenAPI Code Generator
    ReferenceCLI Options

    CLI Configuration Reference

    +CLI Options – OpenAPI Code Generator
    ReferenceCLI Options

    CLI Configuration Reference

    All CLI options can be provided as command-line parameters, or environment variables as you prefer.

    Generate

    The default action is to run code generation.

    @@ -107,4 +107,4 @@

    See authenticated-input-specifications guide for details of how to use.

    -h, --help

    -

    Displays help text for command

    Use with React QueryRelease Notes
    \ No newline at end of file +

    Displays help text for command

    Use with React QueryRelease Notes
    \ No newline at end of file diff --git a/reference/release-notes.html b/reference/release-notes.html index c7d06c81..b5f675c2 100644 --- a/reference/release-notes.html +++ b/reference/release-notes.html @@ -1,4 +1,4 @@ -Release notes – OpenAPI Code Generator
    ReferenceRelease Notes

    Release notes

    +Release notes – OpenAPI Code Generator
    ReferenceRelease Notes

    Release notes

    💡

    This page is statically generated from the Github releases, and may sometimes be slightly out of date.

    2 Nov 2024 (v0.16.0)

    Client class exports will now be given unique names generated from the input specifications info.title field. This can additionally be overridden through a new cli arg --override-specification-title.

    The previous generic exports are kept for backwards compatibility.

    POTENTIALLY BREAKING: Filenames generated from tags or route prefixes will now follow kebab-case naming convention by default. This can be customized to other conventions like camel-case, etc using --filename-convention

    Features

    Full Changelog: https://github.com/mnahkies/openapi-code-generator/commits/v0.1.0

    CLI Options
    \ No newline at end of file +

    Full Changelog: https://github.com/mnahkies/openapi-code-generator/commits/v0.1.0

    CLI Options
    \ No newline at end of file