fix: include body schema in OpenAPI docs when parse is 'none'

[kaigritun]

Summary

Fixes #1720

When using parse: 'none' to preserve raw request bodies, the body schema was being omitted from generated OpenAPI documentation.

Problem

The issue was in the content type switch statement in src/openapi.ts. When parse: 'none' is set:

1. hooks.parse exists (the array contains the 'none' parser)
2. The code enters the if (hooks.parse) branch
3. The for loop iterates through parsers
4. parser.fn === 'none' doesn't match any case in the switch
5. content remains an empty object {}
6. operation.requestBody.content is set to empty

Solution

Added a case 'none': that includes all common content types (application/json, application/x-www-form-urlencoded, multipart/form-data, text/plain) since the raw body could be any format.

Testing

Added test case that verifies body schema is included when parse: 'none' is set.

it('include body schema when parse is "none"', () => {
    const app = new Elysia().post(
        '/echo',
        ({ request }) => request,
        {
            body: t.Object({ input: t.String() }),
            parse: 'none'
        }
    )
    // ... validates requestBody.content['application/json'] exists
})

Summary by CodeRabbit

• New Features

  • Improved OpenAPI schema generation to support all common content types (application/json, application/x-www-form-urlencoded, multipart/form-data, text/plain) when the 'none' parser option is used.

• Tests

  • Added test coverage for the enhanced 'none' parser behavior in OpenAPI schema generation.

[coderabbitai]

Walkthrough

The PR adds support for the 'none' parse option in OpenAPI schema generation. When a request body specifies parse: 'none', the schema is now included across all common content types (JSON, form-encoded, multipart, and text plain) instead of being omitted from the OpenAPI spec.

Changes

Cohort / File(s)	Summary
OpenAPI 'none' Parser Support src/openapi.ts, test/openapi/to-openapi-schema.test.ts	Added new conditional case for parse: 'none' in request body content type handling to populate all common content types with the body schema. Includes test case verifying that requestBody with application/json content is correctly generated when parse is 'none'.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related issues

• Bug: parse: "none" omits body schema from OpenAPI docs elysia#1720: Directly addresses the missing OpenAPI schema generation for parse: 'none' by implementing the required content type population logic.

Poem

🐰 No parse means all ways to play,
Content types dance and sway,
JSON, forms, and plaintext too—
Schema flows through, shining new! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: fixing a bug where body schemas were omitted from OpenAPI docs when using parse 'none', which directly corresponds to the code changes in src/openapi.ts and test additions.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[pae-blue]

Hey! We're hitting the same root cause with parse: 'arrayBuffer' — filed as elysiajs/elysia#1825.

Would it make sense to also handle arrayBuffer in this PR? Or a general fallback for any unmatched parse mode so this class of bug can't recur. Happy to open a separate PR if you'd prefer to keep this one scoped to none. Thanks for working on this!