feat: support OpenAPI 3.2 itemSchema (SSE/streaming)

[dkachur1]

Summary

Adds support for the itemSchema field introduced in OpenAPI 3.2, which defines the shape of individual
items in streaming responses (e.g. text/event-stream, application/x-ndjson).

• MediaTypeObject type now includes itemSchema
• When itemSchema is present, it takes precedence over schema for type generation

Design note: itemSchema vs schema coexistence

The spec allows both schema (complete payload) and itemSchema (per-item) on the same media type object. For type generation, we prefer itemSchema when present because it
describes what consumers actually parse per event/chunk. This is a deliberate trade-off — see spec reference
for details.

Example

responses:
  "200":
    content:
      text/event-stream:
        itemSchema:
          oneOf:
            - type: object
              properties:
                type: { type: string, enum: [content] }
                text: { type: string }
              required: [type, text]
            - type: object
              properties:
                type: { type: string, enum: [done] }
              required: [type]

Generates:

"text/event-stream": {
    type: "content";
    text: string;
} | {
    type: "done";
};

Limitations

- @redocly/openapi-core v1 does not support OpenAPI 3.2 linting, so full 3.2 document support via CLI requires a separate Redocly v2 upgrade (future PR). The itemSchema transform
itself works regardless of spec version.

[netlify]

👷 Deploy request for openapi-ts pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	8c6c20f

[changeset-bot]

🦋 Changeset detected

Latest commit: 8c6c20f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openapi-typescript	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[gzm0]

Relevant section in the OpenAPI spec: https://spec.openapis.org/oas/v3.2.0.html#complete-vs-streaming-content

@drwpow I'd like your input on this one: It seems that schema / itemSchema are complementary (setting both is allowed; the evaluation semantics are different). So removing schema and flattening itemSchema outright might not be our best call: Essentially the information of if it is itemSchema or schema is lost (and the spec is not comprehensive on what a sequential media type is).

@dkachur1 congrats on your first OSS contribution! For the first review iteration, I have some higher level comments for you:

• From the code it might not seem like it, but this is quite a significant adjustment. For these, it can often make sense to discuss the higher level plan in an issue first to avoid duplicate work (essentially what's the PR description here). This comment is for next time; at this point, we might as well iterate over the PR itself.
• It seems that there are a lot of secondary improvements in this PR (renames, redocly fixes, etc.). Even if the fixes are necessary to enable what this PR is trying to achieve, it is usually best to keep each PR hyper focused and split these changes out to separate PRs (have a look here: https://google.github.io/eng-practices/review/developer/small-cls.html; CL is Google's term for PR). Maybe this is something you can already start and do? (a fix is also much more likely to be merged fast than a feature like this).

Hope that helps. LMK if you have questions>

[gzm0]

Requesting changes as per last comment.

[dkachur1]

@gzm0 Thanks for the feedback! I've reverted the Redocly 2.0 migration and kept the changes minimal. Updated the description to address the points you raised. Most of the diff is in tests, let me know if any should be cut. Happy to revisit schema / itemSchema if you have thoughts on the right approach!