You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat!: migrate to @openapi-spec types and target OpenAPI 3.2 with a version option (#1998)
Replaces `json-schema-typed` and `@hey-api/spec-types` with
`@openapi-spec/types`, so `JsonSchema` is the OpenAPI 3.2 Schema Object
and `@orpc/openapi` re-exports the `OpenAPIV3_0`, `OpenAPIV3_1`, and
`OpenAPIV3_2` namespaces. `OpenAPIGenerator` now builds OpenAPI 3.2
documents and takes a `version` option that downgrades to 3.1 or 3.0
through `@openapi-spec/downgrader`, with the return type following the
requested version.
## Breaking changes
- `generate()` emits `3.2.0` by default (was `3.1.2`). Pass `version:
'3.1.2'` to keep 3.1 documents. `base` no longer accepts `openapi`.
- `OpenAPIDocument` requires a version argument;
`OpenAPIDocument<OpenAPIVersion>` is the union of every supported
document. `OpenAPIOperationObject` is replaced by
`OpenAPIV3_2.OperationObject`.
- `JsonSchemaKeywords` is derived from the 3.2 Schema Object, so legacy
keywords such as `additionalItems` are no longer part of it.
## Behavior
- Any `3.0.x`, `3.1.x`, or `3.2.x` `version` is accepted. The minor
version selects the conversion and the document carries the exact
requested value.
- Everything authored (`base`, `openapi({ spec })`, converter output)
stays OpenAPI 3.2 and is downgraded with the rest of the document, so
`type: ['string', 'null']` becomes `nullable: true` in 3.0 output.
- Downgrading runs before serialization: the serializer output is not
made of plain objects and the downgrader would pass it through
untouched.
- QUERY operations still require 3.2 and throw when an older version is
requested.
## Docs
- The specification page documents `version` in its own section, and the
v1 migration guide notes the new default.
## Testing
- Version tests compare whole output documents for `3.2.0`, `3.2.7`,
`3.1.2`, `3.1.0`, `3.0.4`, and `3.0.0`, with type tests for the
version-dependent return type.
- Root type check, lint, the docs JSDoc backlink checker, and both
package builds pass.
- The `oo` helper (`oo.spec`) was removed. To customize the operation object, attach [`openapi({ spec })` metadata](/docs/openapi/specification#customizing-the-operation-object) directly on the procedure or router.
1026
1026
- The `shouldHoistDef` option was replaced by [`customComponentName`](/docs/openapi/specification#hoisting-defs). Root `$defs` are now always hoisted into `components.schemas`; this option only renames them.
1027
+
- Documents are generated as OpenAPI 3.2.0 by default. Pass [`version: '3.1.1'`](/docs/openapi/specification#openapi-version) to keep old behavior.
Copy file name to clipboardExpand all lines: apps/content/docs/openapi/specification.mdx
+15-8Lines changed: 15 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: "OpenAPI Specification"
3
-
description: "Learn how to configure openapi metadata and generate OpenAPI 3.1 documents from your oRPC contracts and routers with OpenAPIGenerator."
3
+
description: "Learn how to configure openapi metadata and generate OpenAPI 3.2, 3.1, or 3.0 documents from your oRPC contracts and routers with OpenAPIGenerator."
4
4
---
5
5
6
6
## Metadata
@@ -38,7 +38,7 @@ For routing metadata, you can learn more in [OpenAPI Routing](/docs/openapi/rout
38
38
39
39
### Customizing the Operation Object
40
40
41
-
Use `spec` to customize the generated operation object. If `spec` is an object, it replaces the generated operation object entirely. If `spec` is a callback, it receives the final operation object and returns an extended version.
41
+
Use `spec` to customize the generated operation object. If `spec` is an object, it replaces the generated operation object entirely. If `spec` is a callback, it receives the final operation object and returns an extended version. The operation object always follows OpenAPI 3.2, whatever [version](#openapi-version) you generate.
42
42
43
43
```ts
44
44
const getPlanet =oc
@@ -131,7 +131,7 @@ In this example, the final `tags` is `undefined`, so no tags are applied to `exa
131
131
132
132
## OpenAPI Generator
133
133
134
-
`OpenAPIGenerator`accepts either a [contract](/docs/contract/router) or a [router](/docs/router)and generates an OpenAPI 3.1 document by default. OpenAPI 3.2 is partially supported.
134
+
`OpenAPIGenerator`turns a [contract](/docs/contract/router) or a [router](/docs/router)into an OpenAPI document.
135
135
136
136
```ts
137
137
import { OpenAPIGenerator } from'@orpc/openapi'
@@ -141,6 +141,7 @@ const generator = new OpenAPIGenerator({
`base` provides the OpenAPI 3.2 document fields to start from, such as `info`, `servers`, or `components`. The `openapi` field comes from `version`.
157
158
158
-
If your router contains a procedure that uses the `QUERY` method, explicitly set the OpenAPI version to `3.2.0`, because OpenAPI 3.1 does not support `QUERY`.
159
+
### OpenAPI Version
160
+
161
+
`version` selects the OpenAPI version, `3.2.0` by default. Any `3.0.x`, `3.1.x`, or `3.2.x` value works.
159
162
160
163
```ts
161
164
const spec =awaitgenerator.generate(router, {
162
-
base: {
163
-
openapi: '3.2.0',
164
-
},
165
+
version: '3.0.4',
165
166
})
166
167
```
167
168
169
+
The document is always built as OpenAPI 3.2, so `base`, [`openapi({ spec })`](#customizing-the-operation-object), and every JSON schema follow 3.2. Older versions come from downgrading the whole document with [`@openapi-spec/downgrader`](https://github.com/middleapi/openapi-spec/blob/main/packages/downgrader/README.md), which converts what the older version can still express and removes the rest.
170
+
171
+
:::warning
172
+
`QUERY` operations require OpenAPI 3.2. Generating an older version from a router with a `QUERY` procedure throws.
173
+
:::
174
+
168
175
### Json Schema Converters
169
176
170
177
`OpenAPIGenerator` relies on JSON Schema converters to translate your input, output, and error schemas into JSON Schemas. oRPC provides dedicated converters through the [Zod](/docs/integrations/zod), [Valibot](/docs/integrations/valibot), and [ArkType](/docs/integrations/arktype) integrations:
0 commit comments