Skip to content

[I] AutorestEmitterOptions

PropertyTypeDescription
arm-types-dir?stringPath to the common-types.json file folder. Default "${project-root}/../../common-types/resource-management"
azure-resource-provider-folder?stringDeprecated Do not use this option. Specify the path directly in emitter-output-dir.
emit-common-types-schema?"never" | "for-visibility-changes"Determines whether and how to emit schemas for common-types Default "for-visibility-changes"
emit-lro-options?"none" | "final-state-only" | "all"Determines whether and how to emit the x-ms-long-running-operation-options Default "final-state-only"
examples-dir?stringDirectory where the examples are located. Default {project-root}/examples
examples-directory?stringDeprecated use examples-dir
include-x-typespec-name?"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. Default "never"
new-line?"crlf" | "lf"Set the newline character for emitting files. Default lf
omit-unreachable-types?booleanOmit 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.
output-dir?stringDeprecated DO NOT USE. Use built-in emitter-output-dir instead
output-file?stringName of the output file. Output file will interpolate the following values: - service-name: Name of the service if multiple - version: Version of the service if multiple Default {emitter-output-dir}/{service-name}/{version-status}/{version}/openapi.json Examples Single service no versioning - openapi.yaml `Multiple services no versioning - `openapi.Org1.Service1.yaml` - `openapi.Org1.Service2.yaml Single service with versioning - openapi.v1.yaml-openapi.v2.yaml `Multiple service with versioning - `openapi.Org1.Service1.v1.yaml` - `openapi.Org1.Service1.v2.yaml` - `openapi.Org1.Service2.v1.0.yaml` - `openapi.Org1.Service2.v1.1.yaml azureResourceProviderFolder is provided - arm-folder/AzureService/preview/2020-01-01.yaml-arm-folder/AzureService/preview/2020-01-01.yaml“
output-splitting?"legacy-feature-files"Determines whether output should be split into multiple files. The only supported option for splitting is “legacy-feature-files”, which uses the typespec-azure-resource-manager @feature decorators to split into output files based on feature.
service-yaml?"never" | "auto" | "always"Controls emission of a service.yaml manifest (declaring the service’s API versions) at the project root, next to tspconfig.yaml. - "auto": Emit/update service.yaml only if the file already exists. (default) - "always": Always emit service.yaml. - "never": Never emit service.yaml. When an existing file is present it is updated in place, preserving comments and unrelated keys. Default "auto"
skip-example-copying?booleanWhen enabled, the emitter will not copy example files to the output directory. Instead, it will reference the source example files using relative file paths. Default false
type-name-strategy?"namespaced" | "name-only"Strategy for naming the OpenAPI names derived from TypeSpec types (definition/schema names, parameter keys, inline names, x-typespec-name, etc.). - "namespaced": Include the namespace prefix when a type lives outside the service namespace (e.g. LiftrBase.Foo). The service (and root TypeSpec) namespace is always stripped. This is the current/default behavior. - "name-only": Use only the type name without any namespace prefix (e.g. Foo). When two types from different namespaces collapse to the same name, the conflict is reported as an error (@typespec/openapi/duplicate-type-name). Default "namespaced"
use-read-only-status-schema?booleanDetermines whether to transmit the ‘readOnly’ property to lro status schemas. Default false
version?string-
version-enum-strategy?"omit" | "include"Decide how to deal with the Version enum when when omit-unreachable-types is not set. Default "omit"
xml-strategy?"none" | "xml-service"Strategy for applying XML serialization metadata to schemas. - “xml-service”: Apply XML serialization metadata for any service that uses the "application/xml" content type. - “none”: Do not apply any XML serialization metadata. Default "xml-service"