Emitter usage
Emitter usage
Section titled âEmitter usageâ- Via the command line
tsp compile . --emit=@typespec/openapi3- Via the config
emit: - "@typespec/openapi3"The config can be extended with options as follows:
emit: - "@typespec/openapi3"options: "@typespec/openapi3": option: valueEmitter options
Section titled âEmitter optionsâemitter-output-dir
Section titled âemitter-output-dirâType: absolutePath
Defines the emitter output directory. Defaults to {output-dir}/@typespec/openapi3
See Configuring output directory for more info
file-type
Section titled âfile-typeâType: string,array
If the content should be serialized as YAML or JSON. Can be a single value or an array to emit multiple formats. Default âyamlâ, if not specified infer from the output-file extension
output-file
Section titled âoutput-fileâType: string
Name of the output file. Output file will interpolate the following values:
- service-name: Name of the service
- service-name-if-multiple: Name of the service if multiple
- version: Version of the service if multiple
- file-type: The file type being emitted (json or yaml). Useful when
file-typeis an array.
Default: {service-name-if-multiple}.{version}.openapi.yaml or .json if file-type is "json"
When file-type is an array: {service-name-if-multiple}.{version}.openapi.{file-type}
Example Single service no versioning
openapi.yaml
Example Multiple services no versioning
openapi.Org1.Service1.yamlopenapi.Org1.Service2.yaml
Example Single service with versioning
openapi.v1.yamlopenapi.v2.yaml
Example Multiple service with versioning
openapi.Org1.Service1.v1.yamlopenapi.Org1.Service1.v2.yamlopenapi.Org1.Service2.v1.0.yamlopenapi.Org1.Service2.v1.1.yaml
openapi-versions
Section titled âopenapi-versionsâType: array
new-line
Section titled ânew-lineâType: "crlf" | "lf"
Set the newline character for emitting files.
omit-unreachable-types
Section titled âomit-unreachable-typesâType: boolean
Omit unreachable types. By default all types declared under the service namespace will be included. With this flag on only types references in an operation will be emitted.
include-x-typespec-name
Section titled âinclude-x-typespec-nameâType: "inline-only" | "never"
If the generated openapi types should have the x-typespec-name extension set with the name of the TypeSpec type that created it.
This extension is meant for debugging and should not be depended on.
safeint-strategy
Section titled âsafeint-strategyâType: "double-int" | "int64"
How to handle safeint type. Options are:
double-int: Will producetype: integer, format: double-intint64: Will producetype: integer, format: int64
Default: int64
seal-object-schemas
Section titled âseal-object-schemasâType: boolean
If true, then for models emitted as object schemas we default additionalProperties to false for
OpenAPI 3.0, and unevaluatedProperties to false for OpenAPI 3.1, if not explicitly specified elsewhere.
Default: false
experimental-parameter-examples
Section titled âexperimental-parameter-examplesâType: "data" | "serialized"
Determines how to emit examples on parameters. Note: This is an experimental feature and may change in future versions. See https://spec.openapis.org/oas/v3.0.4.html#style-examples for parameter example serialization rules See https://github.com/OAI/OpenAPI-Specification/discussions/4622 for discussion on handling parameter examples.
operation-id-strategy
Section titled âoperation-id-strategyâType: undefined
enum-strategy
Section titled âenum-strategyâType: "default" | "annotated"
How to emit TypeSpec enums. Options are:
default: Emit as a single schema using theenumkeyword.annotated: Emit as aoneOfofconstsubschemas annotated withtitleanddescriptionfrom each memberâs@summaryand@doc. Follows the OpenAPI 3.1.1 annotated enumerations pattern. Only supported by OpenAPI 3.1.0 and above; on 3.0.0 thedefaultstyle is used and a warning is reported.