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.
Required Parameters
-i --input <value>
As environment variable OPENAPI_INPUT
Path to the input specification to generate from. Either a local path, or a url may be provided, though not all specifications will build correctly from a url.
By default, this must be a OpenAPI 3.0 (opens in a new tab) or OpenAPI 3.1 (opens in a new tab)
specification, in either YAML
or JSON
format.
When used in conjunction with --input-type typespec
then a TypeSpec (opens in a new tab) specification can be
supplied instead.
-o --output <value>
As environment variable OPENAPI_OUTPUT
directory to output generated code (env: )
-t --template <value>
As environment variable OPENAPI_TEMPLATE
Which template you wish to generate, one of:
Optional Parameters
--input-type <value>
As environment variable OPENAPI_INPUT_TYPE
What type of input file is being provided, one of:
openapi3
(default)typespec
-s --schema-builder <value>
As environment variable OPENAPI_SCHEMA_BUILDER
Which runtime schema parsing library to use, one of:
zod
(default)joi
--grouping-strategy <value>
(experimental)
As environment variable OPENAPI_GROUPING_STRATEGY
Strategy to use for splitting output into separate files. Set to none for a single generated.ts
file, one of:
none
don't split output, yield singlegenerated.ts
(default)first-tag
group operations based on their firsttag
first-slug
group operations based on their first route slug/segment
--enable-runtime-response-validation
(experimental)
As environment variable OPENAPI_ENABLE_RUNTIME_RESPONSE_VALIDATION
Controls whether to validate response bodies using the chosen runtime schema library.
Default false
Note: this is currently always true
for server templates, and only applies to the client library templates.
--enable-typed-base-paths
(client sdks only)
As environment variable OPENAPI_ENABLE_TYPED_BASE_PATHS
Controls whether to generate a union-type of string literals + string
from the openapi specifications
array of server urls. Handy for intellisense.
Default: true
--extract-inline-schemas
(experimental)
As environment variable OPENAPI_EXTRACT_INLINE_SCHEMAS
Generate names based on usage, and extract in-line schemas to be standalone types / schemas in the
generated code. This is especially useful when dealing with input schemas that don't make good use
of named $ref
's.
Default false
--allow-unused-imports
As environment variable OPENAPI_ALLOW_UNUSED_IMPORTS
Allow unused imports to be emitted in generated code. Offered as an escape hatch if any bugs in the unused-import elimination occur.
Default false
--ts-allow-any
As environment variable OPENAPI_TS_ALLOW_ANY
Determines whether to use any
or unknown
when generating types for schemas that don't have
concrete definitions. Eg: additionalProperties: true
or {}
schemas.
Using unknown
will push you towards using type guards / making runtime checks before interacting
with the model and should generally result in more robust code, whilst any
may be more convenient
during rapid prototyping.
Default: false
(use unknown
rather than any
)
Input schema | --ts-allow-any | (default) |
---|---|---|
{} | any | unknown |
{additionalProperties: true} | any | unknown |
{additionalProperties: false} | { [key: string]: never } | { [key: string]: never } |
{type: "object", additionalProperties: true} | {[key: string]: any} | {[key: string]: unknown} |
{type: "array", items: {}} | any[] | unknown[] |
Misc
--remote-spec-request-headers
(authenticated remote specifications)
As environment variable OPENAPI_REMOTE_SPEC_REQUEST_HEADERS
Allows providing request headers to use when fetching remote specifications. This allows for running generation against remote sources that require authentication.
Common examples include private github repositories (opens in a new tab), urls secured by an authenticating proxy like GCP IAP Proxy (opens in a new tab), or just generally authenticated servers
We strongly recommend using the environment variable variant of this option
(OPENAPI_REMOTE_SPEC_REQUEST_HEADERS
), as values for this option will likely include secrets, and it
is best to keep these out of your shell history.
The format of the value is a JSON object keyed by URI, with values being either an object,
or array of {name, value}
pairs. As a typescript type:
type value = {
[uri: string]: { name: string, value: string }[] | { name: string, value: string }
}
For example:
{
"https://example.com": [
{"name": "X-Client-Id", "value": "my-client-id"},
{"name": "X-Client-Secret", "value": "some-secret-value"}
],
"https://example.org/some/path": {"name": "Proxy-Authorization", "value": "some token"}
}
A 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 (opens in a new tab)" the headers would not
be sent for requests to other ports, resource paths, or protocols, but a less specific
uri like "https://example.com (opens in a new tab)" will send headers on any (https
) request to that domain.
Why JSON you ask? Simply put it has well defined semantics, and is easy to parse without fear of jumbling the pieces together.
Unfortunately it is a little annoying to formulate in shell scripts, so here's some examples to get you started
Using jq (opens in a new tab):
jq --null-input --compact-output \
--arg domain "https://example.com" \
--arg name "authorization" \
--arg value "secret value" '{$domain: {$name, $value}}'
Using nodejs (opens in a new tab):
node -p 'JSON.stringify({[process.argv[1]]: {name: process.argv[2], value: process.argv[3]}})' \
https://example.com \
authorization \
'some secret value'
Where typically in either example the values would be coming from shell variables, eg: storing a short-lived access token, etc.
-h, --help
Displays help text for command