[PR #5244] [MERGED] feat(kernel): extensible content media types #5124

New issue

Closed

opened 2026-03-17 02:35:59 +03:00 by kerem · 0 comments

kerem commented

2026-03-17 02:35:59 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hoppscotch/hoppscotch/pull/5244
Author: @CuriousCorrelation
Created: 7/15/2025
Status: ✅ Merged
Merged: 7/24/2025
Merged by: @jamesgeorge007

Base: next ← Head: feat-kernel-extensible-content-media-types

📝 Commits (2)

fe7a1e3 feat(kernel): extensible content media types
1c52a06 docs(kernel): exec guarantees of example object

📊 Changes

2 files changed (+174 additions, -25 deletions)

View changed files

📝 packages/hoppscotch-common/src/helpers/kernel/common/content.ts (+49 -6)
📝 packages/hoppscotch-kernel/src/relay/v/1.ts (+125 -19)

📄 Description

This makes content transformation system extensible by allowing custom media types alongside the predefined MediaType enum values and clarifies the distinction between content routing and HTTP headers.

Closes FE-910

The kind field controls content processing routing. Web mode with Axios completely ignores kind and relies on auto-detection. Desktop mode with relay uses kind to route to specific relay functions like set_json_content(), set_form_content(), set_binary_content() in the content handler. The mediaType field sets the HTTP Content-Type header in both environments regardless of which processing route is taken.

The content transformation system was too restrictive, only accepting specific MediaType enum values instead of flexible vendor-specific formats. More importantly tho, this clarifies fundamental distinction between kind and mediaType fields and their different purposes.

What's change

Updated all ContentType variant definitions to accept MediaType | string instead of restrictive enum unions. Made mediaType parameter optional in all content factory functions with sensible defaults. Added documentation explaining the routing vs header distinction and processor behavior for each content type.

Removed parseJSONAs<unknown>(body) validation from the JSON processor. The JSON processor now treats input as pre-stringified JSON text without validation, since validation belongs in upper layers, not the processor layer. Binary processor explains Blob to Uint8Array conversion with filename preservation. Form processors clarify URL-encoded vs multipart handling. Added examples section showing both new capabilities and backward compatibility patterns.

Implementation

The changes preserve full backward compatibility. Web mode with Axios ignores the kind field and relies on auto-detection, desktop mode with relay uses kind to route to specific processing fn(s). The mediaType field always sets the HTTP Content-Type header in both environments.

Custom formats now work. Vendor-specific JSON uses content.json({ data: { type: "users" } }, "application/vnd.api+json"). Pre-stringified JSON can be sent without encoding with content.text('{"escaped": "content"}', MediaType.APPLICATION_JSON). Custom XML schemas work with content.xml('soap:Envelope...</soap:Envelope>',
"application/soap+xml").

Notes to reviewers

This change affects both type definitions and some functional behavior but maintains backward compatibility for existing valid usage patterns.

All existing code continues to work exactly as before, but now supports custom media types with clearer understanding of the content system's design principles.

Testing should verify that existing content creation continues to work and new custom media types are accepted by the type system.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hoppscotch/hoppscotch/pull/5244 **Author:** [@CuriousCorrelation](https://github.com/CuriousCorrelation) **Created:** 7/15/2025 **Status:** ✅ Merged **Merged:** 7/24/2025 **Merged by:** [@jamesgeorge007](https://github.com/jamesgeorge007) **Base:** `next` ← **Head:** `feat-kernel-extensible-content-media-types` --- ### 📝 Commits (2) - [`fe7a1e3`](https://github.com/hoppscotch/hoppscotch/commit/fe7a1e38fe7cd54004f8c67e8a316eff138e8ebb) feat(kernel): extensible content media types - [`1c52a06`](https://github.com/hoppscotch/hoppscotch/commit/1c52a06c54ba9e9e7ad29697d270f1bc01a1e948) docs(kernel): exec guarantees of `example` object ### 📊 Changes **2 files changed** (+174 additions, -25 deletions) <details> <summary>View changed files</summary> 📝 `packages/hoppscotch-common/src/helpers/kernel/common/content.ts` (+49 -6) 📝 `packages/hoppscotch-kernel/src/relay/v/1.ts` (+125 -19) </details> ### 📄 Description This makes content transformation system extensible by allowing custom media types alongside the predefined `MediaType` enum values and clarifies the distinction between content routing and HTTP headers. Closes FE-910 The `kind` field controls content processing routing. Web mode with Axios completely ignores `kind` and relies on auto-detection. Desktop mode with relay uses `kind` to route to specific `relay` functions like `set_json_content()`, `set_form_content()`, `set_binary_content()` in the content handler. The `mediaType` field sets the HTTP Content-Type header in both environments regardless of which processing route is taken. The content transformation system was too restrictive, only accepting specific `MediaType` enum values instead of flexible vendor-specific formats. More importantly tho, this clarifies fundamental distinction between `kind` and `mediaType` fields and their different purposes. ### What's change Updated all `ContentType` variant definitions to accept `MediaType | string` instead of restrictive enum unions. Made `mediaType` parameter optional in all content factory functions with sensible defaults. Added documentation explaining the routing vs header distinction and processor behavior for each content type. Removed `parseJSONAs<unknown>(body)` validation from the `JSON` processor. The JSON processor now treats input as pre-stringified JSON text without validation, since validation belongs in upper layers, not the processor layer. Binary processor explains Blob to `Uint8Array` conversion with filename preservation. Form processors clarify URL-encoded vs multipart handling. Added examples section showing both new capabilities and backward compatibility patterns. ### Implementation The changes preserve full backward compatibility. Web mode with Axios ignores the kind field and relies on auto-detection, desktop mode with relay uses kind to route to specific processing fn(s). The mediaType field always sets the HTTP Content-Type header in both environments. Custom formats now work. Vendor-specific JSON uses content.json({ data: { type: "users" } }, "application/vnd.api+json"). Pre-stringified JSON can be sent without encoding with content.text('{"escaped": "content"}', MediaType.APPLICATION_JSON). Custom XML schemas work with content.xml('<soap:Envelope>...</soap:Envelope>', "application/soap+xml"). ### Notes to reviewers This change affects both type definitions and some functional behavior but maintains backward compatibility for existing valid usage patterns. All existing code continues to work exactly as before, but now supports custom media types with clearer understanding of the content system's design principles. Testing should verify that existing content creation continues to work and new custom media types are accepted by the type system. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>